Method and apparatus for sharing TXOP operation using CTS-to-Self frame for C-TDMA operation in wireless LAN system

Abstract

A method and an apparatus for performing an operation of sharing a TXOP using a CTS-to-Self frame for a C-TDMA operation in a wireless LAN system are presented. Specifically, a first AP receives an MU-RTS trigger frame from a second AP. And the first AP sends the CTS-to-Self frame to the second AP. A first AP exchanges a first frame with a first non-AP. And configuring the NAV in the BSS for the first non-AP STA based on the CTS-to-Self frame.

Description

Technical Field

[0001] This specification relates to a technique for sharing TXOPs using CTS-to-Self frames for C-TDMA operation in a wireless LAN system, and more specifically, to a method and apparatus for performing frame exchange with a DAP by setting the NAV within the BSS by a non-AP STA within the BSS based on CTS-to-Self frames. Background Technology

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

[0003] Technical issues

[0004] This specification presents a method and apparatus for sharing TXOPs using CTS-to-Self frames for C-TDMA operation in a wireless LAN system.

[0005] Technical solution

[0006] The examples in this specification present a method for sharing TXOPs using CTS-to-Self frames for C-TDMA operations.

[0007] This implementation can be performed in network environments that support next-generation wireless LAN systems (Ultra-High Reliability (UHR) wireless LAN systems or next-generation wireless LAN systems). Next-generation wireless LAN systems are improved versions of the 802.11be system and meet backward compatibility requirements with the 802.11be system.

[0008] This implementation is performed in the first AP. After negotiation in multi-AP communication, the first AP can be set as a shared AP (DAP), and after negotiation in multi-AP communication, the second AP can be set as a shared AP (SAP). The first non-AP STA and the second non-AP STA in this implementation can correspond to at least one station (STA).

[0009] This implementation proposes a method for performing TXOP sharing by utilizing CTS-to-Self frames when performing C-TDMA operation (or multi-AP operation) in multi-access point (multi-AP) communication. Specifically, this implementation proposes a method for performing frame exchange with the DAP without being affected by the SAP's NAV by allowing a non-APSTA connected to the DAP to set the NAV within the BSS when receiving a CTS-to-Self frame (including the TA field but not the RA field).

[0010] The first access point (AP) receives a Multi-User Request Transmission (MU-RTS) Transmission Opportunity (TXOP) Share (TXS) trigger frame from the second AP.

[0011] The first AP sends a Clear Transmission (CTS)-to-self frame to the second AP.

[0012] The first AP and the first non-AP station (STA) exchange the first frame.

[0013] At this point, the second AP is a shared AP that controls the cooperation between multiple APs, and the first AP is a shared AP that receives resources allocated or shared from the shared AP. The first non-AP STA is a non-AP STA within the basic service set (BSS) of the first AP.

[0014] Technologies used for collaboration among multiple access points (APs) may include collaborative multi-AP technologies, such as collaborative time division multiple access (C-TDMA), collaborative spatial reuse (C-SR), collaborative beamforming (C-BF), or collaborative orthogonal frequency division multiple access (C-OFMA).

[0015] In the C-TDMA operation example, the entity sharing the TXOP (SAP, here the second AP) and the entity receiving the TXOP (DAP, here the first AP) are APs with different BSSs. That is, because frame transmission within the SAP's BSS may cause non-AP STAs within the DAP's BSS to set a basic NAV and be unable to smoothly exchange frames with the DAP, protection rules related to the Network Allocation Vector (NAV) setting must be precisely applied to ensure smooth cooperation between APs and frame exchange within each BSS. Specifically, non-AP STAs connected to the DAP can receive / detect frames sent from the SAP or non-AP STAs connected to the SAP, as well as CTS frames sent from the DAP, and set a basic NAV for the SAP. At this point, a problem may occur where non-AP STAs connected to the DAP are unable to send UL PPDUs or frames to the DAP due to the basic NAV.

[0016] However, this embodiment proposes a TXOP sharing method that, in response to a MU-RTS TXS trigger frame, uses (or replaces) CTS-to-Self frames instead of CTS frames to perform the C-TDMA procedure. The C-TDMA operation allows the DAP and some non-AP STAs within the DAP's BSS to exchange frames with the DAP without being affected by the SAP's NAV.

[0017] Specifically, the network allocation vector (NAV) within the BSS is set for the first non-AP STA based on the CTS-to-Self frame.

[0018] Beneficial effects

[0019] This implementation offers the following advantages: by replacing the response to the MU-RTS TXS trigger frame sent from the SAP during C-TDMA-based TXOP sharing with a CTS-to-Self frame instead of a CTS frame, non-AP STAs connected to the DAP can smoothly exchange frames with the DAP without requiring the SAP to set a default NAV. Specifically, due to the CTS-to-Self frame, non-AP STAs connected to the DAP set the NAV within the BSS instead of the SAP's default NAV, allowing the DAP and non-AP STAs to perform separate frame exchanges during allocated time periods. This has the effect of enabling appropriate scheduling based on cooperation among multiple APs and can be expected to increase overall network throughput. Attached Figure Description

[0020] Figure 1 Examples of transmitting and / or receiving devices are shown in this specification.

[0021] Figure 2 This is a conceptual diagram illustrating the structure of a wireless local area network (WLAN).

[0022] Figure 3 The diagram illustrates the typical link establishment process.

[0023] Figure 4 An example of multi-link (ML) is shown.

[0024] Figure 5 Examples of Physical Protocol Data Units or Physical Layer (PHY) Protocol Data Units (PPDUs) transmitted / received by the STA of this disclosure are shown.

[0025] Figure 6 This is a diagram illustrating the layout of a resource unit (RU) for a 20 MHz PPDU.

[0026] Figure 7 The layout of a resource unit (RU) for a 40 MHz PPDU is illustrated.

[0027] Figure 8 This is a diagram illustrating the layout of a resource unit (RU) for an 80 MHz PPDU.

[0028] Figure 9 The operation related to UL-MU is shown.

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

[0030] Figure 11 The illustration shows an example of a channel used / supported / defined within the 5 GHz band.

[0031] Figure 12 The illustration shows an example of a channel used / supported / defined within the 6 GHz band.

[0032] Figure 13 Examples of the modified transmitting and / or receiving devices described in this specification are illustrated.

[0033] Figure 14 The diagram illustrates the operation based on the standard STX procedure.

[0034] Figure 15 An example of coordinated OFDMA (C-OFDMA) is illustrated.

[0035] Figure 16 An example of coordinated beamforming (CBF) is illustrated.

[0036] Figure 17 The illustration shows an example of AP selection.

[0037] Figure 18 An example of JTX / JT is shown in the diagram.

[0038] Figure 19 An example of coordinating TDMA operations is illustrated.

[0039] Figure 20 The illustration shows an example of a basic NAV setup using CTS frames in MU-RTS TXS trigger / CTS frame switching.

[0040] Figure 21 The illustration shows an example of a basic NAV setup problem using CTS frames.

[0041] Figure 22 The illustration shows an example of the frame format when using CTS-to-Self frames during C-TDMA TXOP sharing.

[0042] Figure 23Example 1 illustrates a C-TDMA process utilizing CTS-to-Self frames.

[0043] Figure 24 Example 2 illustrates a C-TDMA process utilizing CTS-to-Self frames.

[0044] Figure 25 This is a flowchart illustrating the operation of the sending method according to this embodiment.

[0045] Figure 26 This is a flowchart illustrating the operation of the receiving method according to this embodiment.

[0046] Figure 27 This is a flowchart illustrating the operation of the transmitting device according to this embodiment.

[0047] Figure 28 This is a flowchart illustrating the operation of the receiving device according to this embodiment.

[0048] Figure 29 This is a flowchart illustrating the process of the TXOP sharing method using CTS-to-Self frames on the shared AP side according to this embodiment.

[0049] Figure 30 This is a flowchart illustrating the process of TXOP sharing using CTS-to-Self frames on the shared AP side according to this embodiment. Detailed Implementation

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

[0051] The forward slash ( / ) or comma used in this disclosure can represent "and / or". For example, "A / B" can mean "A and / or B". Therefore, "A / B" can mean "A only", "B only", or "both A and B". For example, "A, B, C" can mean "A, B, or C".

[0052] In this disclosure, "at least one of A and B" can mean "only A", "only B" or "both A and B". Additionally, in this disclosure, the expression "at least one of A or B" or "at least one of A and / or B" can be interpreted as "at least one of A and B".

[0053] The brackets used in this disclosure may indicate "for example". Specifically, when indicated as "control information (UHR-signal field)", it may indicate that the "UHR-signal field" is cited as an example of "control information". In other words, the "control information" of this disclosure is not limited to the "UHR-signal field", and the "UHR-signal field" may also be cited as an example of "control information". Furthermore, when indicated as "control information (i.e., UHR-signal field)", it may also indicate that the "UHR-signal field" is cited as an example of "control information".

[0054] Furthermore, as used in this disclosure, "a" can mean "at least one" or "one or more". Additionally, terms ending in "(s)" can mean "at least one" or "one or more".

[0055] Furthermore, as used in this disclosure, the expressions “based on”, “on the basis of”, or “according to” mean “at least partially based on”, and not “based on only”.

[0056] The technical features described individually in one of the accompanying drawings of this disclosure may be implemented individually or simultaneously.

[0057] The following examples of this disclosure can be applied to various wireless communication systems. For example, the following examples of this disclosure can be applied to wireless local area network (WLAN) systems. For example, this disclosure can be applied to the IEEE 802.11 a / g / n / ac / ax / be / bn standards. Furthermore, the examples of this disclosure can also be applied to next-generation wireless LAN standards such as enhanced Ultra-High Reliability (UHR) standards or IEEE 802.11 bn. Furthermore, the examples of this disclosure can also be applied to new WLAN standards enhanced from EHT standards or IEEE 802.11 be standards. Furthermore, the examples of this disclosure can be applied to mobile communication systems. For example, it can be applied to mobile communication systems based on Long Term Evolution (LTE), which relies on 3GPP standards and is based on LTE evolution. Furthermore, the examples of this disclosure can be applied to communication systems based on the 5G NR standard of 3GPP standards.

[0058] In the following text, for the purpose of describing the technical features of this disclosure, technical features applicable to this disclosure will be described.

[0059] Figure 1 Examples of transmitting and / or receiving devices of this disclosure are shown.

[0060] exist Figure 1 In the example, the various technical features described below can be implemented. Figure 1At least one station (STA) is involved. For example, STA 110 and 120 of this disclosure may also be referred to by various terms such as mobile terminal, wireless device, wireless transceiver unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or simply user. STA 110 and 120 of this disclosure may also be referred to by various terms such as network, base station, Node B, access point (AP), repeater, router, relay, etc. STA 110 and 120 of this disclosure may also be referred to by various names such as receiving device, transmitting device, receiving STA, transmitting STA, receiving device, transmitting device, etc.

[0061] For example, STA 110 and 120 can be used as AP or non-AP. That is, STA 110 and 120 of this disclosure can be used as AP and / or non-AP. In this disclosure, AP can be indicated as AP STA.

[0062] In addition to the IEEE 802.11 standard, the STAs 110 and 120 of this disclosure can together support various communication standards. For example, they can support communication standards based on 3GPP standards (e.g., LTE, LTE-A, 5G NR standards). Furthermore, the STAs of this disclosure can be implemented in various devices such as mobile phones, vehicles, and personal computers. Additionally, the STAs of this disclosure can support communication for various communication services such as voice calls, video calls, data communication, and autonomous driving.

[0063] The STA 110 and 120 disclosed herein may include media access control (MAC) conforming to the IEEE 802.11 standard and a physical layer interface for radio media.

[0064] The following will refer to Figure 1 The subgraph (a) is used to describe STA 110 and 120.

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

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

[0067] For example, the first STA 110 can perform the operations expected by the AP. For example, the AP's processor 111 can receive signals via transceiver 113, process receive (RX) signals, generate transmit (TX) signals, and provide control over signal transmission. The AP's memory 112 can store signals received via transceiver 113 (e.g., RX signals) and can store signals to be transmitted via transceiver 113 (e.g., TX signals).

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

[0069] For example, a non-AP STA processor 121 can receive signals via transceiver 123, process RX signals, generate TX signals, and provide control over signal transmission. A non-AP STA memory 122 can store signals received via transceiver 123 (e.g., RX signals) and can store signals to be transmitted via transceiver 123 (e.g., TX signals).

