Transmission opportunity sharing procedure in which cooperative access points participate in wireless LAN system

The TXOP sharing procedure in wireless LAN systems addresses NAV setting challenges by allowing cooperative APs to omit default NAV settings, enhancing efficiency and preventing collisions, enabling non-AP STAs to transmit UL PPDU/frames, thus improving network performance in multi-AP environments.

WO2025018671A1PCT designated stage expired Publication Date: 2025-01-23LG ELECTRONICS INC
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
PCT/KR2024/009670
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-09-25
Filing Date
2024-07-08
Publication Date
2025-01-23

AI Technical Summary

Technical Problem

In wireless LAN systems, cooperative access points struggle to efficiently share transmission opportunities (TXOP) due to issues with network allocation vectors (NAV) settings, leading to interference and transmission collisions between APs, especially in multi-AP environments where non-AP STAs connected to DAPs face challenges in transmitting UL PPDU/frames due to default NAV settings.

Method used

A method and apparatus for a TXOP sharing procedure where cooperative APs participate in a wireless LAN system by detecting frames, identifying duration fields, and omitting NAV settings for a portion of the TXOP interval, allowing frame exchange within the APs without setting the default NAV, enabling C-TDMA-based TXOP sharing protected or unprotected by SAP, which allows non-AP STAs to transmit UL PPDU/frames by ignoring or overriding the default NAV.

Benefits of technology

This approach enhances TXOP sharing efficiency by preventing frame collisions and hidden node problems, enabling smooth frame exchange between cooperative APs and allowing non-AP STAs to transmit without interference from set default NAVs, thereby improving overall network performance in multi-AP environments.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure KR2024009670_23012025_PF_FP_ABST
    Figure KR2024009670_23012025_PF_FP_ABST
Patent Text Reader

Abstract

The present disclosure relates to a transmission opportunity (TXOP) sharing procedure in which cooperative access points (APs) participate in a wireless LAN system. According to an embodiment of the present disclosure, a method performed by a station (STA) in a wireless local area network (LAN) system comprises the steps of: detecting a frame transmitted from a second access point (AP) sharing a transmission opportunity (TXOP) with a first AP connected to the STA; identifying a duration field of the frame; on the basis of the duration field of the frame being configured to have a value smaller than a value corresponding to the entire TXOP period, omitting setting of a network allocation vector (NAV) during at least a portion of the entire TXOP period; and performing frame exchange with the first AP within at least a portion of the entire TXOP period in which the setting of the NAV is omitted.
Need to check novelty before this filing date? Find Prior Art

Description

Transmission opportunity sharing procedure in which cooperative access points participate in a wireless LAN system.

[0001] The present disclosure relates to a transmission opportunity (TXOP) sharing procedure involving cooperating access points (APs) in a wireless LAN system.

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

[0003] The present disclosure provides a method and device for a TXOP sharing procedure in which cooperative APs participate in a wireless LAN system.

[0004] According to an embodiment of the present disclosure, a method performed by a station (STA) in a wireless local area network (LAN) system includes the steps of: detecting a frame transmitted from a second AP (access point) sharing a transmission opportunity (TXOP) with a first AP (access point) connected to the STA; identifying a duration field of the frame; omitting setting of a network allocation vector (NAV) during at least a portion of the entire TXOP interval based on the duration field of the frame being set to a value smaller than a value corresponding to the entire TXOP interval; and performing a frame exchange with the first AP within at least a portion of the entire TXOP interval in which setting of the NAV is omitted.

[0005] According to an embodiment of the present disclosure, a method performed by an access point (AP) in a wireless local area network (LAN) system includes the steps of: acquiring a transmission opportunity (TXOP); setting a duration field of a frame to be transmitted to a value smaller than a value corresponding to the entire TXOP period; and transmitting the frame.

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

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

[0008] For example, based on the C-TDMA-based TXOP sharing method protected by SAP, non-AP STAs associated with a DAP can transmit UL PPDUs / frames ignoring the configured default NAV.

[0009] For example, based on the C-TDMA-based TXOP sharing method that is not protected by SAP, non-AP STAs associated with a DAP can transmit UL PPDUs / frames without setting a default NAV.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0024] Figure 14 shows the trigger frame format.

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

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

[0027] Figure 17 illustrates an example of a procedure related to NAV setting.

[0028] Figure 18 shows an example of coordinated time division multiple access (C-TDMA) between cooperating APs.

[0029] FIG. 19 illustrates an example of a C-TDMA-based TXOP sharing procedure protected by SAP according to an embodiment of the present disclosure.

[0030] FIG. 20 illustrates a first example of a procedure for ignoring a default NAV that may be set by SAP according to an embodiment of the present disclosure.

[0031] FIG. 21 illustrates a second example of a procedure for ignoring a default NAV that may be set by SAP according to an embodiment of the present disclosure.

[0032] FIG. 22 illustrates an example of a procedure for ignoring a default NAV that may be set by a non-AP STA connected to a SAP according to an embodiment of the present disclosure.

[0033] FIG. 23 illustrates an example of a C-TDMA-based TXOP sharing procedure not protected by SAP according to an embodiment of the present disclosure.

[0034] FIG. 24 illustrates an example of a method performed by a STA according to an embodiment of the present disclosure.

[0035] FIG. 25 illustrates an example of a method performed by an AP according to an embodiment of the present disclosure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0119] Information regarding preamble puncturing applied to the PPDU may be included in the U-SIG and / or UHR-SIG. For example, the first field of the U-SIG may include information regarding the contiguous bandwidth of the PPDU, and the second field of the U-SIG may include information regarding preamble puncturing applied to the PPDU.

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

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

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

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

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

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

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

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

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

[0129] In the example of Fig. 7, RUs of various sizes, such as 26-RU, 52-RU, 106-RU, and 242-RU, are proposed. Since the specific sizes of these RUs can be expanded or increased, the present embodiment is not limited to the specific size of each RU (i.e., the number of corresponding tones). In the present disclosure, N-RU may be represented as N-tone RU, etc. For example, 26-RU may be represented as 26-tone RU.

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

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

[0132] Additionally, as illustrated, 484 RUs may be used when used for a single user. Meanwhile, the specific number of RUs may be changed, as in the example of FIG. 7.

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

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

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

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

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

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

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

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

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

