Design of response frame for multi-AP coordination in wireless LAN system

Abstract

The present disclosure relates to a design of a response frame for multi-access point (multi-AP) coordination in a wireless LAN system. According to an embodiment of the present disclosure, a method performed by a first access point (AP) configured to operate in a wireless LAN system comprises the steps of: establishing a coordination configuration for multi-AP coordination with one or more APs; transmitting a trigger frame for the multi-AP coordination to a second AP from among the one or more APs; and receiving a multi-STA block acknowledgement (BA) frame from the second AP, in response to the trigger frame, wherein a BA information field of the multi-STA BA frame comprises a per association identifier (AID) traffic identifier (TID) information subfield, and an AID TID information subfield of the per AID TID information subfield is set to a specific value on the basis that the multi-STA BA frame is related to the multi-AP coordination.

Description

Design of a response frame for multi-AP cooperation in a wireless LAN system

[0001] The present disclosure relates to the design of a response frame for multi-access point (multi-AP) coordination in a wireless LAN system.

[0002] Next-generation Wi-Fi (e.g., IEEE 802.11be and / or later) aims to support ultra-high reliability in signal transmission to STAs, and various technologies are being considered to support high throughput, low latency, and extended range.

[0003] For example, Radio Resource Management (RRM) technologies based on coordination between multiple APs have been proposed. For example, each AP can share information about its managed Basic Service Set (BSS) with neighboring APs, and based on this information, adjust channel selection, transmission timing, transmission power, and beamforming direction to minimize interference. This type of inter-AP cooperation technique can reduce transmission collisions, increase the efficiency of wireless resource utilization, and contribute to improving the overall quality of service (QoS) of the system in high-density network environments.

[0004] The present disclosure provides a method and device for designing a response frame for multi-AP cooperation in a wireless LAN system.

[0005] According to an embodiment of the present disclosure, a method performed by a first access point (AP) configured to operate in a wireless LAN system comprises the steps of: establishing a cooperation setting for multi-AP cooperation with one or more APs; transmitting a trigger frame for the multi-AP cooperation to a second AP among the one or more APs; and receiving a multi-STA (multi-STA) block acknowledgment (BA) frame in response to the trigger frame from the second AP, wherein a BA information field of the multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per (per AID TID) information subfield, and an AID TID information subfield of the AID TID per information subfield is set to a specific value based on that the multi-STA BA frame is related to the multi-AP cooperation.

[0006] According to an embodiment of the present disclosure, a method performed by a second access point (AP) configured to operate in a wireless LAN system comprises the steps of: establishing a cooperation setting for multi-AP cooperation with a first AP; receiving a trigger frame for the multi-AP cooperation from the first AP; and transmitting a multi-STA (multi-STA) block acknowledgment (BA) frame to the first AP in response to the trigger frame, wherein a BA information field of the multi-STA BA frame includes a per AID (association identifier) ​​TID (traffic identifier) ​​information subfield, and an AID TID information subfield of the per AID TID information subfield is set to a specific value based on that the multi-STA BA frame is related to the multi-AP cooperation.

[0007] In various embodiments, devices for implementing the above-described methods are provided.

[0008] The present disclosure may have various advantageous effects.

[0009] For example, SAP can perform more efficient multi-AP cooperation by using information contained in multiple STA BA frames transmitted from DAP(s).

[0010] The beneficial effects that can be achieved through specific embodiments of the present disclosure are not limited to the beneficial effects listed above. For example, various technical effects may be understood and / or derived from the present disclosure by those skilled in the art. Therefore, the specific effects of the present disclosure are not limited to those explicitly described herein, but may include various effects that can be understood or derived from the technical features of the present disclosure.

[0011] FIG. 1 illustrates an example of a transmitting device and / or a receiving device of the present disclosure.

[0012] Figure 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).

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

[0014] Figure 4 illustrates an embodiment of multi-link (ML).

[0015] FIG. 5 illustrates a modified example of a transmitting device and / or a receiving device of the present disclosure.

[0016] FIG. 6 illustrates an example of a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received by an STA of the present disclosure.

[0017] Figure 7 shows the operation according to UL-MU.

[0018] Figure 8 shows an example of a header of a MAC frame.

[0019] Figure 9 illustrates a trigger frame format. The trigger frame format may also be referred to as the structure of a trigger frame.

[0020] Figure 10 shows the frame format of the BlockAck frame.

[0021] Figure 11 shows the format of the BA control field.

[0022] Figure 12 shows the format of the BA information field of a multi-STA BlockAck frame.

[0023] Figure 13 shows the format of the AID TID information subfield.

[0024] Figure 14 shows the format of the AID TID specific information subfield when the AID11 subfield is not 2045.

[0025] Figure 15 shows the format of the block Ack start sequence control subfield.

[0026] Figure 16 shows an example of multi-AP operation based on Co-TDMA between APs.

[0027] FIG. 17 illustrates an example of a multi-AP negotiation procedure according to an embodiment of the present disclosure.

[0028] Figure 18 shows an example of a multi-AP selection procedure.

[0029] FIG. 19 illustrates an example of a method performed by a first AP for receiving a response frame for multi-AP cooperation according to various embodiments of the present disclosure.

[0030] FIG. 20 illustrates an example of a method performed by a second AP for transmitting a response frame for multi-AP cooperation according to various embodiments of the present disclosure.

[0031] FIG. 21 illustrates an example of a (UHR) control information subfield format according to an embodiment of the present disclosure.

[0032] FIG. 22 illustrates a first example of a multi-STA BA frame format including Co-TDMA related feedback information according to an embodiment of the present disclosure.

[0033] FIG. 23 illustrates a second example of a multi-STA BA frame format including Co-TDMA related feedback information according to an embodiment of the present disclosure.

[0034] FIG. 24 illustrates a third example of a multi-STA BA frame format including Co-TDMA related feedback information according to an embodiment of the present disclosure.

[0035] FIG. 25 illustrates a first example of a multi-STA BA frame format including Co-SR related feedback information according to an embodiment of the present disclosure.

[0036] FIG. 26 illustrates a second example of a multi-STA BA frame format including Co-SR related feedback information according to an embodiment of the present disclosure.

[0037] FIG. 27 illustrates a third example of a multi-STA BA frame format including Co-SR related feedback information according to an embodiment of the present disclosure.

[0038] FIG. 28 illustrates a first example of a multi-STA BA frame format including Co-BF related feedback information according to an embodiment of the present disclosure.

[0039] FIG. 29 illustrates a second example of a multi-STA BA frame format including Co-BF related feedback information according to an embodiment of the present disclosure.

[0040] FIG. 30 illustrates a third example of a multi-STA BA frame format including Co-BF related feedback information according to an embodiment of the present disclosure.

[0041] FIGS. 31A and 31B illustrate a fourth example of a multi-STA BA frame format including Co-BF related feedback information according to an embodiment of the present disclosure.

[0042] FIGS. 32a and 32b illustrate a fifth example of a multi-STA BA frame format including Co-BF related feedback information according to an embodiment of the present disclosure.

[0043] FIGS. 33a and 33b illustrate a sixth example of a multi-STA BA frame format including Co-BF related feedback information according to an embodiment of the present disclosure.

[0044] FIG. 34 illustrates a seventh example of a multi-STA BA frame format including Co-BF related feedback information according to an embodiment of the present disclosure.

[0045] FIGS. 35a and 35b illustrate an eighth example of a multi-STA BA frame format including Co-BF related feedback information according to an embodiment of the present disclosure.

[0046] FIG. 36 illustrates an example of an AID TID-specific information subfield format when the value of the AID11 subfield is 2045 according to an embodiment of the present disclosure.

[0047] FIG. 37 illustrates an example of transmitting a multi-STA BA frame to an ICR for MAPC by utilizing a specific value of the AID TID information subfield according to an embodiment of the present disclosure.

[0048] FIG. 38 illustrates an example of indicating whether to include an (UHR) control information field having a specific size based on a fragment number subfield according to an embodiment of the present disclosure.

[0049] FIG. 39 illustrates an example of a case where a multi-STA BA frame utilizes a specific value of a fragment number subfield to be transmitted from MAPC to ICR according to an embodiment of the present disclosure.

[0050] FIG. 40 illustrates an example of a MAPC participation reporting procedure based on a participation indication field according to an embodiment of the present disclosure.

[0051] In this disclosure, “A or B” can mean “only A,” “only B,” or “both A and B.” In other words, “A or B” in this disclosure can be interpreted as “A and / or B.” For example, “A, B or C” in this disclosure can mean “only A,” “only B,” “only C,” or “any combination of A, B, and C.”

[0052] As used herein, a slash ( / ) or a comma can mean "and / or." For example, "A / B" can mean "A and / or B." Accordingly, "A / B" can mean "only A," "only B," or "both A and B." For example, "A, B, C" can mean "A, B, or C."

[0053] In the present disclosure, “at least one of A and B” may mean “only A,” “only B,” or “both A and B.” Additionally, in the present disclosure, the expressions “at least one of A or B” or “at least one of A and / or B” may be interpreted identically to “at least one of A and B.”

[0054] In addition, parentheses used in the present disclosure may mean “for example.” Specifically, when “control information (UHR-Signal field)” is indicated, the “UHR-Signal field” may be suggested as an example of “control information.” In other words, the “control information” of the present disclosure is not limited to the “UHR-Signal field,” and the “UHR-Signal field” may be suggested as an example of “control information.” In addition, even when indicated as “control information (UHR-Signal field),” the “UHR-Signal field” may be suggested as an example of “control information.”

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

[0056] Additionally, the expressions “based on” or “on the basis of” or “according to” used in this disclosure mean “based at least in part on” and do not mean “based solely on.”

[0057] Technical features individually described in one drawing in this disclosure may be implemented individually or simultaneously.

[0058] The following examples of the present disclosure can be applied to various wireless communication systems. For example, the following examples of the present disclosure can be applied to a wireless local area network (WLAN) system. For example, the present disclosure can be applied to the IEEE 802.11a / g / n / ac / ax / be / bn standards. Furthermore, the examples of the present disclosure can be applied to the Ultra High Reliability (UHR) standard or a next-generation wireless LAN standard that enhances IEEE 802.11bn. Furthermore, the examples of the present disclosure can be applied to a mobile communication system. For example, the examples of the present disclosure can be applied to a mobile communication system based on the Long Term Evolution (LTE) standard and its evolution based on the 3rd Generation Partnership Project (3GPP) standard.

[0059] In order to explain the technical features of the present disclosure, technical features to which the present disclosure can be applied are described below.

[0060] FIG. 1 illustrates an example of a transmitting device and / or a receiving device of the present disclosure.

[0061] 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 the present disclosure may also be referred to by various names such as a mobile terminal, a wireless device, a Wireless Transmit / Receive Unit (WTRU), a User Equipment (UE), a Mobile Station (MS), a Mobile Subscriber Unit, or simply a user. The STA (110, 120) of the present disclosure may also be referred to by various names such as a network, a base station, a Node-B, an access point (AP), a repeater, a router, a relay, etc. The STA (110, 120) of the present disclosure may also be referred to by various names such as a receiving apparatus, a transmitting apparatus, a receiving STA, a transmitting STA, a receiving device, a transmitting device, etc.

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

[0063] The STA (110, 120) of the present disclosure can support various communication standards other than the IEEE 802.11 standard. For example, it can support communication standards according to the 3GPP standard (e.g., LTE, LTE-A, 5G NR standard). In addition, the STA of the present disclosure can be implemented in various devices such as a mobile phone, a vehicle, a personal computer, etc. In addition, the STA of the present disclosure can support communication for various communication services such as voice calls, video calls, data communications, and autonomous driving (Self-Driving, Autonomous-Driving).

[0064] In the present disclosure, STA (110, 120) may include a medium access control (MAC) and a physical layer interface for a wireless medium that follow the provisions of the IEEE 802.11 standard.

[0065] Based on the sub-drawing (a) of Fig. 1, STA (110, 120) is described as follows.

[0066] The first STA (110) may include a processor (111), a 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.

[0067] The transceiver (113) of the first STA performs signal transmission and reception operations. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be, etc.).

[0068] 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 transmission signal, and perform control for signal transmission. The memory (112) of the AP can store a signal received through the transceiver (113) (i.e., a reception signal) and store a signal to be transmitted through the transceiver (i.e., a transmission signal).

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

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

[0071] For example, in the specification below, the operation of a device indicated as AP may be performed in the first STA (110) or the second STA (120). For example, if the first STA (110) is an AP, the operation of the device indicated as AP may be controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (110). In addition, control information related to the operation of the AP or a transmission / reception signal of the AP may be stored in the memory (112) of the first STA (110). In addition, when the second STA (110) is an AP, the operation of the device indicated as an AP is controlled by the processor (121) of the second STA (120), and a related signal can 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 signal of the AP can be stored in the memory (122) of the second STA (110).

[0072] For example, in the specification below, the operation of a device indicated as a non-AP (or User-STA) may be performed in the STA (110) or the second STA (120). For example, if the second STA (120) is a non-AP, the operation of the device indicated as a non-AP may be controlled by the processor (121) of the second STA (120), and a related signal 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 non-AP or the transmission / reception signal 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 a device indicated as a non-AP is controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (120). In addition, control information related to the operation of the non-AP or the transmission / reception signal of the AP may be stored in the memory (112) of the first STA (110).

[0073] In the following specification, devices called (transmitting / receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting / receiving) Terminal, (transmitting / receiving) device, (transmitting / receiving) apparatus, network, etc. may refer to the STA (110, 120) of FIG. 1. For example, devices indicated as (transmitting / receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting / receiving) Terminal, (transmitting / receiving) device, (transmitting / receiving) apparatus, network, etc. without specific drawing symbols may also refer to the STA (110, 120) of FIG. 1. For example, in the example below, the operation of various STAs transmitting and receiving signals (e.g., PPPDU) may be performed by the transceiver (113, 123) of FIG. 1. In addition, in the example below, 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 processor (111, 121) of FIG. 1.For example, an example of an operation for generating a transmission / reception signal or performing data processing or operation in advance for a transmission / reception signal may include 1) an operation for determining / obtaining / configuring / computing / decoding / encoding bit information of a subfield (SIG, STF, LTF, Data) field included in a PPDU, 2) an operation for determining / configuring / obtaining time resources or frequency resources (e.g., subcarrier resources) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 3) an operation for determining / configuring / obtaining a specific sequence (e.g., a pilot sequence, an STF / LTF sequence, an extra sequence applied to SIG) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 4) a power control operation and / or a power saving operation applied to an STA, 5) an operation related to determining / obtaining / configuring / computing / decoding / encoding an ACK signal, etc. Additionally, in the examples below, various information (e.g., information related to fields / subfields / control fields / parameters / power, etc.) used by various STAs for determining / acquiring / configuring / computing / decoding / encoding transmission / reception signals can be stored in the memory (112, 122) of FIG. 1.

[0074] The device / STA of the sub-drawing (a) of FIG. 1 described above can be modified as in the sub-drawing (b) of FIG. 1. Hereinafter, the STA (110, 120) of the present disclosure will be described based on the sub-drawing (b) of FIG. 1.

[0075] For example, the transceiver (113, 123) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the transceiver illustrated in sub-drawing (a) of FIG. 1 described above. For example, the processing chip (114, 124) illustrated in sub-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) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the processor (111, 121) and the memory (112, 122) illustrated in sub-drawing (a) of FIG. 1 described above.

[0076] 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, Access Point (AP), 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) illustrated in the sub-drawings (a) / (b) of FIG. 1, or may refer to the processing chip (114, 124) illustrated in the sub-drawing (b) of FIG. 1. That is, the technical feature of the present disclosure may be performed in the STA (110, 120) illustrated in the sub-drawings (a) / (b) of FIG. 1, or may be performed only in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1. For example, the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal generated in the processor (111, 121) illustrated in the sub-drawings (a) / (b) of FIG. 1 is transmitted through the transceiver (113, 123) illustrated in the sub-drawings (a) / (b) of FIG. 1. Alternatively, the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal to be transmitted to the transceiver (113, 123) is generated in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1.

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

[0078] Referring to the sub-drawing (b) of FIG. 1, software code (115, 125) may be included in the 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.

[0079] The processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and / or a data processing device. 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 EXYNOS® 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 an enhanced processor thereof.

[0080] In the present disclosure, uplink may mean a link for communication from a non-AP STA to an AP STA, and uplink PPDU / packet / signal, etc. may be transmitted through the uplink. In addition, in the present disclosure, downlink may mean a link for communication from an AP STA to a non-AP STA, and downlink PPDU / packet / signal, etc. may be transmitted through the downlink.

[0081] Figure 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).

[0082] The upper part of Figure 2 shows the structure of the infrastructure BSS (basic service set) of IEEE (institute of electrical and electronic engineers) 802.11.

[0083] Referring to the top of FIG. 2, the wireless LAN system may include one or more infrastructure BSSs (200, 205) (hereinafter, BSS). The BSSs (200, 205) are a collection of APs and STAs, such as an access point (AP) 225 and a station (STA1, 200-1), that have successfully synchronized and can communicate with each other, and are not a concept that designates a specific area. The BSS (205) may also include one or more STAs (205-1, 205-2) that can be associated with one AP (230).

[0084] The BSS may include at least one STA, an AP (225, 230) providing a distribution service, and a distribution system (DS, 210) connecting multiple APs.

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

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

[0087] In a BSS such as the upper part 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 and perform communication between STAs without an AP (225, 230). A network that establishes a network and performs communication between STAs without an AP (225, 230) is defined as an ad-hoc network or an independent basic service set (IBSS).

[0088] The bottom of Figure 2 is a conceptual diagram showing IBSS.

[0089] 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 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 access to the distributed system is not permitted, forming a self-contained network.

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

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

[0092] Figure 3 illustrates a network discovery operation that includes an active scanning process as an example. In active scanning, an STA performing scanning transmits a probe request frame to discover which APs exist in the vicinity while moving between channels and waits for a response. A responder transmits a probe response frame to the STA that transmitted the probe request frame in response to the probe request frame. Here, the responder may be the STA that last transmitted a beacon frame in the BSS of the channel being scanned. In a BSS, the AP transmits the beacon frame, so the AP becomes the responder. In an IBSS, the STAs within the IBSS take turns transmitting beacon frames, so the responder is not constant. 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 (i.e., transmitting and receiving probe requests / responses on channel 2) in the same manner.

[0093] Although not shown in the example of FIG. 3, the scanning operation can also be performed in a passive scanning manner. An STA performing scanning based on passive scanning can wait for a beacon frame while moving between channels. A beacon frame is one of the management frames in IEEE 802.11. It announces the presence of a wireless network and is periodically transmitted so that the scanning STA can find the wireless network and participate in the wireless network. In the BSS, the AP periodically transmits the beacon frame, and in the IBSS, the STAs within the IBSS take turns transmitting the beacon frame. When the scanning STA receives a beacon frame, it stores the information about the BSS included in the beacon frame and moves to another channel, recording the beacon frame information on each channel. An STA that receives a beacon frame can store the BSS-related information included in the received beacon frame, move to the next channel, and perform scanning on the next channel in the same manner.

[0094] An STA that discovers a 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 below. The authentication process of S320 may include a process in which the STA transmits an authentication request frame to the AP, and the AP responds by transmitting an authentication response frame to the STA. The authentication frame used for the authentication request / response corresponds to a management frame.