[0070] For example, the operation of a device designated as an AP in the disclosure described below can be performed in either the first STA 110 or the second STA 120. For instance, if the first STA 110 is an AP, the operation of the device designated as an AP can be controlled by the processor 111 of the first STA 110, and related signals can be transmitted or received via a transceiver 113 controlled by the processor 111 of the first STA 110. Additionally, control information related to the operation of the AP or the AP's TX / RX signals can be stored in the memory 112 of the first STA 110. Similarly, if the second STA 120 is an AP, the operation of the device designated as an AP can be controlled by the processor 121 of the second STA 120, and related signals can be transmitted or received via a transceiver 123 controlled by the processor 121 of the second STA 120. Furthermore, control information related to the operation of the AP or the AP's TX / RX signals can be stored in the memory 122 of the second STA 120.

[0071] For example, in the disclosure described below, the operation of a device indicated as a non-AP (or user STA) can be performed in either the first STA 110 or the second STA 120. For instance, if the second STA 120 is a non-AP, the operation of the device indicated as a non-AP can be controlled by the processor 121 of the second STA 120, and related signals can be transmitted or received via a transceiver 123 controlled by the processor 121 of the second STA 120. Additionally, control information related to the operation of a non-AP or non-AP TX / RX signals can be stored in the memory 122 of the second STA 120. Similarly, if the first STA 110 is a non-AP, the operation of the device indicated as a non-AP can be controlled by the processor 111 of the first STA 110, and related signals can be transmitted or received via a transceiver 113 controlled by the processor 111 of the first STA 110. Additionally, control information related to the operation of a non-AP or non-AP TX / RX signals can be stored in the memory 112 of the first STA 110.

[0072] In the disclosure described below, devices referred to 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., may implicitly refer to Figure 1 STAs 110 and 120. For example, devices indicated as (but without specific labels) (transmitting / receiving) STA, First STA, Second STA, STA1, STA2, AP, First AP, Second AP, AP1, AP2, (transmitting / receiving) terminal, (transmitting / receiving) device, (transmitting / receiving) device, network, etc., can be implied. Figure 1 STAs 110 and 120. For example, in the following example, the operation of various STA transmit / receive signals (e.g., PPDU) can be... Figure 1 The operation is performed in transceivers 113 and 123. Additionally, in the following examples, various STAs can generate TX / RX signals or perform data processing and calculations on TX / RX signals in advance. Figure 1The operations are executed in processors 111 and 121. Examples of operations for generating TX / RX signals or performing prior data processing and calculations may include: 1) operations to determine / obtain / configure / calculate / decode / encode bit information of subfields (SIG, STF, LTF, data) included in the PPDU; 2) operations to determine / configure / obtain time resources or frequency resources (e.g., subcarrier resources) for the subfields (SIG, STF, LTF, data) included in the PPDU; 3) operations to determine / configure / obtain specific sequences (e.g., pilot sequences, STF / LTF sequences, additional sequences applied to SIG) for the subfields (SIG, STF, LTF, data) included in the PPDU; 4) power control operations and / or power-saving operations applied to the STA; and 5) operations related to the determination / obtaining / configuration / decoding / encoding of the ACK signal. Additionally, in the following examples, various information (e.g., information related to fields / subfields / control fields / parameters / power, etc.) used by various STAs to determine / obtain / configure / calculate / decode / decode the TX / RX signal may be stored in the STA's memory. Figure 1 In memory 112 and 122.

[0073] Figure 1 The aforementioned device / STA in subgraph (a) can be as follows Figure 1 The subgraph (b) is modified as shown below. In the following text, the modifications will be based on... Figure 1 The subgraph (b) is used to describe STA 110 and STA 120 of this disclosure.

[0074] For example, Figure 1 The transceivers 113 and 123 shown in subgraph (b) can perform operations with Figure 1 The transceiver shown in sub-diagram (a) has the same function as the aforementioned transceiver. For example, Figure 1 The processing chips 114 and 124 shown in sub-figure (b) may include processors 111 and 121 and memories 112 and 122. Figure 1 The processors 111 and 121 and the memories 112 and 122 shown in sub-figure (b) can perform operations related to Figure 1 The processors 111 and 121 and the memories 112 and 122 shown in sub-figure (a) have the same functions.

[0075] The mobile terminal, wireless device, wireless transceiver 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 unit, transmitting unit, receiving STA, transmitting STA, receiving device, transmitting device, receiving device and / or transmitting device described below may mean Figure 1 The STA 110 and 120 shown in subgraphs (a) / (b) may mean, or Figure 1 The processing chips 114 and 124 are shown in sub-figure (b). That is, the technical features of this disclosure can be... Figure 1 It can be performed in STA 110 and 120 as shown in subgraphs (a) / (b), or it can be performed only in Figure 1 The processing chips 114 and 124 shown in sub-diagram (b) are executed Figure 1 Transceivers 113 and 123 are shown in sub-diagrams (a) and (b). For example, the technical features of transmitting control signals by a STA can be understood as being achieved through... Figure 1 The transceiver 113 shown in sub-diagrams (a) / (b) transmits in Figure 1 The technical features of the control signals generated in processors 111 and 121 are illustrated in sub-figures (a) and (b). Alternatively, the technical features of the STA transmitting control signals can be understood as follows: Figure 1 The technical features of generating control signals to be transmitted to transceivers 113 and 123 in processing chips 114 and 124 are shown in sub-figure (b).

[0076] For example, the technical characteristics of receiving STA control signals can be understood as through... Figure 1 The technical features of transceivers 113 and 123 receiving control signals are shown in sub-figure (a). Alternatively, the technical features of receiving STA control signals can be understood as being achieved through... Figure 1 Processors 111 and 121 shown in subgraph (a) obtain Figure 1 The technical features of the control signals received in transceivers 113 and 123 shown in sub-figure (a) are illustrated. Alternatively, the technical features of receiving control signals by the STA can be understood as being achieved through... Figure 1 The processing chips 114 and 124 shown in sub-figure (b) obtain Figure 1 Technical features of the control signals received in transceivers 113 and 123 as shown in sub-figure (b).

[0077] refer to Figure 1 Subgraph (b), software codes 115 and 125 can be included in memories 112 and 122. Software codes 115 and 125 can include instructions for controlling the operation of processors 111 and 121. Software codes 115 and 125 can be included in various programming languages.

[0078] Figure 1 The processors 111 and 121 or processing chips 114 and 124 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processing devices. The processor may be an application processor (AP). For example, Figure 1 The processors 111 and 121 or processing chips 114 and 124 may include at least one of the following: a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modulator and demodulator (modem). For example, Figure 1 The processors 111 and 121 or the processor chips 114 and 124 may be SNAPDRAGON™ series processors manufactured by Qualcomm®, EXYNOS™ series processors manufactured by Samsung®, A series processors manufactured by Apple®, HELIO™ series processors manufactured by MediaTek®, ATOM™ series processors manufactured by Intel®, or processors enhanced from these processors.

[0079] In this disclosure, an uplink can mean a link used for communication from a non-AP STA to an AP STA, and uplink PPDUs / packets / signals, etc., can be transmitted via the uplink. Similarly, in this disclosure, a downlink can mean a link used for communication from an AP STA to a non-AP STA, and downlink PPDUs / packets / signals, etc., can be transmitted via the downlink.

[0080] Figure 2 This is a conceptual diagram illustrating the structure of a wireless local area network (WLAN).

[0081] Figure 2 The upper part of the diagram illustrates the structure of the Infrastructure Basic Services Set (BSS) of the Institute of Electrical and Electronics Engineers (IEEE) 802.11.

[0082] Figure 2 The upper part of the diagram illustrates the structure of the Infrastructure Basic Services Set (BSS) of the Institute of Electrical and Electronics Engineers (IEEE) 802.11.

[0083] refer to Figure 2 The upper part of the wireless LAN system may include one or more infrastructure BSS 200 and 205 (hereinafter referred to as BSS). BSS 200 and 205, as a set of APs and STAs (e.g., access point (AP) 225 and station (STA1) 200-1) that have successfully synchronized to communicate with each other, are not concepts indicating a specific area. BSS 205 may include one or more STAs 205-1 and 205-2 that can join an AP 230.

[0084] BSS may include at least one STA, APs 255 and 230 that provide distributed services, and a distributed system (DS) 210 that connects multiple APs.

[0085] Distributed system 210 can implement an Extended Service Set (ESS) 240 that is expanded by connecting multiple BSSs 200 and 205. ESS 240 can be used as a term to refer to a network configured by connecting one or more APs 225 or 230 via distributed system 210. APs included in an ESS 240 can have the same Service Set Identifier (SSID).

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

[0087] exist Figure 2 The BSS shown at the top allows for networking between APs 225 and 230, as well as between APs 225 and 230 and STAs 200-1, 205-1, and 205-2. However, it also allows for networking between STAs to perform communication even without APs 225 and 230. Networks that enable communication between STAs by configuring networks even without APs 225 and 230 are defined as self-organizing networks or Independent Basic Service Sets (IBSS).

[0088] Figure 2 The lower part of the diagram shows a concept map, illustrating IBSS.

[0089] refer to Figure 2 The lower part of the IBSS is a BSS that operates in a self-organizing mode. Since the IBSS does not include access points (APs), there is no centralized management entity performing management functions at the center. That is, in the IBSS, STAs 250-1, 250-2, 250-3, 255-4, and 255-5 are managed in a distributed manner. In the IBSS, all STAs 250-1, 250-2, 250-3, 255-4, and 255-5 can be composed of mobile STAs, and access to DS to form a self-contained network is not permitted.

[0090] Figure 3 The diagram illustrates the typical link establishment process.

[0091] In S310, the STA can perform network discovery operations. Network discovery operations can include scanning operations by the STA. That is, in order to access a network, the STA needs to discover participating networks. The process of identifying compatible networks before joining a wireless network and identifying networks existing in a specific area is called scanning. Scanning methods include active scanning and passive scanning.

[0092] Figure 3The diagram illustrates the network discovery process in active scanning. In active scanning, the STA performing the scan sends a probe request frame and waits for a response to it, in order to identify which APs are nearby while moving to a new channel. The responder sends a probe response frame to the STA that sent the probe request frame as a response. Here, the responder can be the STA in the BSS of the channel being scanned that sent the last beacon frame. In the BSS, the AP is the responder because it sends the beacon frame. In the IBSS, the responder is not fixed because the STAs in the IBSS take turns sending beacon frames. For example, when an STA sends a probe request frame via channel 1 and receives a probe response frame via channel 1, the STA can store the BSS-related information included in the received probe response frame, move to the next channel (e.g., channel 2), and perform a scan in the same way (e.g., sending a probe request and receiving a probe response via channel 2).

[0093] Although Figure 3 As not shown, scanning can be performed using a passive scanning method. In passive scanning, the STA performing the scan can wait for beacon frames while moving to a channel. Beacon frames are one of the management frames in IEEE 802.11 and are periodically sent to indicate the presence of a wireless network and enable the STA performing the scan to find and join the wireless network. In a BSS, the AP periodically sends beacon frames. In an IBSS, STAs in the IBSS take turns sending beacon frames. Upon receiving a beacon frame, the STA performing the scan stores information about the BSS included in the beacon frame and records the beacon frame information for each channel, while moving to another channel. The STA receiving the beacon frame can store the BSS-related information included in the received beacon frame, can move to the next channel, and can perform a scan on the next channel using the same method.

[0094] After network discovery, the STA can perform authentication processing in S320. This authentication processing can be referred to as the first authentication processing to clearly distinguish it from the subsequent security establishment operation in S340. The authentication processing in S320 may include the STA sending an authentication request frame to the AP and the AP sending an authentication response frame to the STA in response. The authentication frame used for the authentication request / response is a management frame.

[0095] An authentication frame may include information about the authentication algorithm number, authentication transaction sequence number, status code, challenge text, robust security network (RSN), and finite cyclic group.

[0096] The STA can send an authentication request frame to the AP. The AP can determine whether to allow the STA's authentication based on the information included in the received authentication request frame. The AP can then provide the authentication processing result to the STA via an authentication response frame.

[0097] When a STA is successfully authenticated, it can perform association processing in S330. Association processing includes the STA sending an association request frame to the AP, and the AP responding by sending an association response frame to the STA. For example, the association request frame may include information about various capabilities, beacon listening interval, service set identifier (SSID), supported rates, supported channels, RSN, mobile domain, supported operation classes, service indication map (TIM) broadcast request, and interoperability service capabilities. Similarly, the association response frame may include information about various capabilities, status codes, association ID (AID), supported rates, enhanced distributed channel access (EDCA) parameter set, received channel power indicator (RCPI), received signal-to-noise ratio indicator (RSNI), mobile domain, timeout interval (association recovery time), overlapping BSS scan parameters, TIM broadcast response, and QoS map.