[0142] The 5 GHz band may be referred to by other names, such as a second band / band, etc. The 5 GHz band may refer to a frequency range in which channels with center frequencies greater than or equal to 5 GHz and less than 6 GHz (or less than 5.9 GHz) are used / supported / defined. Alternatively, the 5 GHz band may include multiple channels between 4.5 GHz and 5.5 GHz. The specific figures shown in FIG. 12 are subject to change.

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

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

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

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

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

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

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

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

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

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

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

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

[0155] Control ListPadding

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

[0157] Control IDControl Information

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0174] Figure 17 illustrates an example of a procedure related to NAV setting.

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

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

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

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

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

[0180] For example, an STA must classify a received PPDU as an inter-BSS PPDU if at least one of the following conditions is true:

[0181] - The PPDU carries a frame with a BSSID field whose value is not a BSSID of the BSS to which the STA is connected, or of another BSS in the same multi-BSSID set, or of a co-hosted BSSID set to which the BSS belongs, or of a wildcard BSSID; and / or

[0182] - The PPDU carries a frame without a BSSID field, but with both RA and TA fields, whose values ​​are not all identical to the BSSID of the BSS to which the STA is connected, or of another BSS in the same multi-BSSID set, or in the co-hosted BSSID set to which the BSS belongs. The individual / group bits in the TA field are forced to 0 before comparison.

[0183] An STA shall classify a received PPDU as an intra-BSS PPDU if at least one of the following conditions is true:

[0184] - The PPDU carries a frame with the same RA, TA, or BSSID field value as the BSSID of the BSS or any BSS to which the STA is connected, or of another BSS in the same multi-BSSID set or co-hosted BSSID set to which the BSS belongs. The individual / group bits in the TA field are forced to 0 before comparison; and / or

[0185] - The PPDU carries a control frame with no TA field and an RA field value that matches the stored TXOP holder address of any BSS to which the BSS or STA is connected, or of another BSS in the same multi-BSSID set or in the co-hosting BSSID set to which the BSS belongs.

[0186] Otherwise, the PPDU cannot be determined as an Intra-BSS or Inter-BSS PPDU.

[0187] If the received PPDU satisfies both the Intra-BSS condition and the Inter-BSS condition based on the MAC address information of the frame included in the received PPDU, the received PPDU is classified as an Intra-BSS PPDU.

[0188] Maintaining two NAVs is beneficial in dense deployment scenarios where an STA requires protection from frames transmitted by STAs within its own BSS (i.e., intra-BSS) and wants to avoid interference from frames transmitted by STAs in neighboring BSSs (i.e., inter-BSS). For example, in a TXOP initiated by an AP to which an STA is associated for TB PPDU transmission, the STA's intra-BSS NAV may be set by the AP to prevent the STA from contending for the channel. Since an STA's default NAV is not updated / set by transmissions from the AP during a TXOP, if an STA's default NAV is not 0 and the STA receives a trigger frame from the AP with the CS (carrier sense) required subfield set to 1, the STA does not respond.

[0189] The CS mechanism requirements apply to STAs that maintain two NAVs, excluding the virtual CS indication on the medium. For STAs that maintain two NAVs, if both NAV timers are 0, the virtual CS indication indicates that the medium is idle. If at least one of the two NAV timers is non-zero, the virtual CS indication indicates that the medium is busy.

[0190] The STA shall update / set the intra-BSS NAV with the duration information indicated in the received frame of the PSDU if all of the following conditions are met:

[0191] - The received frame is identified as intra-BSS;

[0192] - The indicated duration is greater than the current intra-BSS NAV value; and

[0193] - The RA of the received frame is not the MAC address of the STA. Or, the STA is not a TXOP holder and the PPDU carrying the frame does not contain a frame requesting an immediate response from the STA. Or, the STA is not a TXOP holder and the received frame is a trigger frame.

[0194] The STA must update / set the default NAV with the duration information indicated in the received frame of the PSDU if all of the following conditions are met:

[0195] - The received frame is identified as inter-BSS, or cannot be identified as intra-BSS or inter-BSS;

[0196] - The indicated duration is greater than the current default NAV value; and

[0197] - The RA of the received frame is not the MAC address of the STA.

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

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

[0200] Figure 18 shows an example of coordinated time division multiple access (C-TDMA) between cooperating APs.

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

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

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

[0204] In a typical (triggered) TXS protocol, since an AP shares a TXOP with non-AP STAs within the same BSS as the AP within the TXOP acquired by the AP, an entity sharing a TXOP (i.e., a non-AP STA) can be protected from the NAV of the entity sharing the TXOP (i.e., an AP). In the present disclosure, being protected by the AP may mean that the NAV is set by the AP. Specifically, STAs belonging to the BSS of the AP can receive / detect frames transmitted from the AP and set an intra-BSS NAV, and STAs not belonging to the BSS of the AP can receive / detect frames transmitted from the AP and set a default NAV.

[0205] On the other hand, in the C-TDMA operation as in FIG. 18, the entity sharing the TXOP (i.e., SAP) and the entity receiving the TXOP (i.e., DAP) may be APs with different BSSs. That is, due to frame transmission within the BSS of the SAP, STAs within the BSS of the DAP may not be able to set the default NAV and perform smooth FE with the DAP. Therefore, for smooth cooperation between APs and / or FE within each BSS, protection rules related to NAV setting need to be precisely applied. In particular, non-AP STAs connected to the DAP may receive / detect frames transmitted from the SAP or non-AP STAs connected to the SAP, and / or CTS frames transmitted from the DAP, and set the default NAV (for the SAP), which may cause a problem in that the non-AP STAs cannot transmit UL PPDUs / frames to the DAP.

[0206] Accordingly, various embodiments of the present disclosure provide methods and devices related to a C-TDMA-based TXOP sharing procedure protected by SAP in a multi-AP cooperation environment.

[0207] Additionally, various embodiments of the present disclosure provide methods and devices related to an unprotected C-TDMA-based TXOP sharing procedure in a multi-AP cooperation environment.

[0208] In this disclosure, specific designations (names) may be changed, and embodiments of the present disclosure are not limited to such specific designations (names).

[0209] I. C-TDMA-based TXOP sharing procedure protected by SAP

[0210] According to an embodiment of the present disclosure, non-AP STAs within a BSS of a SAP, a DAP that shares TXOPs, and / or at least some non-AP STAs within a BSS of the DAP may be protected by a NAV of the SAP through a C-TDMA operating procedure.