[0095] The authentication frame may include information such as an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, a Robust Security Network (RSN), and a Finite Cyclic Group.

[0096] An STA can transmit an authentication request frame to an AP. The AP can determine whether to grant authentication to the STA based on the information contained in the received authentication request frame. The AP can provide the result of the authentication process to the STA via an authentication response frame.

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

[0098] 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 four-way handshaking using an Extensible Authentication Protocol over LAN (EAPOL) frame.

[0099] Figure 4 illustrates an example of a multi-link (ML).

[0100] As illustrated in FIG. 4, multiple multi-link devices (MLDs) can communicate over a remote link. The MLDs can be categorized into AP MLDs including multiple AP STAs and non-AP MLDs including multiple non-AP STAs. That is, the AP MLD can include affiliated APs (i.e., AP STAs), and the non-AP MLD can include affiliated STAs (i.e., non-AP STAs, or user-STAs).

[0101] A multilink may include a first link and a second link, and different channels / subchannels / frequency resources may be allocated to the first and second links. The first and second multilinks may be identified through 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 second link may be configured in different bands.

[0102] The AP MLD of FIG. 4 includes three affiliated APs. In the 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 the 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. Furthermore, in the 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. Furthermore, in the 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.

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

[0104] The specific features of the present disclosure 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.

[0105] FIG. 5 illustrates a modified example of a transmitting device and / or a receiving device of the present disclosure.

[0106] The devices (e.g., AP STA, non-AP STA) illustrated in FIGS. 1 to 4 may be modified as illustrated in FIG. 5. The transceiver (530) of FIG. 5 may be identical to the transceivers (113, 123) of FIG. 1. The transceiver (530) of FIG. 5 may include a receiver and a transmitter.

[0107] The processor (510) of FIG. 5 may be identical to the processor (111, 121) of FIG. 1. Alternatively, the processor (510) of FIG. 5 may be identical to the processing chip (114, 124) of FIG. 1.

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

[0109] Referring to FIG. 5, a power management module (511) manages power to a processor (510) and / or a transceiver (530). A battery (512) supplies power to the power management module (511). A display (513) outputs results processed by the processor (510). A keypad (514) receives input to be used by the processor (510). The keypad (514) may be displayed on the display (513). A SIM card (515) may be an integrated circuit used to securely store an international mobile subscriber identity (IMSI) and an associated key used to identify and authenticate a subscriber in a mobile phone device, such as a mobile phone or computer.

[0110] Referring to FIG. 5, the speaker (540) can output sound-related results processed by the processor (510). The microphone (541) can receive sound-related input to be used by the processor (510).

[0111] FIG. 6 illustrates an example of a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received by an STA of the present disclosure.

[0112] The STA (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) of the present disclosure can transmit and / or receive the PPDU of FIG. 6. The PPDU described in the present disclosure may have, for example, the structure of FIG. 6. In addition, the PPDU described in the present disclosure may be called by various names such as a transmission PPDU, a reception PPDU, a first type PPDU, or an Nth type PPDU, etc. The PPDU described in the present disclosure can be used in a WLAN system defined according to IEEE 802.11bn and / or a next-generation WLAN system that improves upon IEEE 802.11bn.

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

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

[0115] Each block illustrated in Fig. 6 may be called a field / subfield / signal, etc. The names of these fields / subfields / signals may be, as illustrated in Fig. 6, 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.

[0116] The subcarrier spacing of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields in FIG. 6 may be set to 312.5 kHz, and the subcarrier spacing of the UHR-STF, UHR-LTF, and Data fields may 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 may be expressed in units of 312.5 kHz, and the tone index (or subcarrier index) of the UHR-STF, UHR-LTF, and Data fields may be expressed in units of 78.125 kHz.

[0117] In the PPDU of Fig. 6, L-LTF and L-STF may be identical to conventional fields (e.g., non-HT LTF and non-HT STF defined in conventional WLAN standards).

[0118] The L-SIG field of FIG. 6 may include, 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 include information about 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 UHR PPDU, the value of the Length field may be determined as a multiple of 3. For example, if the PPDU is a 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, 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 an UHR PPDU is set to a value satisfying the condition that the remainder is zero when LENGTH is divided by 3.

[0119] For example, (non-AP and AP) STAs can apply BCC encoding based on a code rate of 1 / 2 to the 24 bits of information in the L-SIG field. Then, the transmitting STA can obtain 48 BCC coded bits. BPSK modulation can be applied to the 48 coded bits to generate 48 BPSK symbols. The transmitting STA can map the 48 BPSK symbols to positions excluding the pilot subcarriers {subcarrier index -21, -7, +7, +21} and the DC subcarrier {subcarrier index 0}. As a result, 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 {-1, -1, -1, 1} to the subcarrier indices {-28, -27, +27, +28}. The above signal can be used for channel estimation for the frequency domain corresponding to {-28, -27, +27, +28}.

[0120] For example, (non-AP and AP) STA can generate RL-SIG, which is generated in the same manner as L-SIG. BPSK modulation can be applied to RL-SIG. Receiving (non-AP and AP) STA can determine whether the received PPDU is a HE PPDU, EHT PPDU, or UHR PPDU based on the presence of RL-SIG. In other words, if RL-SIG is present, receiving (non-AP and AP) STA can determine whether the received PPDU is one of HE PPDU, EHT PPDU, or UHR PPDU. In other words, if RL-SIG is not present, receiving (non-AP and AP) STA can determine whether the received PPDU is one of non-HT PPDU, HT PPDU, or VHT PPDU. 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.

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

[0122] A U-SIG can contain N bits of information and can include information for identifying the type of EHT PPDU. For example, a U-SIG can be formed based on two symbols (e.g., two consecutive OFDM symbols). Each symbol (e.g., an OFDM symbol) for a U-SIG can have a duration of 4 microseconds. Each symbol of a U-SIG can be used to transmit 26 bits of information. For example, each symbol of a U-SIG can be transmitted and received based on 52 data tones and 4 pilot tones.

[0123] For example, A bit information (e.g., 52 uncoded bits) can be transmitted through U-SIG, and the first symbol of U-SIG can transmit the first X bits of information (e.g., 26 uncoded bits) out of the total A bit information, and the second symbol of U-SIG can transmit the remaining Y bits of information (e.g., 26 uncoded bits) out of the total A bit information. For example, the transmitting STA can obtain 26 uncoded bits included in each U-SIG symbol. The transmitting STA can perform convolutional encoding (i.e., BCC encoding) based on a rate of R=1 / 2 to generate 52 coded bits, and perform interleaving on the 52 coded bits. The transmitting STA can perform BPSK modulation on the interleaved 52 coded bits to generate 52 BPSK symbols allocated to each U-SIG symbol. 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. The 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.

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

[0125] The A bit information (e.g., 52 uncoded bits) transmitted by the 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 can be assigned only to the first symbol of the U-SIG, or the version-independent bits can be assigned to both the first symbol and the second symbol of the U-SIG. For example, the version-independent bits and the version-dependent bits can be called by various names, such as the first control bit and the second control bit.

[0126] For example, the version-independent bits of the 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 (e.g., a value of 000) of the 3-bit PHY version identifier may indicate that the transmitted and received PPDU is an EHT PPDU. In addition, a second value (e.g., a value of 001) of the 3-bit PHY version identifier may indicate that the transmitted and received PPDU is an UHR PPDU.

[0127] In other words, when the (AP / non-AP) STA transmits an EHT PPDU, it can set the 3-bit PHY version identifier to the first value. In other words, the 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 an UHR PPDU based on the PHY version identifier having the second value.

[0128] 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 relates to UL communication, and the second value of the UL / DL flag field relates to DL communication.

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

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

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

[0132] Preamble puncturing may be applied to the PPDU of FIG. 6. Preamble puncturing refers to applying puncturing to a portion of the entire bandwidth of the PPDU (e.g., the secondary 20 MHz band). For example, when an 80 MHz PPDU is transmitted, the STA may apply puncturing to the secondary 20 MHz band within the 80 MHz band, and transmit the PPDU only through the primary 20 MHz band and the secondary 40 MHz band.

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

[0134] 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.

[0135] 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 individually configured in units of 80 MHz. 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 about a 160 MHz bandwidth, and the second field of the second U-SIG may include information about preamble puncturing applied to the second 80 MHz band (i.e., information about a preamble puncturing pattern). Meanwhile, the UHR-SIG consecutive to the first U-SIG may include information about preamble puncturing applied to the second 80 MHz band (i.e., information about a preamble puncturing pattern), and the UHR-SIG consecutive to the second U-SIG may include information about preamble puncturing applied to the first 80 MHz band (i.e., information about a preamble puncturing pattern).

[0136] Additionally or alternatively, U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following methods. 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).

[0137] 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 can contain different U-SIGs.

[0138] The UHR-SIG of FIG. 6 may include control information for a receiving STA. The UHR-SIG may be transmitted via at least one symbol, and each 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.

[0139] UHR-SIG provides additional signals to the U-SIG field to enable STAs to interpret / decode UHR PPDUs. The UHR-SIG field may contain U-SIG overflow bits that are common to all users. The UHR-SIG field also contains resource allocation information, allowing STAs to look up resources used in fields containing data fields / UHR-STF / UHR-LTF (i.e., UHR modulated fields of an UHR PPDU).

[0140] The frequency resources of the UHR-LTF, UHR-STF, and data fields illustrated in FIG. 6 can be determined based on RUs (resource units) defined by multiple subcarriers / tones. That is, the UHR-LTF, UHR-STF, and data fields of the present disclosure can be transmitted / received through RUs (resource units) defined by multiple subcarriers / tones.

[0141] Figure 7 illustrates an operation according to UL-MU. As illustrated, a transmitting STA (e.g., AP) can acquire a TXOP (725) by performing channel access through contending (i.e., backoff operation) and transmit a trigger frame (730). That is, the transmitting STA (e.g., AP) can transmit a PPDU including a trigger frame (730). When a PPDU including a trigger frame is received, a TB (trigger-based) PPDU is transmitted after a delay of SIFS.

[0142] TB PPDUs (741, 742) are transmitted at the same time and can be transmitted from multiple STAs (e.g., User STAs) whose AIDs are indicated in the Trigger frame (730). The ACK frame (750) for the TB PPDU can be implemented in various forms. For example, the ACK frame (750) for the TB PPDU can be implemented in the form of a BA (block ACK).

[0143] In FIG. 7, transmission(s) of a Trigger Frame (730), a TB PPDU (741, 742) and / or an ACK frame (750) may be performed within a TXOP (725).

[0144] Below, we explain NAV (Network Allocation Vector).

[0145] When a Source (e.g., AP STA / non-AP STA) that wants to transmit data transmits an RTS (request to send) frame to a Destination (e.g., AP STA / non-AP STA) that receives the data, the Destination can notify surrounding terminals that it will receive the data by transmitting a CTS (clear to send) frame. In other words, the Destination designated as the receiver through the RTS frame can transmit a CTS frame. If the Source that transmitted the RTS frame receives the CTS frame, the Source can start transmitting data to the Destination.

[0146] Meanwhile, if an STA other than the Destination designated as the receiver through the RTS frame receives the RTS frame, or if an STA other than the Source that transmitted the RTS frame receives the CTS frame, the STA may set a network allocation vector (NAV). An STA that has set a NAV may not transmit data during the NAV period, thereby avoiding collisions between the STA and the Source / Destination. On the other hand, if the Destination designated as the receiver through the RTS frame receives the RTS frame, or if the Source that transmitted the RTS frame receives the CTS frame, the Source / Destination does not set a NAV.

[0147] If a CTS frame (e.g., PHY-RXSTART.indication primitive) is not received within a certain period from the time when the RTS frame is received (e.g., the time when the MAC receives the PHY-RXEND.indication primitive corresponding to the RTS frame), STAs that have set or updated the NAV through the RTS frame may reset the NAV (e.g., 0). The certain period may be (2*aSIFSTime + CTS_Time + aRxPHYStartDelay + 2*aSlotTime). The CTS_Time may be calculated based on the length of the CTS frame and the data rate indicated by the RTS frame.

[0148] In addition to the RTS frame and / or CTS frame, NAV setting / resetting / updating may also be performed based on fields of other various frames, such as non-HT PPDU, HT PPDU, VHT PPDU or HE PPDU (e.g., duration field in MAC header of MAC frame). For example, if the RA field in the received MAC frame / RTS frame / CTS frame does not match its own address (e.g., MAC address), the STA may set / reset / update NAV based on the value of the duration field in the received MAC frame / RTS frame / CTS frame.

[0149] Non-AP STAs must maintain two NAVs, and APs can maintain two NAVs: an intra-BSS NAV and a basic NAV. The intra-BSS NAV can be updated / set by PPDUs within the BSS. The basic NAV can be updated / set by inter-BSS PPDUs, or PPDUs that cannot be classified as inter-BSS or intra-BSS.

[0150] Below, the structure and types / subtypes of MAC frames are described.

[0151] Figure 8 shows an example of a header of a MAC frame.

[0152] As illustrated, the MAC frame may include a frame control field / information of 2 octets in length, a duration field / information of 2 octets in length, a RA (Receiver Address) field / information of 6 octets in length, and a TA (Transmitter Address) field / information of 6 octets in length. As illustrated in FIG. 8, the four fields may be consecutive to each other. The MAC header of FIG. 8 may be modified in various ways, and a new field may be inserted between the four illustrated fields, or at least one of the illustrated fields may be omitted.

[0153] The MAC header illustrated in Fig. 8 may be positioned at the very front of the MAC frame. That is, the MAC frame may include a MAC header as illustrated in Fig. 8 and MAC body fields / information subsequent to the MAC header. The MAC frame including the MAC header of Fig. 8 is inserted / included in the data field of the PPDU (e.g., UHR PPDU) illustrated in Fig. 5.

[0154] The MAC frames included in the data field of the PPDU of this specification can be classified into various types. For example, the MAC frames of this specification can be classified into control frames, management frames, and data frames.

[0155] For example, the management frame includes Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Beacon, Disassociation, Authentication, and Deauthentication frames / signals defined in conventional WLAN. For the management frame, the values ​​of the type fields (B3 and B2) in FIG. 8 are set to 00. In addition, the values ​​of the subtype fields (B7, B6, B5, B4) in FIG. 8 are as follows: Association Request (0000), Association Response (0001), Reassociation Request (0010), Reassociation Response (0011), Probe Request (0100), Probe Response (0101), Beacon (1000), Disassociation (1010), Authentication (1011), Deauthentication (1100).

[0156] For example, the control frame includes Trigger Beamforming Report Poll, NDP Announcement (NDPA), Control Frame Extension, Control Wrapper, Block Ack Request (BlockAckReq), Block Ack (BlockAck), PS-Poll, RTS, CTS, Ack, and CF-End frames / signals defined in conventional WLAN. For the control frame, the values ​​of the type fields (B3 and B2) in FIG. 8 are set to 01. Also, the values ​​of the subtype fields (B7, B6, B5, B4) of FIG. 8 are as follows: Trigger (0010), Beamforming Report Poll (0100), NDP Announcement (0101), Control Frame Extension (0110), Control Wrapper (0111), BlockAckReq (1000), BlockAck (1001), PS-Poll (1010), RTS (1011), CTS (1100), Ack (1101), CF-End (1110).

[0157] For example, the data frame includes (QoS) Data, (QoS) Null, etc. defined in conventional WLAN. For the management frame, the value of the type field (B3 and B2) of Fig. 8 is set to 10.

[0158] The MAC frame / signal used in this specification can be identified through the type field / information and subtype field / information described above. For example, the “trigger frame” in this specification can mean a MAC frame in which the type bits B3 and B2 bits in the frame control field of the MAC header are set to 01, and the subtype bits B7, B6, B5, B4 bits in the frame control field are also set to 0010. Various MAC frames described in this specification are inserted / included in the data field of various PPDUs (e.g., HE / VHT / HE / EHT / UHR PPDU).

[0159] Figure 9 illustrates a trigger frame format. The trigger frame format may also be referred to as the structure of a trigger frame.

[0160] Referring to FIG. 9, a trigger frame may include a frame control field, a duration / ID field, a receiver address (RA) field, a transmitter address (TA) field, a common info field, a user info list field, a padding field, and / or a frame check sequence (FCS) field. Optionally, the trigger frame may further include a special user info field between the common info field and the user info list field. The user info list field may include one or more user info fields. The frame control field, the duration / ID field, the RA field, and the TA field may constitute a MAC header.

[0161] For example, the common information field may include a trigger type subfield. The trigger type subfield value may indicate a trigger frame variant, as shown in Table 1:

[0162]

[0163] For example, if the value of the trigger type subfield is set to 0, the trigger frame may be a basic trigger frame. For example, if the value of the trigger type subfield is set to 3, the trigger frame may be a multi-user (MU) RTS trigger frame. The following describes block ACK (acknowledgement).

[0164] The block ACK mechanism improves channel efficiency by integrating multiple ACKs into a single frame. In this disclosure, an STA with data to transmit using the block ACK mechanism is referred to as an originator, and the recipient of that data is referred to as a receiver.

[0165] The block ACK mechanism is initiated using an ADDBA (add block acknowledgment) request / response frame exchange or an unsolicited block ACK extension mechanism, except for the GLK-GCR block ACK. After initialization, blocks of QoS data frames can be transmitted from the sender to the receiver. A block can be initiated by winning a polled TXOP, SP, or EDCA contention. The number of frames in a block is limited, and the amount of state that the receiver must maintain is limited. The MPDUs within a block of frames are acknowledged by a block ACK (or BlockAck / BA) frame and requested by a block ACK request (or BlockAckReq / BAR) frame. For the GLK-GCR block ACK, the block ACK mechanism is initiated when a GLK STA associates with a GLK AP. The MPDUs within a block of data frames addressed to a SYNRA address are acknowledged by a BlockAck frame, which is requested by a BlockAckReq frame.

[0166] The block ack mechanism does not require TS configuration. However, a QoS STA using the TS feature can indicate its intent to use the block ack mechanism so that the scheduler can consider it when allocating TXOPs. The block ack mechanism is also used in the GCR service. ACKs for frames belonging to the same TID but transmitted over multiple TXOPs / SPs can also be combined into a single BlockAck frame. This mechanism provides the sender with flexibility in transmitting data frames. The sender can segment frame blocks into TXOPs / SPs, separate data transmission from block ACK exchanges, and interleave MPDU blocks that carry some or all of the MSDUs or A-MSDUs for different TIDs or RAs.

[0167] Non-AP S1G STAs can negotiate asymmetric BA with S1G APs. Non-S1G STAs must not send NDP BlockAck frames and must not initiate asymmetric BA. S1G APs with dot11AsymmetricBlockAckActivated set to false do not support asymmetric BA. In an asymmetric BA operation, a responding S1G STA may use a lower MCS to immediately send a BlockAck frame. The intended receiving STA measures the degree of asymmetry between the AP and the STA and implicitly indicates this value to the originating AP during the block ACK setup phase. This asymmetry is expressed as the difference in MCS values ​​between the AP and the STA, referred to as MCSDifference. After an asymmetric BA agreement is established, the originating AP uses CSDifference to calculate the Duration field of the PV0 frame included in the A-MPDU that derives the BlockAck frame.

[0168] An S1G STA that sets the STA Type Support subfield of the transmitted S1G Capabilities element to 0 or 2 must support the HT-immediate block ACK extension. An S1G STA that sets the A-MPDU Support field of the S1G Capabilities element to 1 must support the HT-immediate block ACK extension.

