Method and apparatus for performing polling step on basis of 3-way handshake by transmitting additional acknowledgement frame in existing ICF / ICR exchange in MAPC procedure in wireless LAN system

Abstract

Proposed is a sequence for performing a polling step on the basis of a 3-way handshake by transmitting an additional acknowledgement frame in an existing ICF / ICR exchange in a MAPC procedure in a wireless LAN system. Particularly, a first AP transmits a first ICF to a second AP. The first AP receives, from the second AP, a first ICR as a response to the first ICF. The first AP transmits an acknowledgement frame to the second AP. The first ICF is used to identify whether there is an intention to perform MAPC transmission. The acknowledgement frame is used to convey information about time allocation for the MAPC transmission.

Description

Method and apparatus for performing a polling step based on 3-way handshake by transmitting an additional acknowledgment frame to the existing ICF / ICR exchange in the MAPC procedure of a wireless LAN system

[0001] The present specification relates to a technique for performing a polling step based on a 3-way handshake by transmitting an additional acknowledgment frame in the existing ICF / ICR exchange in the MAPC procedure of a wireless LAN system, and more specifically, to a sequence for performing an ICF / ICR exchange to switch the operating mode of a target STA before a (cooperative) trigger frame that triggers Co-SR / Co-BF transmission is transmitted.

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

[0003] The present specification proposes a method and apparatus for performing a polling step based on a 3-way handshake by transmitting an additional acknowledgment frame to the existing ICF / ICR exchange in the MAPC procedure of a wireless LAN system.

[0004] One example of this specification proposes a method for performing a polling step based on a 3-way handshake by transmitting an additional acknowledgment frame to the existing ICF / ICR exchange in the MAPC procedure.

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

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

[0007] The present embodiment proposes a sequence for performing a polling phase based on a 3-way handshake by transmitting an additional acknowledgment frame to the existing ICF / ICR exchange during the polling phase of a Co-TDMA procedure. Specifically, the present embodiment proposes a method for indicating the order for TXOP allocation or time allocation when there are multiple polled APs by setting the acknowledgment frame to an ICF, CRF, or M-BA.

[0008] The first AP (access point) transmits the first ICF (Initial Control Frame) to the second AP.

[0009] The first AP receives a first ICR (Initial Control Response) from the second AP in response to the first ICF.

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

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

[0012] The first ICF is used to verify whether there is an intention to perform the MAPC transmission. The first ICR may be used to convey an intention to participate in the MAPC transmission.

[0013] The above acknowledgment frame is used to convey information regarding time allocation for the MAPC transmission. Upon receiving the above acknowledgment frame, the second AP can recognize that it is scheduled to be allocated a TXOP or time for the MAPC transmission. Additionally, the second AP can check the expected time for the TXOP or time to be allocated for the MAPC transmission through the above acknowledgment frame.

[0014] This embodiment proposes a method for transmitting acknowledgment information to an AP that is the target of a TXOP or time allocation by transmitting additional acknowledgment frames during an ICF / ICR exchange in Co-TDMA operation.

[0015] According to the embodiments proposed in this specification, APs that sent the ICR can determine whether they can receive a TXOP or time allocation from the coordinating AP, thereby preventing unnecessary power consumption.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0034] FIG. 19 illustrates an example of an ICF / ICR exchange for Co-TDMA operation.

[0035] FIG. 20 illustrates Example-1 of a 3-way handshake-based polling phase based on additional ICF transmission.

[0036] Figure 21 illustrates an example of a sequential Co-TDMA sequence utilizing a 3-way handshake-based polling phase.

[0037] Figure 22 illustrates Example-1 of a 3-way handshake-based polling phase transmitting M-BA.

[0038] FIG. 23 illustrates Example-2 of a 3-way handshake-based polling phase transmitting M-BA.

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

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

[0041] FIG. 26 is a flowchart illustrating a 3-way handshake-based polling phase procedure in which a coordinated AP according to the present embodiment receives a separate acknowledgment frame.

[0042] FIG. 27 is a flowchart illustrating a 3-way handshake-based polling phase procedure in which a coordinating AP according to the present embodiment transmits a separate acknowledgment frame.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0172] <Examples Applicable to the Present Specification>

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

[0174] In 802.11, trigger frames are defined for the purpose of receiving TB PPDUs from STAs during MU transmissions. For example, the Basic Trigger frame can be used as a trigger to receive data from STAs via UL MU transmissions, and the MU-BAR Trigger frame is used to receive BlockAck frames from STAs via UL MU transmissions. The BSRP (Buffer Status Report Poll) Trigger frame is used to report the Buffer Status of associated STAs. In 802.11bn (UHR), various topics to improve existing technologies, such as In-device-coexistence (IDC), Dynamic Power Saving (DPS), Multi-AP coordination (MAPC), and Non-Primary Channel Access (NPCA), are being discussed, and for these new technologies to operate, it may be necessary to define control frames such as the Initial Control Frame (ICF), Initial Control Response Frame (ICR), and Control Response Frame (CRF). In this case, when defining the described ICF, ICR, CRF, etc., existing defined Trigger frames and response frames may be reused or extended, and a new frame exchange sequence utilizing them may be defined.

[0175] Currently, in 802.11bn, the ICF in Co-TDMA operation is defined as utilizing the BSRP Trigger frame.

[0176] 1. Define IDC, DPS, MAPC, NPCA, DUO, and EMLSR in 802.11bn (UHR).

[0177] 1.1. Ultra High Reliability (UHR) Operation Mode

[0178] UHR operation mode refers to one or more optional operation modes used by a UHR STA or UHR MLD to dynamically change the communication operation method or adjust detailed operation parameters according to the network environment, traffic characteristics, device constraints and coexistence requirements.

[0179] The UHR operation mode can be enabled or disabled to improve power efficiency, latency, reliability, channel access efficiency, and multi-link operation efficiency of the STA or MLD, and each mode can be used independently or in combination.

[0180] The activation, deactivation, and parameter updates of the UHR operation mode are performed by a non-AP MLD or non-AP STA requesting it through the exchange of control frames with an AP or AP MLD, and the AP side accepting it.

[0181] Each UHR operation mode may have one or more parameters defining whether the mode is applied, switching delay, switching conditions, or operation constraints, and the AP performs frame transmission, triggering, and resource allocation by considering these parameters.

[0182] 1.2. Role of UHR Operation Mode

[0183] UHR operation modes are provided to achieve at least one of the following.

[0184] Reduced power consumption (e.g., DPS)

[0185] Improved channel access flexibility (e.g., NPCA, MAPC)

[0186] Handling temporary availability changes (e.g., DUO, IDC)

[0187] Support for single RF operation in multi-link environments (e.g., EMLSR)

[0188] Meeting latency and reliability requirements

[0189] 1.3. Relationship between UHR Operation Mode and Individual Modes

[0190] Below, the concepts and functions of various UHR operation modes, including IDC, DPS, MAPC, NPCA, DUO, and EMLSR, are explained as examples of UHR operation modes.

[0191] 1) In-Device Coexistence (IDC)

[0192] In-Device Coexistence (IDC) is a mechanism that limits or coordinates wireless operations that can be performed at a specific time to mitigate interference between multiple wireless functions or wireless systems coexisting within a single device.

[0193] The IDC ensures coexistence with other wireless functions by controlling the timing of transmit / receive operations, channel access, or link switching when there is a possibility of a collision of internal wireless resources within the STA. The IDC information is transmitted to the AP through an operation mode or parameter update procedure, enabling the AP to perform frame transmission and scheduling that take into account the constraints of the STA.

[0194] 2) Dynamic Power Save (DPS)

[0195] Dynamic Power Save (DPS) is a power-saving operation mode that allows the STA to dynamically switch between a receiving active state and a low-power state depending on traffic demand, operating state, or network conditions.

[0196] In DPS, the STA can switch between Low Power Mode and High Power / Active Mode, and a corresponding transition delay is defined for each mode switch. The AP adjusts the frame transmission timing by taking into account the STA's DPS parameters, thereby ensuring that frame exchange occurs only when the STA is in a receiving state.

[0197] 3) Multi-AP Coordination (MAPC)

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

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

[0200] 3-1) Coordinated Beamforming (Co-BF)

[0201] Co-BF is a cooperative transmission method in which two or more APs cooperate to transmit data simultaneously, and each AP performs beamforming to minimize interference with STAs connected to other APs.

[0202] In Co-BF operation, multiple APs share beamforming parameters based on a pre-negotiated Co-BF agreement and form a beam pattern using Channel State Information (CSI) for each other's receiving STAs.

[0203] Each AP enables simultaneous transmission within the same TXOP by transmitting data to the STA associated with it (non-AP) while simultaneously adjusting the beam to minimize interference to the STA associated with another AP.

[0204] Co-BF transmission is initiated by the Co-BF coordinating AP that has acquired the TXOP, and the AP sends a Co-BF Invite frame to another AP (Co-BF coordinated AP) to request whether to perform simultaneous transmission. The Co-BF coordinated AP responds to this via a Co-BF Response frame.

[0205] APs performing Co-BF pre-establish a Co-BF consensus through MAPC negotiation. STAs are associated with Co-BF disabled by default, and can subsequently be enabled or disabled through the UHR operating mode update procedure.

[0206] The Co-BF transmission procedure is as follows. The Co-BF coordinating AP transmits a Co-BF Invite frame to the Co-BF coordinated AP. The Co-BF coordinated AP responds with a Co-BF Response frame. If necessary, each AP performs ICF / ICR frame exchanges with the associated STAs prior to Co-BF transmission. The Co-BF coordinating AP transmits a Co-BF Trigger frame. Both APs simultaneously transmit PPDUs containing data to their respective associated STAs.

[0207] Co-BF enables simultaneous transmission of multiple APs within the same time resource, minimizes spatial interference, improves spectral efficiency, and has the effect of increasing system throughput in high-density environments.

[0208] 3-2) Co-SR (Coordinated Spatial Reuse)

[0209] Co-SR is a cooperative space reuse method that enables simultaneous transmission within the same time resource by having two or more APs cooperate to control transmission power.

[0210] In Co-SR operation, two APs regulate their respective transmit power based on mutually agreed Co-SR consensus and keep the interference between their transmissions to the STA associated with the other AP below an acceptable level.

[0211] Through this, unlike the existing method where only one AP uses the TXOP exclusively, two APs can perform data transmission simultaneously within the same TXOP.

[0212] Co-SR transmission is initiated by the Co-SR coordinating AP that acquires the TXOP, and another AP participates in the transmission as the Co-SR coordinated AP. The number of APs participating in Co-SR is limited to 2.