[0211] According to an embodiment of the present disclosure, when APs operate based on C-TDMA in a multi-AP environment, a TXOP sharing procedure based on C-TDMA can be protected within the entire TXOP interval acquired by an entity (i.e., SAP) sharing a TXOP.

[0212] The TXOP sharing procedure based on C-TDMA according to the present disclosure can be secured by setting a NAV corresponding to the entire TXOP period or the period allocated to the DAP (i.e., allocation duration) based on information about the entire TXOP period included in the frame transmitted by the SAP or the period allocated to the DAP (i.e., allocation duration). Basically, STAs that receive the frame can set at least one of two NAVs (i.e., a default NAV or an intra-NAV (or, intra-BSS NAV)). The default NAV can be updated / set based on a PPDU identified as inter-BSS (i.e., inter-BSS), or can be updated / set based on a PPDU that cannot be identified as inter-BSS or intra-BSS. The intra-NAV can be updated / set based on a PPDU identified as intra-BSS. Specifically, in the C-TDMA operation according to the present disclosure, non-AP STAs within the BSS of the SAP can be protected by setting an intra-NAV based on a frame transmitted by the SAP. In addition, the DAP and / or at least some non-AP STAs within the BSS of the DAP can be protected by setting a default NAV based on a frame transmitted by the SAP.

[0213] (1) Example of procedure

[0214] FIG. 19 illustrates an example of a C-TDMA-based TXOP sharing procedure protected by SAP according to an embodiment of the present disclosure.

[0215] An AP that acquires a TXOP and acts as a SAP can set the value of the Duration / ID field of the transmitted frame to a value corresponding to the entire TXOP interval acquired (e.g., a value indicating the end point of the entire TXOP interval). That is, STAs that receive frames transmitted by a SAP can set a NAV (e.g., intra-NAV or default NAV) until the end point of the TXOP interval of the SAP. For example, a non-AP STA 1 connected to an SAP belonging to BSS 1 can set an intra-NAV corresponding to the entire TXOP interval based on the frame delivered by the SAP. For example, a non-AP STA that receives a trigger frame directed to a specific non-AP STA transmitted from a SAP or an MU-RTS TF including the AID of a specific non-AP STA in the user information field can ignore the set intra-NAV and transmit a UL PPDU / frame.

[0216] Although Fig. 19 illustrates a case where the NAV is set until the end of the TXOP section, this is exemplary, and the NAV may be set to a different value. For example, STAs that receive frames transmitted by SAP may set the NAV (intra-NAV or default NAV) until the end of the allocation section allocated by SAP (e.g., the allocation section allocated to the DAP by the MU-RTS TXS TF). To this end, the SAP may set the value of the Duration / ID field of the transmitted frame to a value corresponding to the allocation section allocated by SAP (e.g., the allocation section allocated to the DAP by the MU-RTS TXS TF) (e.g., a value indicating the end of the allocation section). In this case, non-AP STA 1 associated with SAP belonging to BSS 1 can set intra-NAV corresponding to the allocated interval based on the frame forwarded by SAP. In addition, DAP(s) that can overhear FE within BSS 1 of SAP can set default NAV based on frame detected during FE process or based on reception of MU-RTS TXS TF forwarded from SAP for TXOP sharing. This protection by SAP can prevent failure of C-TDMA / TXOP sharing procedure and / or frame collision that may occur when two DAPs are within range of SAP but cannot detect each other (e.g., hidden node problem).

[0217] In addition, non-AP STAs located within BSS 2 connected to the DAP can also detect frames transmitted from the SAP or frames transmitted from non-AP STAs connected to the SAP, and set default NAVs based on the detected frames. However, when the DAP that has shared TXOP from the SAP attempts to perform FE during the allocated time (i.e., allocated period), the non-AP STAs connected to the DAP may not be able to transmit UL PPDUs / frames because the non-AP STAs connected to the DAP have set default NAVs.

[0218] To address the issue that non-AP STAs connected to the DAP cannot transmit UL PPDUs / frames due to the default NAV set, the RA field of the MU-RTS TXS TF can be set to the MAC address of the DAP. Non-AP STAs (i.e., non-AP STAs connected to the DAP) that receive an MU-RTS TXS TF with the RA field set to the MAC address of the DAP can interpret the MU-RTS TXS TF as an Intra-BSS PPDU and set an Intra-BSS NAV. Similarly, the DAP can enable non-AP STAs that only hear the CTS-to-self frame transmitted by the DAP to set an Intra-BSS NAV by setting the RA field of the CTS frame, which is a response frame to the MU-RTS TXS TF, to the MAC address of the DAP and transmitting the CTS frame with the RA field set to the MAC address of the DAP.

[0219] Alternatively, the issue of non-AP STAs associated with a DAP not being able to transmit UL PPDUs / frames due to the configured default NAV (i.e., protection issue due to default NAV) may be addressed by the NAV ignoring method / rule described below.

[0220] (2) NAV ignoring method for UL PPDU / frame transmission of non-AP STA

[0221] Each NAV ignoring method according to the present disclosure can solve an issue resulting from a NAV set by a SAP for a non-AP STA connected to a DAP in a C-TDMA operation in a multi-AP cooperation environment and / or an issue resulting from a NAV set by a non-AP STA for a non-AP STA connected to a DAP. For example, each NAV ignoring method according to the present disclosure can enable a non-AP STA connected to a DAP to ignore a default NAV that can be set by a SAP sharing a TXOP for a non-AP STA connected to a DAP so as to exchange frames with the DAP, and can enable a non-AP STA connected to a DAP to ignore a default NAV that can be set by a non-AP STA connected to a DAP so as to exchange frames with the DAP.

[0222] The present disclosure proposes methods for ignoring a default NAV that may be set to a non-AP STA associated with a DAP during a time shared by a SAP (e.g., an allocation interval indicated in the user information field of a TXS trigger frame) in a C-TDMA operation in a multi-AP cooperative environment.

[0223] Method 1) Implicit default NAV override method (based on TXS procedure triggered between APs)

