Communication methods and equipment for implementing coordination between access points (APs) by selecting at least one AP to share a transmission opportunity (TXOP) in a wireless local area network (LAN), access points, and computer-readable media.

Abstract

The invention relates to a method and transmission apparatus for performing coordination between access points (APs) by selecting APs sharing TXOP in a wireless LAN. Specifically, the first AP receives a select request frame from the second AP. The first AP transmits a select response frame to the second AP. The second AP selects the first AP as the AP, which will share the TXOP for coordination between APs, based on the select request frame and the select response frame. The invention also relates to access points and computer-readable means.

Description

Method and device for performing cooperation among multiple APs by selecting one or more APs sharing TXOP in a wireless LAN system

[0001] The present specification relates to a technique for performing cooperation between multiple APs by selecting one or more APs that share a TXOP in a wireless LAN system, and more specifically, to a method and device for transmitting and receiving information necessary for selecting one or more APs that share the TXOP.

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

[0003] The present specification proposes a method and device for performing cooperation between multiple APs by selecting one or more APs that share a TXOP in a wireless LAN system.

[0004] An example of this specification proposes a method for performing cooperation between multiple APs by selecting one or more APs that share a TXOP.

[0005] The present 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 the 802.11be system and can satisfy backward compatibility with the 802.11be system.

[0006] The present embodiment is performed in a first AP, and the first AP may be set as a shared AP (DAP) after negotiation in multi-AP communication, and the second AP may be set as a sharing AP (SAP) after negotiation in multi-AP communication. The first and second non-AP STAs of the present embodiment may correspond to at least one STA (station).

[0007] The present embodiment proposes a method for performing cooperation between multiple APs (e.g., C-TDMA, C-SR, C-BF, C-OFDMA, or J-TX) by selecting one or more APs that share a TXOP. In particular, the present embodiment proposes a method for determining the necessity of multi-AP cooperation of a DAP by determining the necessity in the procedure of selecting one or more APs, and securing a period set in the Duration field so that the DAP performs frame exchange with a non-AP STA within a BSS after the period.

[0008] The first AP (access point) receives a selection request frame from the second AP.

[0009] The first AP transmits a selection response frame to the second AP.

[0010] Based on the above selection request frame and the above selection response frame, the first AP is selected as an AP with which to share TXOP (Transmit Opportunity) for cooperation between multiple APs.

[0011] The above selection request frame may include at least one of information about a TXOP section scheduled by the second AP for cooperation among the plurality of APs, information about a time point at which the second AP expects or schedules to share the TXOP, information about low-latency traffic that each of the plurality of APs intends to transmit and receive, and information about a priority or protection level of cooperation among the plurality of APs.

[0012] The TXOP interval scheduled by the second AP for cooperation between the plurality of APs may be a nominal TXOP interval scheduled by the second AP for cooperation between the plurality of APs.

[0013] In addition, the selection request frame may further include at least one of an identifier of a group for cooperation between the plurality of APs, an identifier of the Shared AP, information about a capability to operate as the Sharing AP, information indicating that the Sharing AP shares the TXOP with the Shared AP, information about a technique for cooperation between the plurality of APs, address information of the Shared AP, channel information on which the plurality of APs operate, and bandwidth information on which the plurality of APs operate.

[0014] The above selection response frame may include at least one of an identifier of a group for cooperation between the plurality of APs, an identifier of the Shared AP, address information of the Shared AP, channel information on which the plurality of APs operate, bandwidth information on which the plurality of APs operate, information on a section of a TXOP that the Shared AP wishes to share, buffer status information of the Shared AP, information on whether sharing of a TXOP by the Sharing AP is necessary, information on low-latency traffic transmitted and received by each of the plurality of APs, and a status code.

[0015] That is, the present embodiment proposes a method for selecting (or deciding whether to select) the first AP as a DAP participating in cooperation between multiple APs by determining whether TXOP sharing (or cooperation between APs (e.g., C-TDMA, C-SR, C-BF, C-OFDMA or J-TX) is required for the first AP based on the information described above in the procedure for selecting one or more APs.

[0016] According to the embodiment proposed in this specification, through the procedure of selecting one or more APs, the SAP can determine the necessity of inter-AP cooperation of DAPs within the acquired TXOP, and if the DAP does not require inter-AP cooperation, the SAP can decide to perform inter-AP cooperation with a subsequent DAP or not perform the inter-AP cooperation operation. This has the effect of reducing the overhead in the procedure for multi-AP selection by having the SAP inform the target DAP of information about TXOP sharing (or inter-AP cooperation).

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

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

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

[0020] Figure 4 illustrates one embodiment of a multi-link (ML).

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

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

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

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

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

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

[0027] Figure 11 illustrates an example of channels used / supported / defined within the 5 GHz band.

[0028] Figure 12 illustrates an example of channels used / supported / defined within the 6 GHz band.

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

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

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

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

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

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

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

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

[0037] Figure 21 illustrates an example of CIRP contents and CIR field format for the A-Control based notify method.

[0038] Figure 22 illustrates an example of a Multi-AP selection procedure using the 2.1.1 Request / Response based selection method.

[0039] Figure 23 illustrates an example of a Multi-AP selection procedure using the 2.1.2 A-Control based selection method.

[0040] Figure 24 illustrates an example of a Multi-AP selection procedure using the 2.1.3 MU-RTS TF / CTS frame-based selection method.

[0041] Figure 25 illustrates an example of a Multi-AP selection procedure using the 2.1.4 one-way instruction-based selection method.

[0042] Figure 26 illustrates an example of a Multi-AP selection procedure performed prior to TXOP acquisition.

[0043] Figure 27 illustrates an example of a method for setting the Duration field of a Multi-AP selection request frame.

[0044] Figure 28 illustrates an example-1 of a Simultaneous Multi-AP selection procedure for selecting multiple DAPs.

[0045] Figure 29 illustrates an example-2 of a Simultaneous Multi-AP selection procedure for selecting multiple DAPs.

[0046] Figure 30 illustrates an example-3 of a Simultaneous Multi-AP selection procedure for selecting multiple DAPs.

[0047] Figure 31 illustrates an example-4 of a Simultaneous Multi-AP selection procedure for selecting multiple DAPs.

[0048] Figure 32 illustrates an example-1 of a Sequential Multi-AP selection procedure for selecting multiple DAPs.

[0049] Figure 33 illustrates an example-2 of a Sequential Multi-AP selection procedure for selecting multiple DAPs.

[0050] Figure 34 illustrates an example of a Simultaneous Multi-AP selection procedure based on Option #1-(5) of Section 2.2.2.

[0051] Figure 35 is a flowchart illustrating the operation of a transmitting device according to the present embodiment.

[0052] Fig. 36 is a flowchart illustrating the operation of a receiving device according to the present embodiment.

[0053] Fig. 37 is a flowchart illustrating a procedure for performing cooperation between multiple APs by selecting an AP that shares a TXOP (or performs cooperation between APs) in terms of the Sharing AP according to the present embodiment.

[0054] FIG. 38 is a flowchart illustrating a procedure for performing cooperation between multiple APs by selecting an AP that shares a TXOP (or performs cooperation between APs) in terms of a shared AP according to the present embodiment.

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

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

[0057] In this specification, “at least one of A and B” can 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” can be interpreted identically to “at least one of A and B.”

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

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

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

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

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

[0063] In order to explain the technical features of this specification, the technical features to which this specification can be applied are described below.

[0064] Figure 1 illustrates an example of a transmitting device and / or a receiving device of the present specification.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0083] The processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and / or a data processing device. The processor may be an application processor (AP). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may be a SNAPDRAGON™ series processor manufactured by Qualcomm®, an 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 an enhanced processor thereof.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0097] Figure 3 illustrates a network discovery operation that includes an active scanning process as an example. In active scanning, an STA performing scanning transmits a probe request frame to discover which APs exist in the vicinity while moving between channels and waits for a response. A responder transmits a probe response frame to the STA that transmitted the probe request frame in response to the probe request frame. Here, the responder may be the STA that last transmitted a beacon frame in the BSS of the channel being scanned. In a BSS, the AP transmits the beacon frame, so the AP becomes the responder. In an IBSS, the STAs within the IBSS take turns transmitting beacon frames, so the responder is not constant. For example, an STA that transmits a probe request frame on channel 1 and receives a probe response frame on channel 1 can store BSS-related information included in the received probe response frame and move to the next channel (e.g., channel 2) to perform scanning (i.e., transmitting and receiving probe requests / responses on channel 2) in the same manner.

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

[0099] An STA that discovers a network can perform an authentication process through step S320. This authentication process may be referred to as the first authentication process to clearly distinguish it from the security setup operation of step S340 described below. The authentication process of S320 may include a process in which the STA transmits an authentication request frame to the AP, and the AP responds by transmitting an authentication response frame to the STA. The authentication frame used for the authentication request / response corresponds to a management frame.

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

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

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

[0103] In step S340, the STA may perform a security setup process. The security setup process of step S340 may include, for example, a process of setting up a private key through a four-way handshaking using an Extensible Authentication Protocol over LAN (EAPOL) frame.

[0104] Figure 4 illustrates one embodiment of a multi-link (ML).

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

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

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

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

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

[0110] FIG. 5 illustrates a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received by an STA of this specification.

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

[0112] 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 a single-user (SU) mode / type / transmission, a multi-user (MU) mode / type / transmission, and a null data packet (NDP) mode / type / transmission related to channel sounding. For example, if the example of FIG. 5 is related to NDP, the Data field illustrated may be omitted. If the PPDU of FIG. 5 is used for a trigger-based (TB) mode, the UHR-SIG of FIG. 5 may be omitted. In other words, an STA that has received a trigger frame for UL-MU (Uplink-MU) communication may transmit a PPDU with the UHR-SIG omitted in the example of FIG. 5.

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

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

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

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

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

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

[0119] For example, (non-AP and AP) STA can generate RL-SIG, which is generated in the same manner as L-SIG. BPSK modulation can be applied to RL-SIG. Receiving (non-AP and AP) STA can determine whether the received PPDU is a HE PPDU, EHT PPDU, or UHR PPDU based on the presence of RL-SIG. In other words, if RL-SIG is present, receiving (non-AP and AP) STA can determine whether the received PPDU is one of HE PPDU, EHT PPDU, or UHR PPDU. In other words, if RL-SIG is not present, receiving (non-AP and AP) STA can determine whether the received PPDU is one of non-HT PPDU, HT PPDU, or VHT PPDU. In other words, the RL-SIG field is a repeat of the L-SIG field and is used to differentiate an UHR PPDU from a non-HT PPDU, HT PPDU, and VHT PPDU.

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

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

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

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

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

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

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

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

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

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

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

[0131] Preamble puncturing may be applied to the PPDU of FIG. 5. Preamble puncturing refers to applying puncturing to a portion of the entire bandwidth of the PPDU (e.g., the secondary 20 MHz band). For example, when an 80 MHz PPDU is transmitted, the STA 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.

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

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

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

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

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

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

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

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

[0140] FIG. 6 is a diagram illustrating the layout of resource units (RUs) used for a 20 MHz PPDU. That is, the 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.

[0141] As shown at the top of Fig. 6, 26 units (i.e., units corresponding to 26 tones) can be arranged. Six tones can be used as a guard band in the leftmost band of the 20 MHz band, and five tones can be used as a guard band in the rightmost band of the 20 MHz band. In addition, seven DC tones can be inserted in the center band, i.e., the DC band, and 26 units corresponding to 13 tones can exist on each side of the DC band. In addition, 26 units, 52 units, and 106 units can be allocated to other bands. Each unit can be allocated for a receiving station, i.e., a user.

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

[0143] In the example of Fig. 6, RUs of various sizes, such as 26-RU, 52-RU, 106-RU, and 242-RU, are proposed. Since the specific sizes 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 represented as N-tone RU, etc. For example, 26-RU may be represented as 26-tone RU.

[0144] Figure 7 is a diagram showing the layout of resource units (RUs) used for 40MHz PPDU.

[0145] As in the example of Fig. 6 where RUs of various sizes were used, the example of Fig. 7 can also use 26-RU, 52-RU, 106-RU, 242-RU, 484-RU, etc. In addition, 5 DC tones can be inserted at the center frequency, 12 tones can be used as a guard band in the leftmost band of the 40 MHz band, and 11 tones can be used as a guard band in the rightmost band of the 40 MHz band.

[0146] Additionally, as illustrated, 484 RUs 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.

[0147] Figure 8 is a diagram illustrating the layout of resource units (RUs) used for an 80MHz PPDU. The layout of resource units (RUs) used in this specification may vary. For example, the layout of resource units (RUs) used in the 80MHz band may vary.

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

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

[0150] Figure 10 shows an example of channels used / supported / defined within the 2.4 GHz band.

[0151] The 2.4 GHz band may be referred to by other names, such as the first band (band). Furthermore, 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 between 2.4 and 2.5 GHz) are used / supported / defined.

[0152] The 2.4 GHz band may include multiple 20 MHz channels. The 20 MHz 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 channel index 1 may be 2.412 GHz, the center frequency of a 20 MHz channel assigned channel index 2 may be 2.417 GHz, and the center frequency of a 20 MHz channel assigned channel index N may be (2.407 + 0.005*N) GHz. The channel indices may be referred to by various names, such as channel numbers. The specific numerical values ​​of the channel indices and center frequencies may change.

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