[0213] APs performing Co-SR pre-establish consensus on Co-SR through MAPC negotiation. STAs are associated with Co-SR disabled by default, and can subsequently enable or disable Co-SR operation through the UHR operating mode update procedure. Co-SR coordinating APs do not perform Co-SR transmissions to STAs with Co-SR disabled or STAs that do not support Co-SR.

[0214] The Co-SR transmission procedure is as follows. The Co-SR frame switching procedure is identical to the Co-BF transmission sequence and operates as follows: The Co-SR coordinating AP transmits a Co-SR Invite frame to the Co-SR coordinated AP. The Co-SR coordinated AP responds with a Co-SR Response frame. If necessary, each AP performs ICF / ICR frame switching with the associated STAs. The Co-SR coordinating AP transmits a Co-SR Trigger frame. Both APs simultaneously transmit power-controlled PPDUs to their respective associated STAs (Co-SR transmission).

[0215] Co-SR enables simultaneous transmission based on transmission power control, improves space reuse efficiency within the same channel, and has the effect of increasing overall system throughput in high-density environments.

[0216] 4) Non-Primary Channel Access (NPCA)

[0217] Non-Primary Channel Access (NPCA) is an operation mode that allows an STA to perform channel access and frame exchange through an auxiliary channel or a non-primary channel rather than the primary channel.

[0218] In NPCA, the STA can initiate or respond to a TXOP on a channel other than the primary channel, and the delay time required for channel switching and return is defined for such operations. The AP performs frame transmission and scheduling by taking into account whether the STA is performing an NPCA operation and the switching delay.

[0219] 5) Dynamic Unavailability Operation (DUO)

[0220] Dynamic Unavailability Operation (DUO) is an operation mode in which a STA dynamically notifies an AP that it is unavailable for wireless communication for a specific period of time or under specific conditions, and is excluded from communication scheduling during that period.

[0221] In DUO mode, a STA can indicate that it is temporarily unable to transmit or receive, and the AP restricts the transmission of trigger frames or data to that STA. This enables efficient resource allocation according to the availability status of the STA.

[0222] 6) Enhanced Multi-Link Single-Radio (EMLSR)

[0223] Enhanced Multi-Link Single-Radio (EMLSR) is an operating mode in which a multi-link device with a single RF chain maintains a listening state on only one of multiple links and switches the listening link as needed.

[0224] In EMLSR, an STA performs a listening operation on only one of the sets of links designated as EMLSR links, and the remaining links may be in a non-receiving state. An STA can switch listening links through the exchange of control frames with an AP, and the time required for this switch is defined as the EMLSR transition delay. The AP adjusts the initial control frame and the TXOP start time in consideration of the STA's listening state and the transition delay.

[0225] FIG. 19 illustrates an example of an ICF / ICR exchange for Co-TDMA operation.

[0226] FIG. 19 illustrates an example in which AP 2 and AP 3, having received a BSRP (Buffer Status Report Poll) TF (Trigger Frame) used as an ICF in Co-TDMA operation, transmit a Multi-STA BlockAck (M-BA) frame as an ICR. If one or more APs transmit an ICR, AP 1, the sharing AP, may allocate a time / TXOP to only one of these APs, or sequentially allocate time / TXOPs to all requesting APs. Alternatively, it may not allocate a time / TXOP to any APs. Following this ICF / ICR exchange, the APs that sent the ICR cannot know whether they will be allocated a time / TXOP from AP 1, and if they do not actually receive a TXOP / time allocation, those APs will consume power unnecessarily.

[0227] Accordingly, the present specification proposes a method for delivering confirmation information to an AP that is the target of a TXOP / time allocation when multiple APs transmit an ICR in a Co-TDMA environment. Specifically, a 3-way handshake method for ICF / ICR exchange can be designed. Additionally, or alternatively, if the target of a DL frame transmission within an individual frame exchange of AP 1 is a STA operating in a mode such as EMLSR / DPS / DUO, confirmation information can be delivered by utilizing the ICF transmitted to that STA.

[0228] In this specification, based on the definitions in 802.11bn, an AP transmitting an ICF for MAPC operation is referred to as a Sharing AP (abbreviation: SAP), and an AP addressed or polled in the said ICF is referred to as a Polled AP (abbreviation: PAP). Additionally, among one or more polled APs, the AP on which coordination-based transmission is ultimately performed is referred to as a Coordinated AP (abbreviation: CAP). Furthermore, the ICF / ICR described in this specification includes not only the ICF / ICR exchanged between APs for MAPC operation, but also the ICF / ICR transmitted and received by each AP to switch the mode of a STA operating in a specific mode, such as EMLSR / DPS / DUO. Although the frame type of the said ICF / ICR may differ depending on the operational purpose (i.e., MAPC, EMLSR, DPS, DUO, NPCA, etc.), the same name is used in this specification.

[0229] Specific names proposed in this specification may be changed and are not limited.

[0230] 2. Transmission of a separate confirmation frame

[0231] This specification proposes a method for delivering confirmation information to an AP that is the target of a TXOP / time allocation among multiple APs when they transmit an ICR in a Co-TDMA environment. A PAP(s) that receives such confirmation information can recognize that it is scheduled to be allocated a TXOP / time. Additionally, if the expected time for the TXOP / time allocation is known, a power saving mechanism or NPCA can be performed according to capability prior to that period. A PAP(s) that has not obtained confirmation information from the SAP can recognize that no TXOP / time allocation is scheduled within the current SAP TXOP (e.g., whole TXOP, shared TXOP, or coordinated TXOP). Therefore, a PAP(s) that has not obtained confirmation information can perform a power saving mechanism or NPCA according to capability.

[0232] In this section, an example of a sequence is presented in which an additional (or separate) confirmation frame is transmitted following the polling phase (ICF / ICR exchange) in Co-TDMA to perform the polling phase based on a 3-way handshake.

[0233] 1) Additional Initial Control frame (or Control Response frame, CRF)

[0234] FIG. 20 illustrates Example-1 of a 3-way handshake-based polling phase based on additional ICF transmission.

[0235] An additional ICF may be transmitted to PAP(s) scheduled to be allocated time / TXOP within the TXOP currently acquired by SAP in order to convey confirmation information. That is, the ICF that SAP transmitted to PAP(s) during the 2-way polling phase can be reused and transmitted for confirmation purposes. Figure 20 shows an example of a 3-way handshake-based polling phase based on the transmission of an additional ICF.

[0236] AP 1, which acquires a TXOP and acts as a SAP, sends an ICF-(1) (or BSRP TF) to neighboring APs 2, 3, and 4 that are in a cooperative relationship, indicating that it intends to perform Co-TDMA. APs 2 and 3, which require a TXOP / time allocation after SIFS, respond with an ICR (or M-BA) indicating that they wish to participate in Co-TDMA and / or require a TXOP / time allocation. Based on the ICRs from multiple PAPs, AP 1 selects the PAP to which it will allocate the TXOP / time and can send an additional ICF-(2) to that AP.

[0237] Additionally or alternatively, a rule may be defined that if AP 1 acting as the SAP sends an ICR containing a positive indicator that the PAPs addressed in the ICF wish to participate, then TXOP / time must be allocated to all corresponding addressed PAPs. Based on this, the SAP may send an additional ICF-(2) to all PAPs wishing to participate for confirmation purposes.

[0238] In the example of FIG. 20, it is assumed that only one PAP (i.e., AP 3) is selected and an ICF-(2) containing the AP ID of AP 3 is sent. That is, while ICF-(1) may contain multiple User Info fields containing identifiers for multiple APs within the AID12 field, ICF-(2) may contain only one User Info field containing an identifier corresponding to AP 3, which is the target of the subsequent TXOP / time allocation, within the AID12 field. Additionally, or alternatively, when targeting a single AP, a BSRP GI3 Trigger frame (a BSRP trigger frame with a GI And UHR-LTF Type field of 3) may be utilized for ICF-(2).

[0239] Figure 21 illustrates an example of a sequential Co-TDMA sequence utilizing a 3-way handshake-based polling phase.

[0240] Additionally or alternatively, a situation may be assumed in which sequential TXOP / time allocations are scheduled for two or more PAPs. FIG. 21 shows an example of a Co-TDMA sequence when TXOPs are sequentially allocated to all PAPs that have selected or expressed their intention to participate in two or more CAPs. In this case, ICF-(1) and ICF-(2) may contain multiple User Info fields that include identifiers for multiple APs within the AID12 field. Additionally, ICF-(2) may include information indicating the priority and / or order of TXOP / time allocations.

[0241] Additionally or alternatively, the arrangement order of the User Info fields included in ICF-(2) may indicate / indicate the order of TXOP / time allocation. For example, the AP addressed in the AID12 field within the first User Info field (i.e., AP 3 in FIG. 21) may be allocated the TXOP / time first, and the AP addressed in the AID12 field within the second User Info field (i.e., AP 2 in FIG. 21) may be allocated the TXOP / time subsequently.

[0242] Additionally or alternatively, a separate field indicating the order of TXOP / time allocations may be defined and utilized within the User Info field of ICF-(2). For example, an n-bit(s) TXOP Allocation Order field may be defined and the field may indicate the order of allocations.

[0243] Additionally or alternatively, each AP can predict its allocation time based on Expected Triggering Timing information that may be included within each User Info field, without defining a separate field indicating the order of TXOP / time allocation.

[0244] In addition, the ICF-(2) transmitted from SAP in FIGS. 20 and 21 must be configured so as not to solicit the response frame in order to be used for confirmation purposes.

[0245] Additionally or alternatively, an appropriate response frame may be transmitted for the ICF-(2) transmitted from SAP for confirmation purposes. For example, if a BSRP Trigger frame is transmitted, a Multi-STA BlockAck frame included in a TB PPDU may be transmitted as a response frame. Also, if a BSRP GI3 Trigger frame is transmitted, a Multi-STA BlockAck frame included in a non-HT (duplicated) PPDU may be transmitted as a response frame.

[0246] Information that may be included in the ICF-(1) and ICF-(2) described above is defined and presented as follows. Specifically, the contents presented below may be included in the ICF-(1) and ICF-(2) in one or more combinations. One or more of the information, fields, and signaling bit(s) presented below may be added and defined within the BSRP TF (ICF-(1) and ICF-(2)), but are not limited thereto. Additionally, the specific names of the proposed information, fields, and signaling bit(s) may be changed.

[0247] a. Address: Address information of the target AP (e.g., BSS color, BSSID for Multi-AP, or MAC address)

[0248] b. Multi-AP group ID (or MAPC Agreement ID): An ID for the set of APs constituting the MAPC (e.g., 0, 1, 2, ...) or an ID according to an individual MAPC agreement