[0098] In the S340, the STA can perform security establishment processes. The security establishment processes in the S340 may include the process of establishing a private key via a four-way handshake (e.g., via Extensible Authentication Protocol (EAPOL) frames over the LAN).

[0099] Figure 4 An example of multi-link (ML) is shown.

[0100] like Figure 4 As illustrated, multiple multi-link devices (MLDs) can communicate via a remote link. MLDs can be classified as AP MLDs, which include multiple AP STAs, and non-AP MLDs, which include multiple non-AP STAs. That is, an AP MLD may include affiliated APs (i.e., AP STAs), and a non-AP MLD may include affiliated STAs (i.e., non-AP STAs or user STAs).

[0101] A multi-link system may include a first link and a second link, and different channel / subchannel / frequency resources may be allocated to the first link and the second link. The first and second multi-link systems can be identified by a 4-bit (or other n-bit) link ID. The first and second links can be configured in the same 2.4 GHz, 5 GHz, or 6 GHz frequency band. Alternatively, the first and second links can be configured in different frequency bands.

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

[0103] exist Figure 4 In the example, AP1 can initiate the multi-link establishment process (ML establishment process) by sending an association request frame to a non-AP STA1. Figure 4 In the example, a non-AP STA1 can send an association response frame in response to an association request frame. Figure 4 The individual APs shown (e.g., AP1 / 2 / 3) can be compared with... Figure 1 and / or Figure 2 The APs shown are the same, and Figure 4 The various non-APs shown (e.g., non-AP1 / 2 / 3) can be compared with... Figure 1 and / or Figure 2 The STAs shown are the same (i.e., user STAs or non-AP STAs).

[0104] The specific features of this disclosure are not limited to Figure 4 The specific characteristics are as follows. That is, the number of links can be defined in various ways, and multiple links can be defined in at least one frequency band in various ways.

[0105] Figure 5 Examples of Physical Protocol Data Units or Physical Layer (PHY) Protocol Data Units (PPDUs) transmitted / received by the STA of this disclosure are shown.

[0106] The STA (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) disclosed herein can send and / or receive. Figure 5 The PPDU described in this disclosure may have, for example... Figure 5 The structure is as follows. Furthermore, the PPDU described in this disclosure may be referred to by various names, such as transmit PPDU, receive PPDU, type 1 or type N PPDU, etc. The PPDU described in this disclosure can be used in WLAN systems defined according to IEEE 802.11bn and / or in next-generation WLAN systems that improve upon IEEE 802.11bn.

[0107] Figure 5 The PPDU can encompass various PPDU types used in UHR systems. For example, Figure 5 Examples can be used for at least one of the following modes related to channel detection: single-user (SU) mode / type / transmission, multi-user (MU) mode / type / transmission, and null packet (NDP) mode / type / transmission. For example, if Figure 5 If the example involves NDP, the data fields shown can be omitted. Figure 5 The PPDU is used in trigger-based (TB) mode and can be omitted. Figure 6 The UHR-SIG. In other words, a STA that has received a trigger frame for uplink-MU (UL-MU) communication can send a UHR-SIG. Figure 5 The UHR-SIG PPDU is omitted in the example.

[0108] exist Figure 5 In this context, L-STF or UHR-LTF can be referred to as a preamble or physical preamble, and can be generated / transmitted / received / acquired / decoded at the physical layer (including in the transmit / receive STA).

[0109] Figure 5 The blocks shown in the diagram can be referred to as fields / subfields / signals, etc. These fields / subfields / signals can be named as Traditional Short Training Field (L-STF), Traditional Long Training Field (L-LTF), Traditional Signal (L-SIG), Repeated L-SIG (RL-SIG), Universal Signal (U-SIG), UHR Signal (UHR-SIG), etc. Figure 5 As shown in the diagram.

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

[0111] exist Figure 5 In the PPDU, the L-LTF and L-STF can be the same as those in the conventional domain (e.g., non-HT LTF and non-HT STF defined in conventional WLAN standards).

[0112] Figure 5The L-SIG field can include, for example, 24 bits of bit information. For instance, the 24 bits could 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 could include information related to the length or duration of the PPDU. For example, the 12-bit length field can be determined based on the type of PPDU. For example, when the PPDU is a Non-High Throughput (HT), High Throughput (HT), Very High Throughput (VHT) PPDU, Extremely High Throughput (EHT) PPDU, or UHR PPDU, the value of the length field can be determined to be a multiple of 3. For example, when the PPDU is an HE PPDU, the length field can be determined to be a multiple of 3 + 1 or a multiple of 3 + 2. In other words, for non-HT, HT, VHT, EHT, or UHR PPDUs, the length field value can be set to a multiple of 3, and for high-efficiency (HE) PPDUs, the length field value can be set to either a multiple of 3 + 1 or a multiple of 3 + 2. In other words, the LENGTH field in a UHR PPDU is set to a value that satisfies the condition that LENGTH divided by 3 leaves a remainder of 0.