[0224] A triggered TXS protocol can be utilized to perform FE without affecting each other by dividing transmissions within the BSS of each cooperative AP into time units. That is, when the triggered TXS protocol is utilized in a multi-AP cooperative environment, the procedure presented in Fig. 15 can be similarly applied. Referring to the triggered TXS protocol of Fig. 15, when an AP transmits an MU-RTS TXS TF to a non-AP STA and receives a response thereto (e.g., a CTS frame), TXOP sharing occurs, and the non-AP STA that has shared the TXOP can perform FE during the allocated time included in the MU-RTS TXS TF (e.g., the allocated period of the user information field for the non-AP STA). When the triggered TXS protocol of FIG. 15 is applied to a multi-AP cooperation environment, the SAP transmits an MU-RTS TXS TF (or control frame) to the DAP, and after the DAP transmits a response (e.g., a CTS frame), FE between the DAP and a non-AP STA can be performed during the allocated time (e.g., the allocated interval included in the user information field for the DAP).

[0225] Therefore, a rule can be added / defined that allows a non-AP connected to a DAP to overhear the FE process between the SAP and the DAP described above, and to ignore the default NAV (set by the SAP) set in the non-AP connected to the DAP when it recognizes the triggered TXS procedure.

[0226] Rules that allow (implicitly) overriding the default NAV may include one or more of the following methods:

[0227] Method 1.1) When a non-AP STA (associated with a DAP) that overhears an MU-RTS TXS TF transmitted (to a DAP) from an OBSS AP (e.g., SAP) and sets a default NAV and detects that the DAP associated with it responds (e.g., with a CTS frame) to the MU-RTS TXS TF after SIFS, the STA can assume the frame exchange between these two APs as a frame exchange for C-TDMA operation and ignore the currently set default NAV.

[0228] Method 1.2) When a non-AP STA (associated with a DAP) that has overheard a frame (e.g., a trigger frame, a control frame, a data frame, or an UM-RTS TXS TF) transmitted from an OBSS AP (e.g., SAP) and has set a default NAV, and then detects that the DAP associated with it responds (e.g., a CTS frame) to an MU-RTS TXS TF transmitted from the same OBSS AP after SIFS, the STA may assume the frame exchange between these two APs as a frame exchange for C-TDMA operation and ignore the currently set default NAV.

[0229] On the other hand, in a scenario where the default NAV is set by frames transmitted from non-AP STAs associated with a SAP, it is difficult for non-AP STAs associated with a DAP to roughly understand the C-TDMA procedure because they can only detect frames transmitted from non-AP STAs associated with the DAP or SAP. Therefore, a method may be considered in which non-AP STAs associated with a DAP override the default NAV by utilizing information obtainable from the DAP or SAP and / or non-AP STAs associated with the SAP (i.e., an explicit default NAV override method).

[0230] Method 2) Explicitly override default NAV (based on inter-AP negotiation information)

[0231] For multi-AP cooperation, negotiation information can be exchanged between APs (e.g., SAPs and DAPs). For example, a SAP can send a request frame for multi-AP cooperation to a DAP, and the DAP can send a response frame for multi-AP cooperation to the SAP. Alternatively, a DAP can send a request frame for multi-AP cooperation to the SAP, and the SAP can send a response frame for multi-AP cooperation to the DAP.

[0232] For example, the request frame may be a cooperation request frame and / or a stream classification service (SCS) request frame. The response frame may be a cooperation response frame and / or an SCS response frame. The request frame and / or the response frame may include negotiation information.

[0233] Since the AID value in the user information field of the trigger frame is the AID used between the DAP and non-AP STAs, additional / new identifiers for the APs in the cooperative relationship may be required for the SAP to share TXOPs with each DAP in multi-AP cooperation. Therefore, defining a new ID and / or signaling that serves as the AID between the SAP and the DAP, or utilizing the BSS color, may be considered. For example, the new ID and signaling may be defined as follows, and an ID or signaling based on one or a combination of A, B, C, or D below may be included in the negotiation information:

[0234] A. Multi-AP Group ID: ID for the group of APs that make up the multi-AP collaboration (e.g. 0, 1, 2, ...).

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

[0236] C. SAP Capability: Indicates whether the AP can operate as a SAP.

[0237] For example, a QoS characteristic element included in a stream classification service (SCS) connection / response frame may be utilized. For example, reserved bits (e.g., 3 bits) in a control information field of a QoS characteristic element may be used. Specifically, 1-bit signaling may be defined among the reserved bits to indicate SAP capability information. If the bit value of the 1-bit signaling is 0, it may indicate that the corresponding AP cannot operate as a SAP. If the bit value of the 1-bit signaling is 1, it may indicate that the corresponding AP has the capability to operate as a SAP.

[0238] For example, the common information field included in the trigger frame may be utilized. For example, the (EHT) reserved bits (e.g., 7 bits) or reserved bits (e.g., 4 bits) of the common information field may be utilized. Specifically, a new subfield for multi-AP cooperation may be defined utilizing the EHT reserved bits, and a 1-bit signaling for indicating SAP capability information may be defined within the subfield. Specifically, a 1-bit signaling for indicating SAP capability information may be defined utilizing the reserved bits within the common information field.

[0239] D. SAP Operation Signaling: The AP can indicate to the DAP that it is currently operating as a SAP and sharing TXOPs.

[0240] For example, a QoS characteristic element included in a QoS data frame may be utilized. For example, reserved bits (e.g., 3 bits) in the control information field of the QoS characteristic element may be used. Specifically, 1-bit signaling may be defined among the reserved bits to indicate SAP operation signaling information. If the value of the 1-bit signaling is 0, it may indicate that the AP acts as a SAP but does not perform TXOP sharing. If the value of the 1-bit signaling is 1, it may indicate that the AP acts as a SAP and performs TXOP sharing to the DAP.

[0241] For example, the common information field included in the trigger frame may be utilized. For example, the (EHT) reserved bits (e.g., 7 bits) or reserved bits (e.g., 4 bits) of the common information field may be utilized. Specifically, a new subfield for multi-AP cooperation may be defined utilizing the EHT reserved bits, and a 1-bit signaling for indicating SAP operation signaling information may be defined within the subfield. Specifically, a 1-bit signaling for indicating SAP operation signaling information may be defined utilizing the reserved bits within the common information field.

[0242] In addition to the above-described information, i) MAC address (indicated by the RA field included in the MAC header of the frame) and / or ii) BSS color information may be included in the negotiation information.

[0243] The names of the IDs and / or signaling defined above may change, and in addition, capabilities and / or signaling according to multi-AP cooperation schemes (e.g., C-OFDMA, C-TDMA, Joint Beamforming) may exist / be included.

[0244] Additionally, information for multi-AP operation (e.g., channel information, buffers of DAP) may be present / included.