[0249] c. AP ID: An ID locally assigned by each AP within a configured multiple AP group / set (e.g., 0, 1, 2, ...)

[0250] For example, the corresponding AP ID can be included in the AID12 field within the User Info field of TF.

[0251] : Additionally or alternatively, the AP ID may be included within the AID12 field of the UHR Special User Info field, which may be newly defined for UHR.

[0252] For example, the corresponding AP ID can be included in the AID11 field within the STA Info field of the UHR NDP Announcement frame.

[0253] d. Multi-AP Coordination (MAPC) Type: Indicates Multi-AP cooperative transmission techniques such as Co-TDMA / SR / BF

[0254] For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the reserved value (e.g., 3) of the GI And HE / EHT-LTF Type / TXS Mode field.

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

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

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

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

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

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

[0261] 0: Co-TDMA

[0262] 1: Co-SR

[0263] 2: Co-BF

[0264] ...

[0265] For example, signaling can be done based on a bitmap as follows.

[0266] B0: Co-TDMA

[0267] B1: Co-SR

[0268] B2: Co-BF

[0269] ...

[0270] e. (Scheduled) Coordination Duration or Whole TXOP Duration: The period during which SAP collaborates with CAPs to perform cooperation-based transfers, or the period including the duration during which SAP performs individual FEs and the duration allocated to CAPs (Co-TDMA), or the total cooperation TXOP (Whole TXOP) period scheduled for MAPC operations.

[0271] For example, specify the coordination duration expected / planned by SAP.

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

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

[0274] Specifically, it is newly defined as the Coordination or Whole TXOP Duration field (tentative name) to indicate the information necessary for MAPC operation and the Coordination or Whole TXOP Duration values.

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

[0276] Specifically, the instruction includes the corresponding period value in the Allocation Duration field.

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

[0278] Additionally, or as an alternative, you can utilize the Reserved field of the User Info field.

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

[0280] f. Operating channel: Information on the operating primary and punctured channels

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

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

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

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

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

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

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

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

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

[0290] The primary channel of PAP or CAP may be included within the channel where SAP operates.

[0291] The primary channel of PAP or CAP may be included within the operation channel excluding the punctured channel of SAP.

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

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

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

[0295] g. Operating bandwidth: Information on operating bandwidth and maximum bandwidth

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

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

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

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

[0300] Set to 0: 20 MHz bandwidth indication

[0301] Set to 1: 40 MHz bandwidth indication

[0302] Set to 2: 80 MHz bandwidth indication

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

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

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

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

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

[0308] The bandwidth of PAP or CAP may be included within the total bandwidth in which SAP operates.

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

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

[0311] Set to 0: 20 MHz bandwidth indication

[0312] Set to 1: 40 MHz bandwidth indication

[0313] Set to 2: 80 MHz bandwidth indication

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

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

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

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

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

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

[0320] h. Expected Triggering Time: The triggering time of the collaboration-based transfer expected / planned by SAP

[0321] For example, the time when a MU-RTS TXS TF is transmitted in Co-TDMA, or the period during which frame exchange with the SAP's In-BSS STA is performed prior to transmitting the MU-RTS TXS TF (in this case, if User Info fields exist for two APs, the Expected Triggering Time values ​​for each User Info field may differ, as the triggering times must be different.)

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

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

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

[0325] For example, define a new field including the Expected triggering time and instruct

[0326] Specifically, define a new field tentatively named Expected Triggering Time to indicate the corresponding value.

[0327] For example, define a new element including the Expected triggering time and instruct

[0328] Specifically, define a new MAPC Operation element (tentative name) to indicate the information required for MAPC operation and the Expected triggering time value.

[0329] h. Low Latency Traffic Information: Information related to the Low Latency Traffic that each AP intends to transmit and receive.

[0330] For example, information on QoS Characteristic elements included in an SCS request / response frame

[0331] For example, utilizing the Delay Bound field information among the QoS Characteristic element information.

[0332] Specifically, the Delay Bound field value for the QoS traffic that each AP intends to transmit can be utilized as Low Latency Traffic information.

[0333] Through this, SAP can use it to check whether cooperation is necessary or to update existing values ​​with PAPs that can complete the transmission of MSDU or A-MSDU within the time when the TXOP interval to be shared ends (e.g., prior negotiated Low Latency Traffic information or Delay Bound field value is shorter than the allocated time).

[0334] For example, utilizing MSDU Lifetime field information among the QoS Characteristic element information

[0335] Specifically, the MSDU Lifetime field value for the QoS traffic that each AP intends to transmit can be utilized as Low Latency Traffic information.

[0336] Through this, SAP can use it to check whether cooperation is necessary or to update existing values ​​for PAPs that do not discard MSDUs within the time period of the TXOP to be shared (e.g., prior negotiated Low Latency Traffic information or MSDU Lifetime field values ​​that have not expired within the allocated time).

[0337] For example, utilizing the Service Start Time field information from the QoS Characteristic element

[0338] Specifically, the Service Start Time field value for the QoS traffic that each AP intends to transmit can be utilized as Low Latency Traffic information.

[0339] Through this, SAP can use it to check whether cooperation is necessary or to update existing values ​​with PAPs that can start the expected Service Period and frame exchange within the time when the TXOP period to be shared ends (e.g., prior negotiated Low Latency Traffic information or Service Start Time field value is shorter than the allocated time).

[0340] For example, TXOP sharing request information requested / directed by an AP requiring the transmission of Low Latency Traffic

[0341] For example, time-bound information of Low Latency Traffic requested / instructed by an AP that requires the transmission of Low Latency Traffic

[0342] For example, the minimum time-bound at which the transmission of low-latency traffic must begin.

[0343] For example, the maximum time-bound at which the transmission of low-latency traffic must be successfully completed.

[0344] For example, arrival rate information of Low Latency Traffic requested / instructed by an AP that requires the periodic transmission of Low Latency Traffic

[0345] For example, the arrival rate of Low Latency Traffic after the last reporting event

[0346] For example, TID (Traffic Identifier) / AC (Access Category) information for Low Latency Traffic

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

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

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

[0350] i. Traffic Priority: Priority information of traffic that SAP recommends to PAP or CAP, or priority information of traffic that SAP allows to PAP or CAP

[0351] For example, TID / AC information regarding traffic allowed to CAP within the TXOP acquired by SAP

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

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

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

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

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

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

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

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

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

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

[0362] For example, this may mean that protection is required for both TXOP sharing and TXOP return in Co-TDMA operation.

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

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

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

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

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

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

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

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

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

[0372] k. Control Info Type: Indicates the UHR feature type for the information contained in the corresponding ICF or CRF.

[0373] In other words, it indicates the purpose (e.g., MAPC) for which the BSRP TF was transmitted.

[0374] For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the reserved value (e.g., 3) of the GI And HE / EHT-LTF Type / TXS Mode field.

[0375] Additionally or alternatively, utilize EHT Reserved or Reserved in the Common Info field

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

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

[0378] 0: Indicates that it is a TF for MAPC operations

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

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

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

[0382] ...

[0383] Additionally or alternatively, instead of indicating only one Control Info Type, it may indicate that it was transmitted for one or more operational purposes such as DPS, IDC, NPCA, MAPC, etc.

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

[0385] An example of using a combination of bits (bitmap) to indicate the feature type and that delivered info is included is as follows.

[0386] If B0: MAPC, B1: DPS, B2: IDC, B3: NPCA, other bits: reserved, 1100 may indicate that instructions for MAPC and DPS operations and delivered info are included.

[0387] l. Control Frame Type: This indicates the type for which the corresponding BSRP TF was transmitted within a specific feature (e.g., MAPC). An example of signaling is as follows.

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

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

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

[0391] 3: Indicates that it is a frame for confirmation purposes.

[0392] Additionally or alternatively, instructions for the CRF and instructions for the frame for confirmation purposes can be integrated.

[0393] For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the reserved value (e.g., 3) of the GI And HE / EHT-LTF Type / TXS Mode field.

[0394] Additionally or alternatively, utilize EHT Reserved or Reserved in the Common Info field

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

[0396] m. TXOP Allocation Order: Information regarding the TXOP / time allocation order instructed to two or more PAPs

[0397] For example, the order in which SAP allocates TXOPs / times to multiple PAPs within the TXOPs acquired.

[0398] Specifically, a new n-bit(s) field can be defined and indicated as follows:

[0399] 0: First order

[0400] 1: Second order

[0401] 2: Third order

[0402] ...

[0403] Specifically, a new 1-bit field can be defined and indicated as follows.

[0404] 0: First order

[0405] 1: Second order

[0406] For example, you can utilize the Reserved field of the User Info field.

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

[0408] 2) Multi-STA BlockAck frame

[0409] Figure 22 illustrates Example-1 of a 3-way handshake-based polling phase transmitting M-BA.

[0410] A Multi-STA BlockAck frame may be transmitted to convey confirmation information to the PAP(s) scheduled to be allocated time / TXOP within the TXOP currently acquired by SAP. That is, SAP may also transmit an M-BA as confirmation for the M-BA received from the PAP(s) during the 2-way polling phase. Figure 22 shows an example of a 3-way handshake-based polling phase in which an M-BA is transmitted as confirmation.

[0411] AP 1, acting as the SAP after acquiring the TXOP, sends an ICF-(1) (e.g., BSRP TF) to neighboring APs 2, 3, and 4 that are in a cooperative relationship, indicating that it intends to perform Co-TDMA. AP 2 and AP 3, which require TXOP / time allocation after SIFS, respond with an ICR (e.g., M-BA) to indicate their desire to participate in Co-TDMA and / or the need for TXOP / time allocation. Based on the ICRs from multiple PAPs, AP 1 can select the PAP to which it will allocate the TXOP / time and send an M-BA to that AP. In the example of FIG. 22, it is assumed that only one PAP (i.e., AP 3) is selected and an M-BA containing AP 3's AP ID (e.g., included in the AID12 field within the M-BA frame) or MAC address is sent. In this case, the M-BA frame may be set to Ack Type = 0 and TID = 13 to indicate that Feedback Info is included.

[0412] FIG. 23 illustrates Example-2 of a 3-way handshake-based polling phase transmitting M-BA.

[0413] Additionally or alternatively, a situation may be assumed in which sequential TXOP / time allocations are scheduled for two or more PAP(s). FIG. 23 shows an example of a Co-TDMA sequence when two or more CAP(s) are selected to sequentially allocate TXOPs. In this case, the M-BA transmitted by the SAP may contain information indicating the priority and / or order of the TXOP / time allocations. Similarly, the M-BA frame may be set to Ack Type = 0 and TID = 13 to indicate that Feedback Info is included.