[0154] Figure 11 illustrates an example of channels used / supported / defined within the 5 GHz band.

[0155] The 5 GHz band may be referred to by other names, such as a second band / band, etc. The 5 GHz band may refer to a frequency range in which channels with center frequencies greater than or equal to 5 GHz 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 are subject to change.

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

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

[0158] Figure 12 illustrates an example of channels used / supported / defined within the 6 GHz band.

[0159] The 6 GHz band may also be referred to by other names, such as the third band / band. The 6 GHz band may refer to the frequency range in which channels with center frequencies above 5.9 GHz are used, supported, or defined. The specific figures shown in Figure 12 are subject to change.

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

[0161] Accordingly, the indexes (or channel numbers) of the 20 MHz channels of 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, It can be 197, 201, 205, 209, 213, 217, 221, 225, 229, 233. Also, according to the (5.940 + 0.005*N) GHz rule mentioned above, the indices of the 40 MHz channels in Fig. 12 can 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.

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

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

[0164] The processor (610) of FIG. 13 may be identical to the processor (111, 121) of FIG. 1. Alternatively, the processor (610) of FIG. 13 may be identical to the processing chip (114, 124) of FIG. 1.

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

[0166] Referring to FIG. 13, a power management module (611) manages power to 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 an associated key used to identify and authenticate a subscriber in a mobile phone device, such as a mobile phone or computer.

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

[0168] Below, the Multi-AP operation applied to this specification is described.

[0169] The above Multi-AP operation refers to a communication technique related to multiple APs in a WLAN. For example, the 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 Multi-AP operation, existing techniques may be expressed by various terms such as STX (Single Transmission). For example, the STX operation may refer to a method in which one BSS AP performs communication with one BSS STA. When communication is performed based on the STX operation, interference with adjacent APs (e.g., APs located in an overlapping BSS) may occur. Due to such interference, a problem 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 may occur.

[0170] Figure 14 illustrates operation according to a conventional STX operation. As illustrated, interference between STA and AP may occur due to adjacent AP1 and AP2.

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

[0172] In Fig. 14, STA1 and AP1 may be included in a BSS, and STA2 and AP2 may be included in an OBSS (Overlapping Basic Service Set). That is, STA2 may be an unassociated STA to AP1, and STA1 may be an unassociated STA to AP2.

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

[0174] FIG. 15 illustrates an example of Coordinated OFDMA (C-OFDMA). The illustrated AP1 may transmit a PPDU / signal to STA1, and AP2 may transmit a PPDU / signal to STA2. Transmission from AP1 and transmission from AP2 may be performed in the same / overlapping time intervals. Transmission from AP1 to STA1 may be performed based on a first frequency band, and transmission from AP2 to STA2 may 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 a BSS, and STA2 and AP2 may be included in an OBSS. That is, STA2 may be an unassociated STA to AP1, and STA1 may be an unassociated STA to AP2.