[0245] This negotiation information can be included in cooperation request / response frames (e.g., SCS request / response, A-control field) exchanged during the negotiation process between APs participating in multi-AP cooperation, and transmitted individually from each AP. Here, the cooperation request and response frames can be defined as new frames, or as new elements of existing request and response frames so that they can be transmitted together with existing request and response frames.

[0246] In addition to the inter-AP negotiation process, an announcement procedure may be required to enable non-AP STAs associated with each AP to obtain negotiation information (e.g., information from neighboring BSSs and / or information negotiated between APs).

[0247] For example, negotiation information (e.g., information from neighboring BSSs and / or information negotiated between APs) may be included in beacon frames transmitted periodically from the AP.

[0248] For example, in order to convey negotiation information (e.g., information of neighboring BSSs and / or information negotiated between APs) to non-AP STAs associated with each AP, the negotiation information may include an ID and / or signaling based on one or more combinations of the above-described common information field and / or user information field in the MU-RTS TXS TF transmitted by the SAP.

[0249] For example, negotiation information including an ID and / or signaling based on one or more combinations described above may be included within a trigger frame (or control frame / data frame) transmitted by the DAP during a time allocated from the SAP (e.g., allocation interval).

[0250] That is, negotiation information (e.g., information of neighboring BSSs and / or information negotiated between APs) can be broadcast to non-AP STAs associated with each AP through reserved bits or new fields within frames transmitted during the existing (broadcast) process.

[0251] As another example, a method may be considered to convey negotiation information (e.g., information from neighboring BSSs and / or information negotiated between APs) to non-AP STAs within individual BSSs through a separate broadcast process, for which a new broadcast frame may be defined or a beacon frame may be utilized.

[0252] Accordingly, a non-AP STA associated with a DAP sharing TXOP may ignore a default NAV set for itself (e.g., a default NAV set by a SAP or non-AP STAs associated with a SAP) based on an ID and / or signaling based on one or more combinations described above. Hereinafter, in C-TDMA operation, the RA value of the MU-RTS TXS TF transmitted from the SAP (i.e., AP-to-AP trigger) may be set to the MAC address of the DAP. Alternatively, the RA value of the MU-RTS TXS TF transmitted from the SAP may be set to broadcast, but the AID value in the user information field of the MU-RTS TXS TF may be set to the AID value of the corresponding DAP (e.g., a specific AID or DAP ID).

[0253] FIG. 20 illustrates a first example of a procedure for ignoring a default NAV that may be set by SAP according to an embodiment of the present disclosure.

[0254] Referring to Figure 20, a non-AP STA connected to a DAP can ignore the default NAV that can be set by the SAP.

[0255] For example, if a non-AP STA associated with a DAP overhears an MU-RTS TXS TF transmitted from a SAP that i) has the same group ID as the multi-AP group ID of the DAP it is associated with, and ii) has SAP capability and SAP operation signaling values ​​enabled (i.e., a SAP that shares TXOPs with the DAP), the non-AP STA associated with the DAP decodes the MU-RTS TXS TF transmitted from the SAP, and if it verifies that the MAC address indicated by the RA of the MU-RTS TXS TF is the MAC address of the DAP (or if it verifies that the AID value in the user information field of the MU-RTS TXS TF is set to the AID of the corresponding DAP (e.g., a specific AID or DAP ID)), it may ignore the default NAV set by the SAP at the time of receiving the MU-RTS TXS TF (① in FIG. 20).

[0256] For example, if a non-AP STA associated with a DAP i) overhears an MU-RTS TXS TF transmitted from a SAP (i.e., a SAP that shares TXOP with the DAP) that has a group ID that is the same as the multi-AP group ID of the DAP associated with it, ii) has SAP capability and SAP operation signaling values ​​enabled (i.e., a SAP that shares TXOP with the DAP), and iii) detects that the DAP responds to the MU-RTS TXS TF (or transmits a CTS frame), the non-AP STA associated with the DAP decodes the MU-RTS TXS TF transmitted from the SAP to confirm that the MAC address indicated by the RA of the MU-RTS TXS TF is the MAC address of the DAP (or confirms that the AID value in the user information field of the MU-RTS TXS TF is set to the AID of the corresponding DAP (e.g., a specific AID or DAP ID), and at the time of detecting a response frame (or CTS frame) from the DAP (② of FIG. 20), sets the default NAV set by the SAP. You can ignore it.

[0257] For example, a non-AP STA associated with a DAP may overhear an MU-RTS TXS TF transmitted from a SAP that i) has the same group ID as the multi-AP group ID of the DAP associated with it, ii) has SAP capability and SAP operation signaling values ​​enabled (i.e., a SAP that shares TXOP with the DAP), and iii) receives a trigger frame (or control frame / data frame) transmitted after the DAP responds to the MU-RTS TXS TF (or transmits a CTS frame), the non-AP STA associated with the DAP decodes the MU-RTS TXS TF transmitted from the SAP to verify that the MAC address indicated by the RA of the MU-RTS TXS TF is the MAC address of the DAP (or verify that the AID value in the user information field of the MU-RTS TXS TF is set to the AID of the corresponding DAP (e.g., a specific AID or DAP ID), and then detects a transmission of a response frame (or CTS frame) from the DAP and then transmits the CTS frame to itself. If the DAP ID value in the transmitted trigger frame matches the DAP ID value obtained from the MU-RTS TXS TF, the default NAV set by the SAP at the time of receiving the trigger frame from the DAP (③ in Fig. 20) can be ignored.

[0258] FIG. 21 illustrates a second example of a procedure for ignoring a default NAV that may be set by SAP according to an embodiment of the present disclosure.

[0259] Referring to FIG. 21, a non-AP STA associated with a DAP that overhears a frame (e.g., a trigger frame, a control frame, a data frame, and / or a MU-RTS TXS TF) transmitted from a SAP and sets a default NAV may decode the received frame to store information about the multi-AP group ID, the DAP ID, the SAP capability, and / or the SAP operation signaling, as well as the TA, the RA, and / or the BSS color. The DAP may transmit a trigger frame (or a control frame / data frame) including the address and BSS color information of the SAP with which it shared the TXOP to the non-AP STAs, and the non-AP STA that receives the trigger frame may compare it with the TA and BSS color information of the previously overheard frame, and if they match, the non-AP STA may ignore the default NAV by the SAP from the time of receiving the trigger frame transmitted from the DAP.

[0260] FIG. 22 illustrates an example of a procedure for ignoring a default NAV that may be set by a non-AP STA connected to a SAP according to an embodiment of the present disclosure. Hereinafter, in a C-TDMA operation, the RA value of an MU-RTS TXS TF (i.e., AP-to-AP trigger) transmitted from a SAP may be set to the MAC address of a DAP. Alternatively, the RA value of the MU-RTS TXS TF transmitted from a SAP may be set to broadcast, but the AID value in the user information field of the MU-RTS TXS TF may be set to the AID value of the corresponding DAP (e.g., a specific AID or DAP ID).

[0261] Referring to FIG. 22, a non-AP STA connected to a DAP that overhears frames transmitted from non-AP STAs connected to a SAP and sets a default NAV can decode the received frames and store information about TA, RA, and BSS color. The DAP can transmit a trigger frame (or control frame / data frame) including the address and BSS color information of the SAP that shared the TXOP to the non-AP STAs, and the non-AP STA that receives the trigger frame can compare it with the RA and BSS color information of the previously overheard frame, and if they match, the non-AP STA can ignore the default NAV by the non-AP STA connected to the SAP from the time of receiving the trigger frame transmitted from the DAP.

[0262] (3) How to set the RA field of MU-RTS TXS TF

[0263] According to an embodiment of the present disclosure, non-AP STAs connected to a DAP receiving an MU-RTS TXS TF may recognize the corresponding PPDU (i.e., the PPDU corresponding to the MU-RTS TXS TF) as an intra-BSS PPDU based on the RA field value of the MU-RTS TXS TF, and may set an intra-BSS NAV. Specifically, the RA field of the MU-RTS TXS TF that the SAP transmits to the DAP for TXOP sharing may include the MAC address of the corresponding DAP. Non-AP STAs connected to the DAP that receive the MU-RTS TXS TF in which the RA field is set to the MAC address of the DAP may interpret the corresponding MU-RTS TXS TF as an intra-BSS PPDU, and may set an intra-BSS NAV. Additionally or alternatively, the RA field of the MU-RTS TXS TF that the SAP transmits to the DAP may include BSS color information of the corresponding DAP.

[0264] To set the RA field of the MU-RTS TXS TF to the address or BSS color information of a specific DAP, the following may be considered:

[0265] 1) An AP can transmit MU-RTS TXS TF to a cooperating AP or an unconnected STA participating in multi-AP cooperation based on information obtained through a beacon or information obtained through a separate negotiation / agreement process.