[0414] The information that may be included in the M-BA described above is defined and presented as follows. Specifically, the contents presented below may be included in the M-BA in one or more combinations. One or more of the information, fields, and signaling bit(s) presented below may be added and defined within the Multi-STA BlockAck, but are not limited thereto. Furthermore, the specific names of the proposed information, fields, and signaling bit(s) may be changed.

[0415] a. Operating channel: Information on the operating primary and punctured channels

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

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

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

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

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

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

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

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

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

[0425] SAP's primary channel can be included within the operating channel width of the DAP.

[0426] The SAP primary channel may be included within the operation channels excluding the DAP punctured channel.

[0427] b. Operating bandwidth: Information on operating bandwidth and maximum bandwidth

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

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

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

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

[0432] Set to 0: 20 MHz bandwidth indication

[0433] Set to 1: 40 MHz bandwidth indication

[0434] Set to 2: 80 MHz bandwidth indication

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

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

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

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

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

[0440] The bandwidth of the SAP can be included within the total bandwidth in which the DAP operates.

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

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

[0443] Set to 0: 20 MHz bandwidth indication

[0444] Set to 1: 40 MHz bandwidth indication

[0445] Set to 2: 80 MHz bandwidth indication

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

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

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

[0449] c. Required TXOP duration: Information related to the TXOP duration that each DAP wishes to receive.

[0450] For example, define a new field including Required TXOP Duration to indicate

[0451] Specifically, a new field tentatively named the Required Duration field is defined to indicate the information required for Co-TDMA operation and the Required TXOP Duration value.

[0452] Specifically, it is newly defined as the Required Duration field (or Coordination Duration field) to indicate the period required for Co-SR and Co-BF-based transmission.

[0453] For example, define a new element including Required TXOP Duration to indicate

[0454] Specifically, a new Co-TDMA Operation element (tentative name) is defined to indicate the information required for Co-TDMA operation and the Required TXOP Duration value.

[0455] Specifically, a new MAPC Operation element (tentative name) is defined to indicate the information required for MAPC-based transmission and the time required for cooperation-based transmission.

[0456] For example, instructing to include the Required TXOP Duration within a QoS Characteristic element that can be used to include negotiation information during the pre-negotiation process for MAPC operation, or within an element that can be newly defined for negotiation in the MAPC environment.

[0457] For example, instruct to include the Required TXOP Duration within a UHR Operation element that can be used to include announcement information during the announcement process of each AP for MAPC operation, or within an element that can be newly defined for announcements in the MAPC environment.

[0458] Alternatively, the Required TXOP Duration field can indicate the length of the PPDU required by the DAP for Co-SR and Co-BF-based transmission.

[0459] To this end, a new field may be defined as the Required (DL) PPDU Length field (tentative name).

[0460] d. Buffer status: Buffer status information for each DAP

[0461] Alternatively, the Buffer Status field can indicate the length of the PPDU required by the DAP for Co-SR and Co-BF-based transmission.

[0462] To this end, a new field may be defined as the Required (DL) PPDU Length field (tentative name).

[0463] e. TXOP sharing requirement (or Coordination requirement): Indicates whether Coordination Triggering / TXOP sharing is necessary due to the expiration of pre-negotiated Low Latency Traffic Information or the unnecessary nature of cooperation-based transmission / TXOP sharing (e.g., if individual FEs have already been performed).

[0464] For example, indicating and responding on whether Coordination Triggering / TXOP sharing using 1 bit is necessary.

[0465] bit 0: Indicates that the DAP receiving an ICF or selection request frame does not require coordination triggering.

[0466] bit 1: Indicates that the DAP receiving an ICF or selection request frame requires coordination triggering.

[0467] f. Low Latency Traffic Information: Information related to the Low Latency Traffic that each AP intends to transmit and receive.

[0468] For example, information on QoS Characteristic elements included in an SCS request / response frame

[0469] For example, utilizing the Delay Bound field information among the QoS Characteristic element information.

[0470] Specifically, the Delay Bound field value for the QoS traffic that each AP intends to transmit can be utilized as Low Latency Traffic information.

[0471] : For cases where the Low Latency Traffic Information has changed differently from the previously negotiated information, include the updated Low Latency Traffic information or Delay Bound field value.

[0472] For example, utilizing MSDU Lifetime field information among the QoS Characteristic element information

[0473] Specifically, the MSDU Lifetime field value for the QoS traffic that each AP intends to transmit can be utilized as Low Latency Traffic information.

[0474] : For cases where the Low Latency Traffic Information has changed differently from the previously negotiated information, include the updated Low Latency Traffic information or MSDU Lifetime field value.

[0475] For example, utilizing the Service Start Time field information from the QoS Characteristic element

[0476] Specifically, the Service Start Time field value for the QoS traffic that each AP intends to transmit can be utilized as Low Latency Traffic information.

[0477] : For cases where the Low Latency Traffic Information has changed differently from the pre-negotiated information, include the updated Low Latency Traffic information or the Service Start Time field value.

[0478] For example, TXOP sharing request information requested / directed by an AP requiring the transmission of Low Latency Traffic

[0479] For example, time-bound information of Low Latency Traffic requested / instructed by an AP that requires the transmission of Low Latency Traffic

[0480] For example, the minimum time-bound at which the transmission of Low Latency Traffic must begin.

[0481] For example, the maximum time-bound at which the transmission of low-latency traffic must be successfully completed.

[0482] For example, arrival rate information of Low Latency Traffic requested / instructed by an AP that requires the periodic transmission of Low Latency Traffic

[0483] For example, the arrival rate of Low Latency Traffic after the last reporting event

[0484] For example, TID / AC information for Low Latency Traffic

[0485] g. Status Code: Accept / Reject / Recommendation information for the Multi-AP selection (or coordination announcement) request (for example, the DAP selected by SAP may accept or reject based on whether coordination triggering is required for it, which may replace the TXOP sharing requirement (or Coordination requirement) information presented above)

[0486] -> For example, Accept or Success (e.g., SUCCESS)

[0487] For example, a Reject or a Reject including a Recommendation

[0488] Specifically, a rejection code containing the rejection reason (e.g., REJECTED_BAD_SUPPORTED_CHANNELS)

[0489] Specifically, a reject code including a recommendation (e.g., REJECTED_WITH_SUGGESTED_CHANGES)

[0490] If the value of the Status Code includes Reject or Recommendation, it may include information for a new selection request. That is, a DAP that receives a selection request frame may include additional information regarding the operating channel and bandwidth, required TXOP duration, low latency traffic information, etc. described above.

[0491] h. Participation Indication (1 bit): Indicates participation in a MAPC-based transmission solicited from the ICF.

[0492] That is, the DAP(s) that received a response from SAP indicate whether they currently require or do not require a single MAPC-based transmission as directed by SAP.

[0493] For example, a participation report using 1 bit could be as follows.

[0494] bit 0: Indicates not to participate in solicited MAPC-based transmissions

[0495] bit 1: Indicates participation in a solicited MAPC-based transmission.

[0496] i. Participation Indication (n bits): Indicates participation in a MAPC-based transmission solicited from the ICF.

[0497] That is, the DAP(s) that received a response from SAP indicate whether they currently require or do not require a single MAPC-based transmission as directed by SAP.

[0498] For example, a participation report using n bits could be as follows.

[0499] bit 0: Indicates not to participate in solicited MAPC-based transmissions

[0500] bit 1: Indicates participation in a solicited MAPC-based transmission.

[0501] bit 2: Indicates that it includes a recommendation to participate in a solicited MAPC-based transmission.

[0502] bit 3: Indicates that it includes the reason for not being able to participate in a solicited MAPC-based transmission.

[0503] -> Additionally or alternatively, participation in a specific scheme can be indicated using a Participation Indication field of the same format as the Multi-AP Coordination Type field that may be included in the ICF transmitted by SAP.

[0504] For example, if the Multi-AP Coordination Type field is defined as 3 bits and Co-TDMA operation is instructed by the SAP, the DAP can respond by setting 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.

[0505] For example, if the Multi-AP Coordination Type field is defined by n bits to indicate a specific scheme using a bitmap method, the 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.

[0506] j. Info Type: Indicates the purpose or type of the MAPC-related information included in the current frame.

[0507] For example, indicates that it is transmitted as a response frame in MAPC cooperation or a specific scheme (e.g., Co-TDMA / SR / BF).

[0508] Specifically, as shown below, the MAPC operation can indicate the purpose for which a frame was transmitted, and based on this, the receiving STA can determine what information is included.

[0509] 0: Indicates that it is an ICF in MAPC

[0510] 1: Indicates that it is an ICR in MAPC

[0511] 2: Indicates that it is a Co-Triggering frame in MAPC (e.g., MU-RTS TXS TF in Co-TDMA).

[0512] 3: Indicates that it is an ICR for confirmation purposes during the polling phase of MAPC.

[0513] 4: Indicates that it is an ICR for the purpose of TXOP return in Co-TDMA in MAPC.

[0514] ...

[0515] Specifically, as shown below, it is possible to indicate the purpose for which a frame was transmitted in a specific scheme, and based on this, the receiving STA can determine what information is included.

[0516] 0: Indicates that it is an ICF in Co-TDMA, Co-SR, or Co-BF.

[0517] 1: Indicates that it is an ICR in Co-TDMA, Co-SR, or Co-BF.

[0518] 2: Indicates that it is a Co-Triggering frame in Co-TDMA, Co-SR, or Co-BF (e.g., MU-RTS TXS TF in Co-TDMA).

[0519] 3: Indicates that it is an ICR for confirmation purposes during the polling phase of Co-TDMA or Co-SR.

[0520] 4: Indicates that it is an ICR for TXOP return purposes in Co-TDMA

[0521] ...

[0522] -> Additionally or alternatively, indicates that the frame is transmitted for the purpose of one of various UHR features (e.g., CoEx or IDC, NPCA, DPS, MAPC, etc.).

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

[0524] 0: Indicates that it is an M-BA for Multi-AP coordination operation

[0525] 1: Indicates that it is an M-BA for DPS operation

[0526] 2: Indicates that it is an M-BA for IDC operations

[0527] 3: Indicates that it is an M-BA for NPCA operations

[0528] other bits: reserved

[0529] Alternatively, each bit of the 4 bits can be used to indicate a specific feature (e.g., DPS, IDC, NPCA, MAPC, etc.) using a bitmap method.

[0530] An example of indicating the UHR feature type using a combination of each bit (bitmap) is as follows.

[0531] In the case where B0: MAPC, B1: DPS, B2: IDC, B3: NPCA, 1100 may include instructions and related information for MAPC and DPS operations.