[0175] Although not illustrated in Figure 15, an example of Coordinated TDMA (C-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.

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

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

[0178] Figure 16 illustrates an example of Coordinated Beamforming (CBF). In the illustrated example, AP1 may transmit a PPDU / signal to STA1, and AP2 may transmit a PPDU / signal to STA2. Transmissions from AP1 and AP2 may be performed in the same / overlapping time intervals. Transmissions from AP1 and AP2 may be performed through the same / overlapping frequency bands. In order to reduce interference caused to STA2 by AP1, AP1 may perform nulling / beamforming toward STA2, and in order to reduce interference caused to STA1 by AP2, AP2 may perform nulling / beamforming toward STA1. For example, such nulling / beamforming may be implemented in a manner of positioning a radiation null to a neighboring unassociated STA. The above-described nulling / beamforming may make a specific AP invisible to a neighboring unassociated STA. For example, the above-described nulling / beamforming may make AP1 (or AP2) invisible to STA2 (or STA1).

[0179] For example, in FIG. 16, 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.

[0180] 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 may be transmitted and received over the backhaul link between AP1 and AP2.

[0181] Figure 17 illustrates an example of AP selection. The illustrated AP2 is determined to have a better channel condition than AP1. AP1 transmits its data / signal to AP2 via a backhaul link, and AP2, instead of AP1, can transmit a signal to STA1. For example, in Figure 17, STA1 and AP1 may be included in the BSS, and STA2 and AP2 may be included in the OBSS. In other words, STA2 may be an unassociated STA to AP1, and STA1 may be an unassociated STA to AP2.

[0182] Figure 18 illustrates an example of JTX / JT. The illustrated AP1 can transmit to STA1 together with AP2. For example, the PPDU / signal transmitted from AP2 to STA1 may be all or part of the same as the PPDU / signal transmitted from AP1 to STA1. For example, the PPDU / signal transmitted from AP2 to STA1 may be simultaneously transmitted through the same / overlapping frequency band as 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 through a backhaul link. For example, in Figure 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 unassociated STA to AP1, and STA1 may be an unassociated STA to AP2.

[0183] More specifically, in FIG. 18, AP1 can transmit a coordination request (or can be named variously, such as a first request, a control request, etc.) to AP2 and receive a coordination response (or can be named variously, such as a first response, a control response, etc.) from AP2. Through the exchange of the request / response, information about coordination between AP1 and AP2 (e.g., information about whether AP1 and AP2 will perform simultaneous transmission to STA1), information about the point in time when coordination starts, information about the point in time when AP1 and AP2 start simultaneous transmission to STA1, information about data shared between AP1 and AP2, etc. can be exchanged. AP1 can share its data with AP2 via the backhaul link. Thereafter, AP1 can transmit a coordination trigger frame (or can be named variously, such as a trigger frame) to AP2 and perform simultaneous transmission to STA1 based on the trigger frame.

[0184] <Embodiments applicable to this specification>

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

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

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

[0188] Fig. 19 shows an example of operation when the TXOP Sharing mode value is 2. When the AP transmits an MU-RTS TXS TF including time allocation information (Time allocated in MU-RTS TXS Trigger Frame of Fig. 19) to non-AP STA 1, non-AP STA 1 can perform P2P transmission to non-AP STA 2 after responding with CTS (Clear-To-Send).

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

[0190] Meanwhile, if the existing Triggered TXOP Sharing protocol is utilized for multi-AP coordination, frame exchange can be performed without affecting each other by dividing the transmission within the BSS of each cooperative AP by time unit. That is, FIG. 20 shows an example of Coordinated-Time Division Multiplexing Access (C-TDMA) according to the time unit among the cooperation methods between cooperative APs. At this time, the AP in the existing Triggered TXS protocol can play the role of an AP that shares TXOP in the multi-AP coordination operation, and the STA in the existing Triggered TXS protocol can play the role of an AP that shares TXOP in the multi-AP coordination operation. In this specification, an AP that shares TXOP is referred to as a Sharing AP (SAP), and an AP that receives TXOP from an SAP is referred to as a Shared AP (DAP). Here, the SAP that shares TXOP is not limited to only AP STAs, and may also include non-AP STAs that share TXOP. Additionally, the DAPs that share TXOPs are not limited to AP STAs, and may also include non-AP STAs that share TXOPs (or transmit and receive with AP STAs that share TXOPs). Furthermore, frame exchanges with non-AP STAs or SAPs belonging to the DAP BSS during the time allocated to the DAP are referred to as BSS frame exchanges (FEs) of the DAP.For example, frame exchange may be performed by transmitting data frames and responding to block ACK frames following RTS / CTS frame exchange between a DAP and a non-AP STA, transmitting UL data frames by non-AP STAs in response to a trigger frame transmitted from the DAP, or transmitting data frames by the DAP in response to a trigger frame transmitted from the SAP.

[0191] However, in order for the above-described C-TDMA to be successfully performed, a procedure needs to be performed to select a target DAP with which the SAP wishes to share a TXOP within the AP set that constitutes multi-AP cooperation, or a procedure needs to be performed to notify that the TXOP will be shared.

[0192] Therefore, this specification proposes a method for performing a Multi-AP selection procedure in C-TDMA operation.

[0193] The Multi-AP selection procedure proposed in this specification allows SAP to determine the need for TXOP sharing among DAPs within the acquired TXOPs. If sharing is not required for a specific DAP, SAP can decide to share the TXOP with a subsequent DAP. Alternatively, SAP can simply notify the target DAP that it intends to share the TXOP, thereby reducing the overhead associated with the selection / reselection procedure and enabling C-TDMA.

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

[0195] This specification describes a procedure for a SAP that wishes to perform C-TDMA transmission in a multi-AP environment to select a DAP as a target of TXOP sharing. Alternatively, the multi-AP selection procedure described in this specification can be applied and utilized to select a DAP as a target of resource allocation in cooperation between APs (e.g., C-SR, C-BF, C-OFDMA, or J-TX) in addition to C-TDMA. Specifically, an AP acting as an SAP can transmit a request frame to select a DAP with which to share TXOPs among cooperative APs operating in C-TDMA (or to perform cooperation between APs), and the target DAP that receives the request frame can transmit a response frame depending on the need for sharing (or the need for multi-AP cooperation). If the target DAP does not require TXOP sharing or does not receive a response frame to the request frame, the SAP can perform a reselection procedure by sending a request frame to another DAP. Alternatively, the selection procedure can simply be performed by notifying the target DAP that it intends to share TXOPs.

[0196] The Multi-AP selection procedure for C-TDMA proposed in this specification can operate as follows.

[0197] 1. Multi-AP selection procedure for C-TDMA

[0198] This section proposes a multi-AP selection procedure for C-TDMA transmission. Specifically, this procedure can be considered as a process by which a SAP notifies a target DAP that it intends to perform TXOP sharing for C-TDMA operations, or as a process by which a target DAP is determined. Furthermore, frames transmitted and received during the multi-AP selection process can update variable content related to multi-AP cooperation or C-TDMA operations.

[0199] 4.1.1. Request / Response-based selection method

[0200] An AP that acquires a TXOP and acts as a SAP can transmit a frame (i.e., a Selection Request frame) soliciting a response frame to the target DAP with which it wishes to share the TXOP. This frame generally refers to a frame that reuses the structure and specific type of an existing Basic Trigger frame, defines a new type of Trigger frame, or defines a new Control frame or Management frame.

[0201] The selection request frame transmitted during the multi-AP selection process for C-TDMA proposed in this specification may include content based on one or a combination of the following contents. The designations (names) of the contents defined below may be changed and are not limited to specific names.

[0202] A. Multi-AP group ID: ID for the set of APs that constitute multi-AP coordination (e.g., 0, 1, 2, ...)

[0203] B. DAP ID: ID assigned by SAP within the configured Multi-AP group (e.g., 0, 1, 2, ...)

[0204] C. SAP capability: Indicates whether the AP can operate as SAP.

[0205] -> For example, by utilizing the QoS Characteristic element included in the SCS request / response frame. For example, by utilizing the Reserved bits (3 bits) in the Control Info field of the QoS Characteristic element. Specifically, among the Reserved bits, define 1 bit of signaling to indicate SAP capability information.

[0206] bit 0: Indicates that the AP cannot operate as a SAP.

[0207] bit 1: Indicates that the AP has the capability to operate as a SAP.

[0208] For example, by utilizing the Common Info field included in the Trigger frame. For example, by utilizing the EHT Reserved (7 bits) or Reserved bits (4 bits) of the Common Info field. Specifically, by utilizing the EHT Reserved, a new subfield for multi-AP coordination is defined and a 1-bit signaling is defined to indicate SAP capability information within that subfield. Specifically, by utilizing the Reserved bits within the Common Info field, a 1-bit signaling is defined to indicate SAP capability information.

[0209] D. SAP operation signaling: Indicates that the AP is currently operating as a SAP and sharing TXOPs with the DAP.

[0210] -> For example, utilizing the QoS Characteristic element included in the QoS data frame. For example, utilizing the Reserved bits (3 bits) in the Control Info field of the QoS Characteristic element. Specifically, among the Reserved bits, define 1 bit of signaling to indicate SAP operation signaling information.

[0211] bit 0: Indicates that the AP acts as an SAP but does not perform TXOP sharing.

[0212] bit 1: Indicates that the AP acts as an SAP and performs TXOP sharing with the DAP.

[0213] For example, the Common Info field included in the Trigger frame is utilized. For example, the EHT Reserved (7 bits) or Reserved bits (4 bits) of the Common Info field are utilized. Specifically, a new subfield for multi-AP coordination is defined using the EHT Reserved, and a 1-bit signaling is defined to indicate SAP operation signaling information within the subfield. Specifically, the Reserved bits within the Common Info field are utilized to define a 1-bit signaling to indicate SAP operation signaling information.

[0214] E. Multi-AP coordination type: Information on multi-AP cooperative transmission techniques such as C-OFDMA, C-TDMA, J-TX, and C-SR.

[0215] F. Address: Address information of the DAP that is the target of TXOP sharing among the participating APs (e.g., BSS color, BSSID for multi-AP, or A and B information defined above)

[0216] G. Operating channel: Information on the primary and punctured channels in operation.

[0217] -> For example, common channel information for smooth cooperation between APs participating in C-TDMA. For example, primary channel information on which APs participating in C-TDMA can operate in common. Specifically, a new field that functions as the CCSF0 field within the EHT Operation Information field can be defined to indicate the channel center frequency index for 20 / 40 / 80 MHz channels.

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

[0219] Additionally, a new field that acts as the CCSF1 field in the EHT 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.

[0220] -> For example, punctured channel information of an AP participating in C-TDMA

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

[0222] A bit value of 0 in the bitmap indicates that the corresponding 20 MHz subchannel is not punctured.

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

[0224] The primary channel of DAP may be included within the channel on which SAP operates.

[0225] DAP's primary channel may be included within the operating channel, excluding SAP's punctured channel.

[0226] H. Operating bandwidth: Operating bandwidth and maximum bandwidth information

[0227] -> For example, common BW information that facilitates smooth cooperation between APs participating in C-TDMA. Specifically, the operating channel and primary channel information described above can be utilized.

[0228] For example, maximum bandwidth information for APs participating in C-TDMA. Specifically, a new field that functions similarly to the Channel Width field in the Control field of the EHT Operation Information field can be defined to indicate the channel width, which is BSS BW information for each AP.

[0229] Set to 0: 20 MHz bandwidth indication

[0230] Set to 1: Indicates 40 MHz bandwidth

[0231] Set to 2: Indicates 80 MHz bandwidth

[0232] Set to 3: Indicates 160 / 80+80 MHz bandwidth

[0233] Set to 4: Indicates 320 / 160+160 MHz bandwidth

[0234] The remaining values ​​5 through 7 can be reserved.

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

[0236] -> For example, UL BW field information included in the Common Info field of MU-RTS TXS TF

[0237] The bandwidth of the DAP may be included within the total bandwidth over which the SAP operates.

[0238] -> For example, a new field for bandwidth indication can be added by changing / redefining the Medium Time field of the QoS Characteristics element to include a new subfield. Specifically, a new field that functions like the Channel Width field in the Control field of the EHT Operation Information field can be defined to indicate the channel width, which is BSS BW information for each AP.

[0239] Set to 0: 20 MHz bandwidth indication

[0240] Set to 1: Indicates 40 MHz bandwidth

[0241] Set to 2: Indicates 80 MHz bandwidth

[0242] Set to 3: Indicates 160 / 80+80 MHz bandwidth

[0243] Set to 4: Indicates 320 / 160+160 MHz bandwidth

[0244] The remaining values ​​5 through 7 can be reserved.

[0245] I. Scheduled TXOP Duration (Nominal TXOP Duration): The period during which APs participating in C-TDMA operation cooperate with each other and perform individual FE and TXOP sharing (or) the nominal TXOP period scheduled by SAP for C-TDMA operation.

[0246] -> For example, a new field including Scheduled TXOP Duration is defined and indicated. Specifically, a new field (tentative name) is defined to indicate the information required for C-TDMA operation and the Scheduled TXOP Duration value.

[0247] -> For example, a new element containing Scheduled TXOP Duration is defined and indicated. Specifically, a new C-TDMA Operation element (tentative name) is defined to indicate the information required for C-TDMA operation and the Scheduled TXOP Duration value.

[0248] -> For example, it indicates the inclusion of Scheduled TXOP Duration in a QoS Characteristic element that can be used to include negotiation information during the pre-negotiation process for C-TDMA operation or an element that can be newly defined for negotiation in C-TDMA.

[0249] -> For example, the UHR Operation element can be used to include announcement information in the announcement process of each AP for C-TDMA operation, or the Scheduled TXOP Duration can be included in an element that can be newly defined for announcement in C-TDMA.

[0250] J. Expected TXOP sharing timing: SAP's expected or scheduled TXOP sharing timing

[0251] -> For example, a new field including Expected TXOP sharing timing is defined and indicated. Specifically, a new field (tentative name) is defined as Expected TXOP sharing timing field to indicate the information required for C-TDMA operation and the Expected TXOP sharing timing value.

[0252] -> For example, a new element including the Expected TXOP sharing timing is defined and indicated. Specifically, a new element (tentative name) is defined as the C-TDMA Operation element to indicate the information required for C-TDMA operation and the Expected sharing timing value.

[0253] K. Low Latency Traffic Information: Information related to low latency traffic that each AP wants to transmit and receive.

[0254] -> For example, information of QoS Characteristic element included in SCS request / response frame. For example, utilizing Delay Bound field information among QoS Characteristic element information. Specifically, Delay Bound field value for QoS traffic that each AP wants to transmit can be utilized as Low Latency Traffic information. Through this, SAP can use it to check whether TXOP sharing is necessary for DAP that can complete transmission of MSDU or A-MSDU within the end time of TXOP section to be shared (i.e., shorter than the time allocated for pre-negotiated Low Latency Traffic information or Delay Bound field value) or to update existing values.

[0255] -> For example, the MSDU Lifetime field information among the QoS Characteristic element information can be utilized. Specifically, the MSDU Lifetime field value for the QoS traffic that each AP wishes to transmit can be utilized as Low Latency Traffic information. Through this, the SAP can use it to check the necessity of TXOP sharing for a DAP that does not discard MSDUs within the end point of the TXOP section to be shared (i.e., the pre-negotiated Low Latency Traffic information or the MSDU Lifetime field value has not expired within the allocated time) or to update the existing value.

[0256] -> For example, the Service Start Time field information in the QoS Characteristic element can be utilized. Specifically, the Service Start Time field value for the QoS traffic that each AP wishes to transmit can be utilized as Low Latency Traffic information. Through this, the SAP can use it to check whether TXOP sharing is necessary for a DAP that can start the expected Service Period and frame exchange within the end point of the TXOP section to be shared (i.e., the pre-negotiated Low Latency Traffic information or the Service Start Time field value is shorter than the allocated time) or to update the existing value.

[0257] -> For example, TXOP sharing request information requested / instructed by an AP that requires transmission of Low Latency Traffic. For example, time-bound information for Low Latency Traffic requested / instructed by an AP that requires transmission of Low Latency Traffic. For example, the minimum time-bound within which Low Latency Traffic transmission must begin. For example, the maximum time-bound within which Low Latency Traffic transmission must successfully complete.

[0258] -> For example, information on the arrival rate of low-latency traffic requested / instructed by an AP that requires periodic transmission of low-latency traffic. For example, the arrival rate of low-latency traffic since the last reporting event.

[0259] -> For example, low-latency traffic information may include TID (Traffic Identifier) / AC (Access Category) information.

[0260] L. Coordination priority: Indicates the priority for currently operating cooperative transmission among multi-AP coordination schemes, or the priority or protection level for efficient operation of C-TDMA transmission.

[0261] -> For example, utilize EHT Reserved (7 bits) or Reserved (4 bits) in the Common Info field.

[0262] Specifically, it indicates the priority (or level of protection) of the current C-TDMA operation using 2 bits corresponding to EHT Reserved or Reserved.

[0263] - bit 0: Indicates that this is a cooperative transmission with a priority (or protection level) of 0. For example, in C-TDMA operation, this may mean that separate protection for TXOP sharing and TXOP return is not required.

[0264] - bit 1: Indicates that this is a cooperative transmission with a priority (or protection level) of 1-1. For example, this may indicate that separate protection is required for TXOP sharing in C-TDMA operation.

[0265] - bit 2: Indicates that this is a cooperative transmission with a priority (or protection level) of 1-2. For example, this could mean that separate protection is required for TXOP return in C-TDMA operation.

[0266] - bit 3: Indicates that this is a cooperative transmission with a two-level priority (or protection level). For example, in C-TDMA operation, this could mean that protection is required for both TXOP sharing and TXOP return.

[0267] Additionally, the selection response frame transmitted during the multi-AP selection process for C-TDMA proposed in this specification may include content based on one or a combination of the following contents. The designations (names) of the contents defined below may be changed and are not limited to specific names.

[0268] A. Multi-AP group ID: ID for the set of APs that constitute multi-AP coordination (e.g., 0, 1, 2, ...)

[0269] B. DAP ID: ID assigned by SAP within the configured Multi-AP group (e.g., 0, 1, 2, ...)

[0270] C. Address: SAP address information (e.g., BSS color, BSSID for Multi-AP, or A and B information defined above)

[0271] D. Operating channel: Information on the primary and punctured channels in operation.

[0272] -> For example, common channel information for smooth cooperation between APs participating in C-TDMA

[0273] -> For example, primary channel information on which APs participating in C-TDMA can operate in common

[0274] Specifically, a new field that acts as the CCSF0 field in the EHT Operation Information field can be defined to indicate the channel center frequency index for 20 / 40 / 80 MHz channels.

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

[0276] Additionally, a new field that acts as the CCSF1 field in the EHT 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.

[0277] -> For example, punctured channel information of an AP participating in C-TDMA

[0278] Specifically, a new field that acts as the Disabled Subchannel Bitmap field within the EHT Operation Information field can be defined to indicate a pucntured 20 MHz subchannel using a bitmap.

[0279] - A bit value of 0 in the bitmap indicates that the corresponding 20 MHz subchannel is not punctured.

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

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

[0282] -> DAP's primary channel can be included within the operating channel excluding SAP's punctured channel.

[0283] E. Operating bandwidth: Operating bandwidth and maximum bandwidth information

[0284] -> For example, BW information that operates in common for smooth cooperation between APs participating in C-TDMA.

[0285] Specifically, the operating channel and primary channel information described above can be utilized.

[0286] -> For example, maximum bandwidth information of APs participating in C-TDMA

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

[0288] - Set to 0: Indicates 20 MHz bandwidth

[0289] - Set to 1: Indicates 40 MHz bandwidth

[0290] - Set to 2: Indicates 80 MHz bandwidth

[0291] - Set to 3: Indicates 160 / 80+80 MHz bandwidth

[0292] - Set to 4: Indicates 320 / 160+160 MHz bandwidth

[0293] - The remaining values ​​5 to 7 can be reserved.

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

[0295] -> For example, UL BW field information included in the Common Info field of MU-RTS TXS TF

[0296] -> The bandwidth of the DAP may be included within the total bandwidth over which the SAP operates.

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

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

[0299] - Set to 0: Indicates 20 MHz bandwidth

[0300] - Set to 1: Indicates 40 MHz bandwidth

[0301] - Set to 2: Indicates 80 MHz bandwidth

[0302] - Set to 3: Indicates 160 / 80+80 MHz bandwidth

[0303] - Set to 4: Indicates 320 / 160+160 MHz bandwidth

[0304] - The remaining values ​​5 to 7 can be reserved.

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

[0306] -> For example, by defining a new field containing Required TXOP Duration

[0307] Specifically, a new Required Duration field (tentative name) is defined to indicate the information required for C-TDMA operation and the Required TXOP Duration value.

[0308] -> For example, by defining a new element containing Required TXOP Duration

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

[0310] -> For example, it indicates the inclusion of Required TXOP Duration in the QoS Characteristic element that can be used to include negotiation information during the pre-negotiation process for C-TDMA operation or in an element that can be newly defined for negotiation in C-TDMA.

[0311] -> For example, the Required TXOP Duration may be included in the UHR Operation element, which may be used to include announcement information during the announcement process of each AP for C-TDMA operation, or in an element that may be newly defined for announcement in C-TDMA.

[0312] G. Buffer status: Buffer status information for each DAP

[0313] H. TXOP sharing requirement: Indicates whether TXOP sharing is required due to expiration of pre-negotiated Low Latency Traffic Information or TXOP sharing is not necessary (e.g., when individual FEs have already been performed).

[0314] -> For example, it indicates and responds whether TXOP sharing is required using 1 bit.

[0315] - bit 0: Indicates that the DAP receiving the selection request frame does not require TXOP sharing.

[0316] - bit 1: Indicates that the DAP receiving the selection request frame requires TXOP sharing.

[0317] I. Low Latency Traffic Information: Information related to low latency traffic that each AP wishes to transmit and receive.

[0318] -> For example, information about the QoS Characteristic element included in the SCS request / response frame

[0319] -> For example, using the Delay Bound field information among the QoS Characteristic element information.

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

[0321] - In case of changes different from the pre-negotiated Low Latency Traffic Information, includes updated Low Latency Traffic Information or Delay Bound field value.

[0322] -> For example, using the MSDU Lifetime field information among the QoS Characteristic element information.

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

[0324] - In case of changes different from the pre-negotiated Low Latency Traffic Information, includes updated Low Latency Traffic information or MSDU Lifetime field value.

[0325] -> For example, use the Service Start Time field information among the QoS Characteristic element information.

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

[0327] - In case of changes different from the pre-negotiated Low Latency Traffic Information, include updated Low Latency Traffic Information or Service Start Time field value.

[0328] -> For example, TXOP sharing request information requested / instructed by an AP that requires transmission of low latency traffic.

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

[0330] - For example, the minimum time-bound for which transmission of Low Latency Traffic must begin

[0331] - For example, the maximum time-bound required to successfully complete transmission of Low Latency Traffic

[0332] -> For example, arrival rate information of Low Latency Traffic requested / instructed by an AP that requires periodic transmission of Low Latency Traffic.

[0333] - For example, the arrival rate of Low Latency Traffic since the last reporting event.

[0334] -> For example, low-latency traffic information may include TID (Traffic Identifier) / AC (Access Category) information.

[0335] J. Status Code: Accept / Reject / Recommendation information for the Selection request (i.e., SAP can accept or reject the selected DAP based on whether it currently requires TXOP sharing, which can replace the TXOP sharing requirement information presented above).

[0336] -> For example, Accept or Success (eg, SUCCESS)

[0337] -> For example, Reject with Reject or Recommendation

[0338] Specifically, a Reject code with a Reject reason (e.g., REJECTED_BAD_SUPPORTED_CHANNELS)

[0339] Specifically, a Reject code with a Recommendation (e.g., REJECTED_WITH_SUGGESTED_CHANGES)

[0340] If the Status Code value includes Reject or Recommendation, it may include information for a new selection request. That is, the DAP receiving the selection request frame may include additional information, such as the Operating Channel and Bandwidth, Required TXOP Duration, and Low Latency Traffic Information, as described above.

[0341] <Reselection 절차> : If the SAP does not receive a response frame (e.g., selection response frame) from the DAP, or there is no TXOP sharing request (i.e., TXOP sharing requirement field = 0) from the DAP, or receives a Status Code including Reject from the DAP, the SAP may perform a reselection procedure. The reselection procedure for C-TDMA operation may send frames for individual selection procedures to other candidate DAP(s), or may not perform a separate reselection procedure (i.e., if a single selection procedure fails, the reselection procedure may not be performed).

[0342] 2.1.2. A-Control-based selection method

[0343] Similar to the aforementioned 2.1.1 Request / Response-based selection method, which transmits a selection request frame and receives a corresponding selection response frame to perform DAP selection, multi-AP selection can be performed using the A-Control field. For example, a new type of Control Information field can be defined by utilizing the Reserved values ​​(7-14) of the Control ID field within the control field.

[0344] Figure 21 illustrates an example of CIRP contents and CIR field format for an A-Control based selection method.

[0345] Specifically, a new type of Trigger frame (e.g., Coordination Information Report Poll (tentative name)) for polling C-TDMA information can be defined (using reserved values ​​8 to 15 of the trigger type field) to receive a report of C-TDMA-related information from the DAP. That is, the DAP that receives this can report C-TDMA information to the SAP by including separate report contents in the Coordination Information Report (CIR) Control field (tentative name). To this end, a new rule that enables the AP to transmit a TB PPDU needs to be defined. The above-described new type of CIR Control field can include contents based on one or a combination of contents defined and listed in 2.1.1 Request / Response-based selection method. That is, FIG. 21 shows an example of contents that can be included in a new type of Trigger frame transmitted by a transmitter (i.e., SAP) and an example of a CIR Control field that can be included by a receiver (i.e., DAP). The information (content), number of bits in the field, or designation (name) that may be included in the Trigger frame and A-Control field presented in this example may be changed and are not limited thereto.

[0346] 2.1.3. MU-RTS Trigger frame / CTS frame-based selection method

[0347] Similar to the above-described 2.1.1 Request / Response-based selection method that transmits a selection request frame and receives a corresponding selection response frame to perform DAP selection, Multi-AP selection can be performed using MU-RTS TF or RTS frames. For example, the existing mode (e.g., mode = 1 or 2) of MU-RTS TXS TF can be utilized, or a new mode (e.g., mode = 3) can be defined using reserved bits.

[0348] Specifically, a new mode MU-RTS TXS TF for notifying a C-TDMA operation can be defined and transmitted to the corresponding DAP(s). For this purpose, a subfield for indicating a new mode, such as a Triggered TXOP Sharing Mode 1 (or 2) Support subfield in the EHT MAC Capabilities Information field, can be defined. The DAP(s) can receive the MU-RTS TXS TF set and indicated as the new mode, obtain information related to the C-TDMA operation, and respond with a CTS frame. The MU-RTS TXS TF, which is the new mode described above, can include contents based on one or a combination of contents that can be included in a selection request frame in the 2.1.1 Request / Response-based selection method in the Common Info field and the User Info field by utilizing Reserved bits. The information (content), the number of bits of the field, or the designation (name) that can be included in the corresponding field may be changed and are not limited thereto. When notifying multiple DAP(s) of C-TDMA operation at the same time, there may be more than one User Info field.

[0349] Alternatively, a separate signaling bit may be included in the MU-RTS TXS TF to perform the Multi-AP selection procedure using the MU-RTS TXS TF among the types of MU-RTS TF. That is, a new signaling bit may be defined and added to indicate that it is the MU-RTS TXS TF transmitted for the Multi-AP selection procedure in C-TDMA, rather than the new TXS mode described above.

[0350] <Multi-AP Selection>: Indicates that this is a MU-RTS TXS TF for Multi-AP selection procedure (or Schedule announcement) in C-TDMA.

[0351] -> For example, using EHT Reserved (7 bits) or Reserved (4 bits) in the Common Info field

[0352] Specifically, a new field is defined to indicate that this is an MU-RTS TXS TF transmitted for the Multi-AP selection procedure, utilizing 1 bit corresponding to EHT Reserved.

[0353] Specifically, a new field is defined to indicate that this is an MU-RTS TXS TF transmitted for the Multi-AP selection procedure by utilizing 1 bit corresponding to Reserved (e.g., B22 in EHT variant Common Info field).

[0354] -> The examples described above can be commonly signaled as follows.

[0355] - bit 0: If the MU-RTS TXS TF is not intended for the Multi-AP selection procedure. That is, bit 0 may also mean that the MU-RTS TXS TF can be transmitted for the purpose of TXOP sharing with an AP (or STA).

[0356] - bit 1: Indicates that the MU-RTS TXS TF was transmitted for the purpose of Multi-AP selection procedure.

[0357] Also, as an alternative to defining a separate signaling bit to perform the Multi-AP selection procedure using the MU-RTS TXS TF, there is a method of using the Allocation Duration field in the MU-RTS TXS TF transmitted by the SAP. For example, the SAP can indicate the timing of TXOP sharing to the target DAP with the duration included in the Duration / ID field of the MU-RTS TXS TF, and the Allocation Duration field in the User Info field for the target DAP can be set to a predefined value (e.g., 0 or the maximum value) to indirectly notify that the MU-RTS TXS TF is transmitted for the purpose of the Multi-AP selection procedure. This method can be recognized by decoding only the target DAP (i.e., the AP that includes information about itself in the AID12 field of the User Info field).

[0358] <Reselection 절차> : If a response frame (i.e., a CTS frame) is not received from a DAP, the SAP may perform a reselection procedure. The reselection procedure for C-TDMA operation may involve sending frames for individual selection procedures to other candidate DAP(s), or may not perform a separate reselection procedure at all (i.e., if a single selection procedure fails, the reselection procedure may not be performed).

[0359] 2.1.4. Unilateral instruction-based selection method

[0360] An AP that acquires a TXOP and acts as a SAP can transmit a frame that does not solicit a response frame to the target DAP with which it wishes to share the TXOP. In other words, unlike the 2.1.1 Request / Response-based selection method that receives a response frame from a DAP and updates or reflects the corresponding contents, this can be considered as unilaterally instructing / notifying the target DAP whether or not the SAP has decided to share the TXOP and the related contents. The frame at this time refers to a general term for reusing the structure and specific type of the existing Basic Trigger frame, defining a new type of Trigger frame, or defining a new Control frame or Management frame.

[0361] As an example of a selection frame (also called a notification frame) transmitted through this section (2.1.4 Unilateral Instruction-Based Selection Method), a new Management frame containing the following contents may be defined. The selection / notification frame may contain contents based on one or a combination of the following contents, and their designations (names) may be changed and are not limited thereto.

[0362] First, the selection / notification frame transmitted through the 2.1.4 one-sided instruction-based selection method can be classified as an Action frame among the types of Management frames. In addition, the selection / notification frame can be classified as a UHR Action frame (tentative name) or Protected UHR Action frame (tentative name) that can be newly defined in UHR (11bn), similar to the EHT Action frame and Protected EHT Action frame newly defined in EHT (11be) among the Category types of Action frames. In other words, the above-described selection / notification frame can be defined as one of the Action frames among the types using the Action field of the UHR Action frame or the Protected UHR Action frame.

[0363] Therefore, an AP that acquires a TXOP and acts as a SAP can transmit a selection / notification frame to indicate to the target DAP that TXOP sharing for C-TDMA operation is scheduled.

[0364] The Action field of the Selection / Notification frame may contain information based on one or more of the following combinations. The names of the information defined below are subject to change and are not limited.

[0365] A. Category: A value indicating the Category field defined in the Action field of the Action frame in the Management frame.

[0366] -> For example, a value indicating an EHT Action frame or a Protected EHT Action frame among the 1-byte Category fields.

[0367] Specifically, a value indicating a UHR Action frame or Protected UHR Action frame that can be newly defined in UHR.

[0368] B. UHR Action (or) Protected UHR Action: A value that indicates the action to be performed with the frame.

[0369] -> For example, a value indicating a Link Reconfiguration Notify frame (example) in the 1-byte Action field of the Protected EHT Action frame

[0370] Specifically, a new C-TDMA Operation Selection / Notification frame (tentative name) is newly defined and instructed among the 1-byte Action fields in the UHR Action frame or Protected UHR Action frame that can be newly defined in UHR.

[0371] C. Multi-AP group ID: ID for the set of APs that constitute multi-AP coordination (e.g., 0, 1, 2, ...)

[0372] D. DAP ID: ID assigned by SAP within the configured Multi-AP group (e.g., 0, 1, 2, ...)

[0373] E. SAP capability: Indicates whether the AP can operate as SAP.

[0374] -> For example, utilizing the QoS Characteristic element included in the SCS request / response frame

[0375] -> For example, using the Reserved bits (3 bits) in the Control Info field of the QoS Characteristic element.

[0376] Specifically, define 1 bit signaling to indicate SAP capability information among the Reserved bits.

[0377] - bit 0: Indicates that the AP cannot operate as SAP.

[0378] - bit 1: Indicates that the AP has the capability to operate as a SAP.

[0379] -> For example, using the Common Info field included in the Trigger frame

[0380] - For example, use of EHT Reserved (7 bits) or Reserved bits (4 bits) in the Common Info field.

[0381] - Specifically, a new subfield for Multi-AP coordination is defined using EHT Reserved, and 1 bit signaling is defined to indicate SAP capability information within the subfield.

[0382] - Specifically, define 1-bit signaling to indicate SAP capability information using Reserved bits within the Common Info field.

[0383] F. SAP operation signaling: Indicates that the AP is currently operating as an SAP and sharing TXOPs with the DAP.

[0384] -> For example, using the QoS Characteristic element included in the QoS data frame

[0385] -> For example, using the Reserved bits (3 bits) in the Control Info field of the QoS Characteristic element.

[0386] Specifically, define 1 bit signaling to indicate SAP operation signaling information among the Reserved bits.

[0387] - bit 0: Indicates that the AP acts as a SAP but does not perform TXOP sharing.

[0388] - bit 1: Indicates that the AP acts as a SAP and performs TXOP sharing with the DAP.

[0389] -> For example, using the Common Info field included in the Trigger frame

[0390] - For example, use EHT Reserved (7 bits) or Reserved bits (4 bits) of the Common Info field.

[0391] Specifically, a new subfield for Multi-AP coordination is defined using EHT Reserved, and a 1-bit signaling is defined to indicate SAP operation signaling information within that subfield.

[0392] Specifically, we define 1 bit signaling to indicate SAP operation signaling information using Reserved bits within the Common Info field.

[0393] G. Multi-AP coordination type: Information on multi-AP cooperative transmission techniques such as C-OFDMA, C-TDMA, J-TX, and C-SR.

[0394] H. Address: Address information of the DAP that is the target of TXOP sharing among the participating APs (e.g., BSS color, BSSID for Multi-AP, or A and B information defined above)

[0395] I. Operating channel: Information on the primary and punctured channels in operation.

[0396] -> For example, common channel information for smooth cooperation between APs participating in C-TDMA

[0397] -> For example, primary channel information on which APs participating in C-TDMA can operate in common

[0398] Specifically, a new field that acts as the CCSF0 field in the EHT Operation Information field can be defined to indicate the channel center frequency index for 20 / 40 / 80 MHz channels.

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

[0400] Additionally, a new field that acts as the CCSF1 field in the EHT 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.

[0401] -> For example, punctured channel information of an AP participating in C-TDMA

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

[0403] - A bit value of 0 in the bitmap indicates that the corresponding 20 MHz subchannel is not punctured.

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

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

[0406] -> DAP's primary channel can be included within the operating channel excluding SAP's punctured channel.

[0407] J. Operating bandwidth: Operating bandwidth and maximum bandwidth information

[0408] -> For example, BW information that operates in common for smooth cooperation between APs participating in C-TDMA.

[0409] Specifically, the operating channel and primary channel information described above can be utilized.

[0410] -> For example, maximum bandwidth information of APs participating in C-TDMA

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

[0412] - Set to 0: Indicates 20 MHz bandwidth

[0413] - Set to 1: Indicates 40 MHz bandwidth

[0414] - Set to 2: Indicates 80 MHz bandwidth

[0415] - Set to 3: Indicates 160 / 80+80 MHz bandwidth

[0416] - Set to 4: Indicates 320 / 160+160 MHz bandwidth

[0417] - The remaining values ​​5 to 7 can be reserved.

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

[0419] -> For example, UL BW field information included in the Common Info field of MU-RTS TXS TF

[0420] -> The bandwidth of the DAP may be included within the total bandwidth over which the SAP operates.

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

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

[0423] - Set to 0: Indicates 20 MHz bandwidth

[0424] - Set to 1: Indicates 40 MHz bandwidth

[0425] - Set to 2: Indicates 80 MHz bandwidth

[0426] - Set to 3: Indicates 160 / 80+80 MHz bandwidth

[0427] - Set to 4: Indicates 320 / 160+160 MHz bandwidth

[0428] - The remaining values ​​5 to 7 can be reserved.

[0429] K. Scheduled TXOP Duration: The period during which APs participating in C-TDMA operation cooperate with each other and perform individual FE and TXOP sharing (or) the nominal TXOP period scheduled by the SAP for C-TDMA operation.

[0430] -> For example, by defining a new field containing Scheduled TXOP Duration.

[0431] Specifically, a new field called Scheduled Duration (tentative name) is defined to indicate the information required for C-TDMA operation and the Scheduled TXOP Duration value.

[0432] -> For example, by defining a new element containing Scheduled TXOP Duration.

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

[0434] -> For example, it indicates the inclusion of Scheduled TXOP Duration in a QoS Characteristic element that can be used to include negotiation information during the pre-negotiation process for C-TDMA operation or an element that can be newly defined for negotiation in C-TDMA.

[0435] -> For example, the UHR Operation element can be used to include announcement information in the announcement process of each AP for C-TDMA operation, or the Scheduled TXOP Duration can be included in an element that can be newly defined for announcement in C-TDMA.

[0436] L. Expected TXOP sharing timing: SAP's expected or scheduled TXOP sharing timing

[0437] -> For example, by defining a new field containing the Expected TXOP sharing timing

[0438] Specifically, a new field called Expected TXOP sharing timing field (tentative name) is defined to indicate the information required for C-TDMA operation and the Expected TXOP sharing timing value.

[0439] -> For example, by defining a new element that includes Expected TXOP sharing timing

[0440] Specifically, a new C-TDMA Operation element (tentative name) is defined to indicate the information required for C-TDMA operation and the Expected sharing timing value.

[0441] M. Coordination priority: Indicates the priority for currently operating cooperative transmission among multi-AP coordination schemes, or the priority or protection level for efficient operation of C-TDMA transmission.

[0442] -> For example, using EHT Reserved (7 bits) or Reserved (4 bits) in the Common Info field

[0443] Specifically, it indicates the priority (or level of protection) of the current C-TDMA operation using 2 bits corresponding to EHT Reserved or Reserved.

[0444] - bit 0: Indicates that this is a cooperative transmission with a priority (or protection level) of 0. For example, in C-TDMA operation, this may mean that separate protection for TXOP sharing and TXOP return is not required.

[0445] - bit 1: Indicates that this is a cooperative transmission with a priority (or protection level) of 1-1. For example, this may indicate that separate protection is required for TXOP sharing in C-TDMA operation.

[0446] - bit 2: Indicates that this is a cooperative transmission with a priority (or protection level) of 1-2. For example, in C-TDMA operation, this could mean that separate protection is required for the TXOP return.

[0447] - bit 3: Indicates that this is a cooperative transmission with a two-level priority (or protection level). For example, in C-TDMA operation, this could mean that protection is required for both TXOP sharing and TXOP return.

[0448] Alternatively, new elements (e.g., UHR Operation element (tentative name), C-TDMA Operation element (tentative name), Multi-AP Coordination element (tentative name)) can be defined to include the contents of C~I described above required for Multi-AP cooperation and C-TDMA operation. Accordingly, the Action field described above as an example of the selection / notification frame defined in this section (e.g., Management frame) can be represented as an example as in Table 1 below.

[0449] OrderMeaning1Category2UHR Action (or) Protected UHR Action (or) Public Action3Definition and use of new elements for new fields (or) Selection frames containing the above C~I contents (e.g., UHR Operation element, C-TDMA Operation element, Multi-AP Coordination element)

[0450] 2. 2. Multi-AP selection method and implementation example for C-TDMA transmission

[0451] For efficient C-TDMA operation, a procedure needs to be designed for selecting a target DAP with which the SAP wishes to share TXOPs within a set of APs that have formed a multi-AP collaboration, or for notifying that TXOP sharing is about to occur. Therefore, this section presents a method for performing the multi-AP selection procedure in C-TDMA.

[0452] 2.2.1. Example of Multi-AP Selection Procedure Using Various Selection Methods

[0453] The Multi-AP selection method for establishing a Multi-AP cooperation and selecting or notifying the DAP(s) to share the TXOP among the APs included / participating in the set can be performed with the following examples. The Multi-AP selection procedures presented below can be performed as a replacement for the NAV-set sequence of the SAP. That is, an AP that can acquire a TXOP and act as an SAP can set its NAV through the Multi-AP selection procedure (the first frame exchange sequence of the SAP can be the Multi-AP selection procedure).

[0454] Figure 22 illustrates an example of a Multi-AP selection procedure using the 2.1.1 Request / Response based selection method.

[0455] Figure 22 illustrates an embodiment of a Multi-AP selection procedure using the Request / Response-based selection method of Section 2.1.1. An AP that acquires a TXOP and acts as a SAP can transmit a selection request frame containing the contents for Multi-AP selection described in Section 2.1.1 to a target DAP with which it wishes to share the TXOP. At this time, if the RA field of the selection request frame is designated as the address of an individual DAP, the AID field can be set to an arbitrary value. The corresponding DAP(s) that receive this can update the information if there is updated information, and determine whether TXOP sharing is necessary or whether to accept a request for inter-AP cooperation (e.g., C-SR, C-BF, C-OFDMA, etc.) through a Status Code and respond with a selection response frame. At this time, the non-AP STA(s) connected to the SAP may receive and detect the response frame transmitted from the DAP(s) and may have an issue of setting the basic NAV. To solve this problem, a method such as setting the Duration field value of the request frame transmitted by SAP to 0 or a method of including only the SAP's address information (e.g., SAP's MAC address or AID, or a new AID defined for multi-AP cooperation) in the address field of the response frame transmitted by DAP can be applied. The DAP(s) selected by SAP can wait without doing anything until the scheduled TXOP sharing time, perform Secondary Channel Access depending on the capability, or enter AP Power mode.Additionally, DAP(s) that are not scheduled to share a TXOP from SAP can hear the selection request frame and recognize that SAP is scheduled to share a TXOP with other DAP(s). AP(s) that are not selected by SAP can defer access to the channel for the time allocated to the selected DAP(s) or for the entire TXOP duration of SAP. Alternatively, AP(s) that are not selected by SAP can perform Secondary Channel Access or enter AP Power mode during that time, depending on their capability. Here, AP(s) that are not selected by SAP refer to AP(s) that are in a coordination relationship with SAP but were not selected for this TXOP.