[0169] When connected between MLDs, a block ACK consensus is established between the two MLDs and follows the block ACK procedure rules for multi-link operation. When connected between STAs, a block ACK consensus is established between the two STAs and follows the rules for setting and modifying block ACK parameters.

[0170] After establishing an immediate block ack agreement, accessing the medium, and establishing protection, the sender can transmit A-MPDUs, if necessary. Using the GCR block ack retransmission policy, the RA field of undelivered frames becomes the receiver's private address. The RA field of GCR frames delivered using the GCR block ack retransmission policy is set to the GCR hidden address. The RA field of data frames delivered using the GLK-GCR block ack retransmission policy is set to SYNRA. The sender requests acknowledgment for outstanding QoS data frames by sending a BlockAckReq frame.

[0171] The multi-TID BlockAck variant MUST be used for all BlockAck frames associated with HT-immediate agreements transmitted within a PSMP sequence, and MUST NOT be used otherwise. For non-HE STAs, the multi-TID BlockAckReq variant MUST be used for all BlockAckReq frames associated with HT-immediate agreements transmitted within a PSMP sequence, and MUST NOT be used otherwise. The multi-TID BlockAckReq variant can be used to request multi-STA BlockAck frames for multi-TID A-MPDUs between HE STAs.

[0172] When the compressed BlockAckReq variant is used in conjunction with HT-immediate agreement in a DMG BSS, all BlockAck and BlockAckReq frames transmitted as part of the HT-immediate agreement must use the compressed BlockAck and compressed BlockAckReq variants.

[0173] When the extended compressed BlockAckReq variant is used in conjunction with HT-immediate agreement in a DMG BSS, all BlockAck and BlockAckReq frames transmitted as part of the HT-immediate agreement must use the extended compressed BlockAck and extended compressed BlockAckReq variants.

[0174] The GCR BlockAck and GCR BlockAckReq variants are used for GCR block ack consensus. The GLKGCR BlockAck and GLK-GCR BlockAckReq variants are used for GLK-GCR block ack consensus.

[0175] An S1G receiver of a block ack agreement negotiated and approved by NDP ADDBA must acknowledge the MPDUs within the A-MPDU using NDP BlockAck frames instead of BlockAck frames during HT-immediate block ack agreement.

[0176] An S1G receiver of a block ack agreement negotiated and approved by BAT ADDBA must acknowledge the MPDUs within the A-MPDU using a BAT frame instead of a BlockAck frame during an HT-immediate block ack agreement. Otherwise, an S1G receiver of an approved block ack agreement must not use a BAT frame.

[0177] An S1G receiver of a block ack agreement negotiated and approved by ADDBA must use the BlockAck frame to acknowledge the MPDUs within the A-MPDU during the HT-immediate block ack agreement.

[0178] The S1G receiver of a negotiated and approved block ack agreement for an ADDBA request / NDP ADDBA response or NDP ADDBA request / ADDBA response must use the NDP BlockAck or BlockAck frame, depending on the response frame type generated by the S1G sender. The response types are as follows:

[0179] - NDP BlockAck frame if the RXVECTOR parameter RESPONSE_INDICATION of the derived PPDU containing the BlockAckReq or A-MPDU is equal to the NDP response;

[0180] - BlockAck frame if the RXVECTOR parameter RESPONSE_INDICATION of the derived PPDU containing BlockAckReq or A-MPDU is equal to a normal response;

[0181] - A PPDU containing a BlockAck frame when the RXVECTOR parameter RESPONSE_INDICATION of the induced PPDU is equal to Long Response.

[0182] Figure 10 shows the frame format of the BlockAck frame.

[0183] Referring to FIG. 10, the BlockAck frame may include a frame control field, a duration field, an RA field, a TA field, a BA control field, a BA information field, and / or an FCS field.

[0184] The value of the period field is related to the period of the NAV timer set by the STA whose address of the recipient STA is not the same as its own MAC address.

[0185] The RA field of a BlockAck frame that is not a multi-STA BlockAck variant is set to the TA field of the request frame or the address of the receiving STA whose data frame is being acknowledged.

[0186] The TA field is the address of the STA transmitting the BlockAck frame.

[0187] The format of the BA control field is as shown in Fig. 11.

[0188] Figure 11 shows the format of the BA control field.

[0189] Referring to FIG. 11, the BA control field may include a BA type subfield, a No Memory Kept subfield, a memory configuration tag subfield, a management Ack subfield, and / or a TID_INFO subfield.

[0190] The BA Type subfield of the BA Control field indicates a BlockAck frame variant. The BlockAck frame variant encoding is as shown in Table 2 below:

[0191]

[0192] In this disclosure, references to the BlockAck frame without any limitation apply to all BlockAck frame variations unless specific exceptions are specified. The GCR BlockAck frame is used in response to a GCR BlockAckReq frame, and the GLK-GCR BlockAck frame is used in response to a GLK-GCR BlockAckReq frame.

[0193] An EDMG STA sets the No Memory Kept subfield to 1 to indicate that the free memory space indicated in the last RBUFCAP subfield may not be maintained at the start of the next frame exchange sequence. Otherwise, if set to 0, the free memory space indicated in the RBUFCAP subfield is maintained by the receiver for the next frame exchange sequence for that TID. The No Memory Kept subfield is reserved when transmitting from an STA other than the EDMG STA.

[0194] For EDMG STAs, the Memory Settings Tag subfield indicates one of two memory settings indicated in the Memory Settings Tag field of the recipient's EDMG Flow Control Extension Settings element. For other types of STAs, this subfield is reserved.

[0195] The Management Ack subfield is set to 1 to indicate that a frame of type Management and a non-Action No Ack subtype has been acknowledged. This subfield is reserved if the BlockAck variant used is not the EDMG Multi-TID BlockAck variant.

[0196] The meaning of the TID_INFO subfield of the BA Control field depends on the BlockAck frame variant type. The meaning of the BA Information field depends on the BlockAck frame variant type.

[0197] Below, among the BlockAck frame variants, the multi-STA BlockAck frame variant is described.

[0198] Multi-STA BlockAck frames are supported when UL MU or multi-TID A-MPDU operation is supported and acknowledging MPDUs contained in HE TB PPDU or multi-STA multi-TID, multi-STA single TID, or single STA multi-TID A-MPDU.

[0199] A HE AP transmitting a multi-STA BlockAck frame in which the per AID TID information field is addressed to more than one STA sets the RA field to the broadcast address. A HE AP transmitting a multi-STA BlockAck frame in which all per AID TID information fields are addressed to a single receiving STA and are transmitted in response to a HE TB PPDU sets the RA field of the multi-STA BlockAck frame to the receiving STA address or broadcast address. A HE AP transmitting a multi-STA BlockAck frame in which all per AID TID information fields are addressed to a single receiving STA and are not transmitted in response to a HE TB PPDU sets the RA field of the multi-STA BlockAck frame to the receiving STA address.

[0200] A non-AP HE STA sets the RA field to the TA field of the request frame or the address of the receiving STA to which the data or management frame was acknowledged.

[0201] The TID_INFO subfield of the BA control field of a multi-STA BlockAck frame is reserved.

[0202] The BA information field of a multi-STA BlockAck frame may have a format as shown in FIG. 12.

[0203] Figure 12 shows the format of the BA information field of a multi-STA BlockAck frame.

[0204] Referring to FIG. 12, the BA information field of the multi-STA BlockAck frame includes one or more AID TID-specific information subfields. The AID TID-specific information subfield may include an AID TID information subfield, and the AID TID information subfield may have a format as shown in FIG. 13.

[0205] Figure 13 shows the format of the AID TID information subfield.

[0206] Referring to FIG. 13, the AID TID information subfield may include an AID11 subfield, an Ack type subfield, and / or a TID subfield.

[0207] The AID11 subfield conveys the least significant 11 bits of the AID of the non-AP STA for which the AID TID-specific information subfield will be used. The format of the AID TID-specific information subfield depends on the value of the AID11 subfield. If a multi-STA BlockAck frame is transmitted to the AP, the AID11 subfield is set to 0. The value 2045 in the AID11 subfield is used as an identifier for all unconnected STAs. When the AID11 subfield is set to 2045, the Ack Type subfield and the TID subfield are set to 0 and 15, respectively.

[0208] Multiple AID TID-specific information subfields may exist in a multi-STA BlockAck frame, with the same value in the AID11 subfield but different values ​​in the TID subfield.

[0209] If the AID11 subfield of the AID TID information subfield is not 2045, the AID TID specific information subfield may have a format as in FIG. 14.

[0210] Figure 14 shows the format of the AID TID specific information subfield when the AID11 subfield is not 2045.

[0211] Referring to FIG. 14, when the AID11 subfield is not 2045, the AID TID-specific information subfield of the multi-STA BlockAck frame may include an AID TID information subfield, a Block Ack start sequence control subfield, and / or a BlockAck bitmap subfield. The context and presence of each optional subfield within the AID TID-specific information subfield of the multi-STA BlockAck frame are as shown in :

[0212]

[0213] Since HE STA does not use HCCA, TID values ​​8 to 15 are not used in QoS data frames.

[0214] Figure 15 shows the format of the block Ack start sequence control subfield.

[0215] Referring to FIG. 15, the Block Ack Start Sequence Control subfield may include a fragment number subfield and a starting sequence number subfield. The starting sequence number subfield contains the sequence number of the first MSDU or A-MSDU transmitted by this multi-STA BA frame. When the Ack type subfield is 0, the fragment number subfield encoding for the multi-STA BlockAck frame variant indicates the length of the BlockAck bitmap subfield as shown in .

[0216]

[0217] When B0 of the fragment number subfield of the Block Ack Start Sequence Control subfield is 0, the BA Information field of the multi-STA BlockAck frame contains an 8-octet, 16-octet, 32-octet, or 4-octet Block Ack Bitmap subfield according to B2-B1 of the fragment number subfield as shown in Table 4, indicating the reception status of up to 64, 128, 256, or 32 MSDUs (or their fragments) and / or A-MSDUs (or their fragments), respectively. Each bit that is 1 in the Block Ack Bitmap subfield sequentially acknowledges the reception of a single MSDU (or its fragment) or A-MSDU (or its fragment). The first bit of the Block Ack Bitmap subfield corresponds to an MSDU or A-MSDU with a sequence number that matches the value of the Start Sequence Number subfield of the Block Ack Start Sequence Control subfield. When B0 of the Fragment Number subfield of the Block Ack Start Sequence Control subfield is 1, the Block Ack Bitmap subfield of the BA Information field of the multi-STA BlockAck frame indicates the reception status of up to 16, 32, 64, or 8 MSDUs and / or A-MSDUs, depending on B2-B1 of the Fragment Number subfield, as shown in Table 4. When bit position n of the Block Ack Bitmap subfield is 1, reception of an MPDU with a sequence number value SN and a fragment number value FN is acknowledged, where n = 4 × (SN - SSN) + FN, where SSN is the value of the Start Sequence Number subfield of the Block Ack Start Sequence Control subfield, and the operation on the sequence number is performed modulo 4096. A bit position n of the Block Ack Bitmap subfield that is 0 indicates that no MPDU was received.

[0218] If B0 of the fragment number subfield is 1, the block Ack bitmap subfield is divided into (block Ack bitmap subfield length) / 4 sub-bitmaps, each of which indicates the reception status for four fragments of each MSDU or A-MSDU as shown in Table 4. For A-MSDUs, only the first bit of the sub-bitmap is used if fragmentation is not allowed in the A-MSDU.

[0219] Meanwhile, according to the EHT (or 802.11be) standard, in order to support peer-to-peer (P2P) transmission to non-AP STAs, the AP may allocate a portion of the time interval within the TXOP acquired by the AP. To allocate a portion of the time interval within the TXOP, a TXOP Sharing Mode subfield may be defined within the Common Info Field of the MU-RTS Trigger frame. When the value of the TXOP Sharing Mode subfield is non-zero, such an MU-RTS trigger frame may be referred to as an MU-RTS TXOP Sharing (TXS) Trigger frame (TF). The values ​​of the TXOP Sharing Mode subfield are described in Table 5 below:

[0220]

[0221] For example, if the value of the TXOP shared mode subfield is 1, one or more (non-TB) PPDU transmissions to the AP may be supported. If the value of the TXOP shared mode subfield is 2, not only (non-TB) PPDU transmissions to the AP but also P2P transmissions may be supported. In the present disclosure, the MU-RTS TXS TF may also be briefly referred to as a TXS trigger frame.

[0222] Meanwhile, to enable terminals to maintain continuous WLAN connectivity over a wider area, numerous APs are being installed adjacent to each other. However, overlapping BSSs of multiple APs can lead to issues such as radio interference and transmission collisions between APs. To address these issues, various technologies related to coordination between APs in the frequency, time, and spatial domains (e.g., RU selection, joint transmission, nulling) have been proposed. Furthermore, various issues that may arise during inter-AP cooperation need to be addressed.

[0223] In this disclosure, multi-AP operation is proposed. Multi-AP operation may be based on a technique for reducing various interferences, such as inter-symbol interference (ISI), through coordination with neighboring APs (e.g., APs located in overlapping BSSs).

[0224] For example, multi-AP operation can be categorized into multi-AP cooperation schemes (or, cooperative schemes) based on various technologies / types / formats / protocols. For example, the cooperative scheme may include Coordinated TDMA (Co-TDMA), which distinguishes wireless resources allocated to multiple APs based on the time domain. Additionally or alternatively, the cooperative scheme may include Coordinated OFDMA (C-OFDMA), which distinguishes wireless resources allocated to multiple APs based on the frequency domain. Additionally or alternatively, the cooperative scheme may include Coordinated Spatial Reuse (Co-SR), which applies spatial reuse (SR) to at least one AP. Additionally or alternatively, the cooperative scheme may include Coordinated beamforming (Co-BF) / nulling, which transmits by nulling interference generated from neighboring APs (e.g., adjacent APs / STAs, and / or OBSS APs / OBSS STAs). Additionally or alternatively, the cooperative scheme may include AP selection, in which an AP with a good channel condition among neighboring APs (e.g., at least one AP located within a BSS or OBSS and with a good channel condition) transmits. Additionally or alternatively, the cooperative scheme may include Joint Transmission (JTX) or Joint Transmission (JT), in which multiple APs (e.g., multiple APs within the same BSS / OBSS, or multiple APs within different BSS / OBSS) cooperate to perform simultaneous transmission and reception, and JTX / JT may be implemented based on Joint Beamforming or Joint MU-MIMO.

[0225] In this disclosure, “multi-AP (cooperative) operation” may also be referred to as “multi-AP (cooperative) transmission.” Furthermore, “multi-AP (cooperative) operation / transmission” and “multi-AP cooperative scheme (or cooperative scheme)” may be used interchangeably.

[0226] When the triggered TXOP sharing protocol is utilized for multi-AP cooperation (e.g., Co-TDMA), transmissions within the BSS of each cooperative AP are divided into time units, so that each cooperative AP can perform frame exchange without affecting other cooperative APs. In this case, the AP in the triggered TXS protocol may be an AP that shares TXOP in multi-AP cooperation operation, and the STA in the triggered TXS protocol may be an AP that shares TXOP in multi-AP cooperation operation.

[0227] In the present disclosure, an AP that shares a TXOP may be referred to as a SAP (sharing AP), and an AP that receives a TXOP from a SAP may be referred to as a DAP (shared AP) (or CAP (coordinated AP)). Here, the term SAP does not limit the entity that shares a TXOP to only AP STAs, and the SAP may also include non-AP STAs that share the TXOP. In addition, the term DAP does not limit the entity that shares a TXOP to only AP STAs, and the DAP may also include non-AP STAs that share the TXOP (or transmit and receive with AP STAs that share the TXOP).

[0228] Additionally, a frame exchange performed by a DAP with a non-AP STA or SAP belonging to the DAP BSS during the allocated time (i.e., the allocated period for the DAP within the TXOP indicated by the MU-RTS TXS TF transmitted from the SAP, which is the time allocated in the MU-RTS TXS TF) may be referred to as a BSS frame exchange (FE) of the DAP. For example, a data frame transmission and a block ACK frame response following an RTS / CTS frame exchange between the DAP and a non-AP STA, a UL data frame transmission of non-AP STAs by a trigger frame transmitted from the DAP, and / or a data frame transmission of the DAP by a trigger frame transmitted from the SAP may be performed.

[0229] In the present disclosure, "frame exchange (FE)" may include frame transmission and / or reception operations between STAs. The STAs may be APs or non-AP STAs. Here, the frames may include various types of frames (e.g., data frames, control frames, management frames).

[0230] Figure 16 shows an example of multi-AP operation based on Co-TDMA between APs.

[0231] Referring to Fig. 16, SAP and non-AP STA1 may belong to BSS1, and DAP and non-AP STA2 may belong to BSS2. SAP may acquire TXOP and share TXOP with DAP by transmitting MU-RTS TXS TF including information about allocation period within TXOP (time allocated in MU-RTS TXS TF in Fig. 6). DAP may transmit CTS in response to MU-RTS TXS TF and perform frame exchange with non-AP STA2 belonging to its BSS (i.e., BSS2) in the allocation period shared from SAP. Although not shown, after frame exchange is completed (or after allocation period ends), DAP may transmit TXOP return frame to return TXOP to SAP. After frame exchange is completed within a TXOP (or after the allocation period ends), there may be a remaining TXOP period, and the SAP may perform frame exchange with a non-AP STA1 belonging to its own BSS (i.e., BSS1) within the remaining TXOP period.

[0232] In order for multi-AP cooperation to be achieved between two APs, the two APs must be in a connected / bonded state, and / or a negotiation procedure must be performed in advance to exchange cooperation request frames / cooperation response frames containing capability information / requirement information of each AP, and then multi-AP transmission (e.g., Co-TDMA (coordinated time division multiple access), C-OFDMA (coordinated orthogonal frequency division multiple access), Co-SR (coordinated spatial reuse), Co-BF (coordinated beamforming), AP selection, or Jo-TX (joint transmission)) can be performed based on the obtained information. That is, in order for multi-AP transmission to be performed smoothly, a negotiation procedure for configuring / managing multi-AP cooperation and / or transmitting based on a specific multi-AP cooperation method must be performed in advance between the above-described SAP and DAP. A multi-AP set can be set up / configured based on the negotiation procedure. Therefore, the negotiation procedure may also be referred to as a multi-AP set setup / configuration procedure.

[0233] FIG. 17 illustrates an example of a multi-AP negotiation procedure according to an embodiment of the present disclosure.

[0234] Referring to FIG. 17, AP 1 can perform a multi-AP negotiation procedure (or a negotiation procedure for multi-AP cooperation) with AP 2. In the negotiation procedure, AP 1 can transmit a coordination request frame including capability information of AP 1, and AP 2 can transmit a coordination response frame including capability information of AP 2. If AP 2 accepts the cooperation request, the coordination response frame can include information indicating such acceptance, and a cooperation setup for multi-AP cooperation (or a (multi-AP) cooperation setup for AP 1 and AP 2) can be established between AP 1 and AP 2. That is, if the negotiation procedure is successfully completed (or if a cooperation response frame is transmitted / received), a cooperation setup for multi-AP cooperation can be established between AP 1 and AP 2. The cooperative setting can be set to be supported by both AP 1 and AP 2 based on the capability information of AP 1 and the capability information of AP 2, and can include at least one of the information included in the capability information of AP 1 or the information included in the capability information of AP 2.