[0113] For example, a (non-AP and AP) STA can apply BCC encoding based on a 1 / 2 coding rate to the 24-bit information of the L-SIG field. The transmitting STA then obtains 48 bits of BCC compiled bits. BPSK modulation can be applied to these 48 compiled bits to generate 48 BPSK symbols. The transmitting STA can map these 48 BPSK symbols to positions other than the pilot subcarriers {subcarrier indices -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 subcarrier indices {-28, -27, +27, +28}. The aforementioned signals can be used for channel estimation in the frequency domain corresponding to {-28, -27, +27, +28}.

[0114] For example, a (non-AP and AP) STA can generate an RL-SIG in the same way as the L-SIG. BPSK modulation can be applied to the RL-SIG. Based on the presence of the RL-SIG, the (non-AP and AP) STA can know that the RX PPDU is an HE PPDU, EHT PPDU, or UHR PPDU. In other words, if the RL-SIG is present, the receiving (non-AP and AP) STA can know that the received PPDU is one of an HE PPDU, EHT PPDU, or UHR PPDU. In other words, if the RL-SIG is not present, the receiving (non-AP and AP) STA can know that the received PPDU is one of a non-HT PPDU, HT PPDU, or VHT PPDU. In other words, the RL-SIG field is a repetition of the L-SIG field and is used to distinguish UHR PPDUs from non-HT PPDUs, HT PPDUs, and VHT PPDUs.

[0115] Universal SIG (U-SIG) can be inserted in Figure 6 Following RL-SIG, U-SIG can be referred to by various terms such as First SIG Field, First SIG, First Type SIG, Control Signal, Control Signal Field, First (Type) Control Signal, Common Control Field, Common Control Field, etc.

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

[0117] Through U-SIG, for example, A bits of information (e.g., 52 uncompiled bits) can be transmitted. The first symbol of U-SIG can transmit the first X bits of the A bits of information (e.g., 26 uncompiled bits), and the second symbol of U-SIG can transmit the remaining Y bits of the A bits of information (e.g., 26 uncompiled bits). For example, the transmitting STA can obtain the 26 uncompiled bits included in each U-SIG symbol. The transmitting STA can perform convolutional coding (i.e., BCC coding) based on a rate of R=1 / 2 to generate 52 compiled bits, and can perform interleaving on the 52 compiled bits. The transmitting STA can perform BPSK modulation on the interleaved 52 compiled bits to generate 52 BPSK symbols to be assigned to each U-SIG symbol. A U-SIG symbol can be transmitted based on 65 tones (subcarriers) from subcarrier index -28 to subcarrier index +28, except for DC index 0. The 52 BPSK symbols generated by the transmitting STA can be transmitted based on the remaining tones (subcarriers) other than the pilot tone, namely tones -21, -7, +7, and +21.

[0118] For example, the A-bit information generated by U-SIG (e.g., 52 uncompiled bits) may include a CRC field (e.g., a 4-bit field) and a tail field (e.g., a 6-bit field). The CRC and tail fields can be sent via a second symbol of U-SIG. The CRC field can be generated based on the 26 bits allocated to the first symbol of U-SIG and the remaining 16 bits from the second symbol excluding the CRC / tail field, and can be generated based on a standard CRC calculation algorithm. Additionally, the tail field can be used to terminate the trellis of the convolutional decoder and can be set to, for example, "000000".

[0119] The A-bit information (e.g., 52 uncompiled bits) sent by U-SIG (or the U-SIG field) can be divided into version-independent bits and version-dependent bits. For example, version-independent bits can have a fixed or variable size. For example, version-independent bits can be assigned only to the first symbol of U-SIG, or version-independent bits can be assigned to both the first and second symbols of U-SIG. For example, version-independent bits and version-dependent bits can be referred to using various terms such as first control bit, second control bit, etc.

[0120] For example, the version-independent bits of the U-SIG can include a 3-bit PHY version identifier. For example, the 3-bit PHY version identifier can include information related to the PHY version of the TX / RX PPDU. For example, the first value of the 3-bit PHY version identifier (e.g., a value of 000) can indicate that the TX / RX PPDU is an EHT PPDU. Furthermore, the second value of the 3-bit PHY version identifier (e.g., a value of 001) can indicate that the TX / RX PPDU is a UHR PPDU.

[0121] In other words, when an (AP / non-AP) STA sends an EHT PPDU, the 3-bit PHY version identifier can be set to a first value, and when an (AP / non-AP) STA sends a UHR PPDU, the 3-bit PHY version identifier can be set to a second 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 with the first value, and can determine that the received PPDU is a UHR PPDU based on the PHY version identifier with the second value.

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

[0123] For example, the version-independent bits of U-SIG can include information related to the transmission opportunity (TXOP) length and information related to the BSS color ID.

[0124] For example, if the UHR PPDU is classified into various types (e.g., types related to SU transmission (based on UL or DL), types related to DL transmission, types related to NDP transmission, types related to DL non-MU-MIMO, types related to DL MU-MIMO, types related to multi-AP operation, types related to Co-BF beamforming (Co-BF), spatial reuse (SR), types related to Co-OFDMA (C-OFDMA), and types related to Co-TDMA (Co-TDMA), then information about the type of UHR PPDU (e.g., 2-bit or 3-bit information) can be included in the version-related bits of the U-SIG.

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

[0126] Can be Figure 5 The PPDU uses a preamble puncturing. A preamble puncturing means that the puncturing is applied to a portion of the full frequency band (e.g., the secondary 20 MHz band). For example, when transmitting an 80 MHz PPDU, the STA can apply puncturing to the secondary 20 MHz band within the 80 MHz band, and can transmit the PPDU only through the primary 20 MHz band and the secondary 40 MHz band.

[0127] For example, the pattern of the preamble perforation can be pre-configured. For example, when applying the first perforation pattern, perforation can be applied only to the secondary 20 MHz band within the 80 MHz band. For example, when applying the second perforation pattern, perforation can be applied only to any one of the two secondary 20 MHz bands within the secondary 40 MHz band included in the 80 MHz band. For example, when applying the third perforation pattern, perforation can be applied only to the secondary 20 MHz band within the primary 80 MHz band included in the 160 MHz band (or 80+80 MHz band). For example, when applying the fourth perforation pattern, perforation can be applied to at least one 20 MHz channel that does not belong to the primary 40 MHz band, provided that the primary 40 MHz band within the 80 MHz band included in the 160 MHz band (or 80+80 MHz band) is present.

[0128] Information related to the prelead puncture applied to the PPDU can be included in the U-SIG and / or UHR-SIG. For example, the first field of the U-SIG may include information related to continuous bandwidth, and the second field of the U-SIG may include information related to the prelead puncture applied to the PPDU.

[0129] For example, based on the following method, U-SIG and UHR-SIG can include information related to prelead punctures. When the bandwidth of the PPDU exceeds 80 MHz, U-SIG can be configured individually in 80 MHz units. For example, when the bandwidth of the PPDU is 160 MHz, the PPDU can include a first U-SIG for a first 80 MHz band and a second U-SIG for a second 80 MHz band. In this case, the first field of the first U-SIG can include information related to the 160 MHz bandwidth, and the second field of the first U-SIG can include information related to prelead punctures applied to the first 80 MHz band (i.e., information related to the prelead puncture pattern). Additionally, the first field of the second U-SIG can include information related to the 160 MHz bandwidth, and the second field of the second U-SIG can include information related to prelead punctures applied to the second 80 MHz band (i.e., information related to the prelead puncture pattern). Meanwhile, the UHR-SIG consecutive with the first U-SIG may include information related to the prelead via applied to the second 80 MHz band (i.e., information related to the prelead via pattern), and the UHR-SIG consecutive with the second U-SIG may include information related to the prelead via applied to the first 80 MHz band (i.e., information related to the prelead via pattern).

[0130] Additionally or alternatively, U-SIG and UHR-SIG may include information related to the preamble puncture, based on the following method: U-SIG may include information related to the preamble puncture for all frequency bands (i.e., information related to the preamble puncture pattern). That is, UHR-SIG may not include information related to the preamble puncture, while only U-SIG may include information related to the preamble puncture (i.e., information related to the preamble puncture pattern).

[0131] U-SIGs can be configured in 20 MHz units. For example, when an 80 MHz PPDU is configured, U-SIGs can be duplicated. That is, four identical U-SIGs can be included in an 80 MHz PPDU. PPDUs with bandwidths exceeding 80 MHz can include different U-SIGs.

[0132] Figure 5 The UHR-SIG can include control information for receiving STAs. The UHR-SIG can be transmitted using at least one symbol, and a symbol can have a length of 4 μs. Information related to the number of symbols used for the UHR-SIG can be included in the U-SIG.

[0133] UHR-SIG provides additional signals to the U-SIG field to enable the STA to interpret / decode the UHR PPDU. The UHR-SIG field may include U-SIG overflow bits that are typically applied to all users. In addition, the UHR-SIG field includes resource allocation information, allowing the STA to locate resources used in fields including the data field / UHR-STF / UHR-LTF (i.e., the UHR modulation field of the UHR PPDU).

[0134] It can be determined based on the RU (Resource Unit) defined by multiple subcarriers / tones. Figure 5 The diagram illustrates the frequency resources of the UHR-LTF, UHR-STF, and data fields. In other words, the UHR-LTF, UHR-STF, and data fields of this disclosure can be transmitted / received via RUs (Resource Units) defined by multiple subcarriers / tones.

[0135] Figure 6 This diagram illustrates the layout of a resource unit (RU) for a 20 MHz PPDU. Specifically, the UHR-LTF, UHR-STF, and / or data fields included in the 20 MHz PPDU can be accessed via... Figure 6 At least one of the various RUs defined in the code is used to send / receive.

[0136] like Figure 6 The topmost diagram shows a configuration that can accommodate 26 units (i.e., units corresponding to 26 tones). Six tones can be used for the leftmost guard band of the 20 MHz band, and five tones can be used for the rightmost guard band of the 20 MHz band. Additionally, seven DC tones can be inserted in the center band (i.e., the DC band), and 26 units corresponding to 13 tones on each of the left and right sides of the DC band can be arranged. Units of 26, 52, and 106 can be allocated to other bands. Individual units can be assigned to receiving STAs (i.e., users).

[0137] at the same time, Figure 6 The RU layout in the diagram can be used not only for multi-user (MU) but also for single-user (SU). In the single-user case, a 242 unit can be used and three DC tones can be inserted, such as... Figure 6 The bottom part is shown in the diagram.

[0138] Although Figure 6Various sizes of RUs have been proposed, namely 26-RU, 52-RU, 106-RU, and 242-RU, but RUs of a specific size can be expanded or increased. Therefore, this embodiment is not limited to individual RUs of a specific size (i.e., the number of corresponding tones). In this specification, an N-RU can be represented as an N-tone RU, etc. For example, a 26-RU can be represented as a 26-tone RU.

[0139] Figure 7 This is a diagram illustrating the layout of a resource unit (RU) for a 40 MHz PPDU.

[0140] With the use of RUs of various sizes Figure 6 Similarly, in Figure 7 Examples of frequencies that can be used include 26-RU, 52-RU, 106-RU, 242-RU, and 484-RU. Additionally, five DC tones can be inserted into the center frequency; 12 tones can be used for the leftmost guard band of the 40 MHz band; and 11 tones can be used for the rightmost guard band of the 40 MHz band.

[0141] like Figure 7 As shown, a 484-RU can be used when the RU layout is for a single user. The specific number of RUs can be similar to... Figure 5 Change.

[0142] Figure 8 This diagram illustrates the layout of resource units (RUs) for an 80 MHz PPDU. The layout of resource units (RUs) used in this specification can vary. For example, the layout of resource units (RUs) used in the 80 MHz band can be varied.

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

[0144] Multiple TB PPDUs 941, 942 can be transmitted simultaneously and can be transmitted from multiple STAs (e.g., user STAs) whose AIDs are indicated in the trigger frame 930. The ACK frame 950 for the TB PPDU can be implemented in various forms.

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

[0146] The 2.4 GHz band can also be referred to by other names, such as "first band". Furthermore, the 2.4 GHz band can refer to the frequency range used / supported / defined by channels having a center frequency adjacent to 2.4 GHz (e.g., channels having a center frequency between 2.4 GHz and 2.5 GHz).

[0147] The 2.4 GHz band can include multiple 20 MHz channels. Each 20 MHz channel within the 2.4 GHz band can have multiple channel indices (e.g., indices 1 to 14). For example, the center frequency of channel index 1 for a 20 MHz channel allocation could be 2.412 GHz, the center frequency of channel index 2 for a 20 MHz channel allocation could be 2.417 GHz, and the center frequency of channel index N for a 20 MHz channel allocation could be (2.407 + 0.005 GHz). (N) GHz. The channel index can be referenced by various names such as the channel number. The specific values ​​of the channel index and the center frequency can be changed.

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

[0149] Figure 11 The figure shows an example of a channel used / supported / defined within the 5 GHz band.

[0150] The 5 GHz band can be referred to by other names, such as second band / band, etc. The 5 GHz band can refer to the frequency range that uses / supports / defines channels with a center frequency greater than or equal to 5 GHz and less than 6 GHz (or less than 5.9 GHz). Alternatively, the 5 GHz band can include multiple channels between 4.5 GHz and 5.5 GHz. Figure 11 The specific figures shown may vary.

[0151] Multiple channels within the 5 GHz band include the unlicensed National Information Infrastructure (UNII)-1, UNII-2, UNII-3, and ISM. UNII-1 may be referred to as the lower UNII. UNII-2 may include frequency ranges referred to as the middle UNII and the extended UNII-2. UNII-3 may be referred to as the upper UNII.

[0152] Within the 5 GHz band, multiple channels can be configured, and the bandwidth of each channel can be configured differently, 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 using a 40 MHz frequency domain. The 5170 MHz to 5330 MHz frequency domain / range can be divided into two channels using an 80 MHz frequency domain. Alternatively, the 5170 MHz to 5330 MHz frequency domain / range can be divided into one channel using a 160 MHz frequency domain.

[0153] Figure 12 The illustration shows an example of a channel used / supported / defined within the 6 GHz band.

[0154] The 6 GHz band can be referred to by other names, such as the third band / band. The 6 GHz band can refer to the frequency range that uses, supports, and defines channels with center frequencies higher than 5.9 GHz. Figure 12 The specific values ​​shown may change.

[0155] For example, it can be defined starting from 5.940 GHz. Figure 12 The 20 MHz channel. Specifically, Figure 12 The leftmost channel in the 20 MHz channel array can have an index of 1 (or channel index, channel number, etc.) and be assigned a center frequency of 5.945 GHz. In other words, the center frequency of channel index N can be determined as (5.940 + 0.005 GHz). (N) GHz.

[0156] therefore, Figure 12The index (or channel number) of the 20 MHz channel can be 1, 5, 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49, 53, 57, 61, 65, 69, 73, 77, 81, 85, 89, 93, 97, 101, 105, 109, 113, 117, 121, 125, 129, 133, 137, 141, 145, 149, 153, 157, 161, 165, 169, 173, 177, 181, 185, 189, 193, 197, 201, 205, 209, 213, 217, 221, 225, 229, 233. Furthermore, according to the above (5.940+0.005) N)GHz rules, Figure 12 The index of the 40 MHz channel 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.

[0157] Figure 13 Examples of modifications to the transmitting and / or receiving apparatus of this disclosure are shown.

[0158] It is possible Figure 13 Modifications shown Figures 1 to 4 The device shown (e.g., AP STA, non-AP STA). Figure 13 The transceiver 630 can be used with Figure 1 The transceivers 113 and 123 are the same. Figure 13 The transceiver 630 may include a receiver and a transmitter.

[0159] Figure 13 The processor 610 can be with Figure 1 The processors 111 and 121 are the same. Alternatively, Figure 13 The processor 610 can be with Figure 1 The processing chips 114 and 124 are the same.

[0160] Figure 13 The memory 150 can be with Figure 1 The memory modules 112 and 122 are identical. Alternatively, Figure 13 The memory 150 can be different Figure 1 Separate external memories for memories 112 and 122.

[0161] Reference Figure 13The power management module 611 manages the power of the processor 610 and / or transceiver 630. The battery 612 supplies power to the power management module 611. The display 613 outputs the results processed by the processor 610. The keyboard 614 receives input to be used by the processor 610. The keyboard 614 may be displayed on the display 613. The SIM card 615 may be an integrated circuit for securely storing the International Mobile Subscriber Identity (IMSI) and its associated keys, used for identifying and authenticating users in mobile devices such as mobile phones and computers.

[0162] Reference Figure 13 The speaker (640) can output the sound-related results processed by the processor 610. The microphone (641) can receive sound-related inputs to be used by the processor 610.

[0163] The following describes the multi-AP operation applied in this manual.

[0164] Multi-AP operation refers to communication techniques involving multiple APs in a WLAN. For example, multi-AP operation can refer to the operation of one or more APs sending and receiving information to one or more STAs. Compared to multi-AP operation, existing technologies can use various terms to express this, such as STX (Single Transmission). For example, STX operation can refer to a method where one BSS AP communicates with one BSS STA. When communication is performed based on STX operation, interference with neighboring APs (e.g., APs located in overlapping BSSs) may occur. This interference can lead to degraded transmit and receive performance for cell-edge users (e.g., non-AP STAs located at the edge of the BSS).

[0165] Figure 14 The diagram illustrates the operation according to standard STX procedures. As shown, adjacent AP1 and AP2 can cause interference between the STA and AP.

[0166] To improve STX operation, a novel multi-AP operation is proposed. This multi-AP operation can be based on techniques to reduce various interferences (such as inter-symbol interference (ISI)) through coordination with neighboring APs (e.g., APs located in overlapping BSSs).

[0167] exist Figure 14 In this context, STA1 and AP1 can be included in the BSS, and STA2 and AP2 can be included in the OBSS (Overlapping Basic Service Set). That is, STA2 can be an STA unrelated to AP1, and STA1 can be an STA unrelated to AP2.

[0168] For example, multi-AP operation can be categorized into various technologies / types / formats / protocols, etc. For instance, multi-AP operation may include coordinated TDMA (C-TDMA), which differentiates the radio resources allocated to multiple APs based on a time axis (time domain). Alternatively, multi-AP operation may include coordinated OFDMA (C-OFDMA), which differentiates the radio resources allocated to multiple APs based on a frequency axis (time domain). Alternatively, multi-AP operation may include coordinated spatial reuse (C-SR) that applies spatial reuse (SR) to at least one AP. Alternatively, multi-AP operation may include coordinated beamforming (CBF) / nulling that nulls interference generated from neighbors (e.g., neighboring APs / STAs and / or OBSS APs / OBSS STAs) and transmits it. Alternatively, multi-AP operation may include AP selection, where the AP with good channel conditions among neighboring APs (e.g., at least one AP located within a BSS or OBSS and with good channel conditions) transmits. Additionally or alternatively, multi-AP operation may include joint transmission (JTX) or JT, in which multiple APs (e.g., multiple APs included in the same BSS / OBSS, or multiple APs included in different BSS / OBSS) cooperate to perform simultaneous transmission and reception, and JTX / JT may be implemented based on joint beamforming or joint MU-MIMO.

[0169] Figure 15 An example of coordinated OFDMA (C-OFDMA) is illustrated. AP1 can send PPDU / signals to STA1, and AP2 can send PPDU / signals to STA2. Transmissions from AP1 and from AP2 can occur in the same / overlapping time intervals. Transmissions from AP1 to STA1 can be performed based on a first frequency band, and transmissions from AP2 to STA2 can be performed based on a second frequency band different from the second frequency band. For example, in... Figure 15 In this context, STA1 and AP1 can be included in the BSS, while STA2 and AP2 can be included in the OBSS. That is, STA2 can be an STA that is not associated with AP1, and STA1 can be an STA that is not associated with AP2.

[0170] Although Figure 15 Although not shown, examples of coordinated TDMA (C-TDMA) are possible. For example, the acquired TXOP can be divided into specific time units (e.g., time slots), and the divided time slots can be sequentially assigned to multiple different APs.

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

[0172] AP1 performing C-OFDMA can act as a shared AP or a primary AP. That is, AP1 can request at least one neighboring AP (e.g., AP2 in the BSS / OBSS) to report information about channel and / or buffer status. Based on this, AP1 can obtain TXOP and share a portion of frequency resources (e.g., a 20MHz subchannel or a specific-sized RU) with at least one nearby AP (e.g., AP2 present in the BSS / OBSS) for all or part of the time interval associated with the TXOP.

[0173] Figure 16 An example of coordinated beamforming (CBF) is illustrated. AP1 can send a PPDU / signal to STA1, and AP2 can send a PPDU / signal to STA2. Transmissions from AP1 and AP2 can occur within the same / overlapping time intervals. Transmissions from AP1 and AP2 can occur via the same / overlapping frequency bands. To reduce interference from AP1 to STA2, AP1 can perform nulling / beamforming on STA2, and to reduce interference from AP2 to STA1, AP2 can perform nulling / beamforming on STA1. For example, such nulling / beamforming can be implemented by nulling radiation for adjacent unassociated STAs. The aforementioned nulling / beamforming can make a particular AP invisible to adjacent unassociated STAs. For example, the aforementioned nulling / beamforming can make AP1 (or AP2) invisible to STA2 (or STA1).

[0174] For example, in Figure 16 In this context, STA1 and AP1 can be included in the BSS, while STA2 and AP2 can be included in the OBSS. In other words, STA2 can be an STA unrelated to AP1, and STA1 can be an STA unrelated to AP2.

[0175] Although not in Figure 16 As shown, however, control signals (e.g., coordination frames) for null / beamforming between AP1 and STA2 and / or between AP2 and STA1 can be sent and received via the backhaul link between AP1 and AP2.

[0176] Figure 17 The illustration shows an example of AP selection. AP2 is shown as having better channel conditions than AP1. AP1 sends its data / signals to AP2 via the backhaul link, and AP2 can send signals to STA1 instead of AP1. For example, in... Figure 17 In this context, STA1 and AP1 can be included in the BSS, while STA2 and AP2 can be included in the OBSS. In other words, STA2 can be an STA unrelated to AP1, and STA1 can be an STA unrelated to AP2.

[0177] Figure 18 An example of JTX / JT is illustrated. AP1 shown can transmit to STA1 together with AP2. For example, the PPDU / signal transmitted from AP2 to STA1 can be wholly or partially the same as the PPDU / signal transmitted from AP1 to STA1. For example, the PPDU / signal transmitted from AP2 to STA1 can be transmitted simultaneously in the same / overlapping frequency band as the PPDU / signal transmitted from AP1 to STA1. For example, the PPDU / signal transmitted from AP2 to STA1 can be a signal transmitted from AP1 via the backhaul link. For example, in... Figure 18 In this context, STA1 and AP1 can be included in the BSS, while STA2 and AP2 can be included in the OBSS. That is, STA2 can be an STA that is not associated with AP1, and STA1 can be an STA that is not associated with AP2.

[0178] More specifically, in Figure 18 In this process, AP1 can send a coordination request (or may be named differently, such as First Request, Control Request, etc.) to AP2 and receive a coordination response (or may be named differently, such as First Response, Control Response, etc.) from AP2. Through the exchange of requests / responses, information can be exchanged regarding the coordination between AP1 and AP2 (e.g., whether AP1 and AP2 will perform simultaneous transmission to STA1), the start time of coordination, the start time of simultaneous transmission to STA1 by AP1 and AP2, and the data shared between AP1 and AP2. AP1 can share its data with AP2 via the backhaul link. Subsequently, AP1 can send a coordination trigger frame (or may be named differently, such as Trigger Frame) to AP2 and perform simultaneous transmission to STA1 based on this trigger frame.

[0179] <Implementation methods applicable to this specification>

[0180] To enable terminals to maintain continuous WLAN connectivity over a wider area, multiple access points (APs) are installed adjacent to each other. However, overlapping BSSs of multiple APs can lead to problems such as radio interference and transmission conflicts between APs. To address these issues, various techniques have been proposed to coordinate APs in the frequency, time, and spatial domains (e.g., RU selection, joint transmission, null traps, etc.). Furthermore, attention should be paid to various problems that may arise during AP coordination.

[0181] In EHT (802.11be), a technique was proposed for allocating time within a TXOP acquired by the AP to support peer-to-peer (P2P) transmissions to non-AP STAs. To this end, a new TXOP sharing mode subfield is defined in the common information field of the existing MU-RTS trigger frame, and the MU-RTS (Multi-User Request Transmission) trigger frame with a non-zero value is called a MU-RTS TXOP sharing (TXS) trigger frame (TF). If the TXOP sharing mode value is 1, the non-AP STA supports one or more (non-TB) PPDU transmissions to the AP, and if the TXOP sharing mode value is 2, the non-AP STA supports P2P transmissions in addition to (non-TB) PPDU transmissions to the AP.

[0182] Figure 19 An example of coordinating TDMA operations is illustrated.

[0183] Furthermore, if the existing trigger TXOP sharing protocol is used for multi-AP coordination, frame switching can be performed without mutual interference by dividing the transmissions within the BSS of each cooperating AP into time units. That is, Figure 19 An example of Coordinated Time Division Multiple Access (Co-TDMA) based on time units is shown in the coordination method among cooperating APs.

[0184] At this point, the AP in the existing Triggered TXS protocol can act as the AP sharing the TXOP in multi-AP coordination operations, and the STA in the existing Triggered TXS protocol can also act as the AP sharing the TXOP in multi-AP coordination operations. In this specification, the AP sharing the TXOP is referred to as the sharing AP (SAP), and the AP receiving the TXOP from the SAP is referred to as the shared AP (DAP). Here, the SAP sharing the TXOP is not limited to AP STAs, but can also include non-AP STAs sharing the TXOP. Furthermore, the DAP sharing the TXOP is not limited to AP STAs, but can also include non-AP STAs sharing the TXOP (or transmitting and receiving with the AP STA sharing the TXOP). Additionally, frame exchange with non-AP STAs or SAPs belonging to the DAP BSS during the time allocated to the DAP is called DAP BSS frame exchange (FE). For example, frame switching may include data frame transmission and block ACK frame response following RTS / CTS frame switching between DAP and non-AP STA, UL data frame transmission by non-AP STA in response to a trigger frame sent from DAP, or data frame transmission by DAP in response to a trigger frame sent from SAP.

[0185] exist Figure 19 In the presented example of C-TDMA operation, since the entity sharing the TXOP (i.e., SAP) and the entity receiving the TXOP (i.e., DAP) are APs with different BSSs, non-AP STAs receiving frames transmitted during the FE process between them set the NAV (Network Assignment Vector). Specifically, STAs belonging to the AP's BSS receive / detect frames transmitted from the AP and set the intra-BSS NAV, while STAs not belonging to the AP's BSS set the basic NAV. That is, in C-TDMA, due to frame transmission within the SAP's BSS, non-AP STAs within the DAP's BSS may not be able to perform FE with the DAP by setting the basic NAV. Therefore, protection rules related to NAV setting must be applied precisely to ensure smooth cooperation and FE between APs within each BSS.

[0186] Figure 20 The illustration shows an example of a basic NAV setup using CTS frames in MU-RTS TXS trigger / CTS frame switching.

[0187] Figure 21 The illustration shows an example of a basic NAV setup problem using CTS frames.

[0188] Specifically, in such as Figure 20In this topology, non-AP STAs (connected to the DAP) that receive / detect response frames (e.g., CTS or ACK frames) to MU-RTS TXS TF (or control frames) sent from the SAP set their NAV based on the RA (i.e., the SAP's MAC address) included in the CTS frame. Therefore, since all non-AP STAs connected to the DAP can receive CTS frames, they set their basic NAV for the SAP, and it's possible that non-AP STAs may be unable to send UL PPDU / frames to the DAP during the time allocated from the SAP (see [link to DAP topology]). Figure 21 ).

[0189] Therefore, this specification proposes a method to resolve a fundamental NAV configuration problem that may occur in non-AP STAs connected to a DAP during the TXOP sharing process of C-TDMA via response frames to MU-RTS TXS TF sent from SAP.

[0190] The method for preventing basic NAV problems caused by response frames, as presented in this specification, allows a non-AP STA connected to the DAP that receives a response frame to send a UL PPDU / frame to the DAP without setting a basic NAV. The specific naming (names) presented in this specification are subject to change and are not limited.

[0191] 1. A method to replace the DAP's response frame to the MU-RTS TXSTF sent by SAP during the C-TDMA TXOP sharing process with a CTS-to-Self frame.

[0192] This specification describes a problem in which a non-AP STA (associated with the DAP) receiving a CTS frame sent from the DAP during a C-TDMA TXOP sharing process sets up a basic NAV for the SAP.

[0193] In the C-TDMA TXOP sharing process according to this disclosure, the response frame of the DAP to the MU-RTS TXS TF sent by the SAP can be replaced by a CTS-to-Self frame. That is, by sending a CTS-to-Self frame instead of a CTS frame as a response frame to the MU-RTS TXS TF that can be sent to share the TXOP with the DAP, the non-AP STA connected to the DAP that receives the response frame is prevented from setting the basic NAV.

[0194] The C-TDMA process using the CTS-to-Self frame as the response frame as described in this specification can be defined as follows.

[0195] Figure 22The illustration shows an example of the frame format when using CTS-to-Self frames during C-TDMA TXOP sharing.

[0196] Figure 22 This illustrates an example of the frame format when a CTS-to-Self frame is used as a response frame to a MU-RTS TXSTF during a C-TDMA TXOP sharing process. When responding using a regular CTS frame, because the SAP's address is included in the RA field, non-AP STAs connected to the DAP receive the CTS frame and set the basic NAV for the SAP. This may cause issues for non-AP STAs connected to the DAP. Figure 21 The basic NAV problem presented in the diagram can be addressed using CTS-to-Self frames. Specifically, the DAP can respond to the reception of the MU-RTS TXS TF using CTS-to-Self frames. Since the frame exchange here differs from the basic triggered TXOP sharing process and the response to the MU-RTS TXS TF, the SAP can indicate a different mode (e.g., mode = 0, 1, and 2) by defining the value (i.e., 3) in the TXOP sharing mode subfield of the MU-RTS TXS TF's common information field, or by signaling the new operation / mode using reserved bits (i.e., B29-B38) in the MU-RTS TXS TF's common information field (in addition to the TXOP sharing mode subfield). Furthermore, new trigger types for C-TDMA operation can be defined and utilized by using reserved bits (B8-B15) in the trigger type field of the MU-RTS TXS TF's common information field.

[0197] Therefore, the DAP receiving the aforementioned C-TDMA MU-RTS TXS TF (i.e., the trigger frame defined by using a new mode or signaling bits or a new trigger type) responds with a CTS-to-Self frame including a TA field with its own address, and the non-AP STA connected to the DAP that receives the CTS-to-Self frame can set an intra-BSS NAV. That is, the non-AP STA connected to the DAP is protected by the set intra-BSS NAV and can send ULPPDU / frames to the DAP within the allocated time.

[0198] The C-TDMA process using CTS-to-Self frames as response frames as described in this specification can be operated in the following embodiments: 1) Implementation method of C-TDMA process using CTS-to-Self frames Figure 23Example 1 illustrates a C-TDMA process utilizing CTS-to-Self frames.