[0456] Figure 23 illustrates an example of a Multi-AP selection procedure using the 2.1.2 A-Control based selection method.

[0457] Alternatively, Fig. 23 illustrates an embodiment of a Multi-AP selection procedure using the A-Control-based selection method of Section 2.1.2. An AP that acquires a TXOP and acts as a SAP can transmit a Trigger frame (CIRP frame) containing the contents for Multi-AP selection described in Section 2.1.2 to a target DAP with which it wishes to share the TXOP. At this time, if the RA field of the CIRP frame is designated as the address of an individual DAP, the AID field can be set to an arbitrary value. The corresponding DAP(s) that receive this can update the information if there is updated information, and determine whether TXOP sharing is necessary or cooperation between APs (e.g., C-SR, C-BF, C-OFDMA, etc.) is necessary and respond with a TB PPDU (CIR frame). At this time, an issue may arise where non-AP STA(s) connected to the SAP receive and detect the TB PPDU (CIR frame) transmitted from the DAP(s) and set the basic NAV. To solve this problem, a method such as setting the Duration field value of the Trigger frame (CIRP frame) transmitted by the SAP to 0 or a method including only the address information of the SAP (e.g., the MAC address or AID of the SAP or a new AID defined for multi-AP cooperation) in the address field of the TB PPDU (CIR frame) transmitted by the DAP can be applied. The DAP(s) selected by the SAP can wait without doing anything until the scheduled TXOP sharing time, perform Secondary Channel Access depending on the capability, or enter AP Power mode.Additionally, DAP(s) that are not scheduled to receive TXOPs from the SAP can hear the CIRP frame and recognize that the SAP is scheduled to share TXOPs with other DAP(s). The AP(s) that are not selected by the SAP can defer access to the channel for the time allocated to the selected DAP(s) or for the entire TXOP duration of the SAP. Alternatively, the AP(s) that are not selected by the SAP can perform secondary channel access during that time, depending on their capabilities, or enter AP Power mode.

