TXOP return in multi-AP cooperation in wireless LAN system

Abstract

The present disclosure relates to transmission opportunity (TXOP) return in multi-AP cooperation in a wireless LAN system. According to embodiments of the present disclosure, a method performed by a first AP in a wireless LAN system comprises the steps of: performing a negotiation procedure for multi-AP cooperation with a second AP; receiving, from the second AP, a transmission opportunity (TXOP) sharing frame including information about an allocation interval within a TXOP interval; performing, during the allocation interval, frame exchange with a station (STA) associated with the first AP; and when the frame exchange is completed, transmitting, to the second AP, a TXOP return frame including a TXOP return notification.

Description

TXOP Return in Multi-AP Cooperation in Wireless LAN Systems

[0001] The present disclosure relates to transmission opportunity (TXOP) return in multi-AP cooperation in a wireless LAN system.

[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 this end, various technologies are being considered to support high throughput, low latency, and extended range. For example, an STA that has received a shared TXOP can exchange frames for the allocated time and then notify the AP with which it shared the TXOP that it has returned the TXOP. This TXOP return may also be required in multi-AP cooperation.

[0003] The present disclosure provides a method and device for returning TXOP in multi-AP cooperation in a wireless LAN system.

[0004] According to an embodiment of the present disclosure, a method performed by a first AP in a wireless LAN system includes the steps of: performing a negotiation procedure for multi-AP cooperation with a second AP; receiving, from the second AP, a TXOP (transmission opportunity) shared frame including information on an allocated section within a TXOP section; performing frame exchange with a STA (station) associated with the first AP in the allocated section; and upon completion of the frame exchange, transmitting, to the second AP, a TXOP return frame including a TXOP return notification.

[0005] According to an embodiment of the present disclosure, a method performed by a second AP in a wireless LAN system includes the steps of: performing a negotiation procedure for multi-AP cooperation with a first AP; transmitting, to the first AP, a TXOP (transmission opportunity) shared frame including information on an allocated section within a TXOP section; receiving, from the first AP, a TXOP return frame including a TXOP return notification upon completion of frame exchange of the first AP in the allocated section; and performing frame exchange with an STA (station) associated with the second AP in a remaining TXOP section after receiving the TXOP return notification within the TXOP section.

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

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

[0008] For example, according to embodiments of the present disclosure, the SAP can transmit indicator information indicating to the DAP whether a return for a shared TXOP is required, thereby preventing unnecessary TXOP return procedures from being performed. In other words, the TXOP return method of the present disclosure allows the DAP to identify whether a TXOP return is required based on a TXOP return request from the SAP, thereby increasing the utilization of the medium and successfully performing the TXOP return procedure to the SAP. Alternatively, the TXOP return procedure can be performed according to the decision and / or implementation of the DAP without a separate instruction from the SAP.

[0009] In addition, in the present disclosure, the interval field of a frame transmitted in a TXOP allocation interval is set to a value corresponding to an individual frame exchange time, thereby solving a hidden node problem that may occur when returning a TXOP.

[0010] Additionally, the present disclosure provides a CCA method and device for enabling a SAP to successfully use the remaining TXOP interval after a TXOP is returned. According to the CCA method provided in the present disclosure, collisions that may occur during frame exchange after a TXOP is returned can be prevented, and the SAP can ensure that it can fully utilize its BSS operating channel width.

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

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

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

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

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

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

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

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

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

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

[0021] Figure 10 shows the operation according to UL-MU.

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

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

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

[0025] Figure 14 shows an example of a random backoff procedure.

[0026] Figure 15 illustrates an example of a procedure related to NAV setting.

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

[0028] Figure 17 shows an example of the user information field format of MU-RTS TXS TF.

[0029] Figure 18 shows an example of operation when the value of the TXOP shared mode subfield is 2.

[0030] Figure 19 shows an example of coordinated time division multiple access (Co-TDMA) between cooperating APs.

[0031] FIG. 20 illustrates an example of a method performed by a first AP for TXOP return in a multi-AP cooperative environment according to an embodiment of the present disclosure.

[0032] FIG. 21 illustrates an example of a method performed by a second AP for TXOP return in a multi-AP cooperative environment according to an embodiment of the present disclosure.

[0033] FIG. 22 illustrates an example of a TXOP return procedure using a CF-End frame according to an embodiment of the present disclosure.

[0034] FIG. 23 illustrates an example of a TXOP return procedure using MU-RTS TXS TF and CTS frames according to an embodiment of the present disclosure.

[0035] FIG. 24 illustrates an example of a TXOP return procedure using a BAR frame and a BA frame according to an embodiment of the present disclosure.

[0036] FIG. 25 illustrates an example of a TXOP return procedure using a management frame including an A-Control field according to an embodiment of the present disclosure.

[0037] FIG. 26 illustrates an example of a TXOP return procedure using a management frame, which is an action frame, according to an embodiment of the present disclosure.

[0038] FIG. 27 illustrates an example of a TXOP return procedure using BSRP TF and TB PPDU according to an embodiment of the present disclosure.

[0039] FIG. 28 illustrates an example of a TXOP return procedure using multiple STA BA frames according to an embodiment of the present disclosure.

[0040] FIG. 29 illustrates an example of setting an interval field to prevent a hidden node problem when returning a TXOP according to an embodiment of the present disclosure.

[0041] FIG. 30 illustrates a first example of a CCA procedure that does not perform backoff after TXOP return according to an embodiment of the present disclosure.

[0042] FIG. 31 illustrates a second example of a CCA procedure that does not perform backoff after TXOP return according to an embodiment of the present disclosure.

[0043] FIG. 32 illustrates a third example of a CCA procedure that does not perform backoff after TXOP return according to an embodiment of the present disclosure.

[0044] FIG. 33 illustrates a first example of a CCA procedure performing backoff after TXOP return according to an embodiment of the present disclosure.

[0045] FIG. 34 illustrates a second example of a CCA procedure performing backoff after TXOP return according to an embodiment of the present disclosure.

[0046] FIG. 35 illustrates an example of setting a PPDU bandwidth after a TXOP return in Co-TDMA according to an embodiment of the present disclosure.

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

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

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

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

[0051] 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.”

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

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

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

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

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

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

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

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

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

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

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

[0063] 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.).

[0064] 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).

[0065] 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.).

[0066] 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).

[0067] 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).

[0068] 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).

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

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

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

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

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

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

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

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

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

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

[0079] 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).

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

[0081] 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).

[0082] 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).

[0083] 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).

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

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

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

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

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

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

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

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

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

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

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

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

[0096] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0111] Each block illustrated in Fig. 6 may be called a field / subfield / signal, etc. The names of these fields / subfields / signals may be, as illustrated in Fig. 6, L-STF (legacy short training field), L-LTF (legacy long training field), L-SIG (legacy signal), RL-SIG (repeated L-SIG), U-SIG (Universal Signal), UHR-SIG (UHR-signal), etc.

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

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

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

[0115] 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}.

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

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

[0118] 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 for a U-SIG (e.g., an OFDM symbol) 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.

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

[0120] 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".

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

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

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

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

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

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

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

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

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

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

[0131] 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).

[0132] 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).

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

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

[0135] 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).

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

[0137] FIG. 7 is a diagram showing 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. 7.

[0138] As shown at the top of Fig. 7, 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.

[0139] Meanwhile, the RU arrangement of FIG. 7 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.

[0140] In the example of Fig. 7, 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 the present disclosure, N-RU may be represented as N-tone RU, etc. For example, 26-RU may be represented as 26-tone RU.

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

[0142] As in the example of Fig. 7 where RUs of various sizes were used, the example of Fig. 8 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.

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

[0144] Figure 9 is a diagram illustrating the layout of resource units (RUs) used for an 80MHz PPDU. The layout of the resource units (RUs) used in the present disclosure may vary. For example, the layout of the resource units (RUs) used in the 80MHz band may vary.

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

[0146] TB PPDUs (1041, 1042) 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 (1030). The ACK frame (1050) for the TB PPDU can be implemented in various forms. For example, the ACK frame (1050) for the TB PPDU can be implemented in the form of a BA (block ACK).

[0147] In FIG. 10, transmission(s) of a Trigger Frame (1030), a TB PPDU (1041, 1042) and / or an ACK frame (1050) may be performed within a TXOP (1025).

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

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

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

[0151] Figure 11 exemplarily illustrates four channels within the 2.4 GHz band. The illustrated first frequency region (1110) to fourth frequency region (1140) may each include one channel. For example, the first frequency region (1110) 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 (1120) may include channel 6. In this case, the center frequency of channel 6 may be set to 2437 MHz. The third frequency region (1130) may include channel 11. In this case, the center frequency of channel 11 may be set to 2462 MHz. The fourth frequency region (1140) may include channel 14. In this case, the center frequency of channel 14 may be set to 2484 MHz.

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

[0153] 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 a center frequency 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. 12 are subject to change.

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

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

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

[0157] 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 / defined. The specific figures shown in Figure 13 are subject to change.

[0158] For example, the 20 MHz channel of FIG. 13 can be defined from 5.940 GHz. Specifically, the leftmost channel among the 20 MHz channels of FIG. 13 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.

[0159] Accordingly, the indexes (or channel numbers) of the 20 MHz channels of FIG. 13 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. 13 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.

[0160] Meanwhile, STAs that have data to transmit can perform CCA (clear channel assessment) to sense the medium for a specific period (e.g., DIFS (distributed coordination function (DCF) inter-frame space)) before transmitting the data. At this time, if the medium is idle, the STA can perform transmission using the medium. However, if the medium is busy, it can be assumed that multiple STAs are already waiting to use the medium, and the STA can transmit data after waiting for a random backoff period in addition to the DIFS. The random backoff period helps avoid collisions because, assuming that there are multiple STAs to transmit data, each STA will have a different backoff period value probabilistically, resulting in different transmission times. Once one STA starts transmitting, other STAs cannot use the medium.