[0235] Additionally, if the negotiation procedure is successfully completed, a multi-AP set / group including AP 1 and AP 2 may be established (or a multi-AP set / group configuration may be established). Accordingly, the negotiation procedure may include at least one of a procedure for establishing a cooperation configuration for multi-AP cooperation or a procedure for establishing a multi-AP set / group (or a multi-AP set / group configuration). In the present disclosure, a multi-AP set / group may also be referred to as a cooperation group.

[0236] After AP 1 performs a multi-AP negotiation procedure with AP 2, AP 1 can perform a multi-AP negotiation procedure with AP 3 in a similar manner. Upon successful completion of the negotiation procedure: i) a (multi-AP) cooperation configuration is established for AP 1, AP 2, and AP 3 (or for each pair among AP 1, AP 2, and AP 3), and ii) a multi-AP set / group including AP 1, AP 2, and AP 3 can be established (or a multi-AP set / group configuration can be established).

[0237] As described above, when an AP performs a multi-AP negotiation procedure with one or more other APs, and the negotiation procedure is successfully completed: i) a (multi-AP) cooperation configuration is established for the APs that performed the negotiation procedure (or for each pair of APs that performed the negotiation procedure), and ii) a multi-AP set / group including the APs that performed the negotiation procedure may be established (or a multi-AP set / group configuration may be established).

[0238] For multi-AP coordination (MAPC) based operations (e.g., Co-SR, Co-BF) and / or Co-TDMA based operations to be successfully performed, a procedure may be required for selecting target DAPs within the set / group of APs that have established multi-AP cooperation with which the SAP wishes to perform multi-AP operations and / or share TXOPs, and / or a procedure may be required for notifying that such MAPC based operations are to be performed.

[0239] Figure 18 shows an example of a multi-AP selection procedure.

[0240] Referring to Fig. 18, a SAP (or Coordinator AP) that has acquired a TXOP can initiate / perform a multi-AP selection (or, cooperation announcement / schedule announcement / polling) procedure. In the multi-AP selection procedure, the SAP can transmit a request frame (i.e., a request frame for AP selection / selection request frame) to one or more DAPs to select a DAP with which to share the TXOP from a multi-AP set established / configured through a negotiation procedure, and one or more DAP(s) that receive the request frame can transmit a response frame (i.e., a response frame for AP selection / selection response frame) to the request frame based on whether TXOP sharing is required. If a response frame including an indication that TXOP sharing is not required is received from the DAP(s), or if no response frame is received from the DAP(s), the SAP can transmit a request frame for AP selection to another DAP - i.e., the SAP can perform AP re-selection. Alternatively, the SAP can simply inform the target DAP(s) that it will share the TXOP in the multi-AP selection procedure. For example, a SAP can send an AP selection request frame that does not solicit a response frame to the target DAP with which it wishes to share a TXOP, and the DAP receiving such an AP selection request frame can prepare an action for the intended TXOP sharing.

[0241] The SAP transmits a frame for TXOP sharing (e.g., TXOP sharing frame / MU-RTS TXS trigger frame) to the selected DAP through a multi-AP selection procedure, and the DAP can exchange frames with non-AP STA(s) associated with the DAP within the time period (e.g., allocation period) allocated by the TXOP sharing frame.

[0242] In this disclosure, multi-AP selection may be used interchangeably with schedule announcement, coordination announcement, and cooperative polling.

[0243] In a multi-AP selection procedure, depending on the type of selection (or cooperation / polling) request frame transmitted from the SAP or the type of response frame solicited within that frame, the DAP may transmit a multi-STA BA frame as a selection (or cooperation / polling) response frame. For example, the multi-STA BA frame may include a Co-TDMA ICR for Co-TDMA, a Co-SR response frame for Co-SR, and / or a Co-BF response frame for Co-BF.

[0244] Accordingly, according to various embodiments of the present disclosure, a structure of a response frame to a multi-AP selection (or cooperation / polling) request frame that can be transmitted for a SAP to select a DAP to perform MAPC-based operation in MAPC operation and / or Co-TDMA operation, and / or to convey information about MAPC-based operation and / or information about scheduled cooperation to one or more DAPs is provided. For example, according to various embodiments of the present disclosure, a structure of a multi-STA BA frame and / or a method of transmitting the same is provided when the multi-STA BA frame is transmitted in response to a trigger frame (e.g., BSRP TF, MU-RTS TF) transmitted as a selection (or cooperation / polling) request frame. Based on the information included in the multi-STA BA frame transmitted from the DAP(s), the SAP can perform more efficient multi-AP cooperation.

[0245] In the present disclosure, a multi-AP selection (or, cooperation / polling) request frame may include at least one of an initial control frame (ICF) (e.g., ICF / Co-TDMA ICF for Co-TDMA), an invite frame (e.g., invite frame for Co-SR / BF), or a sounding invite frame (e.g., sounding invite frame for Co-BF).

[0246] In this disclosure, the terms “field” and “subfield” may be used interchangeably unless specifically distinguished.

[0247] The specific designations (names) proposed in this disclosure may be changed and are not limited.

[0248] FIG. 19 illustrates an example of a method performed by a first AP for receiving a response frame for multi-AP cooperation according to various embodiments of the present disclosure.

[0249] Referring to FIG. 19, in step S1901, the first AP can establish a cooperation setting for multi-AP cooperation with one or more APs.

[0250] In step S1903, the first AP may transmit a trigger frame for multi-AP cooperation to a second AP among one or more APs.

[0251] In step S1905, the first AP may receive a multi-STA BA frame in response to a trigger frame from the second AP. The BA information field of the multi-STA BA frame may include a per AID TID information subfield. The AID TID information subfield of the per AID TID information subfield may be set to a specific value based on whether the multi-STA BA frame is related to multi-AP cooperation.

[0252] According to various embodiments, the AID TID information subfield may include at least one of an AID11 subfield, an Ack (acknowledgement) type subfield, or a TID subfield. A specific value of the AID TID information subfield may include at least one of a value of the AID11 subfield, a value of the Ack type subfield, or a value of the TID subfield.

[0253] According to various embodiments, the value of the AID11 subfield may be set to a value other than 2045.

[0254] According to various embodiments, the value of the Ack Type subfield may be set to 0. The value of the TID subfield may be set to 13.

[0255] According to various embodiments, the AID TID information subfield may be set to a specific value based on whether cooperation information related to multi-AP cooperation is included in the multi-STA BA frame.

[0256] According to various embodiments, the cooperation information may include at least one of information about an operating channel, information related to an operating bandwidth, information about a requested TXOP period, information about a buffer status, information about a TXOP (transmission opportunity) sharing request, low-latency traffic information, or information about a status code.

[0257] According to various embodiments, the AID TID-specific information subfield may include a subfield containing cooperation information. The subfield containing cooperation information may be a BA bitmap subfield, or a control information subfield included in the AID TID-specific information subfield instead of the BA bitmap subfield.

[0258] According to various embodiments, the control information subfield may be a feedback subfield.

[0259] According to various embodiments, the BA starting sequence control subfield of the AID TID-specific information subfield may include a control information type subfield. The control information type subfield may indicate the type of information contained in the BA bitmap subfield or the control information subfield. The type of information may include multi-AP cooperation.

[0260] According to various embodiments, the control information type subfield may be set to a specific value based on whether the cooperation information is included in the BA bitmap subfield or the control information subfield.

[0261] According to various embodiments, the control information type subfield may be a feedback type subfield.

[0262] According to various embodiments, the BA starting sequence control subfield of the AID TID-specific information subfield may include a fragment number subfield. The fragment number subfield may be set to a value related to the length or size of the subfield containing the cooperation information.

[0263] According to various embodiments, the size of the subfield containing the collaboration information may be the size of the collaboration information.

[0264] FIG. 20 illustrates an example of a method performed by a second AP for transmitting a response frame for multi-AP cooperation according to various embodiments of the present disclosure.

[0265] Referring to FIG. 20, in step S2001, the second AP can establish a cooperation setting for multi-AP cooperation with the first AP.

[0266] In step S2003, the second AP can receive a trigger frame for multi-AP cooperation from the first AP.

[0267] In step S2005, the second AP may transmit a multi-STA BA frame to the first AP in response to the trigger frame. The BA information field of the multi-STA BA frame may include a per AID TID information subfield. The AID TID information subfield of the per AID TID information subfield may be set to a specific value based on whether the multi-STA BA frame is related to multi-AP cooperation.

[0268] According to various embodiments, the AID TID information subfield may be set to a specific value based on whether cooperation information related to multi-AP cooperation is included in the multi-STA BA frame.

[0269] According to various embodiments, the AID TID-specific information subfield may include a subfield containing cooperation information. The subfield containing cooperation information may be a BA bitmap subfield, or a feedback subfield included in the AID TID-specific information subfield instead of the BA bitmap subfield.

[0270] Below, a specific embodiment of the design of a response frame for multi-AP cooperation is described.

[0271] According to various embodiments of the present disclosure, a response frame to a trigger frame that can be transmitted in a multi-AP selection (or cooperation announcement / schedule announcement / polling) procedure for a SAP to select a DAP to cooperate with and / or obtain information from potential DAPs in MAPC (e.g., Co-BF, Co-SR, Co-TDMA) operation is defined. For example, various embodiments of the present disclosure provide a method for transmitting a multi-STA BA frame including MAPC related information as a response frame to a trigger frame (e.g., BSRP TF, MU-RTS TF) and / or an apparatus for implementing the method.

[0272] Since a multi-STA BA frame is a frame that can be transmitted to one or more associated (or unassociated) STAs, it can be transmitted in various ways. For example, a multi-STA BA frame classified as a Class 1 frame can be considered a frame suitable for MAPC operation because it can be transmitted between unassociated APs. Based on the multi-STA BA frame structure, information for MAPC operation, and / or a method for transmitting a multi-STA BA frame according to various embodiments of the present disclosure, the multi-STA BA frame can be transmitted as an initial control response (ICR) frame in a MAPC environment.

[0273] Additionally or alternatively, a BA frame may be transmitted in response to a trigger frame (e.g., BSRP TF, MU-RTS TF) if the trigger frame is addressed from an OBSS STA to an AP or STA, even if the trigger frame does not contain MAPC-related information and / or Co-TDMA operation-related information.

[0274] Additionally or alternatively, the multi-STA BA frame according to various embodiments of the present disclosure may be utilized in various procedures related to MAPC, as well as trigger frames (e.g., BSRP TF, MU-RTS TF) that may be transmitted in the multi-AP selection (or, cooperation announcement / schedule announcement / polling) procedure described above. For example, the multi-STA BA frame may be used as a response frame transmitted in the TXOP sharing procedure, the TXOP return procedure in Co-TDMA, and / or the Co-BF sounding procedure.

[0275] In the multi-AP selection (or cooperation announcement / polling) procedure illustrated in FIG. 18, a multi-STA BA frame that a DAP may transmit as a response frame to a trigger frame may include information for MAPC operation (or MAPC information / cooperation information) that includes at least one of the following information elements (IEs) / fields:

[0276] - Operating Channel: Information about the primary channel and / or punctured channel that is in operation.

[0277] In some implementations, the operating channel information may include common operating channel information for smooth cooperation between APs participating in MAPC.

[0278] In some implementations, the operating channel information may include primary channel information on which APs participating in MAPC can commonly operate.

[0279] For example, a new field may be defined that acts as the channel center frequency segment (CCFS) 0 field within the UHR motion information field to indicate the channel center frequency index for 20 / 40 / 80 MHz channels.

[0280] For example, a new field may be defined that acts as the CCFS0 field within the UHR motion information field to indicate the channel center frequency for the primary 80 MHz channel of a 160 MHz channel or the channel center frequency for the primary 160 MHz channel of a 320 MHz channel.

[0281] Additionally, a new field is defined that acts as the CCFS1 field within the UHR motion information field to indicate the channel center frequency for a 160 MHz channel or the channel center frequency for a 320 MHz channel.

[0282] In some implementations, the operating channel information may include punctured channel information of APs participating in MAPC.

[0283] For example, a new field may be defined that serves as the Inactive (Inactived) Subchannel Bitmap field within the UHR Motion Information field to indicate a punctured 20 MHz subchannel using a bitmap. A bit in the bitmap whose value is set to 0 may indicate that the corresponding 20 MHz subchannel is not punctured, and a bit in the bitmap whose value is set to 1 may indicate that the corresponding 20 MHz subchannel is punctured.

[0284] In some implementations, the operating channel information may include information about the SAP's primary channel within the channel (or operating channel width) on which the DAP operates.

[0285] In some implementations, the operating channel information may include information about the SAP's primary channel within the operating channel, excluding the punctured channel of the DAP.

[0286] -Operating Bandwidth: Operating bandwidth and / or maximum bandwidth information.

[0287] In some implementations, the operating bandwidth information may include commonly used BW information to facilitate smooth cooperation between APs participating in MAPC. For example, the operating channel and primary channel information described above may be used to indicate the operating bandwidth.

[0288] In some implementations, the operating bandwidth information may include the maximum bandwidth information of an AP participating in MAPC. For example, a new field that functions similarly to the Channel Width field in the Control field of the UHR Operating Information field may be defined to indicate the channel width, which is BSS BW information, of each AP. If the value of this field is set to 0, it may indicate a 20 MHz bandwidth. If the value of this field is set to 1, it may indicate a 40 MHz bandwidth. If the value of this field is set to 2, it may indicate an 80 MHz bandwidth. If the value of this field is set to 3, it may indicate a 160 / 80+80 MHz bandwidth. If the value of this field is set to 4, it may indicate a 320 / 160+160 MHz bandwidth. The values ​​5 to 7 in this field may be reserved.

[0289] In some implementations, the operating bandwidth information may include BW field information within the SIG-A field.

[0290] In some implementations, the operating bandwidth information may include UL BW field information contained within the common information field of the trigger frame.

[0291] In some implementations, the operating bandwidth information may include information about the bandwidth of the SAP within the overall bandwidth over which the DAP operates.

[0292] In some implementations, the Media Time field of the QoS Characteristics element may be changed / redefined to include new subfields, thereby newly including a field for bandwidth indication. For example, a new field that serves the same role as the Channel Width field in the Control field of the UHR Operation Information field may be defined to indicate the channel width, which is BSS BW information of each AP. If the value of this field is set to 0, this field may indicate a 20 MHz bandwidth. If the value of this field is set to 1, this field may indicate a 40 MHz bandwidth. If the value of this field is set to 2, this field may indicate an 80 MHz bandwidth. If the value of this field is set to 3, this field may indicate a 160 / 80+80 MHz bandwidth. If the value of this field is set to 4, this field may indicate a 320 / 160+160 MHz bandwidth. In this field, values ​​5 to 7 may be reserved.

[0293] - Required TXOP duration: Information related to the TXOP duration that each DAP wishes to share.

[0294] Basically, if the Requested TXOP Duration field is defined as 9 bits, the value contained in the Requested TXOP Duration field can be set to be the same as / similar to the value set in the Assigned Duration field of the MU-RTS TXS trigger frame. That is, the TXOP duration desired by each AP can be reported in units of 16 microseconds through the Requested TXOP Duration field.

[0295] In some implementations, a new field containing the required TXOP duration may be defined. For example, a required duration field may be defined to indicate information required for Co-TDMA operation and / or a required TXOP duration value. For example, a required duration field (or cooperative duration field) may be defined to indicate a required duration for Co-SR or Co-BF-based operation.

[0296] In some implementations, a new element containing a required TXOP duration may be defined. For example, a Co-TDMA operation element may be defined to indicate information required for Co-TDMA operation and / or a required TXOP duration value. For example, a MAPC operation element may be defined to indicate information required for MAPC-based operation and / or a required duration for cooperative-based operation.

[0297] In some implementations, information about the required TXOP duration may be included within the QoS Characteristic element that may be used to include negotiation information during the pre-negotiation process for MAPC operation and / or within the elements that may be defined for negotiation for MAPC.

[0298] In some implementations, information about the required TXOP duration may be included within the UHR operation element that may be used to include announcement information in the announcement process of each AP for MAPC operation and / or within the elements that may be defined for announcement for MAPC.

[0299] Alternatively, the Requested TXOP Duration field may indicate the length of the PPDU required by the DAP for Co-SR and / or Co-BF based operation. For this purpose, a Requested (DL) PPDU Length field may be defined.

[0300] Additionally or alternatively, at least some of the values ​​in the Request TXOP Duration field may be utilized to indicate participation in a specific (cooperation) method requested from SAP. That is, at least some of the values ​​in the Request TXOP Duration field may be replaced by the Participation Indication (1-bit or n-bit) field described below.

[0301] For example, a value of 0 in the Requested TXOP Duration field may indicate an intent not to participate in the requested method from SAP.

[0302] Conversely, setting the Requested TXOP Duration field to a value greater than 0 (e.g., a value corresponding to the desired TXOP duration of each AP) may indicate an intent to participate in the manner requested by SAP.

[0303] Additionally or alternatively, setting the Required TXOP Duration field to its maximum value, based on the number of bits in which the Required TXOP Duration field is defined, may indicate an intent to use the TXOP duration allocated by the SAP without a separate desired TXOP duration. For example, if the Required TXOP Duration field is defined as 9 bits and has a value in units of 16 microseconds, a maximum value of 511*16 microseconds = 8,176 microseconds may indicate that the AP does not have a specific TXOP duration required separately, but will follow the TXOP duration allocated by the AP.

[0304] - Buffer Status: Information about the buffer status of each DAP.

[0305] Alternatively, the Buffer Status field may indicate the length of the PPDU requested by the DAP for Co-SR and / or Co-BF based operations. For this purpose, a newly defined Requested (DL) PPDU Length field may be defined.

[0306] - TXOP Sharing Request (or Cooperation Request): Indicates whether cooperation triggers / TXOP sharing are required based on the expiration of pre-negotiated low-latency traffic information and / or the need for cooperation-based behavior / TXOP sharing (e.g., when individual FEs have already been performed).

[0307] For example, whether cooperative trigger / TXOP sharing is required may be indicated based on a bit value of 1. A bit value of 0 may indicate that the DAP receiving the ICF and / or selection request frame does not request cooperative trigger. A bit value of 1 may indicate that the DAP receiving the ICF and / or selection request frame requests cooperative trigger.

[0308] - Low-latency traffic information: Information related to low-latency traffic that each AP wants to transmit / receive.

[0309] In some implementations, low-latency traffic information may include information from QoS attribute elements included in SCS request / response frames.

[0310] For example, the Delay Bound field information among the QoS characteristic elements can be utilized for low-latency traffic information. For example, the Delay Bound field value for QoS traffic that each AP wishes to transmit can be utilized as low-latency traffic information. If the low-latency traffic information is changed to be different from the pre-negotiated low-latency traffic information, the low-latency traffic information can include the updated low-latency traffic information and / or the Delay Bound field value.

[0311] For example, the MSDU Lifetime field information among the QoS characteristic elements can be utilized for low-latency traffic information. For example, the MSDU Lifetime field value for QoS traffic that each AP wishes to transmit can be utilized as low-latency traffic information. If the low-latency traffic information is changed to be different from the pre-negotiated low-latency traffic information, the low-latency traffic information can include the updated low-latency traffic information and / or the MSDU Lifetime field value.