[0532] k. MAPC Type: Instructions for Multi-AP cooperative transmission techniques such as Co-TDMA, Co-SR, and Co-BF

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

[0534] bit 0: None

[0535] bit 1: Co-TDMA

[0536] bit 2: Co-SR

[0537] bit 3: Co-BF

[0538] ...

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

[0540] 0: Co-TDMA

[0541] 1: Co-SR

[0542] 2: Co-BF

[0543] ...

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

[0545] For example, it indicates that an ICF / ICR exchange procedure is required to switch the EMLSR STA among the associated STAs from listening mode to frame exchange mode.

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

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

[0548] m. TXOP Return Indication: Indicates that the frame is intended for a TXOP return.

[0549] For example, use 1 bit to indicate that the frame was transmitted for the purpose of a TXOP return.

[0550] bit 0: Indicates that the frame is not intended for a TXOP return.

[0551] bit 1: Indicates that the frame is intended for a TXOP return.

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

[0553] Additionally or alternatively, instead of defining or including the TXOP Return Indication bit, some or all of the remaining feedback information related to the Co-TDMA operation may be set to a specific value (e.g., all 0s or all 1s).

[0554] For example, the value of the MAPC Type field can be set to default or 0 to indicate that it was transmitted for the purpose of a TXOP return.

[0555] : Additionally or alternatively, one of the MAPC Type values ​​can be defined and set as the value for the TXOP return.

[0556] For example, the value of the 1-bit Participation Indication bit can be set to 0 to indicate that participation has ended or that it has been transmitted for the purpose of a TXOP return.

[0557] : Additionally or alternatively, the value of the n-bit Participation Indication field can be set to 0 to indicate that participation has ended, or one of the values ​​of the Participation Indication field can be defined and set as a value for the TXOP return.

[0558] For example, you can set the value of the Required TXOP Duration field to 0 to indicate that all TXOPs / hours allocated from SAP have been used or that the allocated TXOPs / hours have been returned.

[0559] n. Expected Triggering Time: The triggering time of a collaboration-based transfer expected / planned by SAP

[0560] For example, the time when the MU-RTS TXS TF is transmitted in Co-TDMA, or the period during which frame exchange with the SAP's In-BSS STA is performed before transmitting the MU-RTS TXS TF.

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

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

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

[0564] For example, define a new field including the Expected triggering time and instruct

[0565] Specifically, define a new field tentatively named Expected Triggering Time to indicate the corresponding value.

[0566] For example, define a new element including the Expected triggering time and instruct

[0567] Specifically, define a new MAPC Operation element (tentative name) to indicate the information required for MAPC operation and the Expected triggering time value.

[0568] o. TXOP Allocation Order: Information regarding the TXOP / time allocation order instructed to two or more PAPs

[0569] For example, the order in which SAP allocates TXOPs / times to multiple PAPs within the TXOPs acquired.

[0570] Specifically, a new n-bit(s) field can be defined and indicated as follows:

[0571] 0: First order

[0572] 1: Second order

[0573] 2: Third order

[0574] ...

[0575] Specifically, a new 1-bit field can be defined and indicated as follows.

[0576] 0: First order

[0577] 1: Second order

[0578] For example, you can utilize the Reserved field of the User Info field.

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

[0580] The present specification proposes a method for delivering confirmation information to an AP that is the target of TXOP / time allocation when multiple APs transmit an ICR in a Co-TDMA environment. The PAP(s) that receive the confirmation information can recognize that they are scheduled to be allocated a TXOP / time.

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

[0582] An example of FIG. 24 can be performed on a transmitting STA or a transmitting device (AP and / or non-AP STA).

[0583] Some of the steps (or detailed sub-steps described later) of the example in Fig. 24 may be omitted or changed.

[0584] Through step S2410, the transmitting device (transmitting STA) can obtain information regarding the above-described Tone Plan. As described above, the information regarding the Tone Plan includes the size and location of the RU, control information related to the RU, information regarding the frequency band in which the RU is included, information regarding the STA receiving the RU, etc.

[0585] Through step S2420, the transmitting device can construct / generate a PPDU based on acquired control information. The step of constructing / generating the PPDU may include the step of constructing / generating each field of the PPDU. That is, step S2420 includes the step of constructing an EHT-SIG field containing control information regarding a Tone Plan. That is, step S2420 may include the step of constructing a field containing control information (e.g., N bitmap) indicating the size / location of the RU and / or the step of constructing a field containing an identifier (e.g., AID) of the STA receiving the RU.

[0586] Additionally, step S2420 may include the step of generating an STF / LTF sequence transmitted through a specific RU. The STF / LTF sequence may be generated based on a pre-configured STF generation sequence / LTF generation sequence.

[0587] Additionally, step S2420 may include a step of generating a data field (i.e., MPDU) transmitted through a specific RU.

[0588] The transmitting device can transmit the PPDU configured through step S2420 to the receiving device based on step S2430.

[0589] While performing step S2430, the transmitting device may perform at least one of the following operations: CSD, Spatial Mapping, IDFT / IFFT operation, GI insertion, etc.

[0590] A signal / field / sequence configured according to the present specification can be transmitted in the form of FIG. 5.

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

[0592] The above-described PPDU can be received according to an example of FIG. 25.

[0593] An example of FIG. 25 can be performed on a receiving STA or a receiving device (AP and / or non-AP STA).

[0594] Some of the steps of each example in FIG. 25 (or detailed sub-steps described later) may be omitted.

[0595] A receiving device (receiving STA) can receive all or part of the PPDU through step S2510. The received signal may be in the form of FIG. 5.

[0596] The sub-step of step S2510 can be determined based on step S2430 of FIG. 24. That is, step S2510 can perform an operation to restore the results of the CSD, Spatial Mapping, IDFT / IFFT operation, and GI insert operation applied in step S2430.

[0597] In step S2520, the receiving device can perform decoding of all or part of the PPDU. Additionally, the receiving device can obtain control information related to the Tone Plan (i.e., RU) from the decoded PPDU.

[0598] More specifically, the receiving device can decode the L-SIG and EHT-SIG of the PPDU based on the Legacy STF / LTF and obtain information contained in the L-SIG and EHT-SIG fields. Information regarding various Tone Plans (i.e., RU) described in this specification may be included in the EHT-SIG, and the receiving STA can obtain information regarding the Tone Plan (i.e., RU) through the EHT-SIG.

[0599] In step S2530, the receiving device can decode the remainder of the PPDU based on information regarding the Tone Plan (i.e., RU) obtained through step S2520. For example, the receiving STA can decode the STF / LTF fields of the PPDU based on information regarding the one Plan (i.e., RU). Additionally, the receiving STA can decode the data fields of the PPDU based on information regarding the Tone Plan (i.e., RU) and obtain the MPDU contained in the data fields.

[0600] Additionally, the receiving device can perform a processing operation to transmit the decoded data through step S2530 to an upper layer (e.g., MAC layer). Furthermore, if the generation of a signal is instructed from the upper layer to the PHY layer in response to the data transmitted to the upper layer, a subsequent operation can be performed.

[0601] Hereinafter, the above-described embodiment will be explained with reference to FIGS. 1 to 25.

[0602] FIG. 26 is a flowchart illustrating a 3-way handshake-based polling phase procedure in which a coordinated AP according to the present embodiment receives a separate acknowledgment frame.

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

[0604] An example of FIG. 26 can be performed at a second AP. The first AP may be a MAPC requesting AP that initiates MAPC negotiation with the second AP regarding at least one MAPC technique. The second AP may be a MAPC responding AP that responds to the MAPC requesting AP. Additionally, the first and second APs may be set as a coordinating AP or a coordinated AP through the MAPC negotiation.

[0605] The present embodiment proposes a sequence for performing a polling phase based on a 3-way handshake by transmitting an additional acknowledgment frame to the existing ICF / ICR exchange during the polling phase of a Co-TDMA procedure. Specifically, the present embodiment proposes a method for indicating the order for TXOP allocation or time allocation when there are multiple polled APs by setting the acknowledgment frame to an ICF, CRF, or M-BA.

[0606] In step S2610, the second AP (access point) receives the first ICF (Initial Control Frame) from the first AP.

[0607] In step S2620, the second AP transmits a first ICR (Initial Control Response) to the first AP in response to the first ICF.

[0608] In step S2630, the second AP receives an acknowledgment frame from the first AP.

[0609] The first AP is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP. The second AP is a coordinated AP that participates in the MAPC transmission. Here, the MAPC transmission can be assumed to be Co-TDMA (Coordinated time division multiple access).

[0610] The first ICF is used to verify whether there is an intention to perform the MAPC transmission. The first ICR may be used to convey an intention to participate in the MAPC transmission.

[0611] The above acknowledgment frame is used to convey information regarding time allocation for the MAPC transmission. Upon receiving the above acknowledgment frame, the second AP can recognize that it is scheduled to be allocated a TXOP or time for the MAPC transmission. Additionally, the second AP can check the expected time for the TXOP or time to be allocated for the MAPC transmission through the above acknowledgment frame.

[0612] If there are multiple polled APs, the polling step can be performed as follows.

[0613] The first AP may transmit the first ICF to the third AP. The first AP may receive a second ICR from the third AP in response to the first ICF. Likewise, the second ICR may be used to convey an intention to participate in the MAPC transmission.

[0614] At this time, the first ICF may be a BSRP (Buffer Status Report Poll) trigger frame, and the first and second ICRs may be M-BA (Multi-STA BlockAck).

[0615] For example, the first AP may select only the second AP and transmit the confirmation frame, and not transmit the confirmation frame to the third AP.

[0616] The first ICF may include a plurality of User Info fields. The plurality of User Info fields may include a first User Info field containing an identifier for the second AP and a second User Info field containing an identifier for the third AP.

[0617] The above confirmation frame may include one user information field containing an identifier for the second AP. Based on the fact that the above confirmation frame includes one user information field, the above confirmation frame may be a BSRP trigger frame in which the GI (Guard Interval) And UHR (Ultra High Reliability)-LTF (Long Training Field) Type field is set to 3.

[0618] As another example, the first AP can also transmit the acknowledgment frame to the third AP.

[0619] Unlike the preceding embodiment, the confirmation frame may include a plurality of user information fields. The plurality of user information fields may include a first user information field containing an identifier for the second AP and a second user information field containing an identifier for the third AP. Information regarding time allocation for MAPC transmission may include information regarding the order of time allocation for the second and third APs. The order of time allocation for the second and third APs may be determined based on the arrangement order of the first and second user information fields.