[0161] In a random backoff procedure, when a specific medium changes from busy to idle, multiple STAs begin preparing to transmit data. To minimize collisions, each STA wishing to transmit data selects a random backoff count and waits for the slot time corresponding to the selected counter. The random backoff count is a pseudo-random integer value, and one of the values ​​is uniformly distributed in the range [0 CW]. CW stands for contention window. The CW parameter takes the CWmin value as the initial value, but if transmission fails, the value is doubled. For example, if an ACK response is not received for a transmitted data frame, it can be considered a collision. When the CW value reaches the CWmax value, the CWmax value is maintained until the data transmission is successful, and if the data transmission is successful, the CW value is reset to the CWmin value. At this time, CW, CWmin, and CWmax are set for convenience of implementation and operation. can be expressed as . Meanwhile, when the random backoff procedure is initiated, the STA selects a random backoff count within the range [0 CW] and continuously monitors the medium while the backoff slot is counting down. If the medium becomes busy during this time, the countdown is stopped and when the medium becomes idle again, the countdown for the remaining backoff slots is resumed.

[0162] Figure 14 shows an example of a random backoff procedure.

[0163] Referring to Figure 14, when multiple STAs have data to send, STA3 can transmit the data frame immediately because the medium is idle for DIFS, while the remaining STAs wait for the medium to become idle. Since the medium has been idle for a while, multiple STAs will be looking for an opportunity to use the medium. Therefore, each STA selects a random backoff count, and STA 2, which selects the smallest backoff count, can transmit the data frame. After STA2 completes its transmission, the medium becomes idle again, and the STAs resume counting down the backoff interval where they were paused. STA 5, which has the next smallest random backoff count after STA 2 and paused the countdown while the medium was busy, counts down the remaining backoff slots and starts transmitting the data frame, but by chance, the random backoff count value of STA 4 overlaps, which may cause a collision. At this time, since neither STA receives an ACK response after transmitting data, the two STAs double the CW and then select a random backoff count value again.

[0164] Figure 15 illustrates an example of a procedure related to NAV setting.

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

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

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

[0168] In Fig. 15, for convenience, setting or updating NAV through RTS frame or CTS frame is illustrated, but NAV setting / resetting / updating may also be performed based on the ¡ field (e.g., duration field in MAC header of MAC frame) of various other frames, for example, non-HT PPDU, HT PPDU, VHT PPDU or HE PPDU. For example, if the RA field in the received MAC frame does not match its own address (e.g., MAC address), the STA may set / reset / update NAV based on the value of the duration field in the received MAC frame.

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

[0170] The MAC frames included in the data field of the PPDU of the present disclosure can be classified into various types. For example, the MAC frames of the present disclosure can be classified into a control frame, a management frame, and a data frame.

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

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

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

[0174] A data frame may include an aggregated-control (A-Control) subfield. For example, a HT Control field included in a data frame may consist of 32 bits B0 to B31, and the A-Control subfield may consist of bits B2 to B31 of the HT Control field with B0 and B1 set to 1. In other words, the A-Control subfield may be 30 bits of information.

[0175] The 30-bit A-Control subfield can have a structure as shown in Table 1 below:

[0176] Control ListPadding

[0177] The bit size (or number of bits) of the Control List subfield can be variable. The bit size of the Padding can be 0 or more. A Control List can contain one or more Control subfields. Each Control subfield can have a structure as shown in Table 2 below:

[0178] Control IDControl Information

[0179] The bit size of the Control ID subfield can be 4 (e.g., B0 to B3). The bit size of the Control Information can be variable. The values ​​of the Control ID subfield can be defined as shown in below:

[0180] Control ID valueMeaningLength of the Control Information subfield (bits)0Triggered response scheduling (TRS)261Operating mode (OM)122HE link adaptation (HLA)263Buffer status report (BSR)264UL power headroom (UPH)85Bandwidth query report (BQR)106Command and status (CAS)87-14Reserved-15Ones need expansion surely (ONES)26

[0181] The type of the MAC frame used in the present disclosure can be identified through the type field / information and the subtype field / information included in the frame control field of the header of the MAC frame (i.e., the MAC header). For example, the “trigger frame” of the present disclosure can mean a MAC frame in which the type bits B3 and B2 bits in the frame control field of the MAC header are set to 01, and the subtype bits B7, B6, B5, and B4 bits in the frame control field are also set to 0010. Various MAC frames described in the present disclosure are inserted / included in the data fields of various PPDUs (e.g., HE / VHT / HE / EHT / UHR PPDUs). Fig. 16 shows a trigger frame format. The trigger frame format may also be referred to as the structure of the trigger frame.

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

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

[0184] Trigger type subfield valueTrigger frame variant0Basic1Beamforming Report Poll (BFRP)2MU-BAR3MU-RTS4Buffer Status Report Poll (BSRP)5GCR MU-BAR6Bandwidth Query Report Poll (BQRP)7NDP Feedback Report Poll (NFRP)8-15Reserved

[0185] For example, if the value of the trigger type subfield is set to 0, the trigger frame may be a basic trigger frame. For example, if the value of the trigger type subfield is set to 3, the trigger frame may be a MU (multi-user) RTS trigger frame. Meanwhile, according to the EHT (or 802.11be) standard, in order to support peer-to-peer (P2P) transmission to a non-AP STA, the AP may allocate a portion of the time interval within the TXOP acquired by the AP. In order to allocate a portion of the time interval within the TXOP, a TXOP Sharing Mode subfield may be defined within the Common Info Field of the MU-RTS trigger frame. When the value of the TXOP Sharing Mode subfield is non-zero, such an MU-RTS trigger frame may be referred to as an MU-RTS TXOP Sharing (TXS) trigger frame (TF). The values ​​of the TXOP Sharing Mode subfield are described in Table 5 below:

[0186] Triggered TXOP Sharing Mode subfield valueDescription0MU-RTS that does not initiate MU-RTS TXOP sharing procedure.1MU-RTS that initiates MU-RTS TXOP sharing procedure wherein a scheduledSTA can only transmit MPDU(s) addressed to its associated AP.2MU-RTS that initiates MU-RTS TXOP sharing procedure wherein a scheduled STA can transmit MPDU(s) addressed to its associated AP or addressed to another STA.3Reserved.

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

[0188] Figure 17 shows an example of the user information field format of MU-RTS TXS TF.

[0189] Referring to FIG. 17, the user information field may include an AID subfield, an RU allocation subfield, an allocation duration subfield, reserved bits, and / or a PS160 subfield.

[0190] The AID subfield may indicate the AID for the corresponding STA. The RU allocation subfield may indicate RU allocation for the corresponding STA.

[0191] The allocation interval subfield can contain 9 bits from B20 to B28 in the MU-RTS TXS TF and can indicate an allocation interval in units of 16us. In this case, the maximum length of the allocation interval that can be indicated by the allocation interval subfield can be 2^9= 8192us.

[0192] The PS160 subfield may indicate the primary 160MHz channel or the second 160MHz channel to which RU or MRU allocation applies.

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

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

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

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

[0197] Figure 18 shows an example of operation when the value of the TXOP shared mode subfield is 2.

[0198] Referring to FIG. 18, an AP may transmit an MU-RTS TXS TF including allocation (time) interval information (e.g., Time allocated in MU-RTS TXS Trigger Frame) to non-AP STA 1. Non-AP STA 1 may transmit a CTS in response to the MU-RTS TXS TF and perform P2P transmission to non-AP STA 2.

[0199] When the triggered TXOP sharing protocol is utilized for multi-AP coordination, transmissions within the BSS of each cooperative AP are divided into time units, so that each cooperative AP can perform frame exchange without affecting other cooperative APs.

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

[0201] Figure 19 shows an example of coordinated time division multiple access (Co-TDMA) between cooperating APs.

[0202] For example, Co-TDMA could mean that each cooperating AP exchanges frames without affecting other cooperating APs by separating transmissions within the BSS of each cooperating AP into time units.

[0203] When the triggered TXS protocol is applied to a multi-AP cooperative operation, an AP in the triggered TXS protocol may be an AP that shares a TXOP in the multi-AP cooperative operation, and an STA in the triggered TXS protocol may be an AP that shares a TXOP in the multi-AP cooperative operation. In the present disclosure, an AP that shares a TXOP may be referred to as a SAP (sharing AP), and an AP that receives a TXOP from a SAP may be referred to as a DAP (shared AP). Here, the term SAP does not limit that the entity that shares a TXOP is only an AP STA, and a SAP may also include a non-AP STA that shares a TXOP. In addition, the term DAP does not limit that the entity that shares a TXOP is only an AP STA, and a DAP may also include a non-AP STA that shares a TXOP (or performs transmission and reception with an AP STA that shares a TXOP). Additionally, the frame exchange performed by the DAP with a non-AP STA or SAP belonging to the DAP BSS during the allocated time (i.e., the allocated period for DAP / AP2 within the TXOP indicated by the MU-RTS TXS TF transmitted from the SAP, which is the time allocated in the MU-RTS TXS TF in FIG. 16) may be referred to as a BSS frame exchange (FE) of the DAP. For example, the RTS / CTS frame exchange between the DAP and the non-AP STA followed by data frame transmission and block ACK frame response, UL data frame transmission of non-AP STAs by a trigger frame transmitted from the DAP, and / or data frame transmission of the DAP by a trigger frame transmitted from the SAP may be performed.

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

[0205] The triggered TXS protocol provides a method for TXOP return. For example, TXOP return for UL transmission (i.e., TXS mode = 1) may be based on not receiving a UL frame from the STA that was allocated the TXOP (or allocation interval) during the PIFS time. For example, TXOP return for P2P transmission and / or UL transmission (i.e., TXS mode = 2) may be based on receiving a QoS Null or QoS data frame containing a CAS (command and status) control field indicating return of the TXOP from the STA that was allocated the TXOP (or allocation interval). In the operation mode of Co-TDMA, the TXOP return method for TXS mode = 1 (in EHT) may not be applicable. In addition, since the QoS Null / QoS data frame including the CAS control field in the TXOP return method when TXS mode = 2 can be exchanged only between STAs associated with the AP, a new TXOP return method between APs for Co-TDMA needs to be defined in the operation method of Co-TDMA.