[0458] Figure 24 illustrates an example of a Multi-AP selection procedure using the 2.1.3 MU-RTS TF / CTS frame-based selection method.

[0459] Alternatively, FIG. 24 illustrates an embodiment of a Multi-AP selection procedure using the MU-RTS TF / CTS frame-based selection method of Section 2.1.3. An AP that acquires a TXOP and acts as a SAP can transmit an MU-RTS TXS TF including contents for Multi-AP selection described in Section 2.1.3 to a target DAP with which it wishes to share the TXOP. At this time, if the RA field of the MU-RTS TXS TF is designated as the address of an individual DAP, the AID field can be set to an arbitrary value. The corresponding DAP(s) can acquire C-TDMA-related information from the received MU-RTS TXS TF and respond with a CTS frame. The DAP(s) selected by the SAP can wait without doing anything until the scheduled TXOP sharing time, perform Secondary Channel Access depending on the capability, or enter AP Power mode. Additionally, DAP(s) that are not scheduled to share TXOPs from SAP can recognize that SAP is scheduled to share TXOPs with other DAP(s) by listening to the MU-RTS TXS TF and CTS frames. AP(s) that are not selected by SAP can defer access to the channel for the time allocated to the selected DAP(s) or for the entire TXOP duration of the SAP. Alternatively, AP(s) that are not selected by SAP can perform Secondary Channel Access or enter AP Power mode during that time, depending on their capabilities.

[0460] Figure 25 illustrates an example of a Multi-AP selection procedure using the 2.1.4 one-way instruction-based selection method.

[0461] Alternatively, Figure 25 illustrates an example of a multi-AP selection procedure using the unilateral instruction-based selection method of Section 2.1.4. An AP that acquires a TXOP and acts as an SAP can transmit a selection / notification frame containing the contents for multi-AP selection described in Section 2.1.4 to a target DAP with which it wishes to share the TXOP. In this case, if the RA field of the selection / notification frame is designated as the address of an individual DAP, the AID field can be set to an arbitrary value. The corresponding DAP(s) that receive this can know in advance whether to share or perform inter-AP cooperation (e.g., C-SR, C-BF, C-OFDMA, etc.) and can prepare C-TDMA operation or inter-AP cooperation (e.g., C-SR, C-BF, C-OFDMA, etc.) based on the transmitted information. The DAP(s) selected by the SAP can wait without doing anything until the scheduled TXOP sharing time, perform Secondary Channel Access according to the capability, or enter AP Power mode. In addition, the DAP(s) that are not scheduled to receive TXOP sharing from the SAP can hear the selection / notification frame and recognize that the SAP is scheduled to share TXOP with other DAP(s). The AP(s) that are not selected by the SAP can defer access to the channel during the time allocated to the selected DAP(s) or for the entire TXOP duration of the SAP. Alternatively, the AP(s) that are not selected by the SAP can perform Secondary Channel Access according to the capability during that time or enter AP Power mode. You can enter mode.

[0462] Figure 26 illustrates an example of a Multi-AP selection procedure performed prior to TXOP acquisition.

[0463] As another alternative, FIG. 26 illustrates an embodiment of a Multi-AP selection procedure performed prior to TXOP acquisition. Prior to acquiring a TXOP, each AP (belonging to a set of APs that have established Multi-AP cooperation) whose SAP role has not been determined can perform a Multi-AP selection procedure to preemptively determine DAP(s) with which to share the TXOP or perform inter-AP cooperation (e.g., C-SR, C-BF, C-OFDMA, etc.) upon acquiring the TXOP, based on pre-negotiated information. This Multi-AP selection procedure may utilize the above-described request / response-based, A-Control-based, MU-RTS TF / CTS frame-based, or unilateral instruction-based selection methods. The contents of the frames transmitted for the Multi-AP selection procedure at this time may differ from the contents presented in Sections 2.1.1, 2.1.2, 2.1.3, and 2.1.4.

[0464] On the other hand, in the following situations, the Multi-AP selection procedure for C-TDMA presented in Sections 2.1 and 2.2 may be omitted. Conditions and situations in which the Multi-AP selection procedure is omitted may be added and are not limited.