[0620] The second and third APs that receive the above acknowledgment frame may recognize that they are scheduled to be allocated a TXOP or time for the MAPC transmission. Additionally, the second and third APs may check the expected time for the TXOP or time to be allocated for the MAPC transmission through the above acknowledgment frame.

[0621] The above verification frame can be set to ICF (or CRF) or M-BA.

[0622] For example, based on the fact that the above confirmation frame is a second ICF, the first and second ICFs may include at least one of information regarding the use of the BSRP trigger frame, information regarding the expected triggering time, or information regarding the TXOP allocation order.

[0623] Information regarding the use of the above BSRP trigger frame may indicate that the above BSRP trigger frame is transmitted as an ICF, a cooperative trigger frame, a CRF (Control Response Frame), or the above acknowledgment frame.

[0624] The information regarding the above-mentioned expected triggering time may include information regarding the time when the first AP transmits a MU-RTS (Multi User-Request To Send) TXS (TXOP Sharing) trigger frame, or the time when the first AP performs frame exchange with an In-BSS (Basic Service Set) STA (station) before transmitting the MU-RTS TXS trigger frame.

[0625] The information regarding the TXOP allocation order may include the order of times allocated to the second and third APs within the TXOP acquired by the first AP.

[0626] As another example, the above acknowledgment frame may be an M-BA containing feedback information, with the Ack Type subfield set to 0 and the TID (Traffic Identifier) ​​subfield set to 13.

[0627] The above confirmation frame may include at least one of information regarding the use of the frame for the MAPC transmission, information regarding the expected triggering time, or information regarding the TXOP allocation order.

[0628] Information regarding the use of the frame for the above MAPC transmission may indicate that the frame for the above MAPC transmission is transmitted to an ICF, an ICR, a cooperative trigger frame, an ICR used as the acknowledgment frame, and an ICR used for TXOP return.

[0629] The information regarding the above-mentioned expected triggering time may include information regarding the time when the first AP transmits a MU-RTS (Multi User-Request To Send) TXS (TXOP Sharing) trigger frame, or the time when the first AP performs frame exchange with an In-BSS (Basic Service Set) STA (station) before transmitting the MU-RTS TXS trigger frame.

[0630] The information regarding the TXOP allocation order may include the order of times allocated to the second and third APs within the TXOP acquired by the first AP.

[0631] The first AP can transmit a MU-RTS TXS trigger frame to the polled APs that transmitted the acknowledgment frame to allocate a TXOP or time to perform the MAPC transmission (or Co-TDMA).

[0632] Specifically, the first AP can transmit a first MU-RTS TXS trigger frame to the second AP and a second MU-RTS TXS trigger frame to the third AP based on information regarding time allocation for the MAPC transmission.

[0633] The first AP can receive a first CTS (Clear To Send) frame from the second AP in response to the first MU-RTS TXS trigger frame. The first AP can receive a second CTS frame from the third AP in response to the second MU-RTS TXS trigger frame.

[0634] Frame exchange between the second AP and an In-BSS STA (a non-AP STA connected to the second AP) may be performed during a first TXOP allocated based on the first MU-RTS TXS trigger frame and the first CTS frame. Frame exchange between the third AP and an In-BSS STA (a non-AP STA connected to the third AP) may be performed during a second TXOP allocated based on the second MU-RTS TXS trigger frame and the second CTS frame. The order and timing of the first and second TXOPs may be determined based on information regarding the expected triggering time or information regarding the TXOP allocation order.

[0635] The present embodiment proposes a method for transmitting acknowledgment information to an AP that is the target of a TXOP or time allocation by additionally transmitting an acknowledgment frame during an ICF / ICR exchange in Co-TDMA operation. By doing so, the APs that sent the ICR can know whether they can receive a TXOP or time allocation from the coordinating AP, thereby preventing unnecessary power consumption.

[0636] According to the present embodiment, by transmitting an additional confirmation frame after the ICF / ICR exchange in Co-TDMA operation, clear confirmation information can be provided to the AP that is the actual target of the TXOP or time allocation. Accordingly, the following technical effects can be obtained.

[0637] (1) Clarification of whether to allocate TXOP

[0638] In the existing Co-TDMA procedure, even if the polled AP transmits an ICR, it is difficult to clearly determine whether a TXOP or time allocation will actually take place. According to the present embodiment, the coordinating AP can clearly notify whether a TXOP or time allocation is scheduled to take place or whether it has been excluded from the allocation target through an additional acknowledgment frame. Accordingly, the AP that transmitted the ICR does not need to wait in a state of uncertainty.

[0639] (2) Reduce unnecessary reception standby and power consumption

[0640] The AP that transmitted the ICR must maintain a receiving state considering the possibility of TXOP allocation, but in this case, unnecessary power consumption may occur due to maintaining PHY and RF circuit activity, channel monitoring, CTS, or waiting for subsequent frames.

[0641] In this embodiment, the AP that receives the confirmation information can immediately determine whether to allocate TXOP / time, so if it is not eligible for allocation, it can immediately switch to low-power operation. Therefore, power waste due to unnecessary standby time can be prevented.

[0642] (3) Linkage with Power Saving Mechanism

[0643] If the scheduled status and expected time of a TXOP or time allocation can be determined through a acknowledgment frame, the AP may perform a Power Saving mechanism or NPCA (Non-Primary Channel Access) operation according to its capability prior to the allocation time.

[0644] For example, if there is some time remaining until the scheduled allocation time, the AP can enter power-saving mode and then be reactivated just before the allocation time. This improves power efficiency.

[0645] (4) Efficient resource utilization of unallocated APs for TXOP

[0646] An AP that has not obtained confirmation information can clearly recognize that no time allocation is scheduled within the corresponding TXOP. Accordingly, instead of waiting unnecessarily in anticipation of channel occupancy, it can perform a Power Saving mechanism according to its capability or seek other channel access opportunities through NPCA operations. In other words, efficiency is improved in terms of network resource utilization.

[0647] (5) Improvement in scheduling predictability

[0648] When information regarding not only whether a TXOP / time allocation is scheduled, but also the expected timing or order is conveyed by an acknowledgment frame, each AP can establish a more precise resource usage plan. This has the effect of improving scheduling predictability in a Co-TDMA environment, increasing the stability of MAPC-based cooperative operation, and reducing the possibility of collisions in a multi-AP environment.

[0649] (6) Effects from a whole network perspective

[0650] The verification frame structure according to the present embodiment improves the reliability of the TXOP sharing procedure, reduces unnecessary waiting and channel occupancy, improves energy efficiency, and increases the efficiency of cooperative operation among multiple BSSs. In particular, the effect can be further enhanced in environments where multiple APs coexist, such as high-density environments or UHR operation modes.

[0651] FIG. 27 is a flowchart illustrating a 3-way handshake-based polling phase procedure in which a coordinating AP according to the present embodiment transmits a separate acknowledgment frame.

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

[0653] An example of FIG. 27 can be performed at a first AP. The first AP may be a MAPC requesting AP that initiates MAPC negotiation with the second AP regarding at least one MAPC technique. The second AP may be a MAPC responding AP that responds to the MAPC requesting AP. Additionally, the first and second APs may be established as a coordinating AP or a coordinated AP through the MAPC negotiation.

[0654] The present embodiment proposes a sequence for performing a polling phase based on a 3-way handshake by transmitting an additional acknowledgment frame to the existing ICF / ICR exchange during the polling phase of a Co-TDMA procedure. Specifically, the present embodiment proposes a method for indicating the order for TXOP allocation or time allocation when there are multiple polled APs by setting the acknowledgment frame to an ICF, CRF, or M-BA.

[0655] In step S2710, the first AP (access point) transmits the first ICF (Initial Control Frame) to the second AP.

[0656] In step S2720, the first AP receives a first ICR (Initial Control Response) from the second AP in response to the first ICF.

[0657] In step S2730, the first AP transmits an acknowledgment frame to the second AP.

[0658] The first AP is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP. The second AP is a coordinated AP that participates in the MAPC transmission. Here, the MAPC transmission can be assumed to be Co-TDMA (Coordinated time division multiple access).

[0659] The first ICF is used to verify whether there is an intention to perform the MAPC transmission. The first ICR may be used to convey an intention to participate in the MAPC transmission.

[0660] The above acknowledgment frame is used to convey information regarding time allocation for the MAPC transmission. Upon receiving the above acknowledgment frame, the second AP can recognize that it is scheduled to be allocated a TXOP or time for the MAPC transmission. Additionally, the second AP can check the expected time for the TXOP or time to be allocated for the MAPC transmission through the above acknowledgment frame.

[0661] If there are multiple polled APs, the polling step can be performed as follows.

[0662] The first AP may transmit the first ICF to the third AP. The first AP may receive a second ICR from the third AP in response to the first ICF. Likewise, the second ICR may be used to convey an intention to participate in the MAPC transmission.

[0663] At this time, the first ICF may be a BSRP (Buffer Status Report Poll) trigger frame, and the first and second ICRs may be M-BA (Multi-STA BlockAck).

[0664] For example, the first AP may select only the second AP and transmit the confirmation frame, and not transmit the confirmation frame to the third AP.

[0665] The first ICF may include a plurality of User Info fields. The plurality of User Info fields may include a first User Info field containing an identifier for the second AP and a second User Info field containing an identifier for the third AP.

[0666] The above confirmation frame may include one user information field containing an identifier for the second AP. Based on the fact that the above confirmation frame includes one user information field, the above confirmation frame may be a BSRP trigger frame in which the GI (Guard Interval) And UHR (Ultra High Reliability)-LTF (Long Training Field) Type field is set to 3.

[0667] As another example, the first AP can also transmit the acknowledgment frame to the third AP.

[0668] Unlike the preceding embodiment, the confirmation frame may include a plurality of user information fields. The plurality of user information fields may include a first user information field containing an identifier for the second AP and a second user information field containing an identifier for the third AP. Information regarding time allocation for MAPC transmission may include information regarding the order of time allocation for the second and third APs. The order of time allocation for the second and third APs may be determined based on the arrangement order of the first and second user information fields.

[0669] The second and third APs that receive the above acknowledgment frame may recognize that they are scheduled to be allocated a TXOP or time for the MAPC transmission. Additionally, the second and third APs may check the expected time for the TXOP or time to be allocated for the MAPC transmission through the above acknowledgment frame.

[0670] The above verification frame can be set to ICF (or CRF) or M-BA.

[0671] For example, based on the fact that the above confirmation frame is a second ICF, the first and second ICFs may include at least one of information regarding the use of the BSRP trigger frame, information regarding the expected triggering time, or information regarding the TXOP allocation order.