[0206] Accordingly, the present disclosure provides a method and device for returning TXOPs between APs for efficient Co-TDMA operation. For example, the present disclosure provides a method and device for a DAP to return a TXOP allocated from a SAP. For example, according to various embodiments of the present disclosure, instruction information indicating whether the return of a TXOP shared by a SAP is required may be defined, and unnecessary TXOP returns may be prevented by utilizing the instruction information. For example, in the present disclosure, a frame type for TXOP return is defined, and the present disclosure provides a method for solving a hidden node problem that may occur when returning a TXOP and / or a channel clear assessment (CCA) method for securing a remaining TXOP after returning a TXOP (and a device for implementing the methods).

[0207] The TXOP return method proposed in this disclosure allows the DAP to return the TXOP to the SAP, which can then occupy the medium again to perform additional frame exchanges.

[0208] The specific designations (names) proposed in the present invention may be changed and are not limited.

[0209] The specific designations / names proposed in this disclosure may be changed and are not limited thereto.

[0210] FIG. 20 illustrates an example of a method performed by a first AP for TXOP return in a multi-AP cooperative environment according to an embodiment of the present disclosure. The first AP may be a DAP, and the second AP may be a SAP.

[0211] Referring to FIG. 20, in step S2001, the first AP can perform a negotiation procedure for multi-AP cooperation with the second AP.

[0212] In step S2003, the first AP may receive a TXOP shared frame including information about an allocated section within a TXOP section from the second AP.

[0213] In step S2005, the first AP can perform frame exchange with an STA (station) associated with the first AP in the allocated section.

[0214] In step S2007, upon completion of frame exchange, the first AP may transmit a TXOP return frame including a TXOP return notification to the second AP.

[0215] According to various embodiments, a first AP may receive a TXOP return indication from a second AP, the TXOP return indication including at least one bit or field indicating that a TXOP return is required in multi-AP cooperation. A TXOP return frame may be transmitted based on the TXOP return indication.

[0216] According to various embodiments, the TXOP return instruction may be received via at least one of a beacon frame received from the second AP, a frame received from the second AP in a negotiation procedure, an initial control frame received from the second AP to indicate that cooperation is about to begin or to exchange additional cooperation-related information (i.e., an initial control frame), or a TXOP shared frame.

[0217] According to various embodiments, the TXOP return frame may be transmitted without the first AP receiving a TXOP return instruction from the second AP.

[0218] According to various embodiments, frame exchange may be completed upon expiration of the allocation interval. A TXOP return frame may be transmitted upon expiration of the allocation interval.

[0219] According to various embodiments, the frame exchange may be completed before the allocation interval expires. The TXOP return frame may be transmitted upon completion of the frame exchange before the allocation interval expires. When the TXOP return frame is transmitted, the first AP may release or truncate the occupied channel.

[0220] According to various embodiments, the TXOP return notification may include at least one bit or field indicating a TXOP return in multi-AP cooperation.

[0221] According to various embodiments, the TXOP return frame may be a contention-free (CF) end frame. The TXOP return notification may be associated with the receiver address (RA) field of the CF end frame, which is set to the address of the second AP.

[0222] According to various embodiments, the TXOP return frame may be a multi-user request to send (MU-RTS) trigger frame. The TXOP return notification may be associated with: i) a user information field of the MU-RTS trigger frame including information of a second AP; ii) a receiver address (RA) field of the MU-RTS trigger frame set to an address of the second AP and an association identifier (AID) field of the MU-RTS frame set to an arbitrary value; or iii) a special user information field of the MU-RTS trigger frame including information of the second AP. The information of the second AP may include at least one of an AID of the second AP or an AP ID of the second AP allocated for multi-AP cooperation.

[0223] According to various embodiments, the TXOP return frame may be a block acknowledgment request (BAR) frame. The TXOP return notification may include (or be associated with) at least one of: a BSSID (basic service set identifier), a BSS color, or a receiver address (RA) field of a BAR frame set to an address of the second AP; an AID of the second AP; or an AP ID of the second AP allocated for multi-AP cooperation.

[0224] According to various embodiments, the TXOP return frame may be a management frame including an A (aggregated)-Control field. The TXOP return notification may be associated with a CIR (coordination information report) control field or a CAS (command and status) control field with the RDG (reserve direction grant) / More PPDU field set to 0.

[0225] According to various embodiments, the TXOP return frame may include an action frame related to the management frame. The TXOP return notification may be included in the action field of the action frame.

[0226] According to various embodiments, the TXOP return frame may be a BSRP (buffer status report poll) trigger frame. The TXOP return notification may be related to: i) a user information field of a BSRP trigger frame including information of a second AP; ii) a receiver address (RA) field of the BSRP trigger frame set to an address of the second AP and an association identifier (AID) field of the MU-RTS frame set to an arbitrary value; or iii) a special user information field of the BSRP trigger frame including information of the second AP. The information of the second AP may include at least one of an AID of the second AP or an AP ID of the second AP allocated for multi-AP cooperation.

[0227] According to various embodiments, the TXOP return frame may be a multi-STA block acknowledgment (BA) frame. The TXOP return notification may include (or be associated with) at least one of: a receiver address (RA) field of the multi-STA BA frame set to the address of the second AP; an AID of the second AP; or an AP ID of the second AP allocated for multi-AP cooperation.

[0228] FIG. 21 illustrates an example of a method performed by a second AP for TXOP return in a multi-AP cooperative environment according to an embodiment of the present disclosure. The first AP may be a DAP, and the second AP may be an SAP.

[0229] Referring to FIG. 21, in step S2101, the second AP can perform a negotiation procedure for multi-AP cooperation with the first AP.

[0230] In step S2103, the second AP may transmit a TXOP shared frame including information about an allocated section within a TXOP section to the first AP.

[0231] Upon completion of frame exchange of the first AP in the allocation section in step S2105, the second AP can receive a TXOP return frame including a TXOP return notification from the first AP.

[0232] In step S2107, the second AP may perform frame exchange with an STA (station) associated with the second AP in the remaining TXOP interval after receiving a TXOP return frame within the TXOP interval.

[0233] According to various embodiments, the remaining TXOP interval may include: i) a time interval after the allocation interval, based on which frame exchange was completed upon expiration of the allocation interval; and ii) a time interval after the allocation interval and a time interval after receiving a TXOP return frame within the allocation interval, based on which frame exchange was completed before expiration of the allocation interval.

[0234] Below, a detailed implementation for TXOP return in a multi-AP cooperative environment is described.

[0235] The present disclosure provides a method and device for returning a TXOP provided by a SAP to a DAP (or for the DAP to return a TXOP provided by the SAP) in a multi-AP cooperation environment (e.g., a Co-TDMA environment). Specifically, when sharing a TXOP, the SAP can indicate the necessity of returning a TXOP, indicating whether the DAP should return the TXOP within the time period (e.g., an allocation period) shared by the SAP. In addition, a method / device for returning a TXOP that the DAP can perform based on the TXOP return instruction is provided. Alternatively, without a separate TXOP return instruction, the DAP may be configured (in advance) to necessarily return a TXOP in Co-TDMA operation, or may be configured (in advance) to perform a TXOP return depending on AP selection / implementation. If TXOP return must be performed without a separate TXOP return instruction, the DAP may perform the TXOP return procedure presented in “II. TXOP return procedure for Co-TDMA” instead of performing the TXOP return method presented in “I. TXOP return instruction-based TXOP return method for Co-TDMA” below.

[0236] The TXOP return method / device for Co-TDMA proposed in the present disclosure can be defined / designed as follows.

[0237] I. TXOP Return Instruction-Based TXOP Return Method for Co-TDMA

[0238] A method is proposed for the SAP to instruct the DAP to perform a TXOP return in the Co-TDMA procedure. Specifically, in the TXOP sharing procedure, the SAP can instruct the DAP whether a TXOP return is required.

[0239] I-1. Method of returning a TXOP instruction using or based on an existing field.

[0240] In order to indicate whether a SAP requires a TXOP return in a Co-TDMA procedure, the “TXOP Return Support In Triggered TXOP Sharing Mode 2” field in EHT TXS may be utilized to indicate support for TXOP return. For example, beacon frames periodically transmitted by APs and / or frames transmitted / received in a multi-AP set setup procedure for multi-AP cooperation (or a multi-AP negotiation procedure) (e.g., cooperation request frame / cooperation response frame / trigger frame / frame related to TB PPDU) may include a field (e.g., TXOP Return Support In Triggered TXOP Sharing Mode 2 field) indicating whether a TXOP return is required in a Co-TDMA procedure. Accordingly, such an indication of whether a TXOP return is required may be delivered in a long-term interval. For example, in a UHR MAC Capabilities Information field that may be newly defined in UHR. The TXOP Return Support In Triggered TXOP Sharing Mode 2 field included in the EHT Capability Information field may be reused. In this case, if a new TXOP sharing mode (i.e., TXS mode) is defined for the TXOP sharing procedure in Co-TDMA, a new field (e.g., TXOP Return Support In Triggered TXOP Sharing Mode 3 field) based on the TXOP Return Support In Triggered TXOP Sharing Mode 2 field may be defined, or the name of the TXOP Return Support In Triggered TXOP Sharing Mode 2 field may be changed and utilized.

[0241] For example, the field that SAP uses to indicate to the DAP that a TXOP return is required can be defined as the “TXOP Return Support In Triggered TXOP Sharing Mode” field.

[0242] The TXOP Return Support In Triggered TXOP Sharing Mode field may indicate that the DAP supports transmitting frames with the RA field set to the address of the SAP within the time allocated to the DAP (e.g., allocation window) in a particular TXS mode, and / or that the DAP must transmit frames with the RA field set to the address of the SAP within the time allocated to the DAP (e.g., allocation window), and / or that the DAP must transmit frames containing information about the SAP (e.g., the AID of the SAP and / or a new AID defined for multi-AP cooperation) within the time allocated to the DAP (e.g., allocation window), and / or that the DAP must transmit frames for returning TXOPs within the time allocated to the DAP (e.g., allocation window).