[0465] - If SAP performs TXOP sharing as soon as it acquires the TXOP.

[0466] - When feedback (i.e., response) from DAP is not required

[0467] - When there is only one AP negotiated through the multi-AP set configuration procedure.

[0468] 2.2.2. How to set the Duration field in the multi-AP selection procedure

[0469] In the Multi-AP selection procedure based on the various selection methods presented in Section 2.2.1 above, the Duration field of the request frame transmitted by the SAP may include only the duration until receiving the response frame for the request frame, or may include the duration for the FE in the BSS of the subsequent SAP, or may include the time until transmitting the MU-RTS TXS TF for the TXOP sharing procedure, or may include the duration until transmitting the MU-RTS TXS TF for the TXOP sharing procedure and receiving the CTS frame, which is a response frame to it.

[0470] Figure 27 illustrates an example of a method for setting the Duration field of a Multi-AP selection request frame.

[0471] Figure 27 illustrates various examples of how to set the Duration field in the Multi-AP selection procedure. Option #1 includes the duration (i.e., T_1) until the response frame is received in the Multi-AP selection procedure in the Duration field of the request frame.

[0472] The duration in the sequences following the Multi-AP selection procedure of Option #1 can be set as follows.

[0473] -> Option #1-(1): The entire period for performing FE within SAP's BSS and the period for TXOP sharing procedures can be set separately.

[0474] Specifically, T_FE may be included in the Duration field of the first frame for FE in SAP's BSS, and T_TXS may be included in the Duration field of MU-RTS TXS TF for TXOP sharing.

[0475] -> Option #1-(2): Individual FE periods and TXOP sharing procedures within SAP's BSS can be set separately.

[0476] Specifically, each frame within the BSS of SAP may have a separate transmission and reception duration, with T_(FE_1), T_(FE_2), and T_(FE_n) being examples. Subsequently, T_TXS may be included in the Duration field of the MU-RTS TXS TF for TXOP sharing.

[0477] -> Option #1-(3): Can be set to include individual FE periods within SAP's BSS and periods for transmission of MU-RTS TXS TF.

[0478] Specifically, a period corresponding to T_3-T_1 may be included in the Duration field of the first frame for FE in SAP's BSS.

[0479] -> Option #1-(4): Can be configured to include individual FE periods within SAP's BSS and periods for receiving response frames (e.g., CTS frames) to MU-RTS TXS TFs.

[0480] Specifically, a period corresponding to T_4-T_1 may be included in the Duration field of the first frame for FE in SAP's BSS.

[0481] Slightly different from the methods of Option #1-(1) to Option #1-(4) above, a method of setting the NAV duration differently only for specific APs may be considered.

[0482] -> Option #1-(5): When a Trigger frame (e.g., MU-RTS (TXS) TF) is transmitted as a Multi-AP selection request frame, the AID field of the User Info field may include identification information of the AP to be subject to TXOP sharing (e.g., DAP's MAC address, BSS color, Multi-AP ID, etc.), and one or more APs including the information may set the NAV duration based on the Expected TXOP sharing timing information that may be included in the User Info field or Common Info field, rather than setting the NAV duration based on the Duration / ID field. The Expected TXOP sharing timing information is proposed in Section 2.1 above and may indicate the TXOP sharing timing information expected or scheduled by the SAP.

[0483] Option #2 includes the period (i.e., T_2) until the Multi-AP selection procedure and the FE within the BSS of the SAP are completed. Option #3 also includes the period described above plus the period (i.e., T_3) until the transmission of the MU-RTS TXS TF for the purpose of TXOP sharing for C-TDMA, and Option #4 includes the period (i.e., T_4) until the reception of a response frame (e.g., CTS frame) to the transmission of the MU-RTS TXS TF.

[0484] 2. 3. Multi-AP selection method and implementation example for multiple DAPs

[0485] This section presents the method and procedure for performing Multi-AP selection for multiple DAPs.

[0486] Figure 28 illustrates an example-1 of a Simultaneous Multi-AP selection procedure for selecting multiple DAPs.

[0487] Figure 29 illustrates an example-2 of a Simultaneous Multi-AP selection procedure for selecting multiple DAPs.

[0488] Figures 28 and 29 illustrate examples 1 and 2 of a simultaneous multi-AP selection procedure among examples of performing multi-AP selection for multiple DAPs. Each AP follows the operations defined in sections 2.1 and 2.2. Figures 28 and 29 illustrate that the request / response frame in the simultaneous multi-AP selection procedure can be an MU-RTS (TXS) TF / CTS frame or a Polling frame (Trigger frame) / Report frame (TB PPDU). The start of the time allocated to the subsequent DAP(s) can be initiated by the transmission of an individual MU-RTS (TXS) TF.

[0489] Figure 30 illustrates an example-3 of a Simultaneous Multi-AP selection procedure for selecting multiple DAPs.

[0490] Figure 31 illustrates an example-4 of a Simultaneous Multi-AP selection procedure for selecting multiple DAPs.

[0491] Alternatively, the start of the time allocated to subsequent DAP(s) as in FIGS. 30 and 31 may be performed by the DAP(s) themselves according to the scheduled time, without transmission of individual MU-RTS TXS TFs from the SAP.

[0492] Figure 32 illustrates an example-1 of a Sequential Multi-AP selection procedure for selecting multiple DAPs.

[0493] Figure 33 illustrates an example-2 of a Sequential Multi-AP selection procedure for selecting multiple DAPs.

[0494] Figures 32 and 33 illustrate examples 1 and 2 of the Sequential Multi-AP selection procedure, which are examples of performing Multi-AP selection on multiple DAPs. Each AP follows the operations defined in Sections 2.1 and 2.2. Figures 32 and 33 illustrate that the start of the time allocated to subsequent DAP(s) through the Sequential Multi-AP selection procedure can be initiated by the transmission of individual MU-RTS TXS TFs from the SAP, or can be performed by the DAP(s) themselves according to a scheduled time.

[0495] Figure 34 illustrates an example of a Simultaneous Multi-AP selection procedure based on Option #1-(5) of Section 2.2.2.

[0496] Figure 34 illustrates an example of a simultaneous multi-AP selection procedure based on the duration setting method of Option #1-(5) in Section 2.2.2, among examples of performing multi-AP selection on multiple DAPs. Each AP follows the operations defined in Sections 2.1 and 2.2. Figure 34 illustrates that the request / response frame in the simultaneous multi-AP selection procedure can be an MU-RTS (TXS) TF / CTS frame.

[0497] According to the duration setting method of Option #1-(5) in Section 2.2.2, the Duration / ID field of the MU-RTS (TXS) TF is set to the value of T_1, and the User Info field or Common Info field may include the value of T_expect. The SAP may include the identification information of the DAP (i.e., AP 2 in FIG. 34) scheduled to share TXOP in the AID field of the User Info field within the acquired TXOP, and the corresponding DAP that receives it may transmit a CTS frame including the value of T_expect, not the value of the Duration / ID field of the MU-RTS (TXS) TF, in the Duration / ID field. The T_expect value at this time may include a period until transmitting the MU-RTS TXS TF transmitted for the purpose of TXOP sharing (i.e., (1) of FIG. 34) or a period until transmitting the CTS frame, which is a response frame to the MU-RTS TXS TF transmitted for the purpose of TXOP sharing (i.e., (2) of FIG. 34).

[0498] This specification proposes a procedure for selecting DAPs as targets of TXOP sharing by an SAP that wishes to perform C-TDMA transmission in a multi-AP environment. Specifically, an AP acting as an SAP can transmit a request frame to select DAP(s) with which to share TXOPs, and the target DAP that receives the request frame can transmit a response frame depending on whether sharing is necessary. If the target DAP does not require TXOP sharing or does not receive a response frame to the request frame, a reselection procedure can be performed to send the request frame to other DAP(s). Alternatively, a selection / notification procedure can be performed that simply notifies the target DAP that it intends to share TXOPs. Alternatively, the multi-AP selection procedure can be omitted in some situations. The multi-AP selection procedure using several of the proposed selection methods has the advantage that the DAP(s) that are targets of sharing or that will not receive sharing can perform subsequent operations, set NAVs, or enter a mode / state for power saving based on the transmitted information or frames.

[0499] Figure 35 is a flowchart illustrating the operation of a transmitting device according to the present embodiment.

[0500] An example of FIG. 35 may be performed at a transmitting STA or transmitting device (AP and / or non-AP STA).

[0501] Some of the steps (or detailed sub-steps described below) in the example of Figure 35 may be omitted or changed.

[0502] Through step S3510, the transmitting device (transmitting STA) can obtain information regarding the aforementioned 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, and information regarding the STA receiving the RU.

[0503] Through step S3520, the transmitting device can configure / generate a PPDU based on the acquired control information. The step of configuring / generating the PPDU may include a step of configuring / generating each field of the PPDU. That is, step S3520 may include a step of configuring an EHT-SIG field including control information regarding a Tone Plan. That is, step S3520 may include a step of configuring a field including control information indicating the size / position of an RU (e.g., an N bitmap) and / or a step of configuring a field including an identifier (e.g., an AID) of an STA receiving the RU.

[0504] Additionally, step S3520 may include a step of generating an STF / LTF sequence to be transmitted through a specific RU. The STF / LTF sequence may be generated based on a preset STF generation sequence / LTF generation sequence.

[0505] Additionally, step S3520 may include a step of generating a data field (i.e., MPDU) to be transmitted via a specific RU.

[0506] The transmitting device can transmit the PPDU configured through step S3520 to the receiving device based on step S3530.

[0507] While performing step S3530, the transmitting device may perform at least one of operations such as CSD, Spatial Mapping, IDFT / IFFT operation, and GI insertion.

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

[0509] Fig. 36 is a flowchart illustrating the operation of a receiving device according to the present embodiment.

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

[0511] An example of FIG. 36 may be performed at a receiving STA or receiving device (AP and / or non-AP STA).

[0512] Some of the steps (or detailed sub-steps described below) in the example of Fig. 36 may be omitted.

[0513] A receiving device (receiving STA) may receive all or part of a PPDU through step S3610. The received signal may have the form of FIG. 5.

[0514] The sub-step of step S3610 can be determined based on step S3530 of FIG. 35. That is, step S3610 can perform an operation to restore the results of the CSD, Spatial Mapping, IDFT / IFFT operations, and GI insert operations applied in step S3530.

[0515] At step S3620, the receiving device can decode 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.

[0516] 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 included in the L-SIG and EHT SIG fields. Information regarding various Tone Plans (i.e., RUs) described herein can be included in the EHT-SIG, and the receiving STA can obtain information regarding the Tone Plan (i.e., RU) through the EHT-SIG.

[0517] In step S3630, the receiving device can decode the remaining portion of the PPDU based on the information about the Tone Plan (i.e., RU) acquired in step S3620. For example, the receiving STA can decode the STF / LTF field of the PPDU based on the information about one Plan (i.e., RU). In addition, the receiving STA can decode the data field of the PPDU based on the information about the Tone Plan (i.e., RU) and acquire the MPDU included in the data field.

[0518] Additionally, the receiving device may perform a processing operation to transmit the decoded data to a higher layer (e.g., MAC layer) through step S3630. Furthermore, if the generation of a signal from the higher layer to the PHY layer is instructed in response to the data transmitted to the higher layer, subsequent operations may be performed.

[0519] Hereinafter, the above-described embodiment will be described with reference to FIGS. 1 to 36.

[0520] FIG. 37 is a flowchart illustrating a procedure of a method for performing cooperation between multiple APs by selecting an AP that shares TXOP or performs cooperation between APs (e.g., C-SR, C-BF, C-OFDMA, etc.) in terms of the Sharing AP according to the present embodiment.

[0521] An example of FIG. 37 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 on the 802.11be system and can satisfy backward compatibility with the 802.11be system.

[0522] An example of FIG. 37 is performed in a second AP, wherein the second AP may be set as a shared AP (SAP) after negotiation in multi-AP communication, and the first AP may be set as a shared AP (DAP) after negotiation in multi-AP communication. The first and second non-AP STAs of the present embodiment may correspond to at least one STA (station).

[0523] The present embodiment proposes a method for performing cooperation between multiple APs (e.g., C-TDMA, C-SR, C-BF, C-OFDMA, or J-TX) by selecting an AP that shares a TXOP or performs cooperation between APs. In particular, the present embodiment proposes a method for determining the necessity of TXOP sharing or cooperation between APs by determining the necessity of TXOP sharing of a DAP or cooperation between APs in a procedure for selecting a multi-AP, and securing a period set in a Duration field so that the DAP performs frame exchange with a non-AP STA within a BSS after the period.

[0524] In step S3710, the second AP (access point) transmits a selection request frame to the first AP.

[0525] At step S3720, the second AP receives a selection response frame from the first AP.

[0526] In step S3730, the second AP selects the first AP as an AP with which to share a TXOP (Transmit Opportunity) for cooperation between multiple APs, based on the selection request frame and the selection response frame.