[0672] Information regarding the use of the above BSRP trigger frame may indicate that the above BSRP trigger frame is transmitted as an ICF, a cooperative trigger frame, a CRF (Control Response Frame), or the above acknowledgment frame.

[0673] The information regarding the above-mentioned expected triggering time may include information regarding the time when the first AP transmits a MU-RTS (Multi User-Request To Send) TXS (TXOP Sharing) trigger frame, or the time when the first AP performs frame exchange with an In-BSS (Basic Service Set) STA (station) before transmitting the MU-RTS TXS trigger frame.

[0674] The information regarding the TXOP allocation order may include the order of times allocated to the second and third APs within the TXOP acquired by the first AP.

[0675] As another example, the above acknowledgment frame may be an M-BA containing feedback information, with the Ack Type subfield set to 0 and the TID (Traffic Identifier) ​​subfield set to 13.

[0676] The above confirmation frame may include at least one of information regarding the use of the frame for the MAPC transmission, information regarding the expected triggering time, or information regarding the TXOP allocation order.

[0677] Information regarding the use of the frame for the above MAPC transmission may indicate that the frame for the above MAPC transmission is transmitted to an ICF, an ICR, a cooperative trigger frame, an ICR used as the acknowledgment frame, and an ICR used for TXOP return.

[0678] The information regarding the above-mentioned expected triggering time may include information regarding the time when the first AP transmits a MU-RTS (Multi User-Request To Send) TXS (TXOP Sharing) trigger frame, or the time when the first AP performs frame exchange with an In-BSS (Basic Service Set) STA (station) before transmitting the MU-RTS TXS trigger frame.

[0679] The information regarding the TXOP allocation order may include the order of times allocated to the second and third APs within the TXOP acquired by the first AP.

[0680] The first AP can transmit a MU-RTS TXS trigger frame to the polled APs that transmitted the acknowledgment frame to allocate a TXOP or time to perform the MAPC transmission (or Co-TDMA).

[0681] Specifically, the first AP can transmit a first MU-RTS TXS trigger frame to the second AP and a second MU-RTS TXS trigger frame to the third AP based on information regarding time allocation for the MAPC transmission.

[0682] The first AP can receive a first CTS (Clear To Send) frame from the second AP in response to the first MU-RTS TXS trigger frame. The first AP can receive a second CTS frame from the third AP in response to the second MU-RTS TXS trigger frame.

[0683] Frame exchange between the second AP and an In-BSS STA (a non-AP STA connected to the second AP) may be performed during a first TXOP allocated based on the first MU-RTS TXS trigger frame and the first CTS frame. Frame exchange between the third AP and an In-BSS STA (a non-AP STA connected to the third AP) may be performed during a second TXOP allocated based on the second MU-RTS TXS trigger frame and the second CTS frame. The order and timing of the first and second TXOPs may be determined based on information regarding the expected triggering time or information regarding the TXOP allocation order.

[0684] The present embodiment proposes a method for transmitting acknowledgment information to an AP that is the target of a TXOP or time allocation by additionally transmitting an acknowledgment frame during an ICF / ICR exchange in Co-TDMA operation. By doing so, the APs that sent the ICR can know whether they can receive a TXOP or time allocation from the coordinating AP, thereby preventing unnecessary power consumption.

[0685] According to the present embodiment, by transmitting an additional confirmation frame after the ICF / ICR exchange in Co-TDMA operation, clear confirmation information can be provided to the AP that is the actual target of the TXOP or time allocation. Accordingly, the following technical effects can be obtained.

[0686] (1) Clarification of whether to allocate TXOP

[0687] In the existing Co-TDMA procedure, even if the polled AP transmits an ICR, it is difficult to clearly determine whether a TXOP or time allocation will actually take place. According to the present embodiment, the coordinating AP can clearly notify whether a TXOP or time allocation is scheduled to take place or whether it has been excluded from the allocation target through an additional acknowledgment frame. Accordingly, the AP that transmitted the ICR does not need to wait in a state of uncertainty.

[0688] (2) Reduce unnecessary reception standby and power consumption

[0689] The AP that transmitted the ICR must maintain a receiving state considering the possibility of TXOP allocation, but in this case, unnecessary power consumption may occur due to maintaining PHY and RF circuit activity, channel monitoring, CTS, or waiting for subsequent frames.

[0690] In this embodiment, the AP that receives the confirmation information can immediately determine whether to allocate TXOP / time, so if it is not eligible for allocation, it can immediately switch to low-power operation. Therefore, power waste due to unnecessary standby time can be prevented.

[0691] (3) Linkage with Power Saving Mechanism

[0692] If the scheduled status and expected time of a TXOP or time allocation can be determined through a acknowledgment frame, the AP may perform a Power Saving mechanism or NPCA (Non-Primary Channel Access) operation according to its capability prior to the allocation time.

[0693] For example, if there is some time remaining until the scheduled allocation time, the AP can enter power-saving mode and then be reactivated just before the allocation time. This improves power efficiency.

[0694] (4) Efficient resource utilization of unallocated APs for TXOP

[0695] An AP that has not obtained confirmation information can clearly recognize that no time allocation is scheduled within the corresponding TXOP. Accordingly, instead of waiting unnecessarily in anticipation of channel occupancy, it can perform a Power Saving mechanism according to its capability or seek other channel access opportunities through NPCA operations. In other words, efficiency is improved in terms of network resource utilization.

[0696] (5) Improvement in scheduling predictability

[0697] When information regarding not only whether a TXOP / time allocation is scheduled, but also the expected timing or order is conveyed by an acknowledgment frame, each AP can establish a more precise resource usage plan. This has the effect of improving scheduling predictability in a Co-TDMA environment, increasing the stability of MAPC-based cooperative operation, and reducing the possibility of collisions in a multi-AP environment.

[0698] (6) Effects from a whole network perspective

[0699] The verification frame structure according to the present embodiment improves the reliability of the TXOP sharing procedure, reduces unnecessary waiting and channel occupancy, improves energy efficiency, and increases the efficiency of cooperative operation among multiple BSSs. In particular, the effect can be further enhanced in environments where multiple APs coexist, such as high-density environments or UHR operation modes.

[0700] <Device Configuration>

[0701] The technical features of the specification described above may be applied to various devices and methods. For example, the technical features of the specification described above may be performed / supported through the device of FIG. 1 and / or FIG. 13. For example, the technical features of the specification described above may be applied only to parts of FIG. 1 and / or FIG. 13. For example, the technical features of the specification described above may 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 (610) and memory (620) of FIG. 13. For example, the device of the specification transmits a first ICF (Initial Control Frame) to a second AP (access point); receives a first ICR (Initial Control Response) from the second AP in response to the first ICF; and transmits an acknowledgment frame to the second AP.

[0702] The technical features of this specification may be implemented based on a computer-readable medium (CRM). For example, the CRM proposed by this specification is at least one computer-readable medium comprising instructions based on execution by at least one processor.

[0703] The above CRM may store instructions for performing operations including the step of transmitting a first ICF (Initial Control Frame) to a second AP (access point); the step of receiving a first ICR (Initial Control Response) from the second AP in response to the first ICF; and the step of transmitting an acknowledgment frame to the second AP. Instructions stored in the CRM of this specification may be executed by at least one processor. At least one processor associated with the CRM of this specification may be the processor (111, 121) or processing chip (114, 124) of FIG. 1, or the processor (610) of FIG. 13. Meanwhile, the CRM of this specification may be the memory (112, 122) of FIG. 1, the memory (620) of FIG. 13, or a separate external memory / storage medium / disk, etc.

[0704] The technical features of the present specification described above are applicable to various applications or business models. For example, the technical features described above may be applied for wireless communication in devices supporting Artificial Intelligence (AI).

[0705] Artificial intelligence refers to the field of researching artificial intelligence or the methodologies to create it, while machine learning refers to the field of researching methodologies to define and solve various problems addressed within the field of artificial intelligence. Machine learning is also defined as an algorithm that improves performance on a task through continuous experience.

[0706] An Artificial Neural Network (ANN) is a model used in machine learning that can refer to any model capable of problem-solving, composed of artificial neurons (nodes) that form a network through the connection of synapses. An artificial neural network can be defined by connection patterns between neurons in different layers, a learning process that updates model parameters, and an activation function that generates output values.

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

[0708] Model parameters refer to parameters determined through learning, including synaptic connection weights and neuron biases. Hyperparameters, on the other hand, refer to parameters that must be set prior to training in a machine learning algorithm, including the learning rate, number of iterations, mini-batch size, and initialization function.

[0709] The objective of training an artificial neural network can be viewed as determining model parameters that minimize the loss function. The loss function can be used as an indicator to determine optimal model parameters during the training process of an artificial neural network.

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

[0711] Supervised learning refers to a method of training an artificial neural network with labels provided for the training data; a label can refer to the correct answer (or result) that the neural network must infer when the training data is input. Unsupervised learning refers to a method of training an artificial neural network without labels provided for the training data. Reinforcement learning refers to a learning method in which an agent defined within an environment is trained to select an action or sequence of actions that maximizes the cumulative reward in each state.

[0712] Machine learning implemented using a Deep Neural Network (DNN) that includes multiple hidden layers among artificial neural networks is also called Deep Learning, and Deep Learning is a part of Machine Learning. Hereinafter, Machine Learning is used in a sense that includes Deep Learning.

[0713] In addition, the aforementioned technical features can be applied to the wireless communication of robots.

[0714] A robot can refer to a machine that automatically processes or operates a given task based on its own capabilities. In particular, a robot that has the ability to perceive its environment, make decisions on its own, and perform actions can be called an intelligent robot.

[0715] Robots can be classified into industrial, medical, domestic, and military types depending on their purpose or field of use. Robots are equipped with drive units, including actuators or motors, to perform various physical movements, such as moving robot joints. Additionally, mobile robots include wheels, brakes, and propellers in their drive units, enabling them to drive on the ground or fly in the air.

[0716] In addition, the aforementioned technical features can be applied to devices that support augmented reality.

[0717] Extended Reality is a collective term for Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR). VR technology provides real-world objects or backgrounds solely as CG images, AR technology provides virtual CG images superimposed on real-world images, and MR technology is a computer graphics technology that mixes and combines virtual objects with the real world.

[0718] MR technology is similar to AR technology in that it displays real-world objects and virtual objects together. However, there is a difference in that while virtual objects in AR technology are used to complement real-world objects, virtual objects and real-world objects are used as equals in MR technology.

[0719] XR technology can be applied to HMDs (Head-Mount Displays), HUDs (Head-Up Displays), mobile phones, tablet PCs, laptops, desktops, TVs, digital signage, etc., and devices to which XR technology is applied can be called XR devices.