[0243] For example, the TXOP Return Support In Triggered TXOP Sharing Mode field may contain one bit indicating whether TXOP return is supported or requested. Bit 0 may indicate that the DAP is not required to perform TXOP return within the allocated time (e.g., allocation window). Bit 1 may indicate that the DAP may or must perform TXOP return within the allocated time (e.g., allocation window).

[0244] Therefore, when an AP participating in multi-AP cooperation receives a frame with the TXOP Return Support In Triggered TXOP Sharing Mode field set to 1 from a SAP during Co-TDMA operation (e.g., a beacon frame / cooperation request frame / cooperation response frame / trigger frame / frame related to TB PPDU), it can perform TXOP return after completing frame exchange within the allocated time (or allocated interval).

[0245] I-2. TXOP Return Instruction Method Utilizing or Based on New Fields

[0246] In addition to utilizing the TXOP Return Support In Triggered TXOP Sharing Mode 2 field in EHT TXS to indicate support for TXOP return, a new field may be defined to indicate whether TXOP return is required in a Co-TDMA procedure. For example, the MU-RTS TXS TF (or a new type of TF) that a SAP may send to a DAP for TXOP sharing may include a new field indicating whether TXOP return is required. This new field may be defined by utilizing a reserved bit in the common information field, the user information field, or the special user information field in the MU-RTS TXS TF (or a new type of TF). For example, if a new field indicating whether a TXOP return is required is included in the common information field or the special user information field of a trigger frame (e.g., MU-RTS TXS TF, a new type of TF), STAs / APs receiving the trigger frame can identify whether a TXOP return is required through the new field. As another example, if a new field indicating whether a TXOP return is required is included in the user information field of a trigger frame (e.g., MU-RTS TXS TF, a new type of TF), only the DAP associated with the user information field can identify whether a TXOP return is required through the new field.

[0247] For example, a new field that indicates to the DAP whether a SAP is required to return a TXOP can be defined as a “TXOP Return Request” field. The TXOP Return Request field can indicate that it is supported for the DAP to transmit frames with the RA field set to the SAP’s address within the allocated time (e.g., allocation window) for a particular TXS mode, and / or that the DAP must transmit frames with the RA field set to the SAP’s address within the allocated time (e.g., allocation window), and / or that the DAP must transmit frames containing information about the SAP (e.g., the SAP’s AID and / or a new AID defined for multi-AP cooperation) within the allocated time (e.g., allocation window), and / or that the DAP must transmit frames for returning a TXOP within the allocated time (e.g., allocation window).

[0248] For example, the TXOP Return Request field may include one bit indicating whether TXOP return is supported and / or required. Bit 0 may indicate that the DAP is not required to perform TXOP return within the allocated time (e.g., allocation window). Bit 1 may indicate that the DAP may or must perform TXOP return within the allocated time (e.g., allocation window).

[0249] Therefore, when an AP participating in multi-AP cooperation receives a frame with the TXOP return request field set to 1 from the SAP during Co-TDMA operation, the AP can perform TXOP return after completing frame exchange within the allocated time (e.g., allocated interval).

[0250] The TXOP return method based on the TXOP return instruction for Co-TDMA can be specifically performed as follows. First, after the SAP shares the TXOP with the DAP during Co-TDMA operation, depending on whether there are any remaining TXOPs, the SAP can indicate whether TXOP return is necessary based on the TXOP return instruction method described above.

[0251] If SAP has no remaining TXOPs (i.e., the TXOPs acquired by SAP after sharing TXOPs with DAPs have expired), the fields indicating whether TXOP return is required (e.g., the TXOP Return Support In Triggered TXOP Sharing Mode field and the TXOP Return Request field) can have a value of 0. A DAP that has been instructed that TXOP return is not required can perform the following actions:

[0252] Case 1) When frame exchange is completed without leaving the allocated time (e.g. allocated interval)

[0253] Since the frame exchange is completed without leaving any allocated time (e.g., allocation interval), the DAP may not perform any additional procedures.

[0254] Case 2) If the frame exchange is completed early, leaving the allocated time (e.g., allocated interval)

[0255] If a frame exchange is completed prematurely before the allocated time (e.g., allocation interval) expires, the DAP may have remaining TXOPs. If the remaining TXOP time is relatively short, the DAP may do nothing during the remaining TXOP time and wait for the allocated time (e.g., allocation interval) to expire (case 2-1). If the remaining TXOP time is determined to be long enough to perform another frame exchange, the DAP may transmit a frame for returning the TXOP (e.g., a CF-End frame) and release / truncate the channel / medium in use. To this end, an exception rule can be defined for a DAP allocated time within the TXOP interval to transmit a frame for returning the TXOP (e.g., a CF-End frame) to the SAP. Therefore, in situations where the SAP does not have remaining TXOPs and thus no TXOP return is required, the DAP may avoid performing unnecessary TXOP returns.

[0256] Alternatively, if there are remaining TXOPs in the SAP (i.e., after sharing a TXOP with the DAP, the TXOP can be returned from the DAP to perform additional frame exchanges), the fields indicating whether a TXOP return is required (e.g., the TXOP Return Support In Triggered TXOP Sharing Mode field, the TXOP Return Request field) can have a value of 1. The SAP and / or the DAP that has been instructed that a TXOP return is required can perform the following actions:

[0257] Case 3) When frame exchange is completed without leaving the allocated time (e.g. allocated interval)

[0258] If a frame exchange is completed before the allocated time (e.g., allocation interval) expires (or just before the allocated time (e.g., allocation interval) expires), the SAP may initiate an individual frame exchange of the SAP after the DAP transmits the last PPDU and the PIFS (case 3-1). That is, if the DAP does not transmit a PPDU during the PIFS at or before the end of the allocated time, the SAP immediately initiates an individual frame exchange.

[0259] Alternatively, when sharing a TXOP with a DAP, the SAP may allocate a time period that includes a time for TXOP return (e.g., a time period for transmitting a TXOP return frame), and the DAP may terminate the allocated time period by performing the TXOP return procedure (case 3-2). In other words, the DAP can always perform the TXOP return procedure when the allocated time period ends. The specific TXOP return procedure is described in “II. TXOP Return Procedure for Co-TDMA” below.

[0260] Case 4) If the frame exchange is completed early, leaving the allocated time (e.g., allocated interval)

[0261] If the frame exchange is completed early, i) if the remaining TXOP time is relatively short, the DAP may do nothing during the remaining TXOP time and wait for the allocated time (e.g., allocation interval) to expire. ii) if the remaining TXOP time is determined to be long enough to perform another frame exchange, the DAP may perform a TXOP handover procedure. The specific TXOP handover procedure is described in “II. TXOP Handover Procedure for Co-TDMA” below.

[0262] Alternatively, if no frame / PPDU is transmitted from the DAP for a certain period of time (e.g. PIFS, DIFS, EIFS) within the allocated time with a separate TXOP return instruction from the SAP (or without a separate TXOP return instruction), the SAP may recover the allocated time based on the CCA result, which may be considered as a forced TXOP return mode or method. This (forced) TXOP return method by the SAP may be implemented immediately after TXOP sharing or when the allocated time expires.

[0263] II. TXOP Return Procedure for Co-TDMA

[0264] II-1. TXOP Return Procedure Using CF-End Frame

[0265] FIG. 22 illustrates an example of a TXOP return procedure using a CF-End frame according to an embodiment of the present disclosure.

[0266] Referring to FIG. 22, the DAP may perform a TXOP return procedure by transmitting a CF (contention free)-End frame when the frame exchange is completed. For example, the DAP may perform the TXOP return procedure for cases 3) and / or 4) in “I. TXOP Return Indication-Based TXOP Return Method for Co-TDMA”. The DAP may transmit a CF-End frame containing the address of the SAP in the RA field to the SAP for TXOP return, and the SAP, which receives the CF-End frame containing the address of the SAP in the RA field, may receive the CF-End frame and initiate individual frame exchange immediately after SIFS or PIFS for smooth Co-TDMA operation. At this time, the BSSID field of the CF-End frame may include the BSSID of the DAP, the BSS color, or the address of the DAP.

[0267] Alternatively, the TXOP return procedure using the CF-End frame can be performed according to the TXOP return rule in Co-TDMA or the selection of DAP without a separate TXOP return instruction from SAP.

[0268] Based on the TXOP return method as above, the SAP that received the TXOP can perform individual frame exchange during the remaining TXOP period, and / or perform additional operations (e.g. (EHT) TXS, Co-TDMA) with other STAs / APs.

[0269] II-2. TXOP Return Procedure Using MU-RTS TXS TF and CTS Frames

[0270] FIG. 23 illustrates an example of a TXOP return procedure using MU-RTS TXS TF and CTS frames according to an embodiment of the present disclosure.

[0271] Referring to FIG. 23, when the DAP completes the FE, the DAP may perform a TXOP return by transmitting an MU-RTS TXS TF frame. For example, the DAP may perform the TXOP return procedure for cases 3) and / or 4) in “I. TXOP Return Indication-Based TXOP Return Method for Co-TDMA”. The DAP may transmit the MU-RTS TXS TF with information of the SAP (e.g., the AID of the SAP and / or a new AID / AP ID defined for multi-AP cooperation) included in the user information field. Alternatively, if the RA field of the MU-RTS TXS TF is set to the address of the SAP, the value of the AID field may be set arbitrarily. Alternatively, the DAP may transmit the MU-RTS TXS TF with information of the SAP included in the special user information field. The MU-RTS TXS TF at this time may be defined as a new mode (e.g., mode 3) or a new type of trigger frame may be defined. The SAP that received the frame transmitted from the DAP may be (pre-)configured to respond with a CTS frame (or CTS-to-Self frame) and start an individual frame exchange immediately after SIFS or PIFS. In addition, the STAs / APs that received the MU-RTS TXS TF for TXOP return may be (pre-)configured to reset the NAV for the TXOP holder. The RA field (or TA field) of the CTS frame (or CTS-to-Self frame) at this time may include the address information of the SAP. If the corresponding CTS frame is not received from the SAP until the CTS timeout expires, the DAP may terminate (or truncate) the allocated TXOP (or the allocated time / allocation interval) by transmitting a CF-End frame.