[0527] The above selection request frame may include at least one of information about a TXOP section scheduled by the second AP for cooperation among the plurality of APs, information about a time point at which the second AP expects or schedules to share the TXOP, information about low-latency traffic that each of the plurality of APs intends to transmit and receive, and information about a priority or protection level of cooperation among the plurality of APs.

[0528] The TXOP interval scheduled by the second AP for cooperation between the plurality of APs may be a nominal TXOP interval scheduled by the second AP for cooperation between the plurality of APs.

[0529] In addition, the selection request frame may further include at least one of an identifier of a group for cooperation between the plurality of APs, an identifier of the Shared AP, information about a capability to operate as the Sharing AP, information indicating that the Sharing AP shares the TXOP with the Shared AP, information about a technique for cooperation between the plurality of APs, address information of the Shared AP, channel information on which the plurality of APs operate, and bandwidth information on which the plurality of APs operate.

[0530] The above selection response frame may include at least one of an identifier of a group for cooperation between the plurality of APs, an identifier of the Shared AP, address information of the Shared AP, channel information on which the plurality of APs operate, bandwidth information on which the plurality of APs operate, information on a section of a TXOP that the Shared AP wishes to share, buffer status information of the Shared AP, information on whether sharing of a TXOP by the Sharing AP is necessary, information on low-latency traffic transmitted and received by each of the plurality of APs, and a status code.

[0531] That is, the present embodiment proposes a method for selecting (or deciding whether to select) the first AP as a DAP participating in cooperation between multiple APs by determining whether TXOP sharing is necessary for the first AP based on the information described above in the procedure for selecting the Multi-AP. That is, through the procedure for selecting the Multi-AP, the SAP can determine the necessity of TXOP sharing of the DAP within the acquired TXOP, and if the DAP does not require TXOP sharing, the SAP can decide to share the TXOP with a subsequent DAP or not perform TXOP sharing. This has the effect of reducing overhead in the procedure for selecting the Multi-AP by having the SAP notify the target DAP of information about TXOP sharing.

[0532] In addition, the present embodiment enables a DAP to perform frame exchange during a shared TXOP after a time set based on the value of the Duration field of a request frame transmitted by a SAP in a procedure for selecting a multi-AP and after a TXOP sharing procedure. Specifically, the method for setting the Duration field can be varied, and the method for setting the Duration field can be characterized in that the operations of surrounding STAs of the DAP may or may not be restricted. In the case where the operations of surrounding STAs of the DAP are restricted, there is an effect that the DAP can stably perform frame exchange with non-AP STAs within a BSS after the secured time.

[0533] Specifically, the second AP transmits a MU-RTS (Multi User-Request to Send) TXS (TXOP sharing) trigger frame to the first AP. The second AP receives a CTS (Clear to Send) frame from the first AP. After a first time, the first AP exchanges a first frame with a first non-AP STA (station).

[0534] At this time, the second AP is a Sharing AP that controls cooperation between multiple APs, and the first AP is a Shared AP that receives or shares resources from the Sharing AP. The first non-AP STA is a non-AP STA within the BSS (Basic Service Set) of the first AP.

[0535] The above first time is set based on the value of the Duration field included in the request frame.

[0536] The value of the above Duration field can be set to one of T_1, T_2, T_3, and T_4.

[0537] The above T_1 may be a value indicating a time interval from the time the request frame is transmitted to the time the response frame is received.

[0538] The above T_2 may be a value indicating a time interval for frame exchange within the BSS of the second AP from the time the request frame is transmitted.

[0539] The above T_3 may be a value indicating a time interval from the time the request frame is transmitted to the time the MU-RTS TXS TF is transmitted.

[0540] The above T_4 may be a value indicating a time interval from the time the request frame is transmitted to the time the CTS frame is received.

[0541] The first AP may further include a step of waiting without performing any action until the first time, performing channel access on a non-primary channel, or entering AP power mode. That is, the present embodiment proposes a method in which the first AP secures the first time so as to smoothly perform frame exchange with the first non-AP STA after the first time without affecting the frame exchange.

[0542] The above non-primary channel may be a secondary 20MHz channel that can perform backoff while a Network Allocation Vector (NAV) is set for the primary 20MHz channel.

[0543] The first AP may exchange the first frame with the first non-AP STA during a first TXOP. The first TXOP may be set based on time information of the MU-RTS TXS trigger frame.

[0544] The second AP may exchange a second frame with a second non-AP STA during a second TXOP. The second TXOP may be set based on T_2. The second non-AP STA may be a non-AP STA within the BSS of the second AP.

[0545] For example, based on the second frame including multiple frames, the value of the Duration field of the first frame among the multiple frames may be set to T_FE.

[0546] The above T_FE may be a value indicating a time interval from the time the first frame is transmitted to the time the second TXOP ends.

[0547] At this time, the value of the Duration field of the MU-RTS TXS trigger frame may be set to T_TXS. The T_TXS may be a value indicating a time interval from the time the MU-RTS TXS trigger frame is transmitted to the time the CTS frame is received.

[0548] As another example, based on the second frame including the third to fifth frames, the value of the Duration field of the third frame may be set to T_FE1, the value of the Duration field of the fourth frame may be set to T_FE2, and the value of the Duration field of the fifth frame may be set to T_FE3.

[0549] The above T_FE1 may be a value indicating a time interval from the time the third frame is transmitted to the time the response frame of the third frame is received. The above T_FE2 may be a value indicating a time interval from the time the fourth frame is transmitted to the time the response frame of the fourth frame is received. The above T_FE3 may be a value indicating a time interval from the time the fifth frame is transmitted to the time the response frame of the fifth frame is received.

[0550] At this time, the value of the Duration field of the MU-RTS TXS trigger frame may be set to T_TXS. The T_TXS may be a value indicating a time interval from the time the MU-RTS TXS trigger frame is transmitted to the time the CTS frame is received.

[0551] As another example, based on the second frame including a plurality of frames, the value of the Duration field of the first frame among the plurality of frames may be set to a time interval of T_3 minus T_1, or a time interval of T_4 minus T_1.

[0552] As another example, based on the request frame being a trigger frame, the AID (Association Identifier) ​​field of the user information field of the trigger frame may include identification information of the first AP. The NAV for the first AP may be set based on information about the timing at which the second AP expects or schedules to share the TXOP, which is included in the user information field or the common information field of the trigger frame. The information about the timing at which the second AP expects or schedules to share the TXOP may be Expected TXOP sharing timing information.

[0553] The technique for cooperation between the above multiple APs may include a coordinated multi-AP technique such as C-TDMA (Coordinated-Time Division Multiplexing Access), C-SR (Coordinated-Spatial Reuse), C-BF (Coordinated-beamforming), or C-OFMA (Coordinated-Orthogonal Frequency Division Multiple Access).

[0554] FIG. 38 is a flowchart illustrating a procedure of a method for performing cooperation between multiple APs by selecting an AP that shares TXOP or performs cooperation between APs (e.g., C-SR, C-BF, C-OFDMA, etc.) in terms of a shared AP according to the present embodiment.

[0555] An example of FIG. 38 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 on the 802.11be system and can satisfy backward compatibility with the 802.11be system.

[0556] An example of FIG. 38 is performed in a first AP, wherein the first AP may be set as a shared AP (DAP) after negotiation in multi-AP communication, and the second AP may be set as a shared AP (SAP) after negotiation in multi-AP communication. The first and second non-AP STAs of the present embodiment may correspond to at least one STA (station).

[0557] The present embodiment proposes a method for performing cooperation between multiple APs (e.g., C-TDMA, C-SR, C-BF, C-OFDMA, or J-TX) by selecting an AP that shares a TXOP or performs cooperation between APs. In particular, the present embodiment proposes a method for determining the necessity of TXOP sharing or cooperation between APs by determining the necessity of TXOP sharing of a DAP or cooperation between APs in a procedure for selecting a multi-AP, and securing a period set in a Duration field so that the DAP performs frame exchange with a non-AP STA within a BSS after the period.

[0558] At step S3810, the first AP (access point) receives a selection request frame from the second AP.

[0559] In step S3820, the first AP transmits a selection response frame to the second AP.

[0560] Based on the above selection request frame and the above selection response frame, the first AP is selected as an AP with which to share TXOP (Transmit Opportunity) for cooperation between multiple APs.

[0561] The above selection request frame may include at least one of information about a TXOP section scheduled by the second AP for cooperation among the plurality of APs, information about a time point at which the second AP expects or schedules to share the TXOP, information about low-latency traffic that each of the plurality of APs intends to transmit and receive, and information about a priority or protection level of cooperation among the plurality of APs.

[0562] The TXOP interval scheduled by the second AP for cooperation between the plurality of APs may be a nominal TXOP interval scheduled by the second AP for cooperation between the plurality of APs.

[0563] In addition, the selection request frame may further include at least one of an identifier of a group for cooperation between the plurality of APs, an identifier of the Shared AP, information about a capability to operate as the Sharing AP, information indicating that the Sharing AP shares the TXOP with the Shared AP, information about a technique for cooperation between the plurality of APs, address information of the Shared AP, channel information on which the plurality of APs operate, and bandwidth information on which the plurality of APs operate.

[0564] The above selection response frame may include at least one of an identifier of a group for cooperation between the plurality of APs, an identifier of the Shared AP, address information of the Shared AP, channel information on which the plurality of APs operate, bandwidth information on which the plurality of APs operate, information on a section of a TXOP that the Shared AP wishes to share, buffer status information of the Shared AP, information on whether sharing of a TXOP by the Sharing AP is necessary, information on low-latency traffic transmitted and received by each of the plurality of APs, and a status code.

[0565] That is, the present embodiment proposes a method for selecting (or deciding whether to select) the first AP as a DAP participating in cooperation between multiple APs by determining whether TXOP sharing is necessary for the first AP based on the information described above in the procedure for selecting the Multi-AP. That is, through the procedure for selecting the Multi-AP, the SAP can determine the necessity of TXOP sharing of the DAP within the acquired TXOP, and if the DAP does not require TXOP sharing, the SAP can decide to share the TXOP with a subsequent DAP or not perform TXOP sharing. This has the effect of reducing overhead in the procedure for selecting the Multi-AP by having the SAP notify the target DAP of information about TXOP sharing.

[0566] In addition, the present embodiment enables a DAP to perform frame exchange during a shared TXOP after a time set based on the value of the Duration field of a request frame transmitted by a SAP in a procedure for selecting a multi-AP and after a TXOP sharing procedure. Specifically, the method for setting the Duration field can be varied, and the method for setting the Duration field can be characterized in that the operations of surrounding STAs of the DAP may or may not be restricted. In the case where the operations of surrounding STAs of the DAP are restricted, there is an effect that the DAP can stably perform frame exchange with non-AP STAs within a BSS after the secured time.

[0567] Specifically, the second AP transmits a MU-RTS (Multi User-Request to Send) TXS (TXOP sharing) trigger frame to the first AP. The second AP receives a CTS (Clear to Send) frame from the first AP. After a first time, the first AP exchanges a first frame with a first non-AP STA (station).

[0568] At this time, the second AP is a Sharing AP that controls cooperation between multiple APs, and the first AP is a Shared AP that receives or shares resources from the Sharing AP. The first non-AP STA is a non-AP STA within the BSS (Basic Service Set) of the first AP.

[0569] The above first time is set based on the value of the Duration field included in the request frame.

[0570] The value of the above Duration field can be set to one of T_1, T_2, T_3, and T_4.

[0571] The above T_1 may be a value indicating a time interval from the time the request frame is transmitted to the time the response frame is received.

[0572] The above T_2 may be a value indicating a time interval for frame exchange within the BSS of the second AP from the time the request frame is transmitted.

[0573] The above T_3 may be a value indicating a time interval from the time the request frame is transmitted to the time the MU-RTS TXS TF is transmitted.

[0574] The above T_4 may be a value indicating a time interval from the time the request frame is transmitted to the time the CTS frame is received.

[0575] The first AP may further include a step of waiting without performing any action until the first time, performing channel access on a non-primary channel, or entering AP power mode. That is, the present embodiment proposes a method in which the first AP secures the first time so as to smoothly perform frame exchange with the first non-AP STA after the first time without affecting the frame exchange.

[0576] The above non-primary channel may be a secondary 20MHz channel that can perform backoff while a Network Allocation Vector (NAV) is set for the primary 20MHz channel.

[0577] The first AP may exchange the first frame with the first non-AP STA during a first TXOP. The first TXOP may be set based on time information of the MU-RTS TXS trigger frame.

[0578] The second AP may exchange a second frame with a second non-AP STA during a second TXOP. The second TXOP may be set based on T_2. The second non-AP STA may be a non-AP STA within the BSS of the second AP.

[0579] For example, based on the second frame including multiple frames, the value of the Duration field of the first frame among the multiple frames may be set to T_FE.

[0580] The above T_FE may be a value indicating a time interval from the time the first frame is transmitted to the time the second TXOP ends.

[0581] At this time, the value of the Duration field of the MU-RTS TXS trigger frame may be set to T_TXS. The T_TXS may be a value indicating a time interval from the time the MU-RTS TXS trigger frame is transmitted to the time the CTS frame is received.