[0720] The claims described in this specification may be combined in various ways. For example, the technical features of the method claims in this specification may be combined to be implemented as a device, and the technical features of the device claims in this specification may be combined to be implemented as a method. Furthermore, the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a device, and the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a method.

Claims

1. In a wireless LAN system, A step in which the first AP (access point) transmits the first ICF (Initial Control Frame) to the second AP; The first AP receives a first ICR (Initial Control Response) from the second AP in response to the first ICF; and The above first AP includes the step of transmitting a confirmation frame to the above second AP, wherein The first AP above is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above first ICF is used to determine whether there is an intention to perform the above MAPC transmission, and The above acknowledgment frame is used to convey information regarding time allocation for the above MAPC transmission. method.

2. In Paragraph 1, The step of the first AP transmitting the first ICF to the third AP; and The above first AP includes the step of receiving a second ICR from the third AP in response to the first ICF, wherein The above first and second ICRs are used to convey an intention to participate in the MAPC transmission, and The above-mentioned first ICF is a BSRP (Buffer Status Report Poll) trigger frame, and The above first and second ICRs are M-BA (Multi-STA BlockAck) method.

3. In Paragraph 2, The above-mentioned first ICF includes a plurality of user information fields, and The plurality of user information fields above include a first user information field including an identifier for the second AP and a second user information field including an identifier for the third AP, and The above confirmation frame includes one user information field containing an identifier for the second AP, and Based on the fact that the above confirmation frame includes one user information field, the above confirmation frame is a BSRP trigger frame in which the GI And UHR-LTF Type field is set to 3. method.

4. In Paragraph 2, The above first AP further includes the step of transmitting the acknowledgment frame to the third AP, wherein The above confirmation frame includes a plurality of user information fields, and The plurality of user information fields above include a first user information field including an identifier for the second AP and a second user information field including an identifier for the third AP, and The information regarding the time allocation for the above MAPC transmission includes information regarding the order of the time allocations of the second and third APs. method.

5. In Paragraph 4, The order of time allocation for the above-mentioned second and third APs is determined based on the arrangement order of the above-mentioned first and second user information fields. method.

6. In Paragraph 4, Based on the fact that the above confirmation frame is a second ICF, the first and second ICFs include at least one of information regarding the use of the BSRP trigger frame, information regarding the expected triggering time, or information regarding the TXOP allocation order, and Information regarding the use of the above BSRP trigger frame indicates that the above BSRP trigger frame is transmitted as an ICF, a cooperative trigger frame, a CRF (Control Response Frame), or the above acknowledgment frame, and The information regarding the above-mentioned expected triggering time includes information regarding the time when the first AP transmits a MU-RTS (Multi User-Request To Send) TXS (TXOP Sharing) trigger frame or the time when the first AP performs frame exchange with an In-BSS (Basic Service Set) STA (station) before transmitting the MU-RTS TXS trigger frame. The information regarding the TXOP allocation order includes the order of times allocated to the second and third APs within the TXOP acquired by the first AP. method.

7. In Paragraph 2, The above acknowledgment frame is an M-BA containing feedback information with the Ack Type subfield set to 0 and the TID (Traffic Identifier) ​​subfield set to 13, and The above acknowledgment frame includes at least one of information regarding the purpose of the frame for the MAPC transmission, information regarding the expected triggering time, or information regarding the TXOP allocation order, and Information regarding the use of the frame for the above MAPC transmission indicates that the frame for the above MAPC transmission is transmitted as an ICF, an ICR, a cooperative trigger frame, an ICR used as the acknowledgment frame, and an ICR used for TXOP return, and The information regarding the above-mentioned expected triggering time includes information regarding the time when the first AP transmits a MU-RTS (Multi User-Request To Send) TXS (TXOP Sharing) trigger frame or the time when the first AP performs frame exchange with an In-BSS (Basic Service Set) STA (station) before transmitting the MU-RTS TXS trigger frame. The information regarding the TXOP allocation order includes the order of times allocated to the second and third APs within the TXOP acquired by the first AP. method.

8. In Paragraph 4, The step of the first AP transmitting a first MU-RTS TXS trigger frame to the second AP and transmitting a second MU-RTS TXS trigger frame to the third AP based on information regarding time allocation for the MAPC transmission; The first AP receives a first CTS (Clear To Send) frame from the second AP in response to the first MU-RTS TXS trigger frame; and The above-mentioned first AP further includes the step of receiving a second CTS frame from the third AP in response to the second MU-RTS TXS trigger frame, wherein Frame exchange between the second AP and the In-BSS STA is performed during the first TXOP allocated based on the first MU-RTS TXS trigger frame and the first CTS frame, and Frame exchange between the third AP and the In-BSS STA is performed during the second TXOP allocated based on the second MU-RTS TXS trigger frame and the second CTS frame. method.

9. In a wireless LAN system, the first AP (access point) is, Memory; transceiver; and The processor comprises the memory and the transceiver, operably coupled thereto, wherein the processor comprises: Transmit the first ICF (Initial Control Frame) to the second AP; Receiving a first ICR (Initial Control Response) from the second AP as a response to the first ICF; and Transmit a confirmation frame to the above-mentioned second AP, The first AP above is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above first ICF is used to determine whether there is an intention to perform the above MAPC transmission, and The above acknowledgment frame is used to convey information regarding time allocation for the above MAPC transmission. 1st AP.

10. In wireless LAN systems, A step in which a second AP (access point) receives a first ICF (Initial Control Frame) from a first AP; The step of the second AP transmitting a first ICR (Initial Control Response) to the first AP in response to the first ICF; and The above second AP includes the step of receiving a confirmation frame from the above first AP, wherein The first AP above is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above first ICF is used to determine whether there is an intention to perform the above MAPC transmission, and The above acknowledgment frame is used to convey information regarding time allocation for the above MAPC transmission. method.

11. In Paragraph 10, The third AP receives the first ICF from the first AP; and The above third AP includes the step of transmitting a second ICR to the first AP in response to the first ICF, wherein The above first and second ICRs are used to convey an intention to participate in the MAPC transmission, and The above-mentioned first ICF is a BSRP (Buffer Status Report Poll) trigger frame, and The above first and second ICRs are M-BA (Multi-STA BlockAck) method.

12. In Paragraph 11, The above-mentioned first ICF includes a plurality of user information fields, and The plurality of user information fields above include a first user information field including an identifier for the second AP and a second user information field including an identifier for the third AP, and The above confirmation frame includes one user information field containing an identifier for the second AP, and Based on the fact that the above confirmation frame includes one user information field, the above confirmation frame is a BSRP trigger frame in which the GI And UHR-LTF Type field is set to 3. method.

13. In Paragraph 11, The above third AP further includes the step of receiving the acknowledgment frame from the above first AP, wherein The above confirmation frame includes a plurality of user information fields, and The plurality of user information fields above include a first user information field including an identifier for the second AP and a second user information field including an identifier for the third AP, and The information regarding the time allocation for the above MAPC transmission includes information regarding the order of the time allocations of the second and third APs. method.

14. In Paragraph 13, The order of time allocation for the above-mentioned second and third APs is determined based on the arrangement order of the above-mentioned first and second user information fields. method.

15. In Paragraph 14, Based on the fact that the above confirmation frame is a second ICF, the first and second ICFs include at least one of information regarding the use of the BSRP trigger frame, information regarding the expected triggering time, or information regarding the TXOP allocation order, and Information regarding the use of the above BSRP trigger frame indicates that the above BSRP trigger frame is transmitted as an ICF, a cooperative trigger frame, a CRF (Control Response Frame), or the above acknowledgment frame, and The information regarding the above-mentioned expected triggering time includes information regarding the time when the first AP transmits a MU-RTS (Multi User-Request To Send) TXS (TXOP Sharing) trigger frame or the time when the first AP performs frame exchange with an In-BSS (Basic Service Set) STA (station) before transmitting the MU-RTS TXS trigger frame. The information regarding the TXOP allocation order includes the order of times allocated to the second and third APs within the TXOP acquired by the first AP. method.

16. In Paragraph 11, The above acknowledgment frame is an M-BA containing feedback information with the Ack Type subfield set to 0 and the TID (Traffic Identifier) ​​subfield set to 13, and The above acknowledgment frame includes at least one of information regarding the purpose of the frame for the MAPC transmission, information regarding the expected triggering time, or information regarding the TXOP allocation order, and Information regarding the use of the frame for the above MAPC transmission indicates that the frame for the above MAPC transmission is transmitted as an ICF, an ICR, a cooperative trigger frame, an ICR used as the acknowledgment frame, and an ICR used for TXOP return, and The information regarding the above-mentioned expected triggering time includes information regarding the time when the first AP transmits a MU-RTS (Multi User-Request To Send) TXS (TXOP Sharing) trigger frame or the time when the first AP performs frame exchange with an In-BSS (Basic Service Set) STA (station) before transmitting the MU-RTS TXS trigger frame. The information regarding the TXOP allocation order includes the order of times allocated to the second and third APs within the TXOP acquired by the first AP. method.

17. In a wireless LAN system, the second AP (access point) is, Memory; transceiver; and The processor comprises the memory and the transceiver, operably coupled thereto, wherein the processor comprises: Receive the first ICF (Initial Control Frame) from the first AP; Transmitting a first ICR (Initial Control Response) to the first AP in response to the first ICF; and Receive a confirmation frame from the above-mentioned first AP, The first AP above is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above first ICF is used to determine whether there is an intention to perform the above MAPC transmission, and The above acknowledgment frame is used to convey information regarding time allocation for the above MAPC transmission. 2nd AP.

18. At least one computer-readable medium comprising an instruction based on execution by at least one processor, A step of transmitting a first ICF (Initial Control Frame) to a second AP (access point); A step of receiving a first ICR (Initial Control Response) from the second AP as a response to the first ICF; and The method includes the step of transmitting a confirmation frame to the second AP, The first AP is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above first ICF is used to determine whether there is an intention to perform the above MAPC transmission, and The above acknowledgment frame is used to convey information regarding time allocation for the above MAPC transmission. Recording media.

19. In a device in a wireless LAN system, Memory; and The processor comprises the above memory and operablely coupled thereto, wherein the processor is: Transmit the first ICF (Initial Control Frame) to the second AP (access point); Receiving a first ICR (Initial Control Response) from the second AP as a response to the first ICF; and Transmit a confirmation frame to the above-mentioned second AP, The first AP is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above first ICF is used to determine whether there is an intention to perform the above MAPC transmission, and The above acknowledgment frame is used to convey information regarding time allocation for the above MAPC transmission. device.

Images