[0199] Figure 23 The illustration shows an implementation (1) of the C-TDMA TXOP sharing process, in which the DAP, having received the MU-RTS TXS TF sent from the SAP, responds with a CTS-to-Self frame. Implementation (1) assumes that a portion of the entire TXOP interval acquired by the SAP is shared, and the SAP can send a newly defined or modified MU-RTS TXS TF (i.e., a trigger frame using a new mode, signaling bits, or trigger type), allowing the DAP to respond with a CTS-to-Self frame. The DAP, having received the MU-RTS TXS TF, responds with a CTS-to-Self frame, and a non-AP STA connected to the DAP that has received the CTS-to-Self frame can set an NAV within the BSS. That is, the DAP and non-AP STAs (connected to the DAP) can perform separate FEs within BSS2 during the time allocated via the MU-RTS TXSTF.

[0200] 2) Example 2 of C-TDMA process using CTS-to-Self frames

[0201] Figure 24 Example 2 illustrates a C-TDMA process utilizing CTS-to-Self frames.

[0202] Figure 24The illustration shows the TXOP sharing process of C-TDMA in Implementation 2, where a DAP that has received a MU-RTS TXS TF sent from an SAP responds with a CTS-to-Self frame. Implementation 2 assumes a TXOP sharing method in which participating APs in C-TDMA gradually acquire TXOPs and switch TXOP holders, and essentially, each AP performs media contention to acquire a TXOP corresponding to the nominal duration. The nominal duration here can be considered as the TXOP duration of TXOP sharing among participating APs and the general multiple frame exchange sequence required / expected by each FE, which is less than or equal to the TXOP limit. The AP acquiring the TXOP and acting as SAP sends a trigger or control frame (Ctrl frame) that includes only the time required by the FE of its STA within its BSS (i.e., t1) in the Duration / ID field, instead of including the TXOP duration corresponding to the nominal duration encompassing the entire expected C-TDMA operation in the Duration / ID field, and acquires and secures the TXOP only for this time period. In other words, the holder of the TXOP from the time of acquisition to time t1 is SAP, and during this period, SAP can execute the individual FE required by SAP.