[0266] 2) When an AP wants to transmit MU-RTS TXS TF in unicast to a cooperating AP or an unconnected STA participating in multi-AP cooperation, the RA field of the MU-RTS TXS TF may include the MAC address of the cooperating AP or STA.

[0267] Similarly, a DAP can set the RA field of a CTS frame to the DAP's MAC address, and by transmitting such a CTS frame, non-AP STAs that hear the CTS-to-Self frame transmitted by the DAP can set an Intra-BSS NAV. That is, the RA field of a CTS frame transmitted as a response frame to an MU-RTS TXS TF can contain the MAC address of the DAP, not the SAP, thereby preventing NAV issues. Additionally or alternatively, the RA field of a CTS frame transmitted by a DAP to a SAP can contain the DAP's BSS color information.

[0268] According to an embodiment of the present disclosure, when APs operate in C-TDMA in a multi-AP environment, the C-TDMA procedure can be protected within the entire TXOP interval acquired by an entity (i.e., SAP) sharing a TXOP or within the period allocated to a DAP (i.e., allocation interval), and specifically, the C-TDMA procedure / TXS procedure can be protected by setting an NAV for the entire TXOP interval acquired by the SAP or the period allocated to the DAP (i.e., allocation interval) by a frame transmitted by the SAP.

[0269] For example, according to the C-TDMA-based TXOP sharing procedure protected by SAP proposed in the present disclosure, the baseline of the triggered TXS can be applied, and the hidden node problem between DAPs that may occur in a multi-AP environment can be prevented / avoided.

[0270] For example, according to an embodiment of the present disclosure, even if a non-AP STA connected to a DAP sets a default NAV by a SAP and / or a non-AP STA connected to the SAP, the non-AP STA connected to the DAP may transmit a UL PPDU / frame by ignoring the default NAV.

[0271] II. C-TDMA-based TXOP sharing procedure not protected by SAP

[0272] According to an embodiment of the present disclosure, in a C-TDMA operating procedure, TXOP sharing and / or FE can be performed in a state where non-AP STAs within a BSS of a SAP, a DAP, and / or at least some non-AP STAs within a BSS of the DAP are not protected by a NAV of the SAP.

[0273] According to an embodiment of the present disclosure, when APs operate based on C-TDMA in a multi-AP environment, TXOP sharing can be performed without the C-TDMA procedure being protected within the entire TXOP interval acquired by an entity (i.e., SAP) sharing the TXOP.

[0274] In a C-TDMA-based TXOP sharing procedure according to an embodiment of the present disclosure, protection by NAV may be excluded within the entire TXOP interval acquired by the SAP, and TXOP sharing and / or FE of the DAP may be performed. For example, the DAP and at least some non-AP STAs within the BSS of the DAP may not set a default NAV by the frame transmitted by the SAP and may not be protected. On the other hand, protection for FE within the BSS of the SAP may be applied. That is, the non-AP STAs within the BSS of the SAP may or may not set an intra-NAV by the frame transmitted by the SAP.

[0275] FIG. 23 illustrates an example of a C-TDMA-based TXOP sharing procedure not protected by SAP according to an embodiment of the present disclosure.

[0276] Referring to FIG. 23, an AP that acquires a TXOP and performs the role of a SAP can set the value of the Duration / ID field of the transmitted frame to i) a value corresponding to a section for FE with non-AP STAs within the BSS (e.g., an allocation section), or ii) 0, rather than a value corresponding to the entire TXOP section acquired (e.g., a value indicating the end point of the entire TXOP section). For example, STAs that receive a frame in which the Duration / ID field value is set to a value corresponding to a section required for FE within the BSS of the SAP (e.g., an allocation section) can set a NAV (e.g., an intra-NAV, a default NAV) during the corresponding section (or until the end point of the corresponding section). For example, STAs that receive a frame in which the Duration / ID field value is set to 0 may not set a NAV.