[0272] Alternatively, the TXOP return procedure using MU-RTS TXS TF and CTS frames can be performed according to the TXOP return rules in Co-TDMA or the selection of DAP without a separate TXOP return instruction from SAP.

[0273] Based on the TXOP return method as above, the SAP that received the TXOP can perform individual frame exchange during the remaining TXOP period, and / or perform additional operations (e.g. (EHT) TXS, Co-TDMA) with other STAs / APs.

[0274] II-3. TXOP Return Procedure Using (MU-)BAR (Trigger) Frame and BA Frame

[0275] FIG. 24 illustrates an example of a TXOP return procedure using a BAR frame and a BA frame according to an embodiment of the present disclosure.

[0276] Referring to FIG. 24, the DAP can perform TXOP return by transmitting a (MU-)BAR (block acknowledgment request) trigger frame when completing the FE. For example, the DAP can perform the TXOP return procedure for case 3) and / or case 4) in “I. TXOP return instruction-based TXOP return method for Co-TDMA”, and / or perform TXOP return according to the TXOP return rule in Co-TDMA or the DAP’s choice without a separate TXOP return instruction from the SAP.

[0277] The RA field of the (MU-)BAR (trigger) frame transmitted by the DAP may include the BSSID, BSS color, or MAC address of the SAP. A new field (or signaling bit) may be defined and / or added to the (MU-)BAR (trigger) frame at this time to indicate that it is used for the purpose of TXOP return in Co-TDMA. An SAP that receives a (MU-)BAR (trigger) frame transmitted from a DAP may be (pre-)configured to respond with a BA frame and start individual frame exchange immediately after an SIFS or PIFS. In addition, STAs that receive the (MU-)BAR (trigger) frame and BA frame for TXOP return may be (pre-)configured to reset the NAV for the target TXOP holder. If a corresponding BA frame is not received from the SAP, the DAP may retransmit a (MU-)BAR (trigger) frame or terminate the allocated TXOP (or allocated time / allocation interval) by sending a CF-End frame.

[0278] Based on the TXOP return method as above, the SAP that received the TXOP can perform individual frame exchange during the remaining TXOP period, and / or perform additional operations (e.g. (EHT) TXS, Co-TDMA) with other STAs / APs.

[0279] II-4. TXOP Return Procedure Using a Management Frame Containing the A-Control Field

[0280] FIG. 25 illustrates an example of a TXOP return procedure using a management frame including an A-Control field according to an embodiment of the present disclosure.

[0281] Referring to Fig. 25, the DAP can perform a TXOP return procedure using a management frame containing an A-Control field when completing frame exchange. For example, the DAP can perform the TXOP return procedure for cases 3) and / or 4) in “I. TXOP Return Indication-Based TXOP Return Method for Co-TDMA”, and / or perform TXOP return according to the TXOP return rules in Co-TDMA or the DAP’s choice without a separate TXOP return instruction from the SAP.

[0282] A new type of control information field may be defined by utilizing reserved control ID values ​​(e.g., control ID values ​​7-14) in the control ID field of a management frame based on the A-Control field. For example, a new type of control information field may be defined for reporting a TXOP return (or including information for reporting Co-TDMA operation related information). In the present disclosure, the above-described new type of control information field (or control field) may be referred to as a CIR (Coordination Information Report) control field. The new type of CIR control field may include a field of elements based on one or more combinations, and may include a signaling bit / type field indicating that it has been transmitted for the purpose of TXOP return. The name of the field may be changed, and elements for Co-TDMA operation may be added.

[0283] Additionally or alternatively, the CAS control field, which is a HE variant of the HT control field, may be utilized. For example, similar to the TXOP return procedure in TXOP sharing of EHT, an AP (or STA) returning a TXOP may transmit a management frame including a HE variant HT control field including a CAS control field with the reserve direction grant (RDG) / More PPDU field set to 0 based on an indication that TXOP return is allowed or required (e.g., a TXOP return indication). As another example, an AP (or STA) returning a TXOP may transmit a management frame including a HE variant HT control field including a CAS control field with the reserve direction grant (RDG) / More PPDU field set to 0 regardless of an indication that TXOP return is allowed or required (e.g., a TXOP return indication). At this time, if the purpose is not TXOP return, the AP (or STA) may be (pre-)configured not to transmit a frame for signaling TXOP return as described above (e.g., a management frame including a HE variant HT control field including a CAS control field with the RDG (reserve direction grant) / More PPDU field set to 0).

[0284] Additionally, STAs / APs that receive management frames and / or BA frames for TXOP return may be (pre-)configured to reset NAV for the target TXOP holder, and / or information for signaling NAV reset may be added to the management frames and / or BA frames for TXOP return.

[0285] Based on the TXOP return method as above, the SAP that received the TXOP can perform individual frame exchange during the remaining TXOP period, and / or perform additional operations (e.g. (EHT) TXS, Co-TDMA) with other STAs / APs.

[0286] II-5. TXOP Return Procedure Using a New Management Frame

[0287] FIG. 26 illustrates an example of a TXOP return procedure using a management frame, which is an action frame, according to an embodiment of the present disclosure.

[0288] Referring to FIG. 26, the DAP can perform TXOP return by transmitting a newly defined management frame when completing the FE. For example, the DAP can perform the TXOP return procedure for case 3) and / or case 4) in “I. TXOP Return Indication-Based TXOP Return Method for Co-TDMA”, and / or perform TXOP return according to the TXOP return rule in Co-TDMA or the DAP’s choice without a separate TXOP return indication from the SAP. The DAP can transmit a management frame, which is a newly defined action frame, for TXOP return. Since a general management frame has a large frame size, using an action frame has the advantage of reducing overhead in terms of frame size.

[0289] According to an embodiment, a new action frame (i.e., a type of management frame) may be defined. Similar to the newly defined EHT action frame and / or protected EHT action frame in EHT (IEEE standard 802.11be), a UHR action frame and / or a protected UHR action frame may be defined in UHR (IEEE standard 802.11bn). That is, an action frame for returning a TXOP in Co-TDMA (or conveying Co-TDMA operation related information) may be defined as one of the values ​​of the action field of the UHR action frame and / or the protected UHR action frame.

[0290] Additionally or alternatively, a common action frame for multi-AP cooperation can be newly defined using reserved values ​​(e.g., 54-59, 61-255) of the public action frame. For example, the action frame can include elements / fields containing common information required for multi-AP cooperation and / or elements / fields containing information separately required depending on the multi-AP cooperation method (e.g., Co-SR, Co-BF, Co-TDMA).

[0291] Additionally or alternatively, a new action frame for Co-TDMA can be defined using reserved values ​​(e.g., 54-59, 61-255) of the public action frame. For example, the action frame can include elements / fields containing general information for Co-TDMA and / or elements / fields for indicating / distinguishing specific procedures (e.g., TXOP sharing procedure / time allocation procedure / multi-AP selection procedure / schedule announcement / TXOP return).

[0292] For example, a public action frame for a TXOP return procedure may include a field / bit indicating that the public action frame was transmitted for a TXOP return (e.g., TXOP Return Indication / Notification).

[0293] Additionally, in the TXOP return procedure, a field indicating why / reason the STA / AP transmitted the (public) action frame for returning the TXOP may be defined and added to the (public) action frame. For example, the reason / reason for transmitting the (public) action frame for returning the TXOP may include at least one of: no buffered data / traffic; all allocated time has been used; no time allocation is required; rescheduling; and a specific event (e.g., IDC, power saving, NPCA (non-primary channel access)) occurring within the allocated time, causing the allocated time to be returned.

[0294] The Action field of the (public) action frame may contain information based on at least one (or a combination thereof) of A, B, or C below. The names of A, B, and C may be changed, and other information than A, B, and C may be additionally included in the Action field, but is not limited thereto. In addition, STAs / APs that receive the management frame and / or the (public) action frame for TXOP return may be (pre-)configured to reset the NAV for the target TXOP holder, and / or the management frame and / or the (public) action frame for TXOP return may be supplemented with information for signaling the NAV reset.

[0295] A. Category: A value indicating a category field defined in the action field of an action frame among management frames. For example, information A may be a value indicating an EHT action frame or a protected EHT action frame among the 1-byte category fields. Specifically, information A may be a value indicating a UHR Action frame or a protected UHR action frame that may be newly defined in UHR.

[0296] B. UHR Action (or) Protected UHR Action: It can indicate an action to be performed with the frame. For example, information B can be a value indicating a link reconfiguration notify frame among the 1-byte action field in the Protected EHT Action frame. Specifically, a Co-TDMA operation frame can be newly defined among the 1-byte action field in the UHR Action frame or the Protected UHR Action frame that can be newly defined in UHR, and information B can indicate the Co-TDMA operation frame. Alternatively, a TXOP return frame can be newly defined among the 1-byte action field in the UHR Action frame or the Protected UHR Action frame that can be newly defined in UHR, and information B can indicate the TXOP return frame.

[0297] C. TXOP Return Request / Report: A value indicating a frame for TXOP return. Information C can use one bit to indicate that the frame is for TXOP. For example, bit 0 can indicate that the frame is not for TXOP return, and bit 1 can indicate that the frame is for TXOP return.

[0298] Based on the TXOP return method as above, the SAP that received the TXOP can perform individual frame exchange during the remaining TXOP period, and / or perform additional operations (e.g. (EHT) TXS, Co-TDMA) with other STAs / APs.

[0299] II-6. TXOP Return Procedure Using BSRP TF and TB PPDU

[0300] FIG. 27 illustrates an example of a TXOP return procedure using BSRP TF and TB PPDU (or non-TB PPDU) according to an embodiment of the present disclosure.