[0312] For example, the service start time field information among the QoS characteristic elements can be utilized for low-latency traffic information. For example, the service start time field value for QoS traffic that each AP wishes to transmit can be utilized as low-latency traffic information. If the low-latency traffic information is changed to be different from the pre-negotiated low-latency traffic information, the low-latency traffic information can include the updated low-latency traffic information and / or the service start time field value.

[0313] In some implementations, the low-latency traffic information may include TXOP sharing request information requested / instructed by an AP requiring transmission of low-latency traffic.

[0314] In some implementations, the low-latency traffic information may include time-bound information of low-latency traffic requested / instructed by an AP requiring transmission of the low-latency traffic.

[0315] For example, low-latency traffic information may include information about the minimum time-bound within which transmission of low-latency traffic should begin.

[0316] For example, low-latency traffic information may include information about the maximum time-bound within which low-latency traffic transmission must be successfully completed. For example, the minimum time-bound within which low-latency (LL) traffic transmission must be initiated and / or the maximum time-bound within which transmission must be successfully completed may be defined based on n bits. For example, a low-latency traffic information field defined by n bits (e.g., n = 4, 6, 7, 8, 9, 10) may indicate the required time-bound based on m-microsecond units (e.g., m = 4, 8, 16, 32, 64). For example, an LLTI field defined by 4 bits and 16 microseconds may indicate a time-bound of 16 to 240 microseconds. For example, an LLTI field defined by 9 bits and 4 microseconds may indicate a time-bound of 4 to 2,044 microseconds.

[0317] In some implementations, the low-latency traffic information may include arrival rate information of low-latency traffic requested / indicated by an AP that requires periodic transmission of low-latency traffic. For example, the low-latency traffic information may indicate the arrival rate of low-latency traffic since the last reporting event based on n bits. For example, a low-latency traffic information field defined by n bits (e.g., n = 4, 6, 7, 8, 9, 10) may indicate a required arrival rate based on m-microsecond units (e.g., m = 4, 8, 16, 32, 64). For example, an LLTI field defined by 4 bits and 16 microseconds may indicate an arrival rate from 16 to 240 microseconds. For example, an LLTI field defined by 9 bits and 4 microseconds may indicate an arrival rate from 4 to 2,044 microseconds.

[0318] In some implementations, the low-latency traffic information may include, for example, TID / AC information for low-latency traffic.

[0319] Additionally or alternatively, the low-latency traffic information field may be classified as a separate feedback type and transmitted separately from MAPC-related information. If the low-latency traffic-related information is classified as a separate feedback type and indicated through a separate Per AID TID information field within a multi-STA BA frame and / or included in a separate Per AID TID information subfield, the above-described low-latency traffic information field may be omitted.

[0320] Status Code: Accept / Reject / Recommendation information for a multi-AP selection (or cooperation notification) request. For example, a DAP selected by SAP can accept or reject a multi-AP selection request based on whether it requires a cooperation trigger. The status code information can replace the TXOP sharing request (or cooperation request) information described above.

[0321] For example, a status code may indicate acceptance or success (e.g., SUCCESS).

[0322] For example, a status code can indicate a rejection or a rejection with a suggestion. For example, the status code information can include a rejection code that includes the reason for the rejection (e.g., REJECTED_BAD_SUPPORTED_CHANNELS). For example, the status code information can include a rejection code that includes a suggestion (e.g., REJECTED_WITH_SUGGESTED_CHANGES).

[0323] If the status code value includes rejection and / or proposal, the status code information may further include information for a new selection request. That is, a DAP that receives a selection request frame may transmit additional information, such as the operating channel, operating bandwidth, requested TXOP duration, and / or low-latency traffic information described above.

[0324] - Participation Indication (1 bit): Indicates with 1 bit whether to participate in MAPC-based operations derived from ICF.

[0325] For example, the participation indication information may indicate whether the DAP(s) requested to respond from SAP currently requires (or will participate in) a single MAPC-based action directed by SAP.

[0326] For example, a participation indication information (or report) bit set to 0 may indicate that the DAP(s) do not participate in the induced MAPC-based operation. A participation indication information (or report) bit set to 1 may indicate that the DAP(s) participate in the induced MAPC-based operation.

[0327] - Participation indication (n bits): Indicates with n bits whether to participate in MAPC-based operations derived from ICF.

[0328] Participation indication information may indicate whether the DAP(s) that have received a response request from SAP currently require (or participate in) a single MAPC-based action directed by SAP.

[0329] For example, a participation instruction (or report) based on n bits could be indicated as follows:

[0330] - Bit value 0: Indicates that the DAP(s) do not participate in the derived MAPC-based operation.

[0331] - Bit value 1: Indicates that the DAP(s) participate in derived MAPC-based operations.

[0332] - Bit value 2: Indicates that the DAP(s) include a proposal to participate in derived MAPC-based operations.

[0333] - Bit value 3: Indicates that the DAP(s) contain a reason why they cannot participate in the induced MAPC-based operation.

[0334] Additionally or alternatively, the participation indication information may indicate whether the Co-BF operation is possible based on a bitmap of n bits to indicate whether sounding to non-TB ICFs (e.g., Co-BF invite frames) received from the SAP in the Co-BF operation and / or non-AP STAs associated with the SAP (i.e., Co-BF target STAs of the SAP) included in the TB ICF succeeded / failed.

[0335] For example, the participation indication information can indicate whether a DAP (or a Co-BF cooperative participating (coordinated) AP) successfully or unsuccessfully performed sounding for non-AP STAs associated with up to three SAPs (or Co-BF cooperative coordinating APs) based on a 3-bit bitmap. For example, bitmap “000” can indicate that sounding for all three STAs was successful. For example, bitmap “001” can indicate that sounding for the first and second STAs was successful, but sounding for the third STA was failed. In this case, even if the number of target STAs indicated by the ICF transmitted by the SAP is less than the maximum number of bits in the bitmap, bits as many as the number of target STAs can be defined to be used based on the LSB and / or MSB of the participation indication bitmap field. For example, if information about only one target STA is included in the ICF, only one bit of the LSB or MBS in the three-bit bitmap may be set to 0 or 1, and the remaining bits may be reserved or set to 0.

[0336] Additionally or alternatively, a participation indication field of the same format as the Multi-AP Cooperation Type field that can be included in the ICF transmitted by the SAP may indicate participation in a specific (cooperation) mode. For example, if the Multi-AP Cooperation Type field is defined as 3 bits and indicates Co-TDMA operation from the SAP, the DAP may respond by setting the participation indication information in the same bits if it wishes to participate in Co-TDMA, or by setting all values ​​to 0 if it does not wish to participate.

[0337] For example, if the Multi-AP Cooperation Type field is defined as n bits, indicating a specific scheme in a bitmap fashion, a DAP can respond by setting it to 1 for the scheme it wishes to participate in, or by setting all values ​​to 0 if it does not wish to participate.

[0338] - Preferred Tx Power: Indicates the maximum Tx power that the DAP desires / prefers.

[0339] For example, a DAP can determine its own appropriate preferred Tx power that does not interfere with other APs / STAs based on the maximum Tx power information delivered by the SAP, In-BSS STA, and / or OBSS STA information.

[0340] -In-BSS STA information: Based on the MAPC method in which SAP and DAP perform simultaneous transmission / reception, such as Co-SR and Co-BF, DAP indicates information about the target STA to perform DL / UL transmission and / or information about all connected STAs.

[0341] For example, there may be as many In-BSS STA information fields as the number of STAs indicated in the Number Of Co-BF Users information described below.

[0342] For example, In-BSS STA information may include identifiers and / or capability information of all STAs that have established a connection with the DAP. For example, In-BSS STA information may include AIDs and / or MAC addresses of the STAs. For example, In-BSS STA information may include MIMO and / or RF capability information of the STAs.

[0343] For example, the In-BSS STA information may include the identifier and / or capability information of a target STA that is attempting to perform DL / UL transmission based on the MAPC method among the STAs that have established a connection with the DAP. For example, the In-BSS STA information may include the AID and / or MAC address of the target STA. For example, the In-BSS STA information may include MIMO and / or RF capability information of the target STA.

[0344] For example, the In-BSS STA information may include identifiers for In-BSS STAs that wish to participate in the multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation.

[0345] - Target STA version information (or PHY version identifier): Indicates the PHY version information of the target STA that is the target of the Co-SR operation of each AP.

[0346] For example, the target STA version information may indicate the PHY version information of the target STA that is the target of the Co-SR transmission during the Co-SR transmission period.

[0347] For example, a 1-bit target STA version information field may be defined. In this case, setting the bit value of the target STA version information field to 0 may indicate that the target STA is an EHT STA. Setting the bit value of the target STA version information field to 1 may indicate that the target STA is an UHR STA.

[0348] For example, a 3-bit target STA version information (or PHY version identifier) ​​field may be defined considering a future generation protocol. In this case, setting the bit value of the target STA version information field to 0 may indicate that the target STA is an EHT STA. Setting the bit value of the target STA version information field to 1 may indicate that the target STA is a UHR STA. Setting the bit value of the target STA version information field to 2 may be to-be-determined (TBD). The remaining bit values ​​(e.g., bit value n) may be reserved.

[0349] - Control information type (or feedback type): Indicates the purpose and / or type of MAPC-related information contained within the current frame.

[0350] In some implementations, the control information type information may indicate that the frame containing the information is to be transmitted as a response frame in MAPC cooperation and / or a specific (cooperative) scheme (e.g., Co-TDMA / Co-SR / Co-BF).

[0351] For example, the control information type information can indicate for what purpose the frame containing the corresponding information is transmitted in the MAPC operation, and based on the control information type information, the receiving STA can know what information is included in the received frame. For example, the control information type field having bit value 0 can indicate that the frame containing the corresponding field is an ICF in MAPC. The control information type field having bit value 1 can indicate that the frame containing the corresponding field is an ICR in MAPC. The control information type field having bit value 2 can indicate that the frame containing the corresponding field is a cooperative trigger frame in MAPC (e.g., MU-RTS TXS TF in Co-TDMA).

[0352] For example, the control information type information can indicate that the frame including the information is a frame transmitted in a specific manner for a specific purpose, and based on the control information type information, the receiving STA can know what information is included in the received frame. For example, the control information type field having bit value 0 can indicate that the frame including the field is an ICF in Co-TDMA / Co-SR / Co-BF. The control information type field having bit value 1 can indicate that the frame including the field is an ICR in Co-TDMA / Co-SR / Co-BF. The control information type field having bit value 2 can indicate that the frame including the field is a cooperative trigger frame in Co-TDMA / Co-SR / Co-BF (e.g., MU-RTS TXS TF in Co-TDMA).

[0353] For example, the control information type information may indicate a type related to the purpose for which the M-BA (or multi-STA BA) frame containing the corresponding information was transmitted in a specific function (e.g., Co-BF). For example, the control information type information having bit value 0 may indicate that the frame containing the corresponding information was transmitted as a response frame to a Co-BF invitation frame in the transmission section of the Co-BF. The control information type information having bit value 1 may indicate that the frame containing the corresponding information was transmitted as a response frame to a Co-BF sounding invitation frame in the sounding section of the Co-BF.

[0354] Additionally or alternatively, the control information type information may indicate the type of a specific UHR function and / or MAPC scheme, and / or the control information for which the corresponding M-BA (or multi-STA BA) frame is transmitted. In this case, the meaning of each bit value of the control information type information may be as follows:

[0355] - Bit value 0: Co-existence

[0356] - Bit value 1: low latency traffic (LLT)

[0357] - Bit value 2: Reserved (or, Co-BF feedback)

[0358] - Bit value 3: ICR role in Co-TDMA (or, Co-TDMA feedback)

[0359] - Bit value 4: Response frame to Co-BF sounding invitation frame in the sounding section of Co-BF (or Co-SR feedback)

[0360] - Bit value 5: Response frame to Co-BF invitation frame in the transmission section of Co-BF

[0361] - Bit value 6: Response frame to Co-SR invitation frame in Co-SR transmission section.

[0362] Additionally or alternatively, the control information type information may indicate that the frame containing the information is a frame transmitted for the purpose of at least one of various UHR functions (e.g., CoEx, IDC, NPCA, DPS, and / or MAPC).

[0363] For example, the control information type information may include information indicating the purpose / type for which the multi-STA BA frame was transmitted (i.e., purpose / type information), which may be utilized as ICR in dynamic power saving (DPS), inter-device coexistence (IDC), non-primary channel access (NPCA), and / or multi-AP coordination (MAPC).

[0364] For example, a bit value of the purpose / type information set to 0 may indicate that the multi-STA BA frame is an M-BA (or multi-STA BA) for multi-AP cooperation operation. A bit value of the purpose / type information set to 1 may indicate that the multi-STA BA frame is an M-BA (or multi-STA BA) for DPS operation. A bit value of the purpose / type information set to 2 may indicate that the multi-STA BA frame is an M-BA (or multi-STA BA) for IDC operation. A bit value of the purpose / type information set to 3 may indicate that the multi-STA BA frame is an M-BA (or multi-STA BA) for NPCA operation. Other bit values ​​may be reserved.

[0365] For example, a bit value of the purpose / type information set to 0 may indicate that the multi-STA BA frame is an M-BA (or multi-STA BA) for IDC. A bit value of the purpose / type information set to 1 may indicate that the multi-STA BA frame is an M-BA (or multi-STA BA) for low-latency traffic forwarding. Bit value 2 may be reserved. A bit value of the purpose / type information set to 3 may indicate that the multi-STA BA frame is an M-BA (or multi-STA BA) for feedback forwarding in Co-TDMA operation. A bit value of the purpose / type information set to 4 may indicate that the multi-STA BA frame is an M-BA (or multi-STA BA) for feedback forwarding in Co-BF operation. A bit value of the purpose / type information set to 5 may indicate that the multi-STA BA frame is an M-BA (or multi-STA BA) for feedback forwarding in Co-SR operation.

[0366] Additionally or alternatively, the control information type information may include a 4-bit bitmap. Each bit in the bitmap may indicate a specific function (e.g., DPS, IDC, NPCA, MAPC). For example, an example of a method for indicating the UHR function type based on a combination of bits (bitmap) is as follows:

[0367] - B0: MAPC

[0368] - B1: DPS

[0369] - B2: IDC

[0370] - B3: NPCA

[0371] In this case, the bitmap “1100” may indicate that it contains instructions / related information for MAPC and DPS operations.

[0372] - MAPC type: Indicates a multi-AP cooperation method such as Co-TDMA, Co-SR, and Co-BF.

[0373] For example, MAPC type information set to bit value 0 may not indicate any multi-AP cooperation scheme. MAPC type information set to bit value 1 may indicate Co-TDMA. MAPC type information set to bit value 2 may indicate Co-SR. MAPC type information set to bit value 3 may indicate Co-BF.

[0374] As another example, MAPC type information set to bit value 0 may indicate Co-TDMA. MAPC type information set to bit value 1 may indicate Co-SR. MAPC type information set to bit value 2 may indicate Co-BF.

[0375] - Allow additional LTFs (1 bit): Indicates whether it is allowed to obtain channel estimation performance gains by utilizing more LTFs than the total number of streams.

[0376] For example, if the number of LTFs corresponding to the total number of streams is defined as in below, channel estimation performance can be improved by utilizing LTFs greater than the corresponding number of LTFs. This allows the transmitter to transmit twice as many LTF symbols as when applying the minimum required number of LTFs, and the receiver can obtain a combining gain, thereby obtaining a channel estimation performance gain of 3 dB.

[0377]

[0378] - Co-BF User Count (1 or 2 bits): Indicates the number of Co-BF STAs that the DAP wants to support. For example, if the Co-BF user count information is expressed as 1 bit, setting the Co-BF user count information to bit value 0 can indicate that the DAP wants to support one STA. Setting the Co-BF user count information to bit value 1 can indicate that the DAP wants to support two STAs.

[0379] For example, if the Co-BF user count information is expressed with 2 bits, setting the bit value of the Co-BF user count information to 0 may indicate that the DAP intends to support one STA. Setting the bit value of the Co-BF user count information to 1 may indicate that the DAP intends to support two STAs. Setting the bit value of the Co-BF user count information to 2 may indicate that the DAP intends to support three STAs. Bit value 3 may be reserved.

[0380] - MCS (5 bits): Indicates MCS information for Co-BF STAs to be supported by DAP.

[0381] For example, there may be as many MCS fields as the number of STAs indicated by the Co-BF user number information described above.

[0382] - NSS (number of spatial streams) for Co-BF users: Indicates NSS information for Co-BF STAs to be supported by DAP.

[0383] For example, there may be as many NSS fields for Co-BF users as the number of STAs indicated by the Co-BF user number information described above.

[0384] Additionally or alternatively, since only one NSS value / count is allowed within a single BSS, the NSS field may only contain one for a Co-BF user.

[0385] -2xLDPC (1 bit): Indicates 2xLDPC information for each Co-BF STA to be supported by the DAP.

[0386] For example, there may be as many 2xLDPC fields as the number of STAs indicated by the Co-BF user number information described above.

[0387] - Number of data OFDM symbols (9 bits): Indicates the number of data OFDMA symbols that the DAP wants / needs.

[0388] For example, the number of data OFDM symbols can be a value selected by the DAP within the range of the minimum number of OFDM symbols and the maximum number of OFDM symbols received from the SAP.

[0389] For example, SAP can set the appropriate PPDU length and / or MCS / NSS for Co-BF transmission based on information about the number of data OFDM symbols.

[0390] - Bandwidth (3 bits): Indicates the bandwidth available to the DAP within the bandwidth delivered / instructed from the SAP.

[0391] - Punctured Channel Information (5 bits): Indicates the non-OFDMA puncturing pattern of the DAP within the non-OFDMA puncturing pattern transmitted / indicated from the SAP.

[0392] - GI+LTF size (2 bits): Indicates the GI+LTF suggested by DAP among the GI+LTF sizes that are equal to or more robust than the GI+LTF size transmitted / indicated from SAP.

[0393] - ICF / ICR Exchange required (or, ICF / ICR requested): Indicates whether an additional sequence is required to transmit ICF to the connected STA before triggering Co-TDMA / SR / BF transmission.

[0394] For example, the ICF / ICR exchange request information may indicate whether an ICF / ICR exchange procedure is required to transition an EMLSR STA among the connected STAs from a listening mode to a frame exchange mode.

[0395] For example, the ICF / ICR exchange request information may indicate whether an ICF / ICR exchange procedure is required to transition a DPS STA among the connected STAs from a low-capability mode to a high-capability mode.

[0396] For example, the ICF / ICR exchange request information may indicate that an ICF / ICR exchange procedure is required to switch a DUO STA among the connected STAs.

[0397] -TXOP Return Indication: Indicates that the frame containing this information / field is a frame for the purpose of TXOP return.

[0398] For example, the TXOP return information may indicate, based on a bit of 1, that the associated frame is a frame transmitted for the purpose of TXOP return. The TXOP return information having a bit value of 0 may indicate that the associated frame is not a frame transmitted for the purpose of TXOP return. The TXOP return information having a bit value of 1 may indicate that the associated frame is a frame transmitted for the purpose of TXOP return.

[0399] Additionally or alternatively, when the TXOP return indication is set to enable (or 1), the remaining feedback information and / or fields related to Co-TDMA operation may be reserved or set to specific values ​​(e.g., all 0s or all 1s).