[0582] As another example, based on the second frame including the third to fifth frames, the value of the Duration field of the third frame may be set to T_FE1, the value of the Duration field of the fourth frame may be set to T_FE2, and the value of the Duration field of the fifth frame may be set to T_FE3.

[0583] The above T_FE1 may be a value indicating a time interval from the time the third frame is transmitted to the time the response frame of the third frame is received. The above T_FE2 may be a value indicating a time interval from the time the fourth frame is transmitted to the time the response frame of the fourth frame is received. The above T_FE3 may be a value indicating a time interval from the time the fifth frame is transmitted to the time the response frame of the fifth frame is received.

[0584] At this time, the value of the Duration field of the MU-RTS TXS trigger frame may be set to T_TXS. The T_TXS may be a value indicating a time interval from the time the MU-RTS TXS trigger frame is transmitted to the time the CTS frame is received.

[0585] As another example, based on the second frame including a plurality of frames, the value of the Duration field of the first frame among the plurality of frames may be set to a time interval of T_3 minus T_1, or a time interval of T_4 minus T_1.

[0586] As another example, based on the request frame being a trigger frame, the AID (Association Identifier) ​​field of the user information field of the trigger frame may include identification information of the first AP. The NAV for the first AP may be set based on information about the timing at which the second AP expects or schedules to share the TXOP, which is included in the user information field or the common information field of the trigger frame. The information about the timing at which the second AP expects or schedules to share the TXOP may be Expected TXOP sharing timing information.

[0587] The technique for cooperation between the above multiple APs may include a coordinated multi-AP technique such as C-TDMA (Coordinated-Time Division Multiplexing Access), C-SR (Coordinated-Spatial Reuse), C-BF (Coordinated-beamforming), or C-OFMA (Coordinated-Orthogonal Frequency Division Multiple Access).

[0588] <Device Configuration>

[0589] The technical features of the present specification described above can be applied to various devices and methods. For example, the technical features of the present specification described above can be performed / supported by the devices of FIG. 1 and / or FIG. 13. For example, the technical features of the present specification described above can be applied only to a part of FIG. 1 and / or FIG. 13. For example, the technical features of the present specification described above can be implemented based on the processing chip (114, 124) of FIG. 1, or based on the processor (111, 121) and the memory (112, 122) of FIG. 1, or based on the processor (610) and the memory (620) of FIG. 13. For example, the device of the present specification receives a selection request frame from a second access point (AP); and transmits a selection response frame to the second AP.

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

[0591] The CRM may store instructions for performing operations including receiving a selection request frame from a second AP (access point); and transmitting a selection response frame to the second AP. The instructions stored in the CRM of the present specification may be executed by at least one processor. At least one processor related to the CRM of the present 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 the present 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. In a wireless LAN system, A step in which a first AP (access point) receives a selection request frame from a second AP; and The first AP comprises a step of transmitting a selection response frame to the second AP, Based on the above selection request frame and the above selection response frame, the first AP is selected as an AP to share TXOP (Transmit Opportunity) for cooperation between multiple APs, The above selection request frame includes at least one of information about a TXOP section scheduled by the second AP for cooperation between the plurality of APs, information about a time point at which the second AP expects or schedules to share the TXOP, information about low-latency traffic that each of the plurality of APs intends to transmit and receive, and information about a priority or protection level of cooperation between the plurality of APs. method.

2. In paragraph 1, A step in which the first AP receives a MU-RTS (Multi User-Request to Send) TXS (TXOP sharing) trigger frame from the second AP; A step in which the first AP transmits a CTS (Clear to Send) frame to the second AP; and The first AP further includes a step of exchanging a first frame with a first non-AP STA (station) after a first time, The above second AP is a Sharing AP that controls cooperation between multiple APs, The above first AP is a Shared AP that is allocated or shared with resources from the Sharing AP, The above first non-AP STA is a non-AP STA within the BSS (Basic Service Set) of the first AP, and The above first time is set based on the value of the Duration field included in the request frame. method.

3. In paragraph 2, The value of the above Duration field is set to one of T_1, T_2, T_3, and T_4, The above T_1 is a value indicating the time interval from the time the request frame is transmitted to the time the response frame is received, The above T_2 is a value indicating a time interval for frame exchange within the BSS of the second AP from the time the request frame is transmitted, The above T_3 is a value indicating the time interval from the time the request frame is transmitted to the time the MU-RTS TXS TF is transmitted, The above T_4 is a value indicating the time interval from the time the request frame is transmitted to the time the CTS frame is received. method.

4. In paragraph 3, The first AP further includes a step of waiting without performing any action until the first time, performing channel access for a non-primary channel, or entering AP power mode, The above non-primary channel is a secondary 20MHz channel that can perform backoff while the NAV (Network Allocation Vector) is set to the primary 20MHz channel. method.

5. In paragraph 3, The first AP exchanges the first frame with the first non-AP STA during the first TXOP, The above first TXOP is set based on the time information of the MU-RTS TXS trigger frame, The second AP exchanges a second frame with a second non-AP STA during the second TXOP, The above second TXOP is set based on the above T_2, The above second non-AP STA is a non-AP STA within the BSS of the second AP. method.

6. In paragraph 5, Based on the above second frame including a plurality of frames, The value of the Duration field of the first frame among the above multiple frames is set to T_FE, The above T_FE is a value indicating the time interval from the time the first frame is transmitted to the time the second TXOP ends, The value of the Duration field of the above MU-RTS TXS trigger frame is set to T_TXS, The above T_TXS is a value indicating the time interval from the time the MU-RTS TXS trigger frame is transmitted to the time the CTS frame is received. method.

7. In paragraph 5, Based on the above second frame including the third to fifth frames, The value of the Duration field of the third frame is set to T_FE1, The value of the Duration field of the fourth frame is set to T_FE2, The value of the Duration field of the fifth frame is set to T_FE3, The above T_FE1 is a value indicating the time interval from the time the third frame is transmitted to the time the response frame of the third frame is received, The above T_FE2 is a value indicating the time interval from the time the fourth frame is transmitted to the time the response frame of the fourth frame is received, The above T_FE3 is a value indicating the time interval from the time the 5th frame is transmitted to the time the response frame of the 5th frame is received, The value of the Duration field of the above MU-RTS TXS trigger frame is set to T_TXS, The above T_TXS is a value indicating the time interval from the time the MU-RTS TXS trigger frame is transmitted to the time the CTS frame is received. method.

8. In paragraph 5, Based on the above second frame including a plurality of frames, The value of the Duration field of the first frame among the above multiple frames is set to the time interval T_3 minus T_1, or the time interval T_4 minus T_1. method.

9. In paragraph 5, Based on the above request frame being a trigger frame, The AID (Association Identifier) ​​field of the user information field of the above trigger frame includes identification information of the first AP, The NAV for the first AP is set based on information about the time at which the second AP expects or schedules to share the TXOP, which is included in the user information field or the common information field of the trigger frame. method.

10. In paragraph 9, The selection request frame further includes at least one of an identifier of a group for cooperation between the plurality of APs, an identifier of the Shared AP, information about a capability to operate as the Sharing AP, information indicating that the Sharing AP shares the TXOP with the Shared AP, information about a technique for cooperation between the plurality of APs, address information of the Shared AP, channel information on which the plurality of APs operate, and bandwidth information on which the plurality of APs operate. The selection response frame includes at least one of an identifier of a group for cooperation between the plurality of APs, an identifier of the Shared AP, address information of the Shared AP, channel information on which the plurality of APs operate, bandwidth information on which the plurality of APs operate, information on a section of a TXOP that the Shared AP wishes to share, buffer status information of the Shared AP, information on whether sharing of the TXOP by the Sharing AP is necessary, information on low-latency traffic transmitted and received by each of the plurality of APs, and a status code. method.

11. In a wireless LAN system, the first AP (access point) is memory; transceiver; and A processor operatively coupled to the memory and the transceiver, the processor comprising: Receive a selection request frame from the second AP; Transmit a selection response frame to the second AP; Based on the above selection request frame and the above selection response frame, the first AP is selected as an AP to share TXOP (Transmit Opportunity) for cooperation between multiple APs, The above selection request frame includes at least one of information about a TXOP section scheduled by the second AP for cooperation between the plurality of APs, information about a time point at which the second AP expects or schedules to share the TXOP, information about low-latency traffic that each of the plurality of APs intends to transmit and receive, and information about a priority or protection level of cooperation between the plurality of APs. 1st AP.

12. In a wireless LAN system, A step in which a second AP (access point) transmits a selection request frame to a first AP; The second AP receives a selection response frame from the first AP; and The second AP comprises a step of selecting the first AP as an AP with which to share a TXOP (Transmit Opportunity) for cooperation between multiple APs based on the selection request frame and the selection response frame. The above selection request frame includes at least one of information about a TXOP section scheduled by the second AP for cooperation between the plurality of APs, information about a time point at which the second AP expects or schedules to share the TXOP, information about low-latency traffic that each of the plurality of APs intends to transmit and receive, and information about a priority or protection level of cooperation between the plurality of APs. method.

13. In paragraph 12, If the above first AP is not an AP that will share TXOP for cooperation between the above multiple APs, A step in which the second AP transmits a separate selection request frame to the third AP and receives a separate selection response frame from the third AP; or The second AP further includes a step of not performing a procedure for selecting an AP to share TXOP for cooperation between the plurality of APs. method.

14. In paragraph 12, A step in which the second AP transmits a MU-RTS (Multi User-Request to Send) TXS (TXOP sharing) trigger frame to the first AP; and The second AP comprises a step of receiving a CTS (Clear to Send) frame from the first AP, After the first time, the first frame is exchanged between the first AP and the first non-AP STA (station), The above second AP is a Sharing AP that controls cooperation between multiple APs, The above first AP is a Shared AP that is allocated or shared with resources from the Sharing AP, The above first non-AP STA is a non-AP STA within the BSS (Basic Service Set) of the first AP, and The above first time is set based on the value of the Duration field included in the request frame. method.

15. In paragraph 14, The value of the above Duration field is set to one of T_1, T_2, T_3, and T_4, The above T_1 is a value indicating the time interval from the time the request frame is transmitted to the time the response frame is received, The above T_2 is a value indicating a time interval for frame exchange within the BSS of the second AP from the time the request frame is transmitted, The above T_3 is a value indicating the time interval from the time the request frame is transmitted to the time the MU-RTS TXS TF is transmitted, The above T_4 is a value indicating the time interval from the time the request frame is transmitted to the time the CTS frame is received. method.

16. In paragraph 15, The first AP exchanges the first frame with the first non-AP STA during the first TXOP, The above first TXOP is set based on the time information of the MU-RTS TXS trigger frame, The second AP exchanges a second frame with a second non-AP STA during the second TXOP, The above second TXOP is set based on the above T_2, The above second non-AP STA is a non-AP STA within the BSS of the second AP. method.

17. In paragraph 16, Based on the above second frame including a plurality of frames, The value of the Duration field of the first frame among the above multiple frames is set to T_FE, The above T_FE is a value indicating the time interval from the time the first frame is transmitted to the time the second TXOP ends, The value of the Duration field of the above MU-RTS TXS trigger frame is set to T_TXS, The above T_TXS is a value indicating the time interval from the time the MU-RTS TXS trigger frame is transmitted to the time the CTS frame is received. method.

18. In a wireless LAN system, the second AP (access point) is memory; transceiver; and A processor operatively coupled to the memory and the transceiver, the processor comprising: Transmit a selection request frame to the first AP; Receive a selection response frame from the first AP; and Based on the above selection request frame and the above selection response frame, the first AP is selected as an AP to share TXOP (Transmit Opportunity) for cooperation between multiple APs. The above selection request frame includes at least one of information about a TXOP section scheduled by the second AP for cooperation between the plurality of APs, information about a time point at which the second AP expects or schedules to share the TXOP, information about low-latency traffic that each of the plurality of APs intends to transmit and receive, and information about a priority or protection level of cooperation between the plurality of APs. 2nd AP.

19. At least one computer-readable medium containing instructions based on being executed by at least one processor, A step of receiving a selection request frame from a second AP (access point); and Including a step of transmitting a selection response frame to the second AP, Based on the above selection request frame and the above selection response frame, the first AP is selected as an AP to share TXOP (Transmit Opportunity) for cooperation between multiple APs, The above selection request frame includes at least one of information about a TXOP section scheduled by the second AP for cooperation between the plurality of APs, information about a time point at which the second AP expects or schedules to share the TXOP, information about low-latency traffic that each of the plurality of APs intends to transmit and receive, and information about a priority or protection level of cooperation between the plurality of APs. Recording medium.

20. In a wireless LAN system, in a device, memory; and A processor operatively coupled to the memory, the processor comprising: Receive a selection request frame from a second AP (access point); and Transmit a selection response frame to the second AP, Based on the above selection request frame and the above selection response frame, the first AP is selected as an AP to share TXOP (Transmit Opportunity) for cooperation between multiple APs, The above selection request frame includes at least one of information about a TXOP section scheduled by the second AP for cooperation between the plurality of APs, information about a time point at which the second AP expects or schedules to share the TXOP, information about low-latency traffic that each of the plurality of APs intends to transmit and receive, and information about a priority or protection level of cooperation between the plurality of APs. device.

Images