[0301] Referring to Fig. 27, when the DAP completes the FE, it can perform the TXOP return procedure by transmitting a BSRP (buffer status report poll) TF. For example, the DAP can perform the TXOP return procedure for cases 3) and / or 4) in “I. TXOP Return Indication-Based TXOP Return Method for Co-TDMA”. The DAP can transmit the BSRP TF with the SAP’s information (e.g., the SAP’s AID and / or a new AID defined for multi-AP cooperation) included in the user information field. Alternatively, the DAP can transmit the BSRP TF with the SAP’s information included in the special user information field. The SAP, which receives the frame transmitted from the DAP, can be (pre-)configured to respond with a TB PPDU (or non-TB PPDU) and start an individual frame exchange immediately after an SIFS or PIFS. Additionally, STAs / APs that receive a BSRP TF for TXOP return can be (pre-)configured to reset the NAV for the TXOP holder.

[0302] Alternatively, the TXOP return procedure using BSRP TF and TB PPDU (or non-TB PPDU) can be performed according to the TXOP return rule in Co-TDMA or the selection of DAP without a separate TXOP return instruction from SAP.

[0303] Based on the TXOP return method as above, the SAP that received the TXOP can perform individual frame exchange during the remaining TXOP period, and / or perform additional operations (e.g. (EHT) TXS, Co-TDMA) with other STAs / APs.

[0304] II-7. TXOP Return Procedure Using Multi-STA BA Frames

[0305] FIG. 28 illustrates an example of a TXOP return procedure using multiple STA BA frames according to an embodiment of the present disclosure.

[0306] Referring to FIG. 28, when the DAP completes frame exchange, if there is still allocated time (or allocated interval) remaining and / or if the SAP instructs / requests a separate TXOP return procedure and / or if the TXOP return procedure is essential, the DAP may perform the TXOP return procedure by transmitting a multi-STA BA (blockAck) frame. For example, the DAP may perform the TXOP return procedure for one or more of the cases in “I. TXOP Return Indication-Based TXOP Return Method for Co-TDMA”. The DAP may transmit a multi-STA BA frame containing the address of the SAP in the RA field to the SAP for TXOP return, and the SAP that receives the multi-STA BA frame containing the address of the SAP in the RA field may be (pre-)configured to receive the multi-STA BA frame and start individual frame exchange immediately after SIFS or PIFS for smooth Co-TDMA operation. At this time, the AID11 field of the multi-STA BA frame may contain 0, 2045, or an ID (e.g., AP ID) for AP identification (which may be newly defined for multi-AP cooperation).

[0307] Alternatively, the TXOP return procedure using multi-STA BA frames can be performed according to the TXOP return rules in Co-TDMA or the selection of DAP without a separate TXOP return instruction from SAP.

[0308] Based on the TXOP return method as above, the SAP that received the TXOP can perform individual frame exchange during the remaining TXOP period, and / or perform additional operations (e.g. (EHT) TXS, Co-TDMA) with other STAs / APs.

[0309] III. Hidden node problem when returning TXOP

[0310] When a DAP returns a TXOP, a hidden node problem may occur. The DAP can transmit a frame for TXOP return based on various TXOP return procedures described in “II. TXOP Return Procedures for Co-TDMA.” Except for cases 1) and 3) in “I. TXOP Return Indication-Based TXOP Return Method for Co-TDMA,” TXOP return for Co-TDMA can be considered a situation in which the allocated time is returned early. In this case, some STAs associated with a SAP (i.e., a hidden node relationship with the DAP) whose NAV is set by the STA associated with the DAP may not be able to reset the default NAV set by the STA associated with the DAP and may not be able to perform FE with the SAP during the remaining TXOP. Additionally, OBSS (overlapping BSS) STAs (i.e., STAs / APs that do not participate in multi-AP cooperation and / or do not share or receive TXOPs) whose NAVs are set by STAs connected to a DAP may also not receive frames for TXOP return transmitted from the DAP and maintain NAVs for the remaining allocated interval, which may result in a decrease in medium utilization.

[0311] To address this, during the allocated time (or allocated interval), DAP can set separate, shorter intervals for individual FE processes, rather than setting a single duration for the entire FE process.

[0312] FIG. 29 illustrates an example of setting an interval field to prevent a hidden node problem when returning a TXOP according to an embodiment of the present disclosure.

[0313] Referring to Fig. 29, in order to prevent the hidden node problem when returning TXOP, the DAP can set the value of the interval field of the frame transmitted in the allocated interval to an appropriate value. For example, during the time allocated from the SAP (e.g., allocated interval), when the DAP performs FE with STAs within its BSS (i.e., BSS 2), the interval field of the frame can be set to the entire interval required to perform FE within the BSS (i.e., ), and a separate section for performing individual FE (i.e., , , ..., ) can be set. In other words, as in Fig. 29, DAP provides a separate short interval (i.e., , , ..., ) can be used to perform FE by transmitting a frame with the value of the interval field set to . Therefore, since the DAP performs FE for each individual interval, the NAV problem due to the remaining allocated interval can be prevented. The DAP can complete the individual FEs and then transmit a frame for TXOP return. Alternatively, the DAP can set the value of the interval field of the frame transmitted in the allocated time (or allocated interval) to the interval from the first frame transmitted within the allocated time (or allocated interval) to the interval for transmitting the TXOP return frame.

[0314] IV. CCA method for remaining TXOP after TXOP return

[0315] According to an embodiment of the present disclosure, a SAP (or TXOP holder / owner) may perform CCA (e.g., energy detection (ED), carrier sensing (CS)) to fully / successfully use the remaining TXOP interval after the TXOP is returned. Each primary channel may exist within the BSS operating channel width of the SAP and the DAP, and the primary channels may be different. Additionally or alternatively, the primary channels of the SAP and the DAP may be the same. In addition, the BSS operating channel widths of the SAP and the DAP may be different. For example, the bandwidth (BW) of the SAP may be 160 MHz, and the BW of the DAP may be 80 MHz. Since the SAP does not perform FE during the time allocated to the DAP by the SAP, some STAs that were in doze state and then changed to awake state may occupy a channel corresponding to the BSS operating channel width of the SAP due to blindness issue, which may cause the SAP to not obtain the remaining TXOP. Therefore, the SAP that receives a frame for TXOP return from the DAP (e.g., CF-End frame, MU-RTS TXS TF, (MU-)BAR (trigger) frame, management frame, BSRP TF) needs to perform CCA before performing frame exchange in the remaining TXOP interval.

[0316] In various embodiments, CCA may be based on, but is not limited to, Mode 1 (ED only), Mode 2 (CS only), Mode 3 (ED and / or CS).

[0317] IV-1. Without backoff

[0318] The SAP may perform CCA on its own BSS operating channel width immediately after receiving a frame for TXOP return transmitted from the DAP (e.g., CF-End frame, MU-RTS TXS TF, (MU-)BAR (trigger) frame, management frame, BSRP TF). Alternatively, the SAP may perform CCA only on channels that do not overlap with the DAP's BSS operating channel width.

[0319] FIG. 30 illustrates a first example of a CCA procedure that does not perform backoff after TXOP return according to an embodiment of the present disclosure.

[0320] Referring to Fig. 30, a SAP that receives a TXOP return frame (e.g., CF-End frame, MU-RTS TXS TF, (MU-)BAR (trigger) frame, management frame, BSRP TF) transmitted for TXOP return can utilize the remaining TXOP interval by performing CCA (e.g., ED / CS) without a separate backoff. In Fig. 30, it is assumed that the SAP has a BSS operating channel width of 160 MHz, but the channel width overlapping with the DAP (i.e., the overlapped / common channel width) is 80 MHz.

[0321] Option 1) A SAP that receives a TXOP return frame transmitted for TXOP return can perform CCA during SIFS (or PIFS) on non-overlapping channels. That is, the channels on which CCA is performed are limited to channels on which SAP and DAP do not overlap. This allows the SAP to perform individual FE in the bandwidth containing the channel if the non-overlapping channel is determined to be idle, and / or perform additional operations (e.g., (EHT) TXS, Co-TDMA) with other STAs / APs. That is, the SAP can be (pre-)configured to receive a frame for TXOP return and immediately perform individual FE in the bandwidth containing the idle channel after SIFS / PIFS.

[0322] Option 2) The SAP can perform CCA on its entire BSS operating channel width, not just on channels that do not overlap with the DAP, and perform FE (in the remaining TXOP interval) when the channel is idle. The SAP can be (pre-)configured to immediately perform individual FE in the bandwidth that includes the channel that received the frame for TXOP return and is idle after SIFS / PIFS.

[0323] Option 3) SAP may perform CCA for the PIFS period before receiving a TXOP return frame for the DAP and its entire BSS operating channel width, and may perform FE if the channel is idle for the period following the start of the remaining TXOP.

[0324] FIG. 31 illustrates a second example of a CCA procedure that does not perform backoff after TXOP return according to an embodiment of the present disclosure.

[0325] Referring to Figure 31, a SAP that receives a TXOP return frame (e.g., CF-End frame, MU-RTS TXS TF, (MU-)BAR (trigger) frame, management frame, BSRP TF) transmitted for TXOP return can utilize the remaining TXOP interval by performing CCA (e.g., ED / CS) without a separate backoff. In Figure 31, it is assumed that the SAP has a BSS operating channel width of 160 MHz, but the overlapping channel width with the DAP (i.e., the overlapped / common channel width) is 80 MHz.

[0326] Option 1) A SAP that receives a TXOP return frame transmitted for TXOP return can perform CCA for a non-overlapping channel during the period of “SIFS + CTS length + SIFS”. That is, the channels on which CCA is performed are limited to channels on which the SAP and DAP do not overlap. This allows the SAP to perform an individual FE in the bandwidth containing the channel if the non-overlapping channel is determined to be idle, and / or perform additional operations (e.g., (EHT) TXS, Co-TDMA) with another STA / AP. That is, the SAP can be (pre-)configured to receive a frame for TXOP return, respond with a corresponding response frame (e.g., CTS frame), and immediately perform an individual FE in the bandwidth containing the idle channel after SIFS from the time of the response.