[0277] For example, a SAP can apply protection by transmitting a frame with the Duration / ID field set to a value corresponding to the time / interval required for the FE to perform FE with a non-AP STA 1 belonging to BSS 1. As another example, a SAP can perform FE without protection at SIFS intervals by transmitting a frame with the Duration / ID field set to 0.

[0278] In addition, the SAP may set the Duration / ID field of the MU-RTS TXS TF to 0 to share the TXOP with the DAP and transmit this MU-RTS TXS TF. This allows the DAP and non-AP STAs connected to the DAP to not set the default NAV by the SAP or the non-AP STAs connected to the SAP during the time allocated by the SAP (e.g., the allocation period), and to perform FE at SIFS intervals without protection from the SAP. That is, by the SAP transmitting the MU-RTS TXS TF with the Duration / ID field set to 0 instead of a value corresponding to the entire TXOP period, the DAP that has shared the TXOP through the MU-RTS TXS TF can perform FE during the allocated time, and the non-AP STAs connected to the DAP can transmit UL PPDUs / frames to the DAP without setting the default NAV.

[0279] According to an embodiment of the present disclosure, when APs operate based on C-TDMA in a multi-AP environment, TXOP sharing can be performed without protecting the C-TDMA procedure within the entire TXOP period acquired by an entity (i.e., SAP) sharing TXOP. To this end, the SAP can transmit an MU-RTS TXS TF with the value of the Duration / ID field set to 0. According to the above-described C-TDMA-based TXOP sharing method, non-AP STAs connected to a DAP can transmit UL PPDUs / frames (without setting a default NAV).

[0280] Below, we describe the method performed by STAs and APs associated with a DAP in a C-TDMA-based TXOP sharing procedure that is not protected by SAP.

[0281] FIG. 24 illustrates an example of a method performed by an STA according to an embodiment of the present disclosure. The STA of FIG. 24 may be an STA connected to a DAP.

[0282] Referring to FIG. 24, in step S2401, the STA can detect a frame transmitted from a second AP (e.g., SAP) that shares a TXOP with a first AP (e.g., DAP) connected to the STA.

[0283] In step S2403, the STA can identify the duration field of the frame.

[0284] In step S2405, the STA may omit setting of the NAV for at least a portion of the entire TXOP interval based on the duration field of the frame being set to a value smaller than a value corresponding to the entire TXOP interval.

[0285] In step S2407, the STA may perform frame exchange with the first AP within at least a portion of the entire TXOP interval in which the setting of NAV is omitted.

[0286] According to various embodiments, the duration field of the frame may be set to a value corresponding to an allocation interval for an STA connected to the second AP within the entire TXOP interval.

[0287] According to various embodiments, during an allocation period for a STA associated with a second AP, frame exchange may be performed between the second AP and the STA associated with the second AP.

[0288] According to various embodiments, an STA may set a NAV during an allocation period for an STA associated with a second AP within the entire TXOP period. At least a portion of the entire TXOP period in which the NAV setting is omitted may include a period excluding an allocation period for an STA associated with a second AP within the entire TXOP period.

[0289] According to various embodiments, the duration field of the frame may be set to 0.

[0290] According to various embodiments, frame exchange may be performed at SIFS intervals based on the duration field of the frame being set to 0.

[0291] According to various embodiments, at least a portion of the entire TXOP interval in which the NAV setting is omitted may include the entire TXOP interval.

[0292] According to various embodiments, the frame with the duration field set to 0 may be a TXS trigger frame transmitted from the second AP to the first AP.

[0293] According to various embodiments, the TXS trigger frame includes information indicating an allocation interval for the first AP. Based on the omission of the NAV setting, the STA can exchange frames with the first AP during the allocation interval.

[0294] FIG. 25 illustrates an example of a method performed by an AP according to an embodiment of the present disclosure. The AP of FIG. 25 may be a SAP.

[0295] Referring to FIG. 25, in step S2501, the AP can obtain a TXOP.

[0296] In step S2503, the AP may set the duration field of the frame to be transmitted to a value smaller than a value corresponding to the entire TXOP interval.

[0297] In step S2505, the AP can transmit the frame.

[0298] According to various embodiments, the duration field of the frame may be set to a value corresponding to an allocation interval for an STA connected to the AP within the entire TXOP interval.

[0299] According to various embodiments, during an allocation period for an STA associated with an AP, frame exchange may be performed between the AP and the STA associated with the AP.

[0300] According to various embodiments, the duration field of the frame may be set to 0.

[0301] According to various embodiments, frame exchange may be performed at SIFS intervals based on the duration field of the frame being set to 0.

[0302] According to various embodiments, the frame with the duration field set to 0 may be a TXS trigger frame transmitted to another AP.

[0303] According to various embodiments, a TXS trigger frame may include information indicating an allocation interval. Based on the duration field of the frame being set to 0, frame exchange may be performed without setting a NAV during the allocation interval.

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

[0305] For example, the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5 may be configured to execute instructions stored in the memory (112, 520) to implement a method performed by an STA in the present disclosure. The method includes: detecting a frame transmitted from a second AP sharing a transmission opportunity (TXOP) with a first AP (access point) connected to the STA; identifying a duration field of the frame; omitting setting of a network allocation vector (NAV) during at least a portion of the entire TXOP interval based on the duration field of the frame being set to a value smaller than a value corresponding to the entire TXOP interval; and performing frame exchange with the first AP within at least a portion of the entire TXOP interval in which the setting of the NAV is omitted.

[0306] For example, the processor (121) and / or the processing chip (124) of FIG. 1 may be configured to execute instructions stored in the memory (122) to implement a method performed by the AP in the present disclosure. The method includes: obtaining a transmission opportunity (TXOP); setting a duration field of a frame to be transmitted to a value smaller than a value corresponding to the entire TXOP period; and transmitting the frame.

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

[0308] For example, the CRM may be the memory (112) of FIG. 1, the memory (520) of FIG. 5, and / or a separate external memory / storage medium / disk. The CRM may store instructions for implementing a method performed by an STA in the present disclosure based on being executed by a processor (e.g., the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5). The method includes: detecting a frame transmitted from a second AP sharing a transmission opportunity (TXOP) with a first AP (access point) connected to the STA; identifying a duration field of the frame; omitting setting of a network allocation vector (NAV) during at least a portion of the entire TXOP interval based on the duration field of the frame being set to a value smaller than a value corresponding to the entire TXOP interval; and performing frame exchange with the first AP within at least a portion of the entire TXOP interval in which the setting of the NAV is omitted.