[0203] After completing the FE with its own STA within its BSS, the SAP can send a newly defined or modified MU-RTS TXS TF (i.e., a trigger frame using a new mode or signaling bits or a new trigger type) within time t1, allowing the DAP to respond with a CTS-to-Self frame for the TXOP shared with the DAP. The SAP terminates its TXOP while sending the MU-RTS TXS TF, and the DAP that allocated time via the MU-RTS TXS TF can respond to the reception of the MU-RTS TXS TF and send a CTS-to-Self frame for the purpose of NAV allocation (setting) for the allocated time. That is, a non-AP STA connected to the DAP that receives the CTS-to-Self frame can set the NAV within the BSS. This allows the DAP and non-AP STAs to perform separate FEs within BSS2 during the allocated time period.

[0204] This specification addresses the fundamental NAV (Network Access Vault) and protection issues arising during C-TDMA TXOP sharing processes for non-AP STAs (connected to the DAP) receiving CTS frames sent by the DAP in response to a MU-RTS TXS TF sent from the SAP. To address this, this specification proposes a method that replaces the response frame sent from the DAP with a CTS-to-Self frame. By utilizing the proposed CTS-to-Self frame response, a non-AP STA connected to the DAP can set an intra-BSS NAV upon receiving the CTS-to-Self frame and then perform a separate FE (Front-End Function) with the DAP during the allocated time period (e.g., data frame transmission following RTS / CTS frame exchange between the DAP and non-AP STAs, and block ACK frame response, in response to a trigger frame sent from the DAP for UL data frame transmission by the non-AP STA).

[0205] Figure 25 This is a flowchart illustrating the operation of the sending method according to this embodiment.

[0206] Figure 25 Examples can be performed at the transmitting device (AP and / or non-AP STA).

[0207] In this implementation, the SAP and DAP described above can be included in the AP.

[0208] Figure 25 Some steps in the example (or the detailed sub-steps described below) may be omitted or modified.

[0209] S2510: The duration / ID field generated by the transmitting device (transmit STA) may include the time covering the entire C-TDMA operation (TXOP duration) or the time required for frame switching within a single BSS.

[0210] S2520: In step S2520, the transmitting device may configure an MPDU including a trigger frame, which includes the duration field configured in S2510. Additionally, the transmitting device may configure / generate a PPDU including the MPDU in the data field. This step of configuring / generating the PPDU may include configuring / generating each field of the PPDU. That is, step S2520 includes configuring the UHR-SIG field and the data field. This may include configuring a field including control information (i.e., an N-bitmap) indicating the size / location of the RU and / or configuring a field including the identifier (i.e., AID) of the STA receiving the RU.

[0211] Additionally, step S2520 may include generating an STF / LTF sequence to be transmitted via a specific RU. The STF / LTF sequence may be generated based on a preset STF generation sequence / LTF generation sequence.

[0212] Step S2520 may also include generating an MPDU to be sent via a specific RU.

[0213] The transmitting device can send the PPDU configured as described above to the receiving device.

[0214] During PPDU transmission, the transmitting device may perform at least one of the following operations: CSD, spatial mapping, IDFT / IFFT operation, and GI insertion.

[0215] The signals / fields / sequences configured according to this instruction manual can be used as follows: Figure 5 Send in the format shown.

[0216] Figure 26 This is a flowchart illustrating the operation of the receiving method according to this embodiment.

[0217] According to Figure 26 The example is used to receive the above PPDU.

[0218] Figure 26 Examples can be performed by the receiving device (AP and / or non-AP STA).

[0219] It can be omitted Figure 26 Some steps of the example (or detailed sub-steps described below).

[0220] S2610: The receiving device (receiving STA) can receive all or part of the PPDU through step S2610. The received signal may have Figure 5 As shown in the figure.

[0221] The sub-steps of step S2610 can be determined based on step S2520. Specifically, step S300 can perform operations to recover the results of the CSD, spatial mapping, IDFT / IFFT operations, and GI insertion operations applied in step S2520.

[0222] S2620: The receiving device can decode all or part of the PPDU. Furthermore, the receiving device can obtain control information related to the tone plan (i.e., RU) from the decoded PPDU.

[0223] More specifically, the receiving device can decode the L-SIG and EHT-SIG fields of the PPDU based on conventional STF / LTF and obtain the information contained in the L-SIG and EHTSIG fields.

[0224] Furthermore, the receiving device can decode the remaining portion of the PPDU based on the tone plan (i.e., RU) information obtained through step S2620. For example, the receiving device can decode the STF / LTF field of the PPDU based on the tone plan information. Additionally, the receiving device can decode the data field of the PPDU based on the tone plan information and obtain the MPDU contained within the data field.

[0225] Furthermore, through step S2620, the receiving device can perform a processing operation to forward the decoded data to a higher layer (i.e., the MAC layer). Additionally, if a signal indicating the generation of a signal from the upper layer to the PHY layer is generated in response to the data sent to the upper layer, subsequent operations can be performed.

[0226] S2630: When decoding the data field, the receiving device can obtain the time information used to set the NAV from the duration field.

[0227] The receiving STA can then perform processing operations to send the data decoded from the data field to a higher layer (e.g., the MAC layer). Furthermore, if the higher layer instructs the PHY layer to generate a signal in response to the data being sent, subsequent operations can be performed.

[0228] Based on the data obtained through step S2630, the receiving STA can set the basic NAV or the NAV within the BSS.

[0229] Figure 27 This is a flowchart illustrating the operation of the transmitting device according to this embodiment.

[0230] Figure 27 Examples can be performed by the transmitting device (AP and / or non-AP STA).

[0231] Figure 27 Some steps in each step of the example (or detailed sub-steps described later) can be skipped / omitted.

[0232] Through step S2710, the transmitting device (transmitting STA) can obtain information about the aforementioned tone plan. As described above, the information about the tone plan includes the size and location of the RU, control information related to the RU, information about the frequency band including the RU, and information about the STA receiving the RU, etc.

[0233] In step S2720, the transmitting device can construct / generate a PPDU based on the acquired control information. Configuring / generating a PPDU may include configuring / generating each field of the PPDU. Specifically, step S2720 includes configuring the EHT-SIG field, which includes control information regarding tone planning. In other words, step S2720 includes configuring fields including control information (e.g., an N-bitmap) indicating the size / location of the RU; and / or configuring fields including the identifier (e.g., AID) of the STA receiving the RU.

[0234] Furthermore, step S2720 may include generating an STF / LTF sequence transmitted via a specific RU. The STF / LTF sequence may be generated based on a preset STF generation sequence / LTF generation sequence.

[0235] In addition, step S2720 may include generating a data field (i.e., MPDU) sent through a specific RU.

[0236] The transmitting device can send the PPDU constructed in step S2720 to the receiving device based on step S2730.

[0237] When performing step S2730, the transmitting device may perform at least one of the following operations: such as CSD, spatial mapping, IDFT / IFFT operation and GI insertion.

[0238] The signals / fields / sequences constructed according to this specification can be used as follows: Figure 5 Send in the form of.

[0239] Figure 28 This is a flowchart illustrating the operation of the receiving device according to this embodiment.

[0240] According to Figure 28 The example is used to receive the above PPDU.

[0241] Figure 28 Examples can be performed by the receiving device / app (AP and / or non-AP STA).

[0242] Figure 28 Some steps in each step of the example (or detailed sub-steps described later) can be skipped / omitted.

[0243] The receiving device (receiving STA) can receive all or part of the PPDU through step S2810. The received signal can be used... Figure 5 In the form of.

[0244] The sub-steps of step S2810 can be based on Figure 27Step S2730 is determined. That is, in step S2810, the results of the CSD, spatial mapping, IDFT / IFFT operations and GI insertion operations applied in step S2730 can be recovered.

[0245] In step S2820, the receiving device can perform decoding on all or part of the PPDU. Furthermore, the receiving device can obtain control information related to the tone plan (i.e., RU) from the decoded PPDU.

[0246] More specifically, the receiving device can decode the L-SIG and EHT-SIG of the PPDU based on conventional STF / LTF and obtain the information included in the L-SIG and EHT SIG fields. The information about various tone schemes (i.e., RUs) described in this specification can be included in the EHT-SIG, and the receiving STA can obtain information about tone schemes (i.e., RUs) through the EHT-SIG.

[0247] In step S2830, the receiving device can decode the remaining portion of the PPDU based on information about the tone plan (i.e., RU) obtained in step S2820. For example, the receiving STA can decode the STF / LTF field of the PPDU based on information about a plan (i.e., RU). Additionally, the receiving STA can decode the data field of the PPDU based on information about the tone plan (i.e., RU) and obtain the MPDU included in the data field.

[0248] Additionally, the receiving device can perform a processing operation to transmit the data decoded in step S2830 to a higher layer (e.g., the MAC layer). Furthermore, when a signal indicating the transmission from the upper layer to the PHY layer is generated in response to data sent to the upper layer, subsequent operations can be performed.

[0249] In the following text, reference will be made to Figures 1 to 28 The above-described implementation method is described.

[0250] Figure 29 This is a flowchart illustrating the process of the TXOP sharing method using CTS-to-Self frames on the shared AP side according to this embodiment.

[0251] Figure 29 The example can be implemented in network environments that support next-generation wireless LAN systems (Ultra-High Reliability (UHR) wireless LAN systems or next-generation Wi-Fi). Next-generation wireless LAN systems are an improved version of the 802.11be system and meet backward compatibility requirements with the 802.11be system.

[0252] Can be executed in the second AP Figure 29For example, a second AP can be set as a shared AP (SAP) after negotiation in multi-AP communication, and a first AP can be set as a shared AP (DAP) after negotiation in multi-AP communication. The first non-AP STA and the second non-AP STA in this embodiment can correspond to at least one station (STA).

[0253] This implementation proposes a method for performing TXOP sharing by utilizing CTS-to-Self frames when performing C-TDMA operation (or multi-AP operation) in multi-access point (multi-AP) communication. Specifically, this implementation proposes a method for performing frame exchange with the DAP without being affected by the SAP's NAV by allowing a non-AP STA connected to the DAP to set an intra-BSS NAV when receiving CTS-to-Self frames that include a TA field instead of a RA field.

[0254] In step S2910, the second access point (AP) sends a Multi-User Request Transmission (MU-RTS) Transmission Opportunity (TXOP) Sharing (TXS) trigger frame to the first AP.

[0255] In step S2920, the second AP receives a Clear Transmit (CTS)-to-Self frame from the first AP.

[0256] The first frame is exchanged between the first AP and the first non-AP station (STA).

[0257] At this point, the second AP is a shared AP that controls the cooperation between multiple APs, and the first AP is a shared AP that receives resources allocated or shared from the shared AP. The first non-AP STA is a non-AP STA within the basic service set (BSS) of the first AP.

[0258] Technologies for collaboration among multiple access points (APs) can include collaborative multi-AP technologies, such as collaborative time division multiple access (C-TDMA), collaborative spatial reuse (C-SR), collaborative beamforming (C-BF), or collaborative orthogonal frequency division multiple access (C-OFMA).