[0327] Option 2) The SAP can perform CCA on its entire BSS operating channel width, not just on channels that do not overlap with the DAP, and perform FE (in the remaining TXOP interval) when the channel is idle. The SAP can be (pre-)configured to receive a frame for TXOP return, respond with a corresponding response frame (e.g., a CTS frame), and immediately perform individual FE in the bandwidth containing the idle channel after SIFS from the time of the response.

[0328] Option 3) SAP may perform CCA for the PIFS period before receiving a TXOP return frame for the DAP and its entire BSS operating channel width, and may perform FE if the channel is idle for the period following the start of the remaining TXOP.

[0329] FIG. 32 illustrates a third example of a CCA procedure that does not perform backoff after TXOP return according to an embodiment of the present disclosure.

[0330] Referring to Figure 32, a SAP that receives a TXOP return frame (e.g., CF-End frame, MU-RTS TXS TF, (MU-)BAR (trigger) frame, management frame, BSRP TF) transmitted for TXOP return can utilize the remaining TXOP interval by performing CCA (e.g., ED / CS) without a separate backoff. In Figure 32, it is assumed that the SAP has a BSS operating channel width of 160 MHz, but the overlapping channel width with the DAP (i.e., the overlapped / common channel width) is 80 MHz.

[0331] Option 1) A SAP that receives a TXOP return frame transmitted for TXOP return can perform CCA during SIFS (or PIFS) on a non-overlapping channel. That is, the channels on which CCA is performed are limited to channels on which the SAP and DAP do not overlap. This allows the SAP to transmit a response frame in the bandwidth containing the channel and perform individual FE, and / or perform additional operations (e.g., (EHT) TXS, Co-TDMA) with other STAs / APs when the non-overlapping channel is determined to be idle.

[0332] At this time, the TXVECTOR parameter CH_BANDWIDTH of the PPDU containing the response frame transmitted by the SAP (which may indicate, for example, 160 MHz) may have a value greater than the TXVECTOR parameter CH_BANDWIDTH of the PPDU containing the frame for TXOP return transmitted by the DAP (which may indicate, for example, 80 MHz). Therefore, the following rule 1) may be defined for the FE after the TXOP return in Co-TDMA:

[0333] Rule 1) In C-TDMA operation, the SAP (i.e., TXOP holder / owner) may transmit a response frame (e.g., CTS / CTS-to-self frame) to a TXOP return frame via a PPDU with the TXVECTOR parameter CH_BANDWIDTH value set to be equal to or greater than the value of the TXVECTOR parameter CH_BANDWIDTH of the non-initial PPDU containing the TXOP return frame transmitted by the DAP for TXOP return (within the allocated time).

[0334] Therefore, a SAP following Rule 1) above can receive a frame for TXOP return (i.e., a TXOP return frame) and perform CCA during SIFS / PIFS, and if the channel is determined to be idle, transmit a corresponding response frame in the bandwidth containing the channel. The SAP can transmit the response frame and perform an individual FE (in the remaining TXOP interval) after SIFS.

[0335] Option 2) The SAP can perform CCA for its entire BSS operating channel width, not just for channels that do not overlap with the DAP, and then perform FE (in the remaining TXOP interval) if the channel is idle. That is, the SAP can perform CCA for SIFS / PIFS for a bandwidth corresponding to the SAP's entire BSS operating channel width, then transmit a response frame in that bandwidth, and then perform FE (in the remaining TXOP interval). In the case of Option 2), the SAP can also follow Rule 1) as in Option 1).

[0336] Option 3) The SAP may perform CCA for the PIFS period before receiving a TXOP return frame for the entire BSS operating channel width of the DAP and its own BSS, and may perform FE if the channel is idle during the period following the start of the remaining TXOP. In the case of Option 3), the SAP may also follow Rule 1) as in Option 1).

[0337] IV-2. When performing backoff (With backoff)

[0338] Immediately after receiving a frame for TXOP return transmitted from DAP (e.g. CF-End frame, MU-RTS TXS TF, (MU-)BAR (trigger) frame, management frame, BSRP TF), SAP can perform i) backoff for overlapped / common channel width of SAP and DAP, and ii) CCA for the remaining channels during SIFS / PIFS.

[0339] FIG. 33 illustrates a first example of a CCA procedure performing backoff after TXOP return according to an embodiment of the present disclosure.

[0340] Referring to Figure 33, the SAP that receives the TXOP return frame for TXOP return can perform backoff and CCA (e.g., ED / CS) to utilize the remaining TXOP interval. In Figure 33, it is assumed that the SAP has a BSS operating channel width of 160 MHz, but the channel width overlapping with the DAP (i.e., the overlapped / common channel width) is 80 MHz.

[0341] Upon receiving the TXOP Return frame transmitted by the DAP for TXOP return, the SAP may i) perform backoff after AIFS upon receiving the TXOP Return frame for the overlapped / common channels of the SAP and the DAP, and ii) perform CCA during SIFS / PIFS for the non-overlapping channels. The SAP may perform individual FE over the bandwidth including the channels determined to be idle based on the backoff / CCA, and / or perform additional operations (e.g., (EHT) TXS, Co-TDMA) with other STAs / APs.

[0342] FIG. 34 illustrates a second example of a CCA procedure performing backoff after TXOP return according to an embodiment of the present disclosure.

[0343] Referring to Figure 34, the SAP that receives the TXOP return frame for TXOP return transmits a response frame for the TXOP return frame and performs backoff and CCA (e.g., ED / CS) to utilize the remaining TXOP interval. In Figure 34, it is assumed that the SAP has a BSS operating channel width of 160 MHz, but the channel width overlapping with the DAP (i.e., the overlapped / common channel width) is 80 MHz.

[0344] Upon receiving a TXOP return frame transmitted by a DAP for TXOP return, a SAP may transmit a response frame for the TXOP return frame, and i) perform backoff after AIFS upon receiving the TXOP return frame for overlapped / common channels of the SAP and DAP, and ii) perform CCA during SIFS / PIFS for non-overlapping channels. The SAP may perform individual FE over the bandwidth including the channels determined to be idle based on backoff / CCA, and / or perform additional operations (e.g., (EHT) TXS, Co-TDMA) with other STAs / APs.

[0345] V. Setting PPDU bandwidth after TXOP return

[0346] When a SAP (i.e., a TXOP holder / owner) transmits a PPDU for frame exchange in the remaining TXOP interval after the TXOP is returned, how to set the bandwidth of the PPDU needs to be addressed. For example, in EHT, in TXOP sharing, there is a bandwidth rule for PPDUs transmitted by non-AP STAs within the allocated time from the AP, but no bandwidth rule is defined for PPDUs transmitted from the AP after the TXOP is returned. Therefore, PPDU bandwidth rules need to be defined for TXOP sharing situations between different BSSs that may have different BSS operating channel widths.

[0347] FIG. 35 illustrates an example of setting a PPDU bandwidth after a TXOP return in Co-TDMA according to an embodiment of the present disclosure.

[0348] Referring to Figure 35, in order to determine / set the bandwidth of a PPDU containing a frame transmitted by the SAP after the TXOP return, the SAP can determine the BW for performing CCA after the TXOP return.

[0349] For example, the SAP may determine the bandwidth value of the CCA upon return of the TXOP based on the CH_BANDWIDTH value of the PPDU containing the first frame that acquires and transmits the TXOP (e.g., the initial control frame (ICF)). The SAP may perform the CCA on a bandwidth less than or equal to the CH_BANDWIDTH value of the PPDU containing the multi-AP selection request frame, and transmit subsequent frames during the remaining TXOP interval using one or more channels that are idle as a result of the CCA.

[0350] Alternatively, the SAP can determine the bandwidth value of the CCA upon return of the TXOP based on the CH_BANDWIDTH value of the PPDU containing the MU-RTS TXS TF transmitted to the DAP to share the TXOP. The SAP can perform the CCA on a bandwidth less than or equal to the CH_BANDWIDTH value of the preceding PPDU and transmit subsequent frames during the remaining TXOP interval using one or more channels that are idle as a result of the CCA.

[0351] Alternatively, the SAP can perform CCA based on the maximum operating channel width of the SAP upon TXOP return, as described in “IV. CCA Method for Remaining TXOPs After TXOP Return”, and determine the bandwidth value of the PPDU. That is, the SAP can perform CCA on the bandwidth corresponding to the maximum bandwidth value within the BSS operating channel width of the SAP at the time of TXOP return, and transmit subsequent frames during the remaining TXOP interval using one or more idle channels resulting from the CCA.

[0352] The present disclosure provides a method and device for returning a TXOP between APs in Co-TDMA operation. According to embodiments of the present disclosure, a SAP can transmit indicator information indicating to a DAP whether a return of a shared TXOP is required, thereby preventing unnecessary TXOP return procedures from being performed. In other words, the TXOP return method of the present disclosure allows a DAP to identify whether a TXOP return is required based on a TXOP return request from the SAP, thereby increasing medium utilization and successfully performing the TXOP return procedure to the SAP. Alternatively, the TXOP return procedure can be performed according to the decision and / or implementation of the DAP without a separate instruction from the SAP.

[0353] In addition, the present disclosure provides a method and device for setting an interval field to solve a hidden node problem that may occur when returning a TXOP.

[0354] Additionally, the present disclosure provides a CCA method and device for enabling a SAP to successfully use the remaining TXOP interval after a TXOP is returned. According to the CCA method provided in the present disclosure, collisions that may occur during frame exchange after a TXOP is returned can be prevented, and the SAP can ensure that it can fully utilize its BSS operating channel width.

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

[0356] For example, the processor (121) and / or the processing chip (124) of FIG. 1 may be configured to execute instructions stored in the memory (122) to implement a method performed by the first AP in the present disclosure. The method includes: performing a negotiation procedure for multi-AP cooperation with a second AP; receiving, from the second AP, a TXOP (transmission opportunity) shared frame including information on an allocated section within a TXOP section; performing frame exchange with a STA (station) associated with the first AP in the allocated section; and upon completion of the frame exchange, transmitting, to the second AP, a TXOP return frame including a TXOP return notification.