[0400] Additionally or alternatively, instead of the associated frame defining / containing the TXOP Return Indication bit, some or all of the remaining feedback information related to the Co-TDMA operation in the associated frame may be set to a specific value (e.g., all 0s or all 1s). For example, the value of the MAPC Type field may be set to the default value or 0 to indicate that the associated frame is transmitted for the purpose of TXOP Return.

[0401] Additionally or alternatively, one of the MAPC type values ​​may be defined and / or set as a value for TXOP return. For example, the value of the 1-bit participation indication bit may be set to 0 to indicate termination of participation and / or to indicate that the associated frame has been transmitted for the purpose of TXOP return.

[0402] Additionally or alternatively, the value of the n-bit participation indication field may be set to 0 to indicate termination of participation, or one of the values ​​of the participation indication fields may be defined and / or set to a value for returning TXOP. For example, the value of the Requested TXOP Duration field may be set to 0 to indicate that all TXOP / time allocated from SAP has been used and / or to return the allocated TXOP / time.

[0403] - Reason for Rejection: Indicates the reason why the cooperative participating AP refused to participate in Co-BF / SR / TDMA cooperation by indicating non-participation through the above-mentioned participation instruction.

[0404] For example, if a 3-bit (or 8-bit) rejection reason field is defined, the rejection reason field can indicate the rejection reason as follows:

[0405] - Bit value 0 (medium unavailability): Indicates not to participate in Co-BF / SR / TDMA transmission because the corresponding medium is busy. For example, medium unavailability may include unavailable due to coexistence in multi-AP cooperation. In this case, bit value 0 may indicate not to participate in Co-BF / SR / TDMA-based cooperation because an unavailable period is expected due to coexistence within the DAP and / or the DAP's target STA.

[0406] - Bit value 1 (inappropriate STA selected): Indicates that the STAs selected by the Co-BF cooperation coordination AP transmitted in the Co-BF invitation frame are not participating in the Co-BF transmission because they are in a state and / or position that is not suitable for performing the Co-BF transmission from the perspective of the Co-BF cooperation participating AP.

[0407] - Bit value 2 (Inappropriate CFO Synchronization Role): Indicates that the CFO synchronization role indicated by the Co-BF coordination AP (e.g., synchronization criteria / follower indication in the Co-BF invitation frame) is not appropriate and therefore cannot participate in the Co-BF transmission.

[0408] - Bit value 3 (Misalignment of Co-BF parameters): Indicates that the key parameters for Co-BF transmission (e.g. bandwidth / puncturing pattern / Nss) that can be included in the Co-BF invitation frame are not appropriate, and therefore, the Co-BF transmission cannot be participated in.

[0409] - Bit value 4 (Undefined Cause): Indicates that the Co-BF / SR / TDMA procedure cannot be participated in for a reason not specifically defined, and / or that the procedure cannot be participated in without specifying a specific reason.

[0410] Additionally or alternatively, if a 5-bit rejection cause field is defined, the rejection cause field may indicate the rejection cause based on a bitmap as follows. Bitmap-based indication has the advantage of being able to convey multiple causes simultaneously. For example, bit 0 of the bitmap may be associated with “medium unavailable (or, unable to participate in multi-AP cooperation due to in-device coexistence)”. Bit 1 may be associated with “inappropriate ST selected”. Bit 2 may be associated with “inappropriate CFO synchronous role”. Bit 3 may be associated with “mismatch of sounding parameters”. Bit 4 may be associated with “undefined cause”.

[0411] Additionally or alternatively, if a 4-bit rejection cause field is defined, the rejection cause field may indicate the rejection cause based on a bitmap as follows. In this case, “undefined cause” may be indicated by setting all bits of the bitmap to 1 or all bits to 0. For example, bit 0 of the bitmap may be associated with “medium unavailable due to IDC issue.” Bit 1 may be associated with “inappropriate STA selected.” Bit 2 may be associated with “inappropriate CFO synchronous role.” Bit 3 may be associated with “mismatch of sounding parameters.”

[0412] - Unavailability Period (10 bits): Indicates the unavailability period during which the responding AP is unavailable for various reasons.

[0413] For example, the unavailability period information may indicate the period of time in units of 64 microseconds that the responding AP transmitting the response frame is unavailable.

[0414] For example, an unavailability period information set to a value of 0 may indicate that the responding AP is available.

[0415] Additionally or alternatively, setting the unavailability period information to a maximum value (e.g., 1023 for 10 bits) may indicate that the responding AP will be unavailable for an indefinite period (or a substantially long period).

[0416] Hereinafter, various embodiments of a method for including information for MAPC in a multi-STA BA frame and a structure of a multi-STA BA frame based on the method are described.

[0417] In some implementations, a specific value in the AID TID information subfield may be utilized to indicate whether a related multi-STA BA frame contains MAPC information.

[0418] For example, the format of the AID TID information subfield included in the AID TID-specific information subfield(s) within the BA information field may be as shown in Fig. 13. In order to utilize a multi-STA BA frame as an ICR for MAPC, at least one field among the AID11, Ack type, or TID subfields present within the AID TID information subfield may be set to a specific value.

[0419] Option 1) For example, in order for a multi-STA BA frame to be transmitted between unassociated APs, the value of the AID11 subfield may be set to 2045. However, in order to utilize / identify the multi-STA BA frame as an ICR for MAPC, the value of the AID11 subfield may be set to a specific value other than 2045 (e.g., reserved values ​​such as 0, 1, 2008 - 2044, or an AP ID assigned by a DAP to a SAP). That is, an AP performing MAPC operation may indicate, based on the setting of the AID11 subfield, that the concerned multi-STA BA frame is a multi-STA BA frame containing information for MAPC-based operation (i.e., MAPC information) in response to a TF received from a neighboring AP. Additionally or alternatively, if the AID11 subfield is used to specify that the associated multi-STA BA frame is a multi-STA BA frame for MAPC, the Ack Type subfield and / or the TID subfield may i) be reserved, ii) contain control information for MAPC (e.g., common information and / or MAPC scheme specific information), or iii) be set to values ​​that should already be included.

[0420] Option 2) Additionally or alternatively, reserved values ​​for combinations of Ack Type subfield and TID subfield values ​​when the value of the AID11 subfield is not 2045 (e.g., Table 7) may be utilized to indicate that the associated multi-STA BA frame contains information about MAPC and / or is intended for MAPC operation. shows the contexts according to combinations of Ack Type subfield and TID subfield values ​​when the value of the AID11 subfield is not 2045:

[0421]

[0422] For example, the Ack Type may be set to one of the values ​​0 and TID 8 to 15 to indicate that the relevant multi-STA BA frame is a multi-STA BA frame in MAPC operation. Additionally, when a reserved value for a combination of the Ack Type subfield and the TID subfield values ​​is utilized to indicate that information for MAPC is included in the relevant multi-STA BA frame, the BlockAck Starting Sequence Control subfield and / or the BA Bitmap subfield within the AID TID-specific information subfield(s) may be replaced with a subfield including information for MAPC operation. For example, as shown in FIG. 21, an (UHR) control information subfield (or feedback subfield) including information for MAPC operation may be included instead of the BlockAck Starting Sequence Control subfield and / or the BA Bitmap subfield. FIG. 21 illustrates an example of an (UHR) control information subfield format according to an embodiment of the present disclosure.

[0423] Referring to FIG. 21, the (UHR) control information subfield may include an ID subfield and a control information subfield. The ID subfield may indicate which of various functions (e.g., MAPC, IDC, DPS, NPCA) the related multi-STA BA frame was transmitted for, and / or may indicate which (feedback) information related to which function is included in the control information subfield for various functions (e.g., MAPC, IDC, DPS, NPCA). For example, based on the function indicated by the ID subfield (e.g., MAPC), the (feedback) information related to that function may be included in the control information subfield. For example, one or more contents included in the MAPC information may be included as new fields and / or bits within the control information subfield. In this case, the size of the BA start sequence control subfield and / or the BA bitmap subfield may be the size of the (UHR) control information field itself.

[0424] Examples of utilizing the BA Start Sequence Control subfield and / or the BA Bitmap subfield within the AID TID-specific information subfield(s) to include information for individual MAPC schemes (e.g., Co-TDMA / SR / BF) are shown in FIGS. 22 through 35 below.

[0425] FIG. 22 illustrates a first example of a multi-STA BA frame format including Co-TDMA related feedback information according to an embodiment of the present disclosure.

[0426] Referring to FIG. 22, based on whether the AID TID Info subfield is set to a specific value (e.g., a reserved value such as 0, 1, 2008 - 2044 in the AID11 subfield, or an AP ID assigned by the DAP to the SAP), it may be indicated that the associated multi-STA BA frame includes MAPC information and / or feedback information. Additionally or alternatively, the Ack type of the AID TID Info subfield may be set to 0, and the TID may be set to a value from 8 to 15. When it is indicated that the associated multi-STA BA frame includes MAPC information and / or feedback information, i) the BA Start Sequence Control subfield may include a Number of Info subfield, and ii) one or more feedback subfields may be included instead of the BA Bitmap subfield. For example, at least one reserved bit may be used in the BA Start Sequence Control subfield to include the Number of Info subfield.

[0427] The Number of Info subfield may indicate the number of feedback subfields included in the current BA bitmap subfield. Each feedback subfield may include information about a control information type (or feedback type) and related feedback information. The control information type (or feedback type) may indicate the type / function of the related feedback information (e.g., MAPC, IDC, DPS, NPCA). Additionally or alternatively, MAPC may be replaced with one indicating a specific cooperation method (e.g., Co-BF, Co-SR, Co-TDMA, etc.). Information about the length of the feedback information according to each feedback type may or may not be included in the related feedback subfield. For example, if the length of the feedback information all has a fixed value, the length information may be omitted for optimization.

[0428] FIG. 23 illustrates a second example of a multi-STA BA frame format including Co-TDMA related feedback information according to an embodiment of the present disclosure.

[0429] Referring to FIG. 23, based on the AID TID Info subfield being set to a specific value (e.g., a reserved value such as 0, 1, 2008 - 2044 in the AID11 subfield, or an AP ID assigned by the DAP to the SAP), it may be indicated that the associated multi-STA BA frame includes MAPC information and / or feedback information. Additionally or alternatively, the Ack type of the AID TID Info subfield may be set to 0, and the TID may be set to a value from 8 to 15. When it is indicated that the associated multi-STA BA frame includes MAPC information and / or feedback information, i) the BA Start Sequence Control subfield may include a Control Information Type (or Feedback Type) subfield, and ii) a Feedback subfield may be included instead of the BA Bitmap subfield, including feedback information related to the Control Information Type (or Feedback Type). For example, at least one reserved bit may be used in the BA Start Sequence Control subfield to include the Control Information Type (or Feedback Type) subfield. The control information type (or feedback type) may indicate the type / function of the related feedback information (e.g., MAPC, IDC, DPS, NPCA). Additionally or alternatively, reserved bits (e.g., 8 bits) may be used in the BA Start Sequence Control subfield to include a Status Code subfield. The Status Code subfield may indicate Accept / Reject / Recommendation information for a multi-AP selection (or cooperation announcement) request.

[0430] In some implementations, the control information type (or feedback type) may indicate a specific MAPC type (or cooperation scheme) (e.g., Co-TDMA / Co-SR / Co-BF) instead of indicating the type / function of the related feedback information as MAPC. For example, if the control information type (or feedback type) indicates Co-TDMA as the specific MAPC type (or cooperation scheme), the feedback subfield (or BA bitmap subfield) includes Co-TDMA related feedback information, and the MAPC type field may be omitted in the Co-TDMA related feedback information.

[0431] FIG. 24 illustrates a third example of a multi-STA BA frame format including Co-TDMA related feedback information according to an embodiment of the present disclosure.

[0432] Referring to FIG. 24, based on whether the AID TID Info subfield is set to a specific value (e.g., a reserved value such as 0, 1, 2008 - 2044 in the AID11 subfield, or an AP ID assigned by the DAP to the SAP), it may be indicated that the associated multi-STA BA frame includes MAPC information and / or feedback information. Additionally or alternatively, the Ack type of the AID TID Info subfield may be set to 0, and the TID may be set to a value from 8 to 15. When it is indicated that the associated multi-STA BA frame includes MAPC information and / or feedback information, i) the BA Start Sequence Control subfield may include a presence bitmap subfield (12 bits), and ii) a feedback subfield may be included instead of the BA bitmap subfield, which includes feedback information indicated by the presence bitmap. For example, at least one reserved bit may be used in the BA Start Sequence Control subfield to include the presence bitmap subfield. As another example, at least one bit in the Number of Info subfield (4 bits) and / or the Reserved field (8 bits) in the BA Start Sequence Control subfield may be used to include a presence bitmap subfield (12 bits => 8 bits). The presence bitmap may indicate the type / function (e.g., MAPC, IDC, DPS, NPCA) of the feedback information contained in the feedback subfield. Additionally or alternatively, MAPC may be replaced with one indicating a specific cooperation scheme (e.g., Co-BF, Co-SR, Co-TDMA, etc.).

[0433] FIG. 25 illustrates a first example of a multi-STA BA frame format including Co-SR related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 22 applies equally to FIG. 25 , except that the MAPC type (or cooperative scheme) may be set to Co-SR instead of Co-TDMA.

[0434] FIG. 26 illustrates a second example of a multi-STA BA frame format including Co-SR related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 23 applies equally to FIG. 26 , except that the MAPC type (or cooperative scheme) may be set to Co-SR instead of Co-TDMA.

[0435] In some implementations, the control information type (or feedback type) may indicate a specific MAPC type (or cooperative scheme) (e.g., Co-TDMA / Co-SR / Co-BF) instead of indicating the type / function of the related feedback information as MAPC. For example, if the value 5 of the control information type (or feedback type) is defined as Co-SR, and the value of the control information type (or feedback type) is set to 5, the feedback subfield (or BA bitmap subfield) includes Co-SR related feedback information, and the MAPC type field may be omitted in the Co-SR related feedback information. In addition, the target STA version (or PHY version identifier) ​​field may be defined as 3 bits to indicate the PHY version of the target STA that is the target of the Co-SR transmission.

[0436] FIG. 27 illustrates a third example of a multi-STA BA frame format including Co-SR related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 24 applies equally to FIG. 27, except that the MAPC type (or cooperative scheme) may be set to Co-SR instead of Co-TDMA.

[0437] FIG. 28 illustrates a first example of a multi-STA BA frame format including Co-BF-related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 22 applies equally to FIG. 28, except that the MAPC type (or cooperative scheme) may be set to Co-BF instead of Co-TDMA.

[0438] According to various embodiments, Co-BF related feedback information may include a Co-BF common information field and / or a Co-BF user information field.

[0439] FIG. 29 illustrates a second example of a multi-STA BA frame format including Co-BF-related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 23 applies equally to FIG. 29 , except that the MAPC type (or cooperative scheme) may be set to Co-BF instead of Co-TDMA.

[0440] According to various embodiments, since the MAPC feedback information field including some information other than the Co-BF common information field and / or the Co-BF user information field may have a length exceeding 4 octets, the value of the fragment number subfield may be set according to the amount / length of information included in the MAPC feedback information field and / or the number of target STAs. For example, as shown in , when the value of the fragment number subfield is B3 = 0, B2-B1 = 3, B0 = 0, the BA bitmap subfield (or feedback subfield) has a length of 4 octets, but when the value of the fragment number subfield is B3 = 0, B2-B1 = 1, B0 = 0, the BA bitmap subfield (or feedback subfield) may have a length of 16 octets. Accordingly, as in FIG. 30, the fragment number subfield may be set to a length of 16 octets so that Co-BF common information and Co-BF user information are included together within one AID TID-specific information subfield. Additionally or alternatively, the fragment number subfield may be indicated to be a length of 8 octets (or, B3 = 0, B2-B1 = 0, B0 = 0), and one AID TID-specific information subfield may include Co-BF user information for one or two STAs.

[0441] FIG. 30 illustrates a third example of a multi-STA BA frame format including Co-BF-related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 23 may be equally applicable to FIG. 30.

[0442] According to various embodiments, the control information type (or feedback type) may indicate a specific MAPC type (or cooperative scheme) (e.g., Co-TDMA / Co-SR / Co-BF) instead of indicating the type / function of the related feedback information as MAPC. For example, if the value 4 of the control information type (or feedback type) is defined as Co-BF, and the value of the control information type (or feedback type) is set to 4, the feedback subfield (or BA bitmap subfield) includes Co-BF related feedback information, and the MAPC type field may be omitted in the Co-BF related feedback information.

[0443] Based on the setting of the Fragment Number field (e.g., B3 = 0, B2-B1= 1, B0 = 0), the AID TID-specific information subfield may include a 128-bit Co-BF feedback information field (instead of the BA bitmap subfield). In this case, the STA-related information in the Co-BF user information field may include information corresponding to up to three STAs. That is, the Co-BF user information field may include at least one combination of STA-ID, MCS, Nss, 2xLDPC and / or at most three combinations of STA-ID, MCS, Nss, 2xLDPC.

[0444] FIGS. 31A and 31B illustrate a fourth example of a multi-STA BA frame format including Co-BF-related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 23 may be equally applicable to FIG. 31 .

[0445] Referring to FIGS. 31a and 31b, each of a plurality of AID TID-specific information subfields (e.g., AID TID-specific information-(3) and AID TID-specific information-(4)) may individually include Co-BF common information or Co-BF user information. In this case, there may be one or more AID TID-specific information subfields including Co-BF user information. Additionally or alternatively, when the Info Type field indicates user information, fields such as participation instruction and ICF request may be omitted, and only information corresponding to Co-BF user information (e.g., STA-ID, MCS, Nss, 2xLDPC) may be included in the AID TID-specific information subfields including Co-BF user information. In this case as well, there may be one or more AID TID-specific information subfields including Co-BF user information. Additionally or alternatively, the Co-BF user information may be included immediately following the AID TID specific information subfield containing the Co-BF common information, and thus there may be one or more AID TID specific information subfields containing the Co-BF user information.

[0446] FIGS. 32a and 32b illustrate a fifth example of a multi-STA BA frame format including Co-BF-related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 23 may be equally applicable to FIGS. 32a and 32b.

[0447] According to various embodiments, since the Co-BF user information field, which may include at least one combination of STA-ID, MCS, Nss, 2xLDPC and up to three combinations of STA-ID, MCS, Nss, 2xLDPC, may have a long length exceeding 4 octets, the value of the fragment number subfield may be set based on the amount / length of information included in the feedback information (or feedback subfield / BA bitmap subfield).

[0448] For example, as shown in Fig. 32a, the fragment number subfield may be set to B3 = 0, B2-B1 = 3, B0 = 0 in order for the AID TID-specific information subfield-(3) to include Co-BF common information, and based on the setting of the fragment number subfield value, the BA bitmap subfield (or feedback subfield) may have a length of 4 octets.

[0449] In Fig. 32a, at least one of the (sub)fields / information elements included in the Co-BF feedback information may be excluded. For example, Co-BF user information may be excluded from the Co-BF feedback information.

[0450] On the other hand, as shown in FIG. 32b, the AID TID-specific information subfield-(4) includes a fragment number subfield set to B3 = 0, B2-B1 = 0, B0 = 0 based on the amount / length of information included in the feedback information (or feedback subfield / BA bitmap subfield) and / or the number of target STAs, and based on the setting of the fragment number subfield value, the BA bitmap subfield (or feedback subfield) can have a length of 8 octets. For example, if the feedback information (or feedback subfield / BA bitmap subfield) includes information about only one target STA, the fragment number subfield can indicate a length of 4 octets (or set to B3 = 0, B2-B1 = 3, B0 = 0).