[0259] In the C-TDMA operation example, the entity sharing the TXOP (SAP, here the second AP) and the entity receiving the TXOP (DAP, here the first AP) are APs with different BSSs. That is, because frame transmission within the SAP's BSS may cause non-AP STAs within the DAP's BSS to set a basic NAV and be unable to smoothly exchange frames with the DAP, protection rules related to Network Allocation Vector (NAV) settings must be precisely applied to ensure smooth cooperation between APs and frame exchange within each BSS. Specifically, non-AP STAs connected to the DAP can receive / detect frames sent from the SAP or non-AP STAs connected to the SAP, as well as CTS frames sent from the DAP, and set a basic NAV for the SAP. At this point, a non-AP STA connected to the DAP may be unable to send UL PPDUs or frames to the DAP due to the basic NAV.

[0260] However, this embodiment proposes a TXOP sharing method that, in response to a MU-RTS TXS trigger frame, uses (or replaces) CTS-to-Self frames instead of CTS frames to perform the C-TDMA procedure. The C-TDMA operation allows the DAP and some non-AP STAs within the DAP's BSS to exchange frames with the DAP without being affected by the SAP's NAV.

[0261] Specifically, the Network Assignment Vector (NAV) within the BSS is set for the first non-AP STA based on the CTS-to-Self frame. The CTS-to-Self frame may include a transmitter address (TA) field, but may not include a receiver address (RA) field. The TA field may include the address of the first AP (because the CTS-to-Self frame is sent from the first AP).

[0262] That is, the DAP (first AP) responds to the MU-RTS TXS trigger frame by sending a CTS-to-Self frame including a TA field with its own address, and the non-AP STA (first non-AP STA) connected to the DAP that receives the CTS-to-Self frame can set the NAV within the BSS due to the CTS-to-Self frame. Therefore, the first non-AP STA can be protected by the NAV within the BSS and can exchange the first frame with the first AP.

[0263] Furthermore, this implementation proposes a TXOP sharing method in which APs participating in C-TDMA gradually occupy TXOPs, and the TXOP holder switches from SAP to DAP.

[0264] The first TXOP can be switched to the second TXOP starting from the transmission of the MU-RTS TXS trigger frame. The first TXOP can be a TXOP acquired by the second AP, and the second TXOP can be a TXOP acquired by the first AP.

[0265] The first TXOP can end at the very first moment of sending the MU-RTS TXS trigger frame. The second AP can exchange a second frame with the second non-AP STA until the first moment. The second non-AP STA can be a non-AP STA within the BSS of the second AP. The second frame can include a second trigger frame or a second control frame. The duration or ID field of the second trigger frame or second control frame can include information about the first moment.

[0266] The second TXOP can end at a second time after the exchange of the first frame is completed. The second time can be determined based on the value of the allocation duration subfield in the user information field of the MU-RTS TXS trigger frame. Additionally, the first frame may include either a first trigger frame or a first control frame. The duration or ID field of the first trigger frame or first control frame may include information about the second time.

[0267] Additionally, the SAP (second AP) can redefine or modify the MU-RTS TXS trigger frame, allowing the DAP (first AP) to respond with a CTS-to-Self frame for TXOP sharing. The SAP can send the MU-RTS TXS trigger frame to the DAP until the first moment.

[0268] For example, a CTS-to-Self frame can be responded to based on the value of the TXOP shared mode subfield in the common information field of the MU-RTS TXS trigger frame, the reserved bits of the MU-RTS TXS trigger frame (e.g., B29-B38), or the reserved bits of the trigger type subfield in the common information field (e.g., B8-B15). In this case, the value of the TXOP shared mode subfield can be set to 3.

[0269] In other words, this implementation has the following effect: by replacing the response to the MU-RTS TXS trigger frame sent from the SAP during the C-TDMA-based TXOP sharing process with CTS-to-Self frames instead of CTS frames, non-APSTAs connected to the DAP can smoothly exchange frames with the DAP without the SAP setting a default NAV. That is, due to the CTS-to-Self frames, non-AP STAs connected to the DAP can set the NAV within the BSS instead of the default NAV for the SAP, allowing the DAP and non-AP STAs to perform separate frame exchanges during their allocated time periods. This has the effect of allowing appropriate scheduling based on cooperation between multiple APs and can be expected to increase the overall network throughput.

[0270] Figure 30 This is a flowchart illustrating the process of TXOP sharing using CTS-to-Self frames on the shared AP side according to this embodiment.

[0271] Figure 30 The example can be executed in network environments that support next-generation wireless LAN systems (Ultra-High Reliability (UHR) wireless LAN systems or next-generation wireless LAN systems). Next-generation wireless LAN systems are an improved version of the 802.11be system and meet backward compatibility requirements with the 802.11be system.

[0272] Can be executed in the first AP Figure 30 For example, after negotiation in multi-AP communication, a first AP can be set as a shared AP (DAP), and after negotiation in multi-AP communication, a second AP can be set as a shared AP (SAP). In this embodiment, the first non-AP STA and the second non-AP STA can correspond to at least one station (STA).

[0273] This implementation proposes a method for performing TXOP sharing by utilizing CTS-to-Self frames when performing C-TDMA operation (or multi-AP operation) in multi-access point (multi-AP) communication. Specifically, this implementation proposes a method for performing frame exchange with the DAP without being affected by the SAP's NAV by allowing a non-AP STA connected to the DAP to set an intra-BSS NAV when receiving CTS-to-Self frames that include a TA field instead of a RA field.

[0274] In step S3010, the first access point (AP) receives a Multi-User Request Transmission (MU-RTS) Transmission Opportunity (TXOP) Sharing (TXS) trigger frame from the second AP.

[0275] In step S3020, the first AP sends a Clear Transmission (CTS)-to-self frame to the second AP.

[0276] In step S3030, the first AP and the first non-AP station (STA) exchange the first frame.

[0277] At this point, the second AP is a shared AP that controls the cooperation between multiple APs, and the first AP is a shared AP that receives resources allocated or shared from the shared AP. The first non-AP STA is a non-AP STA within the basic service set (BSS) of the first AP.

[0278] Technologies used for collaboration among multiple access points (APs) may include collaborative multi-AP technologies such as collaborative time division multiple access (C-TDMA), collaborative spatial reuse (C-SR), collaborative beamforming (C-BF), or collaborative orthogonal frequency division multiple access (C-OFMA).

[0279] In the C-TDMA operation example, the entity sharing the TXOP (SAP, here the second AP) and the entity receiving the TXOP (DAP, here the first AP) are APs with different BSSs. That is, because frame transmission within the SAP's BSS may cause non-AP STAs within the DAP's BSS to set a basic NAV and be unable to smoothly exchange frames with the DAP, protection rules related to Network Allocation Vector (NAV) settings must be precisely applied to ensure smooth cooperation between APs and frame exchange within each BSS. Specifically, non-AP STAs connected to the DAP can receive / detect frames sent from the SAP or non-AP STAs connected to the SAP, as well as CTS frames sent from the DAP, and set a basic NAV for the SAP. At this point, a non-AP STA connected to the DAP may be unable to send UL PPDUs or frames to the DAP due to the basic NAV.

[0280] However, this embodiment proposes a TXOP sharing method that, in response to a MU-RTS TXS trigger frame, uses (or replaces) CTS-to-Self frames instead of CTS frames to perform the C-TDMA procedure. The C-TDMA operation allows the DAP and some non-AP STAs within the DAP's BSS to exchange frames with the DAP without being affected by the SAP's NAV.

[0281] Specifically, the Network Assignment Vector (NAV) within the BSS is set for the first non-AP STA based on the CTS-to-Self frame. The CTS-to-Self frame may include a Transmitter Address (TA) field, but may not include a Receiver Address (RA) field. The TA field may include the address of the first AP (because the CTS-to-Self frame is sent from the first AP).

[0282] That is, the DAP (first AP) responds to the MU-RTS TXS trigger frame by sending a CTS-to-Self frame including a TA field with its own address, and the non-AP STA (first non-AP STA) connected to the DAP that receives the CTS-to-Self frame can set the NAV within the BSS due to the CTS-to-Self frame. Therefore, the first non-AP STA can be protected by the NAV within the BSS and can exchange the first frame with the first AP.

[0283] Furthermore, this implementation proposes a TXOP sharing method, in which APs participating in C-TDMA gradually occupy TXOPs, and the TXOP holder switches from SAP to DAP.

[0284] The first TXOP can be switched to the second TXOP starting from the transmission of the MU-RTS TXS trigger frame. The first TXOP can be a TXOP acquired by the second AP, and the second TXOP can be a TXOP acquired by the first AP.

[0285] The first TXOP can end at the very first moment of sending the MU-RTS TXS trigger frame. The second AP can exchange a second frame with the second non-AP STA until the first moment. The second non-AP STA can be a non-AP STA within the BSS of the second AP. The second frame can include a second trigger frame or a second control frame. The duration or ID field of the second trigger frame or second control frame can include information about the first moment.

[0286] The second TXOP can end at a second time after the exchange of the first frame is completed. The second time can be determined based on the value of the allocation duration subfield in the user information field of the MU-RTS TXS trigger frame. Additionally, the first frame may include either a first trigger frame or a first control frame. The duration or ID field of the first trigger frame or first control frame may include information about the second time.

[0287] Additionally, the SAP (second AP) can redefine or modify the MU-RTS TXS trigger frame, allowing the DAP (first AP) to respond with a CTS-to-Self frame for TXOP sharing. The SAP can send the MU-RTS TXS trigger frame to the DAP until the first moment.

[0288] For example, a CTS-to-Self frame can be responded to based on the value of the TXOP shared mode subfield in the common information field of the MU-RTS TXS trigger frame, the reserved bits of the MU-RTS TXS trigger frame (e.g., B29-B38), or the reserved bits of the trigger type subfield in the common information field (e.g., B8-B15). In this case, the value of the TXOP shared mode subfield can be set to 3.

[0289] In other words, this implementation has the following effects: by replacing the response to the MU-RTS TXS trigger frame sent from the SAP during the C-TDMA-based TXOP sharing process with a CTS-to-Self frame instead of a CTS frame, non-AP STAs connected to the DAP can smoothly exchange frames with the DAP without the SAP setting a default NAV. That is, due to the CTS-to-Self frame, non-AP STAs connected to the DAP can set the NAV within the BSS instead of the default NAV for the SAP, allowing the DAP and non-AP STAs to perform separate frame exchanges during their allocated time periods. This has the effect of allowing appropriate scheduling based on cooperation between multiple APs and can be expected to increase the overall network throughput.

[0290] <Device Configuration>

[0291] The technical features of this disclosure can be applied to various apparatuses and methods. For example, they can be used... Figure 1 and / or Figure 13 The apparatus is used to execute / support the technical features of this disclosure. For example, the technical features of this disclosure may be applied only to... Figure 1 and / or Figure 13 Part of it. For example, the technical features of this disclosure may be based on Figure 1 The processing chips 114 and 124 are used to implement this, or it can be implemented based on processors 111 and 121 and memory 112 and 122, or based on... Figure 13 The processor 610 and memory 620 are used for implementation. For example, the apparatus according to this disclosure receives a Multiple User Request Transmission (MU-RTS) Transmission Opportunity (TXOP) Share (TXS) trigger frame from a second access point (AP); sends a Clear Transmission (CTS)-to-Self frame to the second AP; and exchanges a first frame with a first non-AP station (STA).

[0292] The technical features of this disclosure can be implemented based on a computer-readable medium (CRM). For example, the CRM according to this disclosure is at least one computer-readable medium including instructions designed to be executed by at least one processor.

[0293] The CRM can store instructions for performing operations, including: receiving a Multi-User Request Transmission (MU-RTS) Transport Opportunity (TXOP) Sharing (TXS) trigger frame from a second access point (AP); sending a Clear Transmission (CTS)-to-Self frame to the second AP; and exchanging a first frame with a first non-AP station (STA). At least one processor can execute the instructions stored in the CRM according to this disclosure. The at least one processor associated with the CRM of this disclosure may be... Figure 1 Processors 111, 121, Figure 1 Processing chips 114, 124 or Figure 13 The processor 610. Meanwhile, the CRM disclosed herein can be... Figure 1 Memory 112, 122, Figure 13 The memory 620, or a separate external memory / storage medium / disk.

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