[0357] For example, the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5 may be configured to execute instructions stored in the memory (112, 520) to implement a method performed by the second AP in the present disclosure. The method includes: performing a negotiation procedure for multi-AP cooperation with a first AP; transmitting, to the first AP, a TXOP shared frame including information about an allocated section within a TXOP (transmission opportunity) section; receiving, from the first AP, a TXOP return frame including a TXOP return notification upon completion of frame exchange of the first AP in the allocated section; and performing frame exchange with an STA (station) associated with the second AP in a remaining TXOP section after receiving the TXOP return notification within the TXOP section.

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

[0359] For example, the CRM may be the memory (122) of FIG. 1 and / or a separate external memory / storage medium / disk. The CRM may store commands for implementing a method performed by the first AP in the present disclosure based on being executed by a processor (e.g., the processor (121) and / or the processing chip (124) of FIG. 1). The method includes: performing a negotiation procedure for multi-AP cooperation with a second AP; receiving, from the second AP, a TXOP (transmission opportunity) shared frame including information on an allocated section within a TXOP section; performing frame exchange with an STA (station) associated with the first AP in the allocated section; and, upon completion of the frame exchange, transmitting, to the second AP, a TXOP return frame including a TXOP return notification.

[0360] For example, the CRM may be the memory (112) of FIG. 1, the memory (520) of FIG. 5, and / or a separate external memory / storage medium / disk. The CRM may store commands for implementing a method performed by the second AP in the present disclosure based on being executed by a processor (e.g., the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5). The method includes: performing a negotiation procedure for multi-AP cooperation with a first AP; transmitting, to the first AP, a TXOP (transmission opportunity) shared frame including information on an allocated section within a TXOP section; receiving, from the first AP, a TXOP return frame including a TXOP return notification upon completion of frame exchange of the first AP in the allocated section; And it includes a step of performing frame exchange with an STA (station) associated with the second AP in the remaining TXOP interval after receiving the TXOP return notification within the TXOP interval.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0378] For example, according to embodiments of the present disclosure, the SAP can transmit indicator information indicating to the DAP whether a return for a shared TXOP is required, thereby preventing unnecessary TXOP return procedures from being performed. In other words, the TXOP return method of the present disclosure allows the DAP to identify whether a TXOP return is required based on a TXOP return request from the SAP, thereby increasing the utilization of the medium and successfully performing the TXOP return procedure to the SAP. Alternatively, the TXOP return procedure can be performed according to the decision and / or implementation of the DAP without a separate instruction from the SAP.

[0379] In addition, in the present disclosure, the interval field of a frame transmitted in a TXOP allocation interval is set to a value corresponding to an individual frame exchange time, thereby solving a hidden node problem that may occur when returning a TXOP.

[0380] Additionally, the present disclosure provides a CCA method and device for enabling a SAP to successfully use the remaining TXOP interval after a TXOP is returned. According to the CCA method provided in the present disclosure, collisions that may occur during frame exchange after a TXOP is returned can be prevented, and the SAP can ensure that it can fully utilize its BSS operating channel width.

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

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

Claims

1. A step in which the first AP (access point) performs a negotiation procedure for multi-AP cooperation with the second AP; A step in which the first AP receives a TXOP shared frame including information about an allocated section within a TXOP (transmission opportunity) section from the second AP; A step in which the first AP performs frame exchange with an STA (station) associated with the first AP in the allocated section; and A method comprising the step of: upon completion of the frame exchange, the first AP transmitting, to the second AP, a TXOP return frame including a TXOP return notification.

2. In claim 1, the first AP further comprises a step of receiving a TXOP return indication from the second AP, the TXOP return indication including at least one bit or field indicating that a TXOP return is required in the multi-AP cooperation, The above TXOP return frame is transmitted based on the above TXOP return instruction.

3. In claim 2, the TXOP return instruction is received through at least one of a beacon frame received from the second AP, a frame received from the second AP in the negotiation procedure, or the TXOP shared frame.

4. A method according to claim 1, wherein the TXOP return frame is transmitted without the first AP receiving a TXOP return instruction from the second AP.

5. In claim 1, the frame exchange is completed upon expiration of the allocation interval, The above TXOP return frame is transmitted upon expiration of the above allocation interval.

6. In claim 1, the frame exchange is completed before the allocation interval expires, The above TXOP return frame is transmitted upon completion of the frame exchange before the expiration of the allocation interval, A method further comprising the step of releasing or truncating a channel occupied by the first AP for frame exchange for the allocated interval when the TXOP return frame is transmitted.

7. A method according to claim 1, wherein the TXOP return notification includes at least one bit or field for notifying TXOP return in the multi-AP cooperation.

8. In claim 1, the TXOP return frame is a CF (contention-free) end frame, The above TXOP return notification is a method related to the RA (receiver address) field of the CF termination frame set to the address of the second AP.

9. In claim 1, the TXOP return frame is a MU-RTS (multi-user request to send) trigger frame, The TXOP return notification is related to: i) a user information field of the MU-RTS trigger frame including information of the second AP; ii) a receiver address (RA) field of the MU-RTS trigger frame set to an address of the second AP and an association identifier (AID) field of the MU-RTS frame set to an arbitrary value; or iii) a special user information field of the MU-RTS trigger frame including information of the second AP, A method in which the information of the second AP includes at least one of the AID of the second AP or the AP ID of the second AP allocated for the multi-AP cooperation.

10. In claim 1, the TXOP return frame is a BAR (block acknowledgment request) frame, The above TXOP return notification is a method related to at least one of: a BSSID (basic service set identifier), a BSS color, or a receiver address (RA) field of the BAR frame set to an address of the second AP; an AID (association identifier) ​​of the second AP; or an AP ID of the second AP allocated for multi-AP cooperation.

11. In claim 1, the TXOP return frame is a management frame including an A(aggregated)-Control field, The above TXOP return notification is a method related to the coordination information report (CIR) control field or the command and status (CAS) control field with the reserve direction grant (RDG) / More PPDU field set to 0.

12. In claim 1, the TXOP return frame includes an action frame related to a management frame, The above TXOP return notification is included in the action field of the above action frame.

13. In claim 1, the TXOP return frame is a BSRP (buffer status report poll) trigger frame, The TXOP return notification is related to: i) a user information field of the BSRP trigger frame including information of the second AP; ii) a receiver address (RA) field of the BSRP trigger frame set to an address of the second AP and an association identifier (AID) field of the MU-RTS frame set to an arbitrary value; or iii) a special user information field of the BSRP trigger frame including information of the second AP. A method in which the information of the second AP includes at least one of the AID of the second AP or the AP ID of the second AP allocated for the multi-AP cooperation.

14. In claim 1, the TXOP return frame is a multi-STA BA (block acknowledgment) frame, The above TXOP return notification is a method related to at least one of: a receiver address (RA) field of the multi-STA BA frame set to the address of the second AP; an association identifier (AID) of the second AP; or an AP ID of the second AP allocated for multi-AP cooperation.

15. At the first AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The above memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: An action to perform negotiation procedures for secondary AP and multi-AP cooperation; An operation of receiving, from the second AP, a TXOP shared frame including information about an allocated section within a TXOP (transmission opportunity) section; An operation of performing frame exchange with an STA (station) associated with the first AP in the above allocation section; and A first AP comprising an operation for transmitting a TXOP return frame including a TXOP return notification to the second AP upon completion of the above frame exchange.

16. In the device, at least one processor; and comprising at least one memory functionally coupled with at least one processor; The at least one memory stores instructions that perform operations based on being executed by the at least one processor, the operations comprising: An action to perform negotiation procedures for secondary AP and multi-AP cooperation; An operation of receiving, from the second AP, a TXOP shared frame including information about an allocated section within a TXOP (transmission opportunity) section; An operation of performing frame exchange with an STA (station) associated with the first AP in the above allocation section; and A device comprising an action for transmitting, to the second AP, a TXOP return frame including a TXOP return notification upon completion of the frame exchange.

17. A non-transitory computer readable medium (CRM) storing program code implementing instructions that perform operations based on being executed by at least one processor, said operations comprising: An action to perform negotiation procedures for secondary AP and multi-AP cooperation; An operation of receiving, from the second AP, a TXOP shared frame including information about an allocated section within a TXOP (transmission opportunity) section; An operation of performing frame exchange with an STA (station) associated with the first AP in the above allocation section; and A CRM comprising an action of transmitting, upon completion of the above frame exchange, a TXOP return frame including a TXOP return notification to the second AP.

18. A step in which the second AP (access point) performs a negotiation procedure for multi-AP cooperation with the first AP; A step in which the second AP transmits a TXOP shared frame including information about an allocated section within a TXOP (transmission opportunity) section to the first AP; Upon completion of frame exchange of the first AP in the above allocation interval, the second AP receives a TXOP return frame including a TXOP return notification from the first AP; and A method comprising a step of performing frame exchange between the second AP and a STA (station) associated with the second AP in a remaining TXOP interval after receiving the TXOP return notification within the TXOP interval.

19. At the second AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The above memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: An action to perform a negotiation procedure for multi-AP cooperation with the first AP; An operation of transmitting a TXOP shared frame including information about an allocated section within a TXOP (transmission opportunity) section to the first AP; An operation of receiving a TXOP return frame including a TXOP return notification from the first AP upon completion of frame exchange of the first AP in the above allocation interval; and A method including an operation of performing frame exchange with an STA (station) associated with the second AP in a remaining TXOP interval after receiving the TXOP return frame within the TXOP interval.

20. The method of claim 19, wherein the remaining TXOP interval comprises: i) a time interval after the allocation interval, based on the frame exchange being completed upon expiration of the allocation interval; and ii) a time interval after the allocation interval and a time interval after receiving the TXOP return frame within the allocation interval, based on the frame exchange being completed before expiration of the allocation interval.

Images