[0451] In Fig. 32b, at least one of the (sub)fields / information elements included in the Co-BF feedback information may be excluded. For example, Co-BF common information may be excluded from the Co-BF feedback information.

[0452] FIGS. 33a and 33b illustrate a sixth example of a multi-STA BA frame format including Co-BF-related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 23 may be equally applicable to FIG. 33.

[0453] Referring to FIGS. 33a and 33b, the Co-BF user information field may be individually included in two or more AID TID-specific information subfields (e.g., AID TID-specific information-(4), AID TID-specific information-(5), and AID TID-specific information-(6)) for each STA's information. That is, there may be one or more AID TID-specific information subfields containing Co-BF feedback information, and there may also be one or more AID TID-specific information subfields containing Co-BF user information.

[0454] In Fig. 33a, at least one of the (sub)fields / information elements included in the Co-BF feedback information may be excluded. For example, Co-BF user information may be excluded from the Co-BF feedback information.

[0455] In Fig. 33b, at least one of the (sub)fields / information elements included in the Co-BF feedback information may be excluded. For example, Co-BF common information may be excluded from the Co-BF feedback information.

[0456] According to various embodiments, one or more Co-BF user information fields including a combination of STA-ID, MCS, Nss, and 2xLDPC may be separately included within a 32-bit (4 octet long) Co-BF feedback information field.

[0457] For example, as shown in FIG. 33, up to four AID TID-specific information subfields including a Co-BF feedback information field having a length of 4 octets may include Co-BF common information and / or Co-BF user information.

[0458] FIG. 34 illustrates a seventh example of a multi-STA BA frame format including Co-BF-related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 24 applies equally to FIG. 34 , except that the MAPC type (or cooperative scheme) may be set to Co-BF instead of Co-TDMA.

[0459] Referring to Fig. 34, information per AID TID may include one feedback information. The BA start sequence control subfield may include a presence bitmap indicating the type / function (e.g., MAPC, IDC, DPS, NPCA) of the feedback information included in the feedback subfield. For example, at least one reserved bit may be used in the BA start sequence control subfield to include a presence bitmap subfield. As another example, at least one bit in the Number of Info subfield (4 bits) and / or the Reserved field (8 bits) in the BA start sequence control subfield may be used to include a presence bitmap subfield (12 bits).

[0460] FIGS. 35a and 35b illustrate an eighth example of a multi-STA BA frame format including Co-BF-related feedback information according to an embodiment of the present disclosure. Unless otherwise specified, the description of FIG. 24 applies equally to FIG. 35 , except that the MAPC type (or cooperative scheme) may be set to Co-BF instead of Co-TDMA.

[0461] Referring to FIGS. 35a and 35b, one or more AID TID-specific information subfields (e.g., AID TID-specific information-(3) and AID TID-specific information-(4)) may individually include Co-BF common information and / or Co-BF user information. At this time, there may be one or more AID TID-specific information subfields including Co-BF user information. The BA start sequence control subfield may include a presence bitmap indicating the type / function (e.g., MAPC, IDC, DPS, NPCA) of feedback information included in the feedback subfield. For example, at least one reserved bit may be used in the BA start sequence control subfield to include a presence bitmap subfield. As another example, at least one bit in the Number of Info subfield (4 bits) and / or the Reserved field (8 bits) in the BA start sequence control subfield may be used to include a presence bitmap subfield (12 bits).

[0462] In the examples described above, the Co-BF-related feedback information may include at least one content from the MAPC information. For example, the Co-BF-related feedback information may further include a participation indication field, a status code field, and / or a rejection reason field.

[0463] The AP may indicate that the relevant multi-STA BA frame is a multi-STA BA frame for MAPC based on the above-described options 1) and / or 2), and the combined size of the BA Start Sequence Control subfield (2 octets) and / or the BA Bitmap subfield (e.g., 4, 8 octets) may be utilized to include MAPC operation related information (or MAPC information). shows the encoding of the Fragment Number subfield indicating the length of the BA Bitmap subfield when the value of the Ack Type subfield is 0:

[0464]

[0465] For example, when the value of the fragment number subfield is B3 = 0, B2-B1 = 3, B0 = 0, the BA bitmap subfield (or feedback subfield) has a length of 4 octets, and the 4 octets are used to contain MAPC operation related information, and / or an (UHR) control information field (containing MAPC operation related information) having a length of 4 octets may be defined. Additionally or alternatively, bits other than those required for MAPC related information may be reserved.

[0466] Option 3) In some implementations, the relevant multi-STA BA frame may be indicated as a multi-STA BA frame for MAPC based on the AID TID-specific information subfield format when the value of the AID11 subfield is 2045.

[0467] FIG. 36 illustrates an example of an AID TID-specific information subfield format when the value of the AID11 subfield is 2045 according to an embodiment of the present disclosure.

[0468] For example, to transmit a multi-STA BA frame to an unassociated STA, the AID11 subfield may be set to 2045, the Ack type subfield may be set to 0, and / or the TID subfield may be set to 15. When the value of the AID11 subfield is 2045, a reservation (4 octets) and an RA (6 octets) may exist within the AID TID information subfield following the AID TID information subfield.

[0469] Since the multi-STA BA frame can be broadcast to multiple STAs (connected or not) by an AP, the RA field in the MAC header is set to broadcast, and the connected STA can be identified based on the AID11 subfield in the BA information (or AID TID-specific information) field. On the other hand, when the multi-STA BA frame is transmitted to a non-connected STA, since the value of the AID11 subfield is set to 2045, the RA field can be included in the AID TID-specific information subfield as shown in FIG. 36 to identify the STA. However, if the multi-STA BA frame is used as an ICR between APs in MAPC, the RA field in the MAC header can be set to the MAC address of the AP that derived the ICR instead of broadcast. Therefore, when multiple STA BA frames are utilized as ICRs in MAPC, the RA (6 octets) in the AID TID-specific information subfield when the value of the AID11 subfield is 2045 may also be reserved. The 10-octet reserved field may include information for MAPC and / or (UHR) control information fields such as FIG. 21.

[0470] In some implementations, a specific value in the fragment number subfield within the BA start sequence control subfield may be utilized to indicate whether a related multi-STA BA frame contains MAPC information.

[0471] The format of the AID TID-specific information subfield when the AID11 subfield value is not 2045 is as illustrated in Fig. 14. In order to utilize a multi-STA BA frame as an ICR for MAPC, the fragment number subfield that can be included in the BA start sequence control subfield within the AID TID-specific information subfield can be set to a specific value.

[0472] shows the encoding of the fragment number subfield, which indicates the length of the BA bitmap subfield when the value of the Ack type subfield is 0. For example, when the value of the fragment number subfield is B3 = 0, B2-B1 = 3, B0 = 0, the BA bitmap subfield has a length of 4 octets.

[0473] Therefore, among the values ​​of the fragment number subfield illustrated in , reserved values ​​that are not currently in use (e.g., B3 = 1, B2-B1 = any, B0 = any) can be used for MAPC. When a specific reserved value (e.g., B3 = 1, B2-B1 = 0, B0 = 0) in the fragment number subfield is used, the BA bitmap subfield can be replaced with a subfield containing information for MAPC operation (e.g., a feedback subfield). For example, in the AID TID-specific information subfield, an (UHR) control information field (or feedback subfield) containing information for MAPC operation can be included instead of the BA bitmap subfield. In this case, the size of the field containing information for MAPC operation can be the size of the (UHR) control information field (or feedback subfield) itself. The size of the BA bitmap subfield can be used for the size of the field containing information for MAPC operation. When the size of the BA bitmap subfield is used, the remaining bits may be reserved except for the (UHR) control information field, which may contain information for MAPC operation.

[0474] Additionally or alternatively, whether a given multi-STA BA frame contains MAPC information may be indicated by utilizing a specific value of the Fragment Number subfield within the BA Start Sequence Control subfield and / or a specific value of the AID TID Information subfield.

[0475] In some implementations, at least one of the reserved bits within a multi-STA BA frame may be utilized to indicate whether the associated multi-STA BA frame contains MAPC information.

[0476] The format of the BA control field may be as shown in Fig. 11. In order to utilize a multi-STA BA frame as an ICR for MAPC, a reserved field of the BA control field within the multi-STA BA frame may be used.

[0477] For example, one of the reserved bits (B0 or ​​B5-B8) within the BA control field may be used to indicate the presence of information for MAPC and / or the (UHR) control information field.

[0478] Additionally or alternatively, a non-DMG STA may utilize at least one of the unused fields No Memory Kept, Memory Configuration Tag, Management Ack, etc. to indicate the presence of the information for MAPC and / or (UHR) control information field.

[0479] Additionally or alternatively, specific values ​​in the TID_INFO field may be used. For example, in a multi-STA BA frame, since the values ​​in the TID_INFO field are reserved, the presence of information for MAPC and / or (UHR) control information fields may be indicated by utilizing specific values ​​from among the reserved values.

[0480] When a BA information field exists in a multi-STA BA frame, the information for MAPC and / or (UHR) control information field described above may be located after the BA information field. Additionally or alternatively, when the information for MAPC and / or (UHR) control information field is included in a multi-STA BA frame, the BA information field may not be included (i.e., may be omitted). When the BA information field is not included (i.e., omitted), a method for indicating the presence of the information for MAPC and / or (UHR) control information field described above may be utilized to indicate the presence of the BA information field.

[0481] FIG. 37 illustrates an example of transmitting a multi-STA BA frame to an ICR for MAPC by utilizing a specific value of the AID TID information subfield according to an embodiment of the present disclosure.

[0482] Referring to FIG. 37, AP 1 may transmit an ICF (e.g., (BSRP) trigger frame) to APs in a cooperative relationship (e.g., AP 2 and AP 3) or to a single AP to perform a multi-AP selection (or cooperation announcement) procedure during MAPC operation. At this time, a new field may be included in the corresponding TF to indicate that the corresponding TF is a TF transmitted for MAPC operation and / or C-TDMA operation. APs that can identify the TF transmitted for MAPC operation and / or C-TDMA operation and have their own ID (e.g., a new ID for MAPC such as a multi-AP ID or AP ID) included in the user information field(s) or whose RA field is designated as their own address may transmit a multi-STA BA frame according to various embodiments of the present disclosure as a response frame to the corresponding TF.

[0483] The multi-STA BA frame at this time may or may not include information regarding MAPC operation. When transmitting a multi-STA BA frame including information regarding MAPC operation as a response, the multi-STA BA frame may include an (UHR) control information field including information regarding MAPC operation. An AP that has received a TF from a neighboring AP and thus induced transmission of a multi-STA BA frame may set the AID TID information subfield to a specific value to indicate that the multi-STA BA frame has been transmitted for the purpose of MAPC operation and / or to indicate that the multi-STA BA frame includes information regarding MAPC operation.

[0484] For example, the AP may utilize one of the reserved values ​​in the AID11 subfield (e.g., 2008 in FIG. 37) to indicate that a multi-STA BA frame was transmitted for the purpose of MAPC operation and / or that the multi-STA BA frame contained information for MAPC operation.

[0485] Additionally or alternatively, the AP may set the Ack Type subfield and / or the TID subfield to specific values ​​(e.g., 0 and 8 in FIG. 37) to indicate that the multi-STA BA frame was transmitted for the purpose of MAPC operation and / or to indicate that the multi-STA BA frame contained information for MAPC operation.

[0486] Meanwhile, in order for the multi-STA BA frame to include information about BA as before, the multi-STA BA frame may be transmitted together with one or more AID TID-specific information subfields (e.g., AID TID-specific information-(1) and AID TID-specific information-(2) in FIG. 37). In this case, AID TID-specific information-(1) and AID TID-specific information-(2) may include BA information about TID 0 and TID 1 of the AP that received the TF.

[0487] FIG. 38 illustrates an example of indicating whether to include an (UHR) control information field having a specific size based on a fragment number subfield according to an embodiment of the present disclosure.

[0488] Referring to FIG. 38, a multi-STA BA frame may be transmitted as an ICR for MAPC by utilizing a specific value of the AID TID information subfield, in which case the inclusion of an (UHR) control information field having a specific size may be indicated based on the fragment number subfield. For example, a 4-octet BA bitmap subfield may be replaced by an (UHR) control information field, or at least some information regarding MAPC operation may be included within the BA bitmap subfield.

[0489] Certain values ​​of the AID TID Information subfield may be utilized to indicate that a multi-STA BA frame was transmitted for the purpose of MAPC and / or contained information for MAPC operation. For example, the AP may utilize one of the reserved values ​​of the AID11 subfield (e.g., 2008 in FIG. 37) to indicate that a multi-STA BA frame was transmitted for the purpose of MAPC and / or contained information for MAPC operation. Additionally or alternatively, the AP may set the Ack Type subfield and / or the TID subfield to certain values ​​(e.g., 0 and 8 in FIG. 37) to indicate that a multi-STA BA frame was transmitted for the purpose of MAPC and / or contained information for MAPC operation.

[0490] In the example of Fig. 38, the presence or absence of the BA start sequence control subfield is determined by setting the value of the Ack type subfield to 0, and the size of the BA bitmap can be determined by setting the fragment number subfield to a specific value (e.g., B3 = 0, B2-B1 = 3, B0 = 0 in Fig. 38). By utilizing fields set to a specific size, information about MAPC and / or (UHR) control information fields can be included instead of existing information.

[0491] Meanwhile, in order for the multi-STA BA frame to include information about BA as before, the multi-STA BA frame may be transmitted together with one or more AID TID-specific information subfields (e.g., AID TID-specific information-(1) and AID TID-specific information-(2) in FIG. 37). In this case, AID TID-specific information-(1) and AID TID-specific information-(2) may include BA information about TID 0 and TID 1 of the AP that received the TF.

[0492] FIG. 39 illustrates an example of a case where a multi-STA BA frame utilizes a specific value of a fragment number subfield to be transmitted from MAPC to ICR according to an embodiment of the present disclosure.

[0493] Referring to FIG. 39, a specific value of the fragment number subfield may be utilized for transmitting a multi-STA BA frame from MAPC to ICR. The multi-STA BA frame at this time may or may not include MAPC-related information. When transmitting a multi-STA BA frame including information for MAPC operation as a response, the multi-STA BA frame may include an (UHR) control information field. A specific value of the fragment number subfield may be utilized to indicate that the multi-STA BA frame was transmitted for the purpose of MAPC and / or included information for MAPC operation. For example, if a specific reserved value (e.g., B3 = 1, B2-B1 = 0, B0 = 0 in FIG. 39) is used, the (UHR) control information field for MAPC may be included instead of the BA bitmap subfield, or information for MAPC may be included within the BA bitmap subfield.

[0494] Meanwhile, in order for the multi-STA BA frame to include information about BA as before, the multi-STA BA frame may be transmitted together with one or more AID TID-specific information subfields (e.g., AID TID-specific information-(1) and AID TID-specific information-(2) in FIG. 37). In this case, AID TID-specific information-(1) and AID TID-specific information-(2) may include BA information about TID 0 and TID 1 of the AP that received the TF.

[0495] In some implementations, a DAP that has received an ICF (e.g., BSRP TF) forwarded by an AP that has acquired a TXOP and become a SAP may transmit a multi-STA BA frame containing information indicating whether the DAP will participate in the specific MAPC scheme (or cooperative scheme) indicated by the ICF.

[0496] For example, a participation indication field of 1 or n bits may be defined.

[0497] For example, a 1-bit signaling bit may be defined to report whether or not to participate in a MAPC-based operation derived from ICF. The DAP(s) that have received a response request from the SAP may indicate whether or not they currently require one of the MAPC-based operations indicated by the SAP based on a 1-bit participation indication field. For example, a bit value of the participation indication field set to 0 may indicate that the corresponding DAP does not participate in the derived MAPC-based operation. A bit value of the participation indication field set to 1 may indicate that the corresponding DAP participates in the derived MAPC-based operation.

[0498] Additionally or alternatively, an n-bit participation indication field may be defined to report whether or not to participate in a MAPC-based operation derived from an ICF, the proposal, and / or the reason for rejection. A DAP(s) requested to respond from a SAP may indicate whether or not it currently requires one of the MAPC-based operations indicated by the SAP based on the n-bit participation indication field. For example, a participation indication field with bit value 0 may indicate that the corresponding DAP does not participate in the derived MAPC-based operation. A participation indication field with bit value 1 may indicate that the corresponding DAP participates in the derived MAPC-based operation. A participation indication field with bit value 2 may indicate that information related to a proposal for the corresponding DAP to participate in the derived MAPC-based operation is included in the response frame (e.g., a multi-STA BA frame). The Participation Indication field having bit value 3 set may indicate that information regarding the reason why the corresponding DAP cannot participate in the induced MAPC-based operation is included in the response frame (e.g., multi-STA BA frame).

[0499] Additionally or alternatively, a participation indication field (n bits) of the same format as the multi-AP collaboration type field that may be included in the ICF transmitted by SAP may indicate participation in a particular method.

[0500] For example, if Co-TDMA operation is indicated from the SAP based on a 3-bit Multi-AP Cooperation Type field, the DAP can respond by i) setting the Multi-AP Cooperation Type field to the same bit if it wishes to participate in Co-TDMA, or ii) setting all values ​​of the Multi-AP Cooperation Type field to 0 if it does not wish to participate in Co-TDMA.

[0501] For example, if the Multi-AP Cooperation Type field is defined as n bits and indicates a specific cooperation method based on a bitmap, the DAP can respond by setting the bits to 1 for the method it wishes to participate in, or by setting all values ​​of the Multi-AP Cooperation Type field to 0 if it does not wish to participate in that cooperation method.

[0502] FIG. 40 illustrates an example of a MAPC participation reporting procedure based on a participation indication field according to an embodiment of the present disclosure.

[0503] Referring to FIG. 40, an AP may transmit a MAPC participation report including a 1-bit or n-bit signaling field (or participation indication field). For example, AP 4 may indicate that it cannot transmit a response frame due to its default NAV, and AP 2 may indicate that it does not participate in the indicated MAPC cooperation. AP 3 may include a newly defined signaling field / bit(s) (e.g., participation indication field) in a response frame for a BSRP TF that may be transmitted from AP 1 as an ICF, and may indicate participation in MAPC by transmitting a response frame including the participation indication field. Based on the response frame, AP 1 may transmit a cooperation trigger frame to AP 3 that wishes to participate, and perform MAPC-based operations (e.g., Co-TDMA / SR / BF).

[0504] A 1-bit or n-bit participation indication field may be included in a multi-STA BA frame according to various embodiments described above.

[0505] In some implementations, to indicate whether to participate in the MAPC scheme indicated by SAP, the DAP may set at least one of the AID11, Ack Type, or TID subfields within the AID TID Info subfield to a specific value based on at least one of the options 1 to 3 below.