[0309] For example, the CRM may be the memory (122) of FIG. 1 and / or a separate external memory / storage medium / disk. The CRM may store commands for implementing a method performed by an AP in the present disclosure based on being executed by a processor (e.g., the processor (121) and / or the processing chip (124) of FIG. 1). The method includes: acquiring a transmission opportunity (TXOP); setting a duration field of a frame to be transmitted to a value smaller than a value corresponding to the entire TXOP period; and transmitting the frame.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0327] For example, based on the C-TDMA-based TXOP sharing method protected by SAP, non-AP STAs associated with a DAP can transmit UL PPDUs / frames ignoring the configured default NAV.

[0328] For example, based on the C-TDMA-based TXOP sharing method that is not protected by SAP, non-AP STAs associated with a DAP can transmit UL PPDUs / frames without setting a default NAV.

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

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

Claims

1. A method performed by a STA (station) in a wireless local area network (LAN) system, A step of detecting a frame transmitted from a second AP sharing a transmission opportunity (TXOP) with a first AP (access point) connected to the STA; A step of identifying a duration field of the above frame; A step of omitting the setting of a network allocation vector (NAV) for at least a portion of the entire TXOP interval based on the duration field of the frame being set to a value smaller than a value corresponding to the entire TXOP interval; and A method comprising a step of performing frame exchange with the first AP within at least a portion of the entire TXOP interval in which the setting of the NAV is omitted.

2. A method according to claim 1, wherein the duration field of the frame is set to a value corresponding to an allocation interval for an STA connected to the second AP within the entire TXOP interval.

3. A method according to claim 2, wherein, during an allocation period for an STA connected to the second AP, frame exchange is performed between the second AP and the STA connected to the second AP.

4. In claim 2, further comprising a step of setting a NAV during an allocation period for a STA connected to the second AP within the entire TXOP period, A method in which at least a portion of the entire TXOP interval in which the setting of the above NAV is omitted includes an interval excluding an allocation interval for an STA connected to the second AP within the entire TXOP interval.

5. A method according to claim 1, wherein the duration field of the frame is set to 0.

6. A method according to claim 5, wherein frame exchange is performed at SIFS (short interframe space) intervals based on the duration field of the frame being set to 0.

7. A method according to claim 5, wherein at least a part of the entire TXOP section in which the setting of the NAV is omitted includes the entire TXOP section.

8. A method according to claim 5, wherein the frame in which the duration field is set to 0 is a TXS (TXOP sharing) trigger frame transmitted from the second AP to the first AP.

9. In claim 8, the TXS trigger frame includes information indicating an allocation interval for the first AP, A method further comprising a step of performing frame exchange with the first AP during the allocation period based on the omission of the setting of the above NAV.

10. In a wireless local area network (LAN) system, in the STA (station), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: An operation of detecting a frame transmitted from a second AP (access point) sharing a transmission opportunity (TXOP) with a first AP (access point) connected to the STA; An action to identify the duration field of the above frame; An operation of omitting the setting of a network allocation vector (NAV) for at least a portion of the entire TXOP interval based on the duration field of the frame being set to a value smaller than a value corresponding to the entire TXOP interval; and A method comprising an operation of performing frame exchange with the first AP within at least a portion of the entire TXOP interval in which the setting of the NAV is omitted.

11. In a device configured to operate in a wireless local area network (LAN) system, at least one processor; and At least one memory functionally coupled with at least one processor, The at least one memory stores instructions that perform operations based on being executed by the at least one processor, the operations being: An operation of detecting a frame transmitted from a second AP (access point) sharing a transmission opportunity (TXOP) with a first AP (access point) connected to the STA; An action to identify the duration field of the above frame; An operation of omitting the setting of a network allocation vector (NAV) for at least a portion of the entire TXOP interval based on the duration field of the frame being set to a value smaller than a value corresponding to the entire TXOP interval; and A device comprising an operation for performing frame exchange with the first AP within at least a portion of the entire TXOP interval in which the setting of the NAV is omitted.

12. A non-transitory computer readable medium (CRM) storing program code that implements instructions that perform operations based on being executed by at least one processor, wherein the operations are: An operation of detecting a frame transmitted from a second AP (access point) sharing a transmission opportunity (TXOP) with a first AP (access point) connected to the STA; An action to identify the duration field of the above frame; An operation of omitting the setting of a network allocation vector (NAV) for at least a portion of the entire TXOP interval based on the duration field of the frame being set to a value smaller than a value corresponding to the entire TXOP interval; and A CRM comprising an operation of performing frame exchange with the first AP within at least a portion of the entire TXOP interval in which the setting of the NAV is omitted.

13. In a method performed by an access point (AP) in a wireless local area network (LAN) system, Step of acquiring TXOP (transmission opportunity); A step of setting the duration field of the frame to be transmitted to a value smaller than the value corresponding to the entire TXOP interval; and A method comprising the step of transmitting the above frame.

14. In a wireless local area network (LAN) system, at the AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: The action of acquiring a TXOP (transmission opportunity); An action of setting the duration field of the frame to be transmitted to a value smaller than the value corresponding to the entire TXOP interval; and An AP comprising an operation for transmitting the above frame.

15. A method according to claim 14, wherein the duration field of the frame is set to a value corresponding to an allocation interval for an STA connected to the AP within the entire TXOP interval.

16. A method according to claim 15, wherein frame exchange is performed between the AP and the STA connected to the AP during an allocation period for the STA connected to the AP.

17. A method according to claim 14, wherein the duration field of the frame is set to 0.

18. A method according to claim 17, wherein frame exchange is performed at SIFS (short interframe space) intervals based on the duration field of the frame being set to 0.

19. A method according to claim 17, wherein the frame in which the duration field is set to 0 is a TXS (TXOP sharing) trigger frame transmitted to another AP.

20. In claim 19, the TXS trigger frame includes information indicating an allocation interval, A method in which frame exchange is performed without setting a network allocation vector (NAV) during the allocation period based on the duration field of the above frame being set to 0.

Citation Information

Patent Citations

  • Display apparatus

    KR1020240061857A

  • Control of Uplink Wireless Transmissions in Shared TXOP

    US20230087687A1

  • Wireless communication device and method

    WO2022059483A1

  • KR20230026269A