[0295] Artificial intelligence (AI) refers to the field of research concerning artificial intelligence or the methods used to create it, while machine learning refers to the field of research concerning methods for defining and solving various problems within the field of AI. Machine learning is also defined as an algorithm that improves operational performance through stable operational experience.

[0296] Artificial neural networks (ANNs) are models used in machine learning, and can refer to models that solve problems in general, including artificial neurons (nodes) that form a network by combining synapses. An artificial neural network 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 the output value.

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

[0298] Model parameters refer to the parameters determined through learning, and include the weights of synaptic connections and the biases of neurons. Hyperparameters refer to the parameters that are set before learning in a machine learning algorithm, and include the learning rate, number of iterations, minimum batch size, and initialization function.

[0299] Learning artificial neural networks may aim to determine model parameters used to minimize a loss function. The loss function can be used as a metric for determining the optimal model parameters during the learning process of an artificial neural network.

[0300] Machine learning can be divided into supervised learning, unsupervised learning, and reinforcement learning.

[0301] Supervised learning refers to the method of training an artificial neural network using labels provided for the training data. When the training data is input into the artificial neural network, the labels indicate the correct answer (or result value) that the network should infer. Unsupervised learning refers to the method of training an artificial neural network without providing labels for the training data. Reinforcement learning can be a training method used to train an agent defined in an environment to select actions or sequences of actions to maximize the cumulative reward in each state.

[0302] Machine learning implemented using deep neural networks (DNNs) with multiple hidden layers is called deep learning, and deep learning is a part of machine learning. In the following text, machine learning is interpreted as including deep learning.

[0303] The aforementioned technical features can be applied to wireless communication for robots.

[0304] A robot can be defined as a machine that automatically processes or operates a given task using its own capabilities. In particular, a robot that has the ability to recognize its environment and make autonomous judgments to perform operations can be called an intelligent robot.

[0305] Depending on their application or field, robots can be categorized into industrial, medical, household, and military robots, among others. Robots can include actuators or drives that include motors to perform various physical operations, such as moving robot joints. Additionally, mobile robots can include wheels, brakes, propellers, etc., in their drives to move on the ground or fly in the air.

[0306] The aforementioned technical features can be applied to devices that support extended reality.

[0307] Extended reality is collectively referred to as virtual reality (VR), augmented reality (AR), and mixed reality (MR). VR technology is a computer graphics technology that provides real-world objects and backgrounds only in CG images; AR technology is a computer graphics technology that provides virtual CG images on top of real object images; and MR technology is a computer graphics technology that provides virtual objects that are mixed and combined with the real world.

[0308] MR technology is similar to AR technology in that it can display real and virtual objects together. However, in AR technology, virtual objects are used as a supplement to real objects, while in MR technology, virtual and real objects are used as equals.

[0309] XR technology can be applied to head-mounted displays (HMDs), head-up displays (HUDs), mobile phones, tablets, laptops, desktop computers, televisions, digital signage, and more. Devices that utilize XR technology can be referred to as XR devices.

[0310] The claims disclosed in this specification can be combined in various ways. For example, the technical features in the method claims of this specification can be combined to be implemented as a device, and the technical features in the device claims of this specification can be combined to be implemented by a method. Furthermore, the technical features in the method claims and device claims of this specification can be combined to be implemented as a device, and the technical features in the method claims and device claims of this specification can be combined to be implemented by a method.

Claims

1. A method in a wireless local area network, WLAN, system, the method comprising: receiving, by a first access point, AP, from a second AP, a multi-user request to send, MU-RTS, transmission opportunity, TXOP, sharing, TXS, trigger frame; sending, by the first AP, to the second AP, a clear to send, CTS-to-Self, frame; and exchanging, by the first AP, a first frame with a first non-AP station, STA, wherein the second AP is a sharing AP that controls cooperation among multiple APs, wherein the first AP is a shared AP that receives resources allocated or shared from the sharing AP, wherein the first non-AP STA is a non-AP STA within a basic service set, BSS, of the first AP, and wherein a BSS-internal network allocation vector, NAV, is set for the first non-AP STA based on the CTS-to-Self frame. the CTS-to-Self frame includes a transmitter address, TA, field and does not include a receiver address, RA, field, 2. The method of claim 1, wherein, wherein the TA field includes an address of the first AP, and wherein the first non-AP STA is protected by the BSS-internal NAV and exchanges the first frame with the first AP. switching a first TXOP to a second TXOP from a start of transmission of the MU-RTS TXS trigger frame, 3. The method of claim 2, wherein, wherein the first TXOP is a TXOP acquired by the second AP and the second TXOP is a TXOP acquired by the first AP, wherein the first TXOP ends at a first time at which the MU-RTS TXS trigger frame is sent, wherein the second AP exchanges a second frame with a second non-AP STA until the first time, and wherein the second non-AP STA is a non-AP STA within a BSS of the second AP. the second TXOP ends at a second time after completion of the exchange of the first frame, and 4. The method of claim 3, wherein, wherein the second time is determined based on a value of an allocation duration subfield of a user info field of the MU-RTS TXS trigger frame. responding to the CTS-to-Self frame based on a value of a TXOP sharing mode subfield in a common info field of the MU-RTS TXS trigger frame, a reserved bit of the MU-RTS TXS trigger frame, or a reserved bit of a trigger type subfield in the common info field, and 5. The method of claim 4, wherein, wherein the value of the TXOP sharing mode subfield is set to 3. the first frame includes a first trigger frame or a first control frame, 6. The method of claim 5, wherein, wherein a duration or ID field of the first trigger frame or the first control frame includes information about the second time, wherein the second frame includes a second trigger frame or a second control frame, wherein a duration or ID field of the second trigger frame or the second control frame includes information about the first time.

7. A first access point, AP, in a wireless local area network, WLAN, system, the first AP comprising: a memory; a transceiver; and a processor operatively connected to the memory and the transceiver, ​ ​ wherein the processor is configured to: receive, from a second AP, a multi-user request to send, MU-RTS, transmission opportunity, TXOP, sharing, TXS, trigger frame; send, to the second AP, a clear to send, CTS-to-Self, frame; and exchange, with a first non-AP station, STA, first frames, wherein the second AP is a sharing AP that controls cooperation among a plurality of APs, wherein the first AP is a shared AP that receives resources allocated or shared from the sharing AP, wherein the first non-AP STA is a non-AP STA within a basic service set, BSS, of the first AP, and wherein a BSS-internal network allocation vector, NAV, is set for the first non-AP STA based on the CTS-to-Self frame.

8. A method in a wireless local area network, WLAN, system, the method comprising: sending, by a second access point, AP, to a first AP, a multi-user request to send, MU-RTS, transmission opportunity, TXOP, sharing, TXS, trigger frame; and receiving, by the second AP, from the first AP, a clear to send, CTS-to-Self, frame, wherein first frames are exchanged between the first AP and a first non-AP station, STA, wherein the second AP is a sharing AP that controls cooperation among a plurality of APs, wherein the first AP is a shared AP that receives resources allocated or shared from the sharing AP, wherein the first non-AP STA is a non-AP STA within a basic service set, BSS, of the first AP, and wherein a BSS-internal network allocation vector, NAV, is set for the first non-AP STA based on the CTS-to-Self frame. the CTS-to-Self frame includes a transmitter address, TA, field and does not include a receiver address, RA, field, 9. The method of claim 8, wherein, wherein the TA field includes an address of the first AP, and wherein the first non-AP STA is protected by the BSS-internal NAV and exchanges the first frames with the first AP. switching a first TXOP to a second TXOP from a start of transmission of the MU-RTS TXS trigger frame, 10. The method of claim 9, wherein, wherein the first TXOP is a TXOP acquired by the second AP and the second TXOP is a TXOP acquired by the first AP, wherein the first TXOP ends at a first time at which the MU-RTS TXS trigger frame is sent, wherein the second AP exchanges second frames with a second non-AP STA until the first time, and wherein the second non-AP STA is a non-AP STA within a BSS of the second AP. the second TXOP ends at a second time after completion of the exchange of the first frames, and 11. The method of claim 10, wherein, wherein the second time is determined based on a value of an allocation duration subfield of a user info field of the MU-RTS TXS trigger frame.

9. A wireless local area network, WLAN, system comprising: a first access point, AP, configured to exchange first frames with a first non-AP station, STA, a second AP configured to send, to the first AP, a multi-user request to send, MU-RTS, transmission opportunity, TXOP, sharing, TXS, trigger frame, and receive, from the first AP, a clear to send, CTS-to-Self, frame, wherein the first AP is a shared AP that receives resources allocated or shared from the sharing AP, wherein the first non-AP STA is a non-AP STA within a basic service set, BSS, of the first AP, and wherein a BSS-internal network allocation vector, NAV, is set for the first non-AP STA based on the CTS-to-Self frame. the CTS-to-Self frame includes a transmitter address, TA, field and does not include a receiver address, RA, field, wherein the TA field includes an address of the first AP, and wherein the first non-AP STA is protected by the BSS-internal NAV and exchanges the first frames with the first AP. the first AP is configured to switch a first TXOP to a second TXOP from a start of transmission of the MU-RTS TXS trigger frame, wherein the first TXOP is a TXOP acquired by the second AP and the second TXOP is a TXOP acquired by the first AP, wherein the first TXOP ends at a first time at which the MU-RTS TXS trigger frame is sent, wherein the second AP is configured to exchange second frames with a second non-AP STA until the first time, and wherein the second non-AP STA is a non-AP STA within a BSS of the second AP. the second TXOP ends at a second time after completion of the exchange of the first frames, and wherein the second time is determined based on a value of an allocation duration subfield of a user info field of the MU-RTS TXS trigger frame.

12. The method of claim 11, wherein, responding to the CTS-to-Self frame based on a value of a TXOP share mode subfield in a common information field of the MU-RTS TXS trigger frame, a reserved bit of the MU-RTS TXS trigger frame, or a reserved bit of a trigger type subfield in the common information field, wherein the value of the TXOP share mode subfield is set to 3.

13. The method of claim 12, wherein, the first frame comprises a first trigger frame or a first control frame, wherein a duration or ID field of the first trigger frame or the first control frame comprises information about the second time, wherein the second frame comprises a second trigger frame or a second control frame, wherein a duration or ID field of the second trigger frame or the second control frame comprises information about the first time.

14. A second access point, AP, in a wireless local area network, WLAN, system, the second AP comprising: a memory; a transceiver; and a processor operatively connected to the memory and the transceiver, wherein the processor is configured to: send, to a first AP, a multi-user request to send, MU-RTS, transmission opportunity, TXOP, share, TXS, trigger frame; and receive, from the first AP, a clear to send, CTS-to-Self, frame, wherein a first frame is exchanged between the first AP and a first non-AP station, STA, wherein the second AP is a shared AP controlling cooperation between a plurality of APs, wherein the first AP is a shared AP receiving resources allocated or shared from the shared AP, wherein the first non-AP STA is a non-AP STA within a basic service set, BSS, of the first AP, and wherein a BSS-internal network allocation vector, NAV, is set for the first non-AP STA based on the CTS-to-Self frame.

15. A computer readable medium comprising instructions for execution by at least one processor and performing a method comprising: receiving, from a second access point, AP, a multi-user request to send, MU-RTS, transmission opportunity, TXOP, share, TXS, trigger frame; sending, to the second AP, a clear to send, CTS-to-Self, frame; and exchanging a first frame with a first non-AP station, STA, wherein the second AP is a shared AP controlling cooperation between a plurality of APs, wherein the first AP is a shared AP receiving resources allocated or shared from the shared AP, wherein the first non-AP STA is a non-AP STA within a basic service set, BSS, of the first AP, and wherein a BSS-internal network allocation vector, NAV, is set for the first non-AP STA based on the CTS-to-Self frame.

16. An apparatus in a wireless local area network, WLAN, system, the apparatus comprising: a memory; and a processor operatively connected to the memory, wherein the processor is configured to: receive, from a second access point, AP, a multi-user request to send, MU-RTS, transmission opportunity, TXOP, share, TXS, trigger frame; send, to the second AP, a clear to send, CTS-to-Self, frame; and exchanging a first frame with a first non-AP station STA, wherein the second AP is a shared AP that controls cooperation among multiple APs, wherein the first AP is a shared AP that receives resources allocated or shared from the shared AP, wherein the first non-AP STA is a non-AP STA within a basic service set (BSS) of the first AP, and wherein a BSS-internal network allocation vector (NAV) is set for the first non-AP STA based on the CTS-to-Self frame.

Images