[0506] Option 1) In order for multiple STA BA frames to be transmitted between APs that are not connected, the value of the AID11 subfield needs to be set to 2045. However, in order to indicate participation, the value of the AID11 subfield can be set to a specific value other than 2045 (e.g., 1, a reserved value such as 2008 - 2044, or an AP ID assigned from SAP). For example, an AP that wants to participate in the MAPC scheme can respond by transmitting a multiple STA BA frame in which the value of the AID11 subfield is set to the AP ID assigned from SAP, and an AP that does not participate in the MAPC scheme can respond by transmitting a multiple STA BA frame in which the value of the AID11 subfield is set to 2045 (or a reserved value such as 2008 - 2044).

[0507] Option 2) Additionally or alternatively, reserved values ​​for combinations of Ack Type subfield and TID subfield values ​​when the value of the AID11 subfield is not 2045 (e.g., Table 7) may be utilized to indicate participation. shows the context according to the combination of Ack Type subfield and TID subfield values ​​when the value of the AID11 subfield is not 2045. For example, the AID11 subfield may be set to the AP ID value assigned to each AP by the SAP, and one of the values ​​Ack Type = 0, TID = 8~15 may be utilized to indicate participation. For example, when Ack Type = 0, TID = 8 is utilized, setting the value to 0 (e.g., not Ack Type = 0, TID = 8, but Ack Type = 0, TID = 9) indicates non-participation, and setting it to 1 (e.g., Ack Type = 0, TID = 8) can indicate participation. In other words, Ack Type = 0, TID = 8 can indicate participation, and Ack Type = 0, TID = 9 can indicate non-participation.

[0508] Additionally or alternatively, when indicating participation in the MAPC scheme by utilizing reserved values ​​for a combination of the Ack Type subfield and the TID subfield values, the BA Start Sequence Control subfield and / or the BA Bitmap subfield within the AID TID Specific Information subfield(s) may be replaced by a field containing information for MAPC operation (e.g., a Feedback subfield).

[0509] Option 3) Whether to participate in the MAPC method can be indicated based on the format of the AID TID-specific information subfield when the value of the AID11 subfield is 2045. The format of the AID TID-specific information subfield when the value of the AID11 subfield is 2045 is illustrated in FIG. 36. In order to transmit a multi-STA BA frame to a non-connected STA, the AID11 subfield needs to be set to 2045, the Ack type subfield needs to be set to 0, and / or the TID subfield needs to be set to 15. Within the AID TID-specific information subfield when the value of the AID11 subfield is 2045, a reserved field (4 octets) and an RA field (6 octets) may exist following the AID TID information subfield.

[0510] Since the multi-STA BA frame can be broadcast to multiple STAs (connected or not) by an AP, the RA field in the MAC header is set to broadcast, and the connected STA can be identified based on the AID11 subfield in the BA information (or AID TID-specific information) field. On the other hand, when the multi-STA BA frame is transmitted to a non-connected STA, since the value of the AID11 subfield is set to 2045, the RA field can be included in the AID TID-specific information subfield as shown in FIG. 36 to identify the STA. However, if the multi-STA BA frame is used as an ICR between APs in MAPC, the RA field in the MAC header can be set to the MAC address of the AP that derived the ICR instead of broadcast. Therefore, when multiple STA BA frames are utilized as ICRs in MAPC, the RA (6 octets) in the AID TID-specific information subfield when the value of the AID11 subfield is 2045 may also be reserved. The 10-octet reserved field may include a 1-bit or n-bit participation indication field indicating whether to participate in the MAPC method.

[0511] In some implementations, the reserved field in the BA Control field within the BA frame may be used to indicate participation in the MAPC scheme. The BA Control field format is illustrated in Figure 11.

[0512] For example, one or n bits of the reserved bits (B0 or ​​B5-B8) within the BA control field can be used to indicate participation in the MAPC scheme.

[0513] Additionally or alternatively, a non-DMG STA may indicate whether or not to participate in the MAPC scheme by utilizing one or more of the following unused fields: No Memory Kept, Memory Configuration Tag, Management Ack, or n bits.

[0514] Additionally or alternatively, specific values ​​in the TID_INFO field can be used to indicate participation in the MAPC scheme. Since the TID_INFO field is reserved in a multi-STA BA frame, participation in the MAPC scheme can be indicated by utilizing specific values ​​among the reserved values. For example, the 4-bit TID_INFO field can be set to all 0s to indicate non-participation in the MAPC scheme, or all 1s to indicate participation in the MAPC scheme.

[0515] In some implementations, information unique to each cooperation method in the MAPC-related information (or MAPC information) described above may be utilized to indicate whether to participate in the MAPC method.

[0516] For example, in the case of Co-TDMA, the requested TXOP duration information (or information that can be included in the ICR for Co-TDMA operation) can be set to a required value / period / specific value to indicate that the UE wishes to participate in the MAPC mode, or set to 0 to indicate that the UE does not wish to participate in the MAPC mode.

[0517] For example, in the case of Co-SR, the target STA version information (or information that can be included in the ICR for Co-SR operation), which can be defined as a value of 2 or more bits, can be set to 1 (e.g., EHT STA) or 2 (e.g., UHR STA) to indicate participation in the MAPC method, and the target STA version information can be set to 0 or the remaining bit can be used to indicate not to participate in the MAPC method.

[0518] For example, in the case of Co-BF, the Co-BF user count information (or information that can be included in the ICR for Co-BF operation) that can be defined as a value of 2 or more bits can be set to 1 (e.g., one Co-BF user) or 2 (e.g., two Co-BF users) or 3 (e.g., three Co-BF users) to indicate participation in the MAPC scheme, and the Co-BF user count information can be set to 0 or the remaining bits can be used to indicate not to participate in the MAPC scheme.

[0519] The present disclosure provides a method for transmitting a multi-STA BA frame as a response frame to a trigger frame (e.g., BSRP, MU-RTS) that can be transmitted from each AP in MAPC and / or C-TDMA operation, and various embodiments for implementing the method. For example, various embodiments are provided regarding information that can be included in the frame when transmitting the multi-STA BA frame, the structure of the frame, and / or the method for transmitting the frame. By utilizing the information included in the multi-STA BA frame transmitted from the DAP(s), the SAP can perform more efficient multi-AP cooperation.

[0520] The technical features of the present disclosure described above can be applied to various devices and methods. For example, the technical features of the present disclosure described above can be performed / supported by the devices of FIG. 1 and / or FIG. 5. For example, the technical features of the present disclosure described above can be applied only to a portion of FIG. 1 and / or FIG. 5. For example, the technical features of the present disclosure described above can be implemented based on the processing chip (114, 124) of FIG. 1, or based on the processor (111, 121) and memory (112, 122) of FIG. 1, or based on the processor (510) and memory (520) of FIG. 5.

[0521] For example, the processor (121) and / or the processing chip (124) of FIG. 1 may be configured to execute instructions stored in the memory (122) to perform operations performed by the first AP in the present disclosure. The operations include: establishing a cooperation setting for multi-AP cooperation with one or more APs; transmitting a trigger frame for the multi-AP cooperation to a second AP among the one or more APs; and receiving a multi-STA (multi-STA) block acknowledgment (BA) frame in response to the trigger frame from the second AP, wherein the BA information field of the multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per AID TID information subfield, and the AID TID information subfield of the AID TID per information subfield is set to a specific value based on that the multi-STA BA frame is related to the multi-AP cooperation.

[0522] For example, the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5 may be configured to execute instructions stored in the memory (112, 520) to perform operations performed by the second AP in the present disclosure. The operations include: establishing a cooperation setting for multi-AP cooperation with the first AP; receiving a trigger frame for the multi-AP cooperation from the first AP; and transmitting a multi-STA (multi-STA) block acknowledgment (BA) frame to the first AP in response to the trigger frame, wherein the BA information field of the multi-STA BA frame includes a per AID (association identifier) ​​TID (traffic identifier) ​​information subfield, and the AID TID information subfield of the per AID TID information subfield is set to a specific value based on that the multi-STA BA frame is related to the multi-AP cooperation.

[0523] The technical features of the present disclosure can be implemented based on a computer-readable medium (CRM). For example, the CRM proposed by the present disclosure is at least one computer-readable recording medium containing instructions that are executed by at least one processor.

[0524] For example, the CRM may be the memory (122) of FIG. 1 and / or a separate external memory / storage medium / disk. The CRM may store commands that perform operations performed by the first AP in the present disclosure based on being executed by a processor (e.g., the processor (121) and / or the processing chip (124) of FIG. 1). The operations include: establishing a cooperation setting for multi-AP cooperation with one or more APs; transmitting a trigger frame for multi-AP cooperation to a second AP among the one or more APs; And an operation of receiving a multi-STA (multi-STA) block acknowledgment (BA) frame in response to the trigger frame from the second AP, wherein a BA information field of the multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per AID TID information subfield, and an AID TID information subfield of the AID TID per information subfield is set to a specific value based on the multi-STA BA frame being related to the multi-AP cooperation.

[0525] For example, the CRM may be the memory (112) of FIG. 1, the memory (520) of FIG. 5, and / or a separate external memory / storage medium / disk. The CRM may store commands that perform operations performed by the second AP in the present disclosure based on being executed by a processor (e.g., the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5). The operations include: establishing a cooperation setting for multi-AP cooperation with the first AP; receiving a trigger frame for the multi-AP cooperation from the first AP; And an operation of transmitting a multi-STA (multi-STA) block acknowledgment (BA) frame in response to the trigger frame to the first AP, wherein a BA information field of the multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per AID TID information subfield, and an AID TID information subfield of the AID TID per information subfield is set to a specific value based on the multi-STA BA frame being related to the multi-AP cooperation.

[0526] The technical features of the present disclosure described above are applicable to various applications and business models. For example, the technical features described above can be applied to wireless communication in devices that support artificial intelligence (AI).

[0527] Artificial intelligence (AI) is the study of artificial intelligence or the methodologies for creating it, while machine learning (ML) defines various problems in the field of AI and studies the methodologies for solving them. Machine learning is also defined as an algorithm that improves performance on a task through consistent experience.

[0528] An artificial neural network (ANN) is a model used in machine learning. It can refer to a model with problem-solving capabilities, consisting of artificial neurons (nodes) formed by the connection of synapses to form a network. An ANN can be defined by the connection patterns between neurons in different layers, the learning process that updates model parameters, and the activation function that generates output values.

[0529] An artificial neural network may include an input layer, an output layer, and optionally one or more hidden layers. Each layer contains one or more neurons, and the artificial neural network may include synapses connecting neurons. In an artificial neural network, each neuron can output a function value of an activation function based on input signals, weights, and biases received through the synapses.

[0530] Model parameters are parameters determined through learning, including synaptic connection weights and neuron biases. Hyperparameters are parameters that must be set before learning in machine learning algorithms, including the learning rate, number of iterations, mini-batch size, and initialization function.

[0531] The goal of artificial neural network training can be seen as determining model parameters that minimize a loss function. The loss function can be used as an indicator for determining optimal model parameters during the artificial neural network training process.

[0532] Machine learning can be classified into supervised learning, unsupervised learning, and reinforcement learning depending on the learning method.

[0533] Supervised learning refers to a method for training an artificial neural network when given labels for the training data. The labels can refer to the correct answer (or output value) that the artificial neural network must infer when the training data is input to the artificial neural network. Unsupervised learning can refer to a method for training an artificial neural network when the training data is not given labels. Reinforcement learning can refer to a learning method in which an agent defined within a given environment is trained to select actions or action sequences that maximize the cumulative reward in each state.

[0534] Machine learning implemented with a deep neural network (DNN) containing multiple hidden layers among artificial neural networks is also called deep learning, and deep learning is a subset of machine learning. Hereinafter, the term "machine learning" is used to encompass deep learning.

[0535] Additionally, the above-described technical features can be applied to wireless communication of robots.

[0536] A robot can be defined as a machine that automatically performs or operates a given task based on its own capabilities. Specifically, a robot capable of perceiving its environment, making independent judgments, and performing actions can be called an intelligent robot.

[0537] Robots can be categorized into industrial, medical, household, and military applications based on their intended use or field. Robots are equipped with actuators or motors, enabling them to perform various physical actions, such as moving robot joints. Furthermore, mobile robots incorporate wheels, brakes, and propellers into their actuators, enabling them to move on the ground or fly in the air.

[0538] Additionally, the above-described technical features can be applied to devices that support extended reality.

[0539] Extended reality is a general term for virtual reality (VR), augmented reality (AR), and mixed reality (MR). VR technology presents real-world objects and backgrounds as CG images only, AR technology presents virtual CG images over images of real objects, and MR technology is a computer graphics technology that blends and combines virtual objects with the real world.

[0540] MR technology is similar to AR in that it presents both real and virtual objects simultaneously. However, while AR uses virtual objects to complement real objects, MR uses virtual and real objects on an equal footing.

[0541] XR technology can be applied to HMD (Head-Mount Display), HUD (Head-Up Display), mobile phones, tablet PCs, laptops, desktops, TVs, digital signage, etc., and devices to which XR technology is applied can be called XR devices.

[0542] The present disclosure may have various advantageous effects.

[0543] For example, SAP can perform more efficient multi-AP cooperation by using information contained in multiple STA BA frames transmitted from DAP(s).

[0544] The beneficial effects that can be achieved through specific embodiments of the present disclosure are not limited to the beneficial effects listed above. For example, various technical effects may be understood and / or derived from the present disclosure by those skilled in the art. Therefore, the specific effects of the present disclosure are not limited to those explicitly described herein, but may include various effects that can be understood or derived from the technical features of the present disclosure.

[0545] The claims set forth in this disclosure may be combined in various ways. For example, the technical features of the method claims of this disclosure may be combined and implemented as a device, and the technical features of the device claims of this disclosure may be combined and implemented as a method. Furthermore, the technical features of the method claims of this disclosure and the technical features of the device claims of this disclosure may be combined and implemented as a device, and the technical features of the method claims of this disclosure and the technical features of the device claims of this disclosure may be combined and implemented as a method.

Claims

1. A step in which the first AP (access point) establishes a cooperation setting for multi-AP cooperation with one or more APs; A step in which the first AP transmits a trigger frame for multi-AP cooperation to a second AP among the one or more APs; and The step of the first AP receiving a multi-STA block acknowledgement (BA) frame in response to the trigger frame from the second AP, The BA information field of the above multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per AID TID information subfield, A method in which the AID TID information subfield of the above AID TID-specific information subfield is set to a specific value based on whether the multi-STA BA frame is related to the multi-AP cooperation.

2. In claim 1, the AID TID information subfield includes at least one of an AID11 subfield, an Ack (acknowledgement) type subfield, or a TID subfield, A method wherein a specific value of the AID TID information subfield comprises at least one of a value of the AID11 subfield, a value of the Ack type subfield, or a value of the TID subfield.

3. In claim 2, a method in which the value of the AID11 subfield is set to a value other than 2045.

4. In claim 2, the value of the Ack type subfield is set to 0, How the value of the above TID subfield is set to 13.

5. A method according to claim 1, wherein the AID TID information subfield is set to the specific value based on the cooperation information related to the multi-AP cooperation being included in the multi-STA BA frame.

6. A method according to claim 5, wherein the cooperation information includes at least one of information about an operating channel, information related to an operating bandwidth, information about a requested TXOP period, information about a buffer status, information about a TXOP (transmission opportunity) sharing request, low-latency traffic information, or information about a status code.

7. In claim 5, the AID TID-specific information subfield includes a subfield including the cooperation information, A method in which a subfield including the above cooperation information is a BA bitmap subfield or a control information subfield included in the AID TID-specific information subfield instead of the BA bitmap subfield.

8. A method according to claim 7, wherein the control information subfield is a feedback subfield.

9. In claim 7, the BA starting sequence control subfield of the AID TID-specific information subfield includes a control information type subfield, The above control information type subfield indicates the type of information contained in the BA bitmap subfield or the above control information subfield, The type of information above is a method including the above multi-AP cooperation.

10. A method according to claim 9, wherein the control information type subfield is set to a specific value based on whether the cooperation information is included in the BA bitmap subfield or the control information subfield.

11. A method according to claim 9, wherein the control information type subfield is a feedback type subfield.

12. In claim 5, the BA starting sequence control subfield of the AID TID-specific information subfield includes a fragment number subfield, A method in which the above fragment number subfield is set to a value related to the length or size of the subfield containing the above cooperation information.

13. A method according to claim 5, wherein the size of the subfield containing the cooperation information is the size of the cooperation information.

14. In the first AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: An action to establish a cooperative setting for multi-AP cooperation with one or more APs; An operation of transmitting a trigger frame for multi-AP cooperation to a second AP among the one or more APs; and An operation of receiving a multi-STA block acknowledgment (BA) frame in response to the trigger frame from the second AP, The BA information field of the above multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per AID TID information subfield, The AID TID information subfield of the above AID TID-specific information subfield is a first AP set to a specific value based on the multi-STA BA frame being related to the multi-AP cooperation.

15. In the device, at least one processor; and At least one memory functionally coupled with at least one processor, The at least one memory stores instructions that perform operations based on being executed by the at least one processor, the operations being: An action to establish a cooperative setting for multi-AP cooperation with one or more APs (access points); An operation of transmitting a trigger frame for multi-AP cooperation to a second AP among the one or more APs; and An operation of receiving a multi-STA block acknowledgment (BA) frame in response to the trigger frame from the second AP, The BA information field of the above multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per AID TID information subfield, A device in which the AID TID information subfield of the above AID TID-specific information subfield is set to a specific value based on whether the multi-STA BA frame is related to the multi-AP cooperation.

16. A non-transitory computer readable medium (CRM) storing program code that implements instructions that perform operations based on being executed by at least one processor, wherein the operations are: An action to establish a cooperative setting for multi-AP cooperation with one or more APs (access points); An operation of transmitting a trigger frame for multi-AP cooperation to a second AP among the one or more APs; and An operation of receiving a multi-STA block acknowledgment (BA) frame in response to the trigger frame from the second AP, The BA information field of the above multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per AID TID information subfield, The AID TID information subfield of the above AID TID-specific information subfield is a CRM that is set to a specific value based on whether the multi-STA BA frame is related to the multi-AP cooperation.

17. A step in which the second AP (access point) establishes a cooperation setting for multi-AP cooperation with the first AP; A step in which the second AP receives a trigger frame for multi-AP cooperation from the first AP; and The second AP comprises a step of transmitting a multi-STA block acknowledgement (BA) frame to the first AP in response to the trigger frame, The BA information field of the above multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per AID TID information subfield, A method in which the AID TID information subfield of the above AID TID-specific information subfield is set to a specific value based on whether the multi-STA BA frame is related to the multi-AP cooperation.

18. A method according to claim 17, wherein the AID TID information subfield is set to the specific value based on the cooperation information related to the multi-AP cooperation being included in the multi-STA BA frame.

19. In claim 18, the AID TID specific information subfield includes a subfield including the cooperation information, A method in which the subfield containing the above cooperation information is a BA bitmap subfield or a feedback subfield included in the AID TID-specific information subfield instead of the BA bitmap subfield.

20. In a STA (station) connected to a second AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: Action to establish a cooperative setting for multi-AP cooperation with the first AP; An operation of receiving a trigger frame for multi-AP cooperation from the first AP; and Including an operation of transmitting a multi-STA BA (block acknowledgment) frame in response to the trigger frame to the first AP, The BA information field of the above multi-STA BA frame includes an AID (association identifier) ​​TID (traffic identifier) ​​per AID TID information subfield, The AID TID information subfield of the above AID TID-specific information subfield is a second AP that is set to a specific value based on whether the multi-STA BA frame is related to the multi-AP cooperation.

Images