Trigger frame design in AP selection procedure for multi-AP cooperation in wireless LAN system

Abstract

The present disclosure relates to a trigger frame design in an AP selection procedure for multi-AP cooperation in a wireless LAN system. According to an embodiment of the present disclosure, a method performed by a first AP in a wireless LAN system comprises the steps of: performing a negotiation procedure for multi-AP cooperation with neighboring APs; configuring a multi-AP set including the neighboring APs on the basis of the negotiation procedure; transmitting, to a second AP included in the multi-AP set, a selection request frame for starting the multi-AP cooperation with the second AP; receiving, from the second AP, a selection response frame for the selection request frame; and, on the basis of receiving the selection response frame, transmitting, to the second AP, a TXOP sharing frame including information about an allocation period.

Description

Trigger frame design in the AP selection procedure for multi-AP cooperation in a wireless LAN system.

[0001] The present disclosure relates to the design of a trigger frame in an AP selection procedure for multi-AP cooperation in a wireless LAN system.

[0002] Next-generation Wi-Fi (e.g., IEEE 802.11be and / or later) aims to support ultra-high reliability when transmitting signals to STAs. To this end, various technologies are being considered to support high throughput, low latency, and extended range. For example, APs can perform a negotiation procedure for multi-AP cooperation to establish a multi-AP set, and then select an AP to initiate multi-AP cooperation among the APs included in the multi-AP set. The trigger frame transmitted during the AP selection procedure needs to be designed.

[0003] The present disclosure provides a method and device for designing a trigger frame in an AP selection procedure for multi-AP cooperation in a wireless LAN system.

[0004] According to an embodiment of the present disclosure, a method performed by a first AP in a wireless LAN system includes the steps of: performing a negotiation procedure for multi-AP cooperation with neighboring APs; configuring a multi-AP set including the neighboring APs based on the negotiation procedure; transmitting a selection request frame to a second AP included in the multi-AP set for initiating multi-AP cooperation with the second AP; receiving a selection response frame for the selection request frame from the second AP; and transmitting a TXOP shared frame including information on an allocation interval to the second AP based on receiving the selection response frame.

[0005] According to an embodiment of the present disclosure, a method performed by a second AP in a wireless LAN system includes the steps of: performing a negotiation procedure for multi-AP cooperation with neighboring APs; configuring a multi-AP set including the neighboring APs based on the negotiation procedure; receiving, from a first AP included in the multi-AP set, a selection request frame for initiating the multi-AP cooperation with the second AP; transmitting, to the first AP, a selection response frame for the selection request frame; and, after transmitting the selection response frame, receiving, from the first AP, a TXOP shared frame including information on an allocation interval.

[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, in the present disclosure, the structure / format of a trigger frame transmitted by a SAP to select a DAP to perform multi-AP cooperation-based transmission in multi-AP operation / C-TDMA operation is defined. Using the trigger frame according to various embodiments of the present disclosure, the SAP can perform a multi-AP selection procedure to select a DAP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0023] Figure 14 illustrates an example of a procedure related to NAV setting.

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

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

[0026] Figure 17 shows an example of a single TXOP-based coordinated time division multiple access (Co-TDMA) operation diagram between cooperating APs.

[0027] FIG. 18 illustrates an example of a multi-AP selection procedure according to an embodiment of the present disclosure.

[0028] FIG. 19 illustrates an example of a method performed by a first AP according to an embodiment of the present disclosure.

[0029] FIG. 20 illustrates an example of a method performed by a second AP according to an embodiment of the present disclosure.

[0030] FIG. 21 illustrates an example of a MAP trigger frame format for a multi-AP selection procedure according to an embodiment of the present disclosure.

[0031] Figure 22 shows an example of a MAP-RTS trigger frame format for a multi-AP selection procedure.

[0032] FIG. 23 illustrates an example of an MU-RTS TXS trigger frame format for a multi-AP selection procedure according to an embodiment of the present disclosure.

[0033] FIG. 24 illustrates an example of a BSRP trigger frame format for a multi-AP selection procedure according to an embodiment of the present disclosure.

[0034] FIG. 25 illustrates a first example of a UHR special user information field according to an embodiment of the present disclosure.

[0035] FIG. 26 illustrates a second example of a UHR special user information field 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., PPPDU) may be performed by the transceiver (113, 123) of FIG. 1. In addition, in the example below, the operation of various STAs generating transmission and reception signals or performing data processing or calculations in advance for transmission and reception signals may be performed by the processor (111, 121) of FIG. 1.For example, an example of an operation for generating a transmission / reception signal or performing data processing or operation in advance for a transmission / reception signal may include 1) an operation for determining / obtaining / configuring / computing / decoding / encoding bit information of a subfield (SIG, STF, LTF, Data) field included in a PPDU, 2) an operation for determining / configuring / obtaining time resources or frequency resources (e.g., subcarrier resources) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 3) an operation for determining / configuring / obtaining a specific sequence (e.g., a pilot sequence, an STF / LTF sequence, an extra sequence applied to SIG) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 4) a power control operation and / or a power saving operation applied to an STA, 5) an operation related to determining / obtaining / configuring / computing / decoding / encoding an ACK signal, etc. Additionally, in the examples below, various information (e.g., information related to fields / subfields / control fields / parameters / power, etc.) used by various STAs for determining / acquiring / configuring / computing / decoding / encoding transmission / reception signals can be stored in the memory (112, 122) of FIG. 1.

[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 a 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 CO-BF (Coordinated beamforming), SR (Spatial Reuse), a type related to C-OFDMA (Coordinated OFDMA), a type related to CO-TDMA (Coordinated TDMA)), information about the type of the EHT PPDU (e.g., 2-bit or 3-bit information) can be included in the version-dependent bits of the U-SIG.

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

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

[0151] Figure 14 illustrates an example of a procedure related to NAV setting.

[0152] Referring to FIG. 14, 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.

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

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

[0155] In Fig. 14, 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 fields of other various frames, such as non-HT PPDU, HT PPDU, VHT PPDU or HE PPDU (e.g., duration field in MAC header of MAC frame). For example, if the RA field in the received MAC frame / RTS frame / CTS 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 / RTS frame / CTS frame.

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

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

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

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

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

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

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

[0163] Referring to FIG. 15, 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.

[0164] 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 1:

[0165] 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)8Ranging9-15Reserved

[0166] For example, if the value of the trigger type subfield is set to 0, the trigger frame may be a basic trigger frame. For example, if the value of the trigger type subfield is set to 3, the trigger frame may be a MU (multi-user) RTS trigger frame. Meanwhile, according to the EHT (or 802.11be) standard, in order to support peer-to-peer (P2P) transmission to a non-AP STA, 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 2 below:

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

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

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

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

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

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

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

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

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

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

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

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

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

[0180] Figure 17 shows an example of a single TXOP-based coordinated time division multiple access (Co-TDMA) operation diagram between cooperating APs.

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

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

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

[0184] For successful multi-AP cooperation, a multi-AP selection procedure (or AP selection procedure for multi-AP cooperation) may be performed to select a DAP with which the SAP wishes to share TXOPs within a multi-AP set established / configured through a negotiation procedure and / or to notify that the TXOPs will be shared. Through the multi-AP selection procedure, the SAP can determine whether a DAP requires TXOP sharing within the acquired TXOPs, and if a specific DAP does not require TXOP sharing, it can decide to share the TXOPs with subsequent / other DAPs. Alternatively, the SAP can simply notify the target DAPs that it intends to share TXOPs during the multi-AP selection procedure, thereby enabling multi-AP cooperation to be performed while reducing the overhead caused by the multi-AP selection procedure.

[0185] FIG. 18 illustrates an example of a multi-AP selection procedure according to an embodiment of the present disclosure.

[0186] Referring to FIG. 18, in a multi-AP selection procedure, a SAP may transmit a request frame (i.e., a request frame for AP selection / selection request frame) to one or more DAPs to select a DAP with which to share a TXOP from a multi-AP set established / configured through a negotiation procedure, and one or more DAP(s) receiving the request frame may transmit a response frame (i.e., a response frame for AP selection / selection response frame) to the request frame based on whether TXOP sharing is required. If a response frame including an indication that TXOP sharing is not required is received from a DAP(s), or if a response frame is not received from a DAP(s), the SAP may transmit a request frame for AP selection to another DAP - i.e., the SAP may perform AP reselection. Alternatively, the SAP may simply inform the target DAP(s) that it intends to share a TXOP in the multi-AP selection procedure. For example, a SAP can send an AP selection request frame that does not solicit a response frame to the target DAP with which it wishes to share a TXOP, and the DAP receiving such an AP selection request frame can prepare an action for the intended TXOP sharing.

[0187] The SAP transmits a frame for TXOP sharing (e.g., TXOP sharing frame / MU-RTS TXS trigger frame) to the selected DAP through a multi-AP selection procedure, and the DAP can exchange frames with non-AP STA(s) connected to the DAP in the time interval (e.g., allocation interval) allocated by the TXOP sharing frame.

[0188] When performing a multi-AP selection procedure, the multi-AP selection request frame transmitted by the SAP to the DAP needs to be more specifically defined / designed. Therefore, the present disclosure defines the structure / format of a trigger frame transmitted by the SAP to select a DAP for multi-AP cooperation-based transmission in multi-AP cooperation and / or Co-TDMA operation.

[0189] Additionally, in order to initiate transmission based on a multi-AP cooperation scheme such as Co-SR or Co-BF, a procedure may be required to announce cooperation and / or perform short-term negotiation for the cooperation scheme. Accordingly, the present disclosure defines the structure / format of a trigger frame transmitted to initiate transmission based on a multi-AP cooperation scheme (e.g., Co-TDMA, Co-SR, Co-BF) and / or perform short-term negotiation.

[0190] According to various embodiments of the present disclosure, by transmitting a multi-AP selection request frame / trigger frame for multi-AP operation, the SAP can select a DAP to share a TXOP and / or perform multi-AP operation and / or announce information related to multi-AP operation / Co-TDMA operation. In addition, the AP can check whether other APs are participating in multi-AP cooperation.

[0191] In the present disclosure, the multi-AP selection request frame / trigger frame may serve as an initial control frame (ICF) for initiating multi-AP cooperation.

[0192] The specific designations / names proposed in this disclosure may be modified and are not limited thereto. For example, in this disclosure, "multi-AP selection" may be used interchangeably with "schedule announcement," "coordination announcement," and "cooperative polling."

[0193] FIG. 19 illustrates an example of a method performed by a first AP according to an embodiment of the present disclosure. The first AP may be an AP transmitting an ICF to initiate a multi-AP cooperation / multi-AP selection procedure.

[0194] Referring to FIG. 19, in step S1901, the first AP can perform a negotiation procedure for multi-AP cooperation with neighboring APs.

[0195] In step S1903, the first AP may configure a multi-AP set including neighboring APs based on a negotiation procedure.

[0196] In step S1905, the first AP may transmit a selection request frame to the second AP included in the multi-AP set to initiate multi-AP cooperation with the second AP.

[0197] In step S1907, the first AP can receive a selection response frame for a selection request frame from the second AP.

[0198] In step S1909, the first AP may transmit a TXOP shared frame including information about the allocation interval to the second AP based on receiving the selection response frame.

[0199] According to various embodiments, the selection request frame may include identification information of a second AP for multi-AP cooperation.

[0200] According to various embodiments, the identification information of the second AP for multi-AP cooperation may be included in the AID (association identifier) ​​12 field within the user information field of the selection request frame. The identification information of the second AP may include at least one of the BSSID (basic service set identifier) ​​of the second AP, the BSS color of the second AP, the ID of the multi-AP set, or the ID assigned to the second AP within the multi-AP set.

[0201] According to various embodiments, the identification information of the second AP for multi-AP cooperation may include the address of the second AP. The RA (receiver address) field of the selection request frame may be set to the address of the second AP.

[0202] According to various embodiments, the selection request frame may be an initial control frame (ICF) for initiating multi-AP cooperation. The selection response frame may be an initial control reply (ICR) for the ICF.

[0203] According to various embodiments, the selection request frame may include at least one of information about the type of ICF (e.g., ICF type), information about the cooperation method (e.g., MAP cooperation type), information indicating that the selection request frame requests selection of an AP for multi-AP cooperation (e.g., MAP selection / MAP procedure), information about the type of response to the selection request frame (e.g., response type), information about whether ICR is allowed (e.g., general response), or cooperation dependency information.

[0204] According to various embodiments, the cooperation dependency information may include at least one of an identifier of a multi-AP set (e.g., a MAP group ID), an ID assigned to a second AP within the multi-AP set (e.g., an AP ID), information about an address of the second AP (e.g., an address), information about an operating channel (e.g., an operating channel), information about an operating bandwidth (e.g., an operating bandwidth), information about a scheduled TXOP period (e.g., a scheduled TXOP period), information about a timing of TXOP sharing (e.g., an expected TXOP sharing timing), low-latency traffic information, or information about a priority of a current cooperation method among cooperation methods (e.g., a cooperation priority).

[0205] According to various embodiments, the selection response frame may include at least one of an identifier of a multi-AP set, an ID assigned to a second AP within the multi-AP set, information about an address of the second AP, information about an operating channel, information about an operating bandwidth, information about a TXOP period requested by the second AP (e.g., a requested TXOP period), information about a buffer status of the second AP (e.g., a buffer status), information about whether TXOP sharing is required (e.g., a TXOP sharing request), low-latency traffic information, or a status code for a request by a selection request frame.

[0206] According to various embodiments, the selection request frame may be a trigger frame including a trigger type subfield set to a reserved value among the values ​​of the trigger type subfield. The reserved value may be one of 9 to 15.

[0207] According to various embodiments, the selection request frame may be a MU (multi-user)-RTS TXS (TXOP sharing) trigger frame.

[0208] According to various embodiments, the selection request frame may be a BSRP (buffer status report poll) trigger frame.

[0209] According to various embodiments, the common information field of the BSRP trigger frame may include at least one of information about the type of ICF, information about the cooperation method, information indicating that the selection request frame requests selection of an AP for multi-AP cooperation, information about the type of response to the selection request frame, or information about whether ICR is allowed. The special user information field of the BSRP trigger frame may include cooperation dependency information.

[0210] According to various embodiments, the special user information field of the BSRP trigger frame may include at least one of information about the type of ICF, information about the cooperation method, information indicating that the selection request frame requests selection of an AP for multi-AP cooperation, information about the type of response to the selection request frame, information about whether ICR is allowed, or cooperation dependency information.

[0211] According to various embodiments, the common information field or the user information field of the BSRP trigger frame may include information indicating that a special user information field exists.

[0212] According to various embodiments, the selection response frame may be a quality of service (QoS) null frame, a QoS data frame, a clear-to-send (CTS) frame, a CTS-to-Self frame, a block acknowledgment (BA) frame, or an action frame.

[0213] FIG. 20 illustrates an example of a method performed by a second AP according to an embodiment of the present disclosure. The second AP may be an AP transmitting an ICR for an ICF to initiate a multi-AP cooperation / multi-AP selection procedure.

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

[0215] In step S2003, the second AP may configure a multi-AP set including neighboring APs based on a negotiation procedure.

[0216] In step S2005, the second AP may receive a selection request frame for initiating multi-AP cooperation with the second AP from the first AP included in the multi-AP set.

[0217] In step S2007, the second AP may transmit a selection response frame to the selection request frame to the first AP.

[0218] In step S2009, after transmitting the selection response frame, the second AP can receive a TXOP shared frame including information about the allocation interval from the first AP.

[0219] Below, a detailed implementation of the trigger frame design in the AP selection procedure for multi-AP cooperation is described.

[0220] In the present disclosure, a trigger frame that can be transmitted in a multi-AP selection procedure in which a SAP selects a DAP to share a TXOP in a Co-TDMA-based transmission, which is a multi-AP cooperation method, can be defined / designed. In addition, a trigger frame that can be considered as an initial control frame for initiating multi-AP operation in an individual multi-AP cooperation procedure can be defined / designed. In the present disclosure, the structure / format of a trigger frame for a multi-AP selection procedure in multi-AP cooperation and / or Co-TDMA operation can be defined / designed.

[0221] I. Defining a new trigger frame type

[0222] In some implementations, a new type of trigger frame may be proposed / designed for multi-AP cooperation and / or multi-AP selection procedures in Co-TDMA-based transmissions. For example, a new type of trigger frame that can be utilized in multi-AP cooperation and / or Co-TDMA-based transmissions may be implemented by utilizing reserved values ​​(e.g., 9 to 15) among the types of trigger frames (e.g., values ​​of the Trigger Type subfield in Table 1).

[0223] I-1. Multi-AP (MAP) trigger frame

[0224] A MAP trigger frame (TF) may be implemented / defined to support multi-AP cooperation / Co-TDMA-based transmission. The specific name (title) of the trigger frame may be changed. The MAP TF may allocate and / or request resources for transmission of one or more TB PPDUs between APs, and an AP responding to the TF may also convey information necessary for transmitting the TB PPDU.

[0225] FIG. 21 illustrates an example of a MAP trigger frame format for a multi-AP selection procedure according to an embodiment of the present disclosure.

[0226] Referring to FIG. 21, a MAP trigger frame may include a common information field and a user information field, and the fields included in the common information field / user information field and the number of bits for each field are illustrated. The names and / or number of bits of the fields may be changed and are not limited thereto. In addition, the MAP trigger frame may further include one or more fields.

[0227] Alternatively, other trigger frame variants besides the MAP trigger frame (e.g., the BSRP trigger frame) may be utilized.

[0228] Alternatively, a block acknowledgment request (BAR) frame may be utilized in addition to the trigger frame.

[0229] The common information field / user information field of the MAP trigger frame may include at least one of the following fields:

[0230] - ICF Type: Indicates the type of ICF. For example, the EHT reserved or reserved bits in the Common Information field can be utilized for the ICF Type field.

[0231] The ICF Type field can indicate the purpose for which the TF is transmitted in the trigger frame. For example, the ICF Type field can indicate the purpose for which the TF that can be utilized as an ICF in DPS (Dynamic Power Saving), IDC (Inter-Device Coexistence), DSO (Dynamic Subband Operation), and / or multi-AP cooperation is transmitted. For example, bit 0 can indicate that the trigger frame is the default TF. Bit 1 can indicate that the trigger frame is a TF for multi-AP cooperation / operation. Bit 2 can indicate that the trigger frame is a TF for DPS operation. Bit 3 can indicate that the trigger frame is a TF for IDC operation. Bit 4 can indicate that the trigger frame is a TF for DSO operation. Other bits may be reserved.

[0232] The ICF Type / MAP Coordination Type field in Fig. 21 may be replaced with the ICF Type field. In this case, the MAP Coordination Type field may utilize some bits of the Coordination Dependent Info field (e.g., 8 bits may be utilized for the MAP Coordination Type field and the Coordination Dependent Info field), or may be defined as a subfield of the Coordination Dependent Info field.

[0233] Additionally or alternatively, the ICF Type field may utilize the EHT Reserved Bits (7 bits) and / or Reserved Bits (4 bits) to indicate one or more specific ICF types, for one or more operations such as DPS, IDC, DSO, multi-AP cooperation, and / or to solicit initial control reply (ICR) information. For example, each bit of the 7 bits may indicate a specific type (e.g., DPS, IDC, DSO, MAP). A combination of each bit (e.g., a bitmap) may be set to solicit ICR information. For example, if B56: MAP, B57: DPS, B58: IDC, B59: DSO (or NPCA (non-primary channel access), other bits: Reserved), then 1100 may solicit ICR information for MAP and DPS.

[0234] - MAP Cooperation Type: Information about multi-AP cooperation methods such as Co-OFDMA, Co-TDMA, and Co-SR.

[0235] In some implementations, the EHT reserved bits (7 bits) or the reserved bits (4 bits) of the common information field may be utilized for the MAP cooperation type field. For example, a new field may be defined to indicate the MAP cooperation type by utilizing one or more bits of the EHT reserved bits (7 bits) (e.g., utilizing 1 to n bits depending on the number of possible multi-AP cooperation schemes). For example, a new field may be defined to indicate the MAP cooperation type by utilizing one or more bits of the reserved bits (4 bits) (e.g., utilizing 1 to n bits depending on the number of possible multi-AP cooperation schemes). For example, a value of 0 may indicate that the trigger frame is a TF for Co-TDMA operation. A value of 1 may indicate that the trigger frame is a TF for Co-SR operation. A value of 2 may indicate that the trigger frame is a TF for Co-BF operation. Other bits may be reserved.

[0236] In some implementations, the TXOP shared mode field (2 bits) and the reserved bit (1 bit) triggered for the MAP cooperation type field may be combined / extended, as illustrated in FIG. 21. For example, the combined / extended 3 bits may indicate the currently operating multi-AP cooperation scheme, such as Co-OFDMA, Co-TDMA, Co-SR, or J-TX.

[0237] Additionally or alternatively, the MAP Collaboration Type field may be included in a user information field or a special user information field.

[0238] - Multi-AP selection (or multi-AP procedure): Indicates a trigger frame (i.e., MAP TF) for a unified multi-AP selection procedure for multi-AP cooperation.

[0239] In some implementations, the EHT reserved bit (7 bits) or reserved bit (4 bits) of the common information field may be utilized for the multi-AP selection field. For example, as illustrated in FIG. 21, one bit corresponding to the type dependent signaling-1 or type dependent signaling-2 field may be utilized to indicate that the TF is transmitted for the multi-AP selection procedure. In this case, bit 0 may indicate that the TF is not transmitted for the multi-AP selection procedure, and bit 1 may indicate that the TF is transmitted for the multi-AP selection procedure.

[0240] Additionally or alternatively, one bit may be additionally utilized to indicate one of the procedures for multi-AP cooperation. For example, the one bit may indicate that the TF is transmitted for a specific procedure among the procedures for multi-AP cooperation. In this case, bit 0 may indicate that the TF is not transmitted for a multi-AP selection procedure. Bit 1 may indicate that the TF is transmitted for a multi-AP selection procedure. Bit 2 may indicate that the TF is transmitted for a TXOP procedure (e.g., time allocation) or a cooperation triggering procedure (i.e., a procedure for initiating / triggering another multi-AP cooperation-based transmission). Additionally or alternatively, bit 2 may replace bit 0. That is, bit 0 may be utilized for the indication by bit 2. Bit 3 may indicate that the TF is transmitted for a TXOP return procedure.

[0241] In some implementations, reserved bits in the user information field may be utilized for the multi-AP selection field.

[0242] Additionally or alternatively, there may be one or more user information field(s) with the same AID, and the additional user information fields may include bits / fields for indicating multi-AP selection (or multi-AP procedure).

[0243] Additionally or alternatively, special user information fields may be utilized for multi-AP selection fields.

[0244] Additionally or alternatively, some bits of the cooperative dependency information field illustrated in FIG. 21 may be utilized for the multi-AP selection field.

[0245] - Response type: Indicates the type of response frame to the transmitted TF and / or the type of information derived from the receiving device.

[0246] In some implementations, one or more type dependent signaling bits illustrated in FIG. 21 may be utilized for the response type field.

[0247] In some implementations, some bits of the Cooperation Dependency Information field illustrated in FIG. 21 may be utilized for the Response Type field. For example, in DPS, IDC, DSP, multi-AP cooperation, this may indicate for what purpose the TF was transmitted and / or what response frame it elicits. In this case, a value of bit 0 or 0 may instruct the receiving device to respond with a QoS Null / Data frame (e.g., including an A-Control field). A value of bit 1 or 1 may instruct the receiving device to respond with a block acknowledgment (BA) frame (e.g., multi-STA BA). A value of bit 2 or 2 may instruct the receiving device to respond with an Action frame (e.g., including an A-Control field). A value of bit 3 or 3 may be reserved. Depending on the derivation type / method, more bits may be used, and a bitmap may also be utilized.

[0248] Additionally or alternatively, the reserved bits of the User Information field may be utilized for the Response Type field.

[0249] Additionally or alternatively, there may be one or more user information field(s) with the same AID, and the additional user information fields may include bits / fields to indicate the response type.

[0250] Additionally or alternatively, special user information fields may be utilized for the response type field.

[0251] Additionally or alternatively, the Response Type field may utilize the EHT reserved bits (7 bits) to be integrated with the ICF Type field for one or more operations such as DPS, IDC, DSO, multi-AP cooperation and / or to solicit initial control reply (ICR) information. For example, each bit of the 7 bits may indicate a specific type (e.g., DPS, IDC, DSO, MAP). A combination of each bit (e.g., a bitmap) may be set to solicit ICR information. For example, if B56: MAP, B57: DPS, B58: IDC, B59: DSO (or NPCA (non-primary channel access), other bits: reserved), 1100 may solicit ICR information for MAP and DPS.

[0252] - General response: Indicates that a general ICR is allowed as a response frame to the transmitted TF.

[0253] In some implementations, the generic response field may allow multiple STA BA (or Compressed BA) frames, Action frames and / or QoS Null / Data frames (containing a new A-Control field or more than one A-Control field) to be transmitted in response to a basic TF.

[0254] In some implementations, the generic response field may allow multiple STA BA (or Compressed BA) frames, Action frames, and / or QoS Null / Data frames (containing a new A-Control field or more than one A-Control field) to be transmitted in response to a BSRP TF.

[0255] In some implementations, the generic response field may allow a multi-STA BA (or Compressed BA) frame, an action frame, and / or a QoS Null / Data frame (containing a new A-Control field or more than one A-Control field) to be transmitted in response to the MU-RTS (TXS) TF.

[0256] In some implementations, the generic response field may allow a multi-STA BA (or Compressed BA) frame, an action frame, and / or a QoS Null / Data frame (containing a new A-Control field or one or more A-Control fields) to be transmitted in response to the (MU-)BAR trigger frame.

[0257] For example, bit 0 of the generic response field may indicate to the receiving device that generic responses are not allowed. Bit 1 of the generic response field may indicate to the receiving device that generic responses are allowed.

[0258] - Coordination Dependent Info: A field that may optionally exist based on the value of the ICF Type / MAP Coordination Type field, and contains information / signaling bits that need to be indicated according to the ICF type, and / or contains common information for multi-AP cooperation or information about a specific cooperation method.

[0259] In some implementations, the cooperation dependency information field may contain / indicate common information required for a specific MAP cooperation scheme and / or Co-TDMA operation.

[0260] For example, the Cooperative Dependency Information field may include information about the Nominal TXOP Duration, which is the period of time (e.g., the nominal TXOP duration scheduled by the SAP for Co-TDMA operation) during which APs participating in Co-TDMA operation cooperate with each other to perform individual FE and / or TXOP sharing / return. The Nominal TXOP Duration may mean the “Scheduled TXOP Duration” below.

[0261] For example, the cooperative dependency information field may include channel and / or bandwidth information on which the SAP is operating (e.g., primary channel, punctured channel, BSS operating channel width, maximum bandwidth). The operating channel and / or bandwidth information may include at least one of the following: “operating channel” information or “operating bandwidth” information.

[0262] In some implementations, the cooperation dependency information field may contain / indicate cooperation mode specific or user specific information required for a particular MAP cooperation mode and / or Co-TDMA operation.

[0263] For example, the Collaboration Dependency Information field may contain information about the TXOP sharing point expected and / or scheduled by SAP. The TXOP sharing point may refer to the “Expected TXOP Sharing Point” below.

[0264] For example, the collaboration dependency information field may include a signaling bit indicating that the SAP may perform more than one TXOP share within the entire TXOP period acquired.

[0265] In some implementations, the cooperative dependency information field may include BSS operating channel width and primary / secondary channel index information recommended by the SAP to the DAP with which the TXOP is to be shared to improve efficiency in Co-TDMA based transmission.

[0266] In some implementations, the TF / Cooperation Dependency Information field transmitted in the multi-AP selection procedure may further include, but is not limited to, at least one of the following A through I. Furthermore, the specific designations (names) of the fields may be changed.

[0267] For example, the TF / Cooperation Dependency Information field transmitted in the multi-AP selection procedure may include the following “A. Multi-AP Group ID” to provide group ID information for corresponding DAPs. In addition, the TF / Cooperation Dependency Information field transmitted in the multi-AP selection procedure may include the following “B. Multi-AP ID” to allow each DAP to recognize that the information is for itself.

[0268] For example, the TF / Cooperation Dependency Information field transmitted in the multi-AP selection procedure may include the “H. Low-Delay Traffic Information” below, and may provide TID (traffic identifier) / AC (access category) information and / or SCS (stream classification service) information for low-delay traffic to corresponding DAPs.

[0269] For example, the TF / cooperation dependency information field transmitted in the multi-AP selection procedure may include “I. Cooperation Priority” below, and may indicate the priority of the currently applied cooperation method among the multi-AP cooperation methods, and / or indicate the priority / protection level for efficient operation of Co-TDMA transmission.

[0270] Additionally or alternatively, the cooperation dependency information field may include at least one of a MAP cooperation type field, a multi-AP selection field, or a response type field, or may include bit(s) corresponding thereto.

[0271] The MAP TF transmitted in the multi-AP selection procedure may further include at least one content from among A to I below. The designations (names) of A to I below may be changed and are not limited thereto. In addition, at least one content from among A to I below may also be included in various trigger frames for the multi-AP selection procedure (e.g., MAP-RTS trigger frame, MU-RTS (TXS) trigger frame, BSRP trigger frame).

[0272] Additionally, the MAP TF may have one or more (additional) user information field(s) with the same AID, and the (additional) user information field(s) may contain content of at least one of the A~I below.

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

[0274] B. DAP ID: An ID locally assigned by each SAP within the configured multi-AP group / set (e.g. 0, 1, 2, ...)

[0275] C. Address: Address information of the DAP that is the target of TXOP sharing among the APs participating in multi-AP cooperation (or included in a multi-AP set) (e.g., BSS color, BSSID for multi-AP, multi-AP group ID, and / or DAP ID).

[0276] D. Operating Channel: Information about the primary channel and punctured channels that are in operation.

[0277] For example, the operating channel information may include commonly operating channel information for smooth cooperation between APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

[0278] For example, the operating channel information may include primary channel information on which APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX) can commonly operate. In some implementations, a new field that serves as the CCSF0 field in the EHT operating information field may be defined to indicate a channel center frequency index for a 20 / 40 / 80 MHz channel. In some implementations, a new field that serves as the CCSF0 field in the EHT operating information field may be defined to indicate a channel center frequency for a primary 80 MHz channel of a 160 MHz channel or a channel center frequency for a primary 160 MHz channel of a 320 MHz channel. In addition, a new field that serves as the CCSF1 field in the EHT operating information field may be defined to indicate a channel center frequency for a 160 MHz channel or a channel center frequency for a 320 MHz channel.

[0279] For example, the operating channel information may include punctured channel information of an AP participating in multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, a new field that acts as a Disabled subchannel bitmap field in the EHT operating information field may be defined to indicate a punctured 20 MHz subchannel using a bitmap. A bit value of 0 in the bitmap may indicate that the corresponding 20 MHz subchannel is not punctured. A bit value of 1 in the bitmap may indicate that the corresponding 20 MHz subchannel is punctured.

[0280] For example, the operating channel information may include information about the primary channel of the DAP within the channel on which the SAP operates.

[0281] For example, the operating channel information may include information about the primary channel of the DAP within the operating channel excluding the punctured channel of the SAP.

[0282] E. Operating Bandwidth Information: Operating bandwidth and maximum bandwidth information.

[0283] For example, the operating bandwidth information may include common operating bandwidth (BW) information for smooth cooperation between APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, the above-described operating channel and primary channel information may be utilized.

[0284] For example, the operating bandwidth information may include the maximum bandwidth information of an AP participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, a new field that functions like the channel width field in the control field of the EHT operation information field may be defined to indicate the channel width, which is BSS BW information for each AP, as follows:

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

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

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

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

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

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

[0291] For example, the operating bandwidth information may include BW field information within the SIG-A field.

[0292] For example, the operating bandwidth information may include UL BW field information included within the common information field of the MU-RTS TXS TF.

[0293] For example, the operating bandwidth information may include information about the bandwidth of the DAP within the overall bandwidth over which the SAP operates.

[0294] For example, a new field for bandwidth indication (i.e., operating bandwidth information) can be added by modifying / redefining the Medium Time field of the QoS characteristic element to include a new subfield. In some implementations, a new field that functions similarly to the Channel Width field in the Control field of the EHT Operating Information field can be defined to indicate the channel width, which is BSS BW information for each AP, as follows:

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

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

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

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

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

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

[0301] F. Scheduled TXOP duration: The period during which APs participating in multi-AP operation / Co-TDMA operation cooperate with each other and perform individual FE and / or TXOP sharing, and / or the nominal TXOP duration scheduled by the SAP for multi-AP operation / Co-TDMA operation.

[0302] For example, a new field including a scheduled TXOP interval may be defined. In some implementations, a scheduled interval field may be defined to indicate information required for multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX) and a scheduled TXOP interval value. In some implementations, a Co-TDMA operation element may be defined to indicate information required for multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX) and a scheduled TXOP interval value.

[0303] For example, a scheduled TXOP interval may be included within a QoS characteristic element that may be used to include negotiation information / cooperation information during a pre-negotiation process for multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX) or an element that may be newly defined for negotiation for multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

[0304] For example, a scheduled TXOP interval may be included within a UHR operation element that may be used to include broadcast information in the broadcast process of each AP for multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX) or an element that may be newly defined for broadcast for multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

[0305] G. Expected TXOP sharing timing: The timing of TXOP sharing expected and / or scheduled by SAP.

[0306] In some implementations, a new field may be defined that includes the expected TXOP sharing point. For example, a new Expected TXOP Sharing Point field may be defined to indicate information required for Co-TDMA operation and / or the expected TXOP sharing point value.

[0307] In some implementations, a new element may be defined that includes the expected TXOP sharing point in time. For example, a new C-TDMA operation element may be defined that indicates information required for Co-TDMA operation and / or the expected TXOP sharing point in time.

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

[0309] For example, low-latency traffic information may be included in the information of QoS attribute elements included in the SCS request / response frame.

[0310] For example, the Delay Bound field information among the QoS characteristic elements can be utilized. In some implementations, the Delay Bound field value for the QoS traffic that each AP wishes to transmit can be utilized as low-delay traffic information. Through this, the SAP can use it to check whether TXOP sharing is necessary for a DAP that can complete transmission of an MSDU or A-MSDU within the end time of the TXOP section to be shared (i.e., the time allocated for the pre-negotiated low-delay traffic information or Delay Bound field value is shorter than the time allocated) or to update the existing value.

[0311] For example, the MSDU Lifetime field information among the QoS characteristic elements can be utilized. In some implementations, the MSDU Lifetime field value for the QoS traffic that each AP wants to transmit can be utilized as low-latency traffic information. Through this, the SAP can use it to check whether TXOP sharing is necessary for a DAP that does not discard MSDUs within the end point of the TXOP section to be shared (i.e., the pre-negotiated low-latency traffic information or the MSDU Lifetime field value has not expired within the allocated time) or to update the existing value.

[0312] For example, the service start time field information among the QoS characteristic elements can be utilized. In some implementations, the service start time field value for the QoS traffic that each AP wishes to transmit can be utilized as low-latency traffic information. Through this, the SAP can use it to check whether TXOP sharing is necessary for a DAP that can start the expected service section and frame exchange within the end time of the TXOP section to be shared (i.e., the pre-negotiated low-latency traffic information or the service start time field value is shorter than the allocated time) or to update the existing value.

[0313] For example, low-latency traffic information may include TXOP sharing request information requested / instructed by an AP requiring transmission of low-latency traffic.

[0314] For example, the low-latency traffic information may include time bound information of the low-latency traffic requested / instructed by the AP requiring transmission of the low-latency traffic (e.g., minimum time-bound within which transmission of the low-latency traffic must begin / maximum time-bound within which transmission of the low-latency traffic must successfully end).

[0315] For example, the low-latency traffic information may include arrival rate information of low-latency traffic requested / instructed by an AP requiring periodic transmission of low-latency traffic (e.g., the arrival rate of low-latency traffic since the last reporting event).

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

[0317] I. Cooperation Priority: It can indicate the priority of the currently used cooperation method among the multi-AP cooperation methods, and / or indicate the priority / protection level for efficiently performing Co-TDMA operation.

[0318] For example, the EHT reserved bit (7 bits) or reserved bit (4 bits) of the common information field can be utilized for the cooperative priority field. For example, two bits of the EHT reserved bit (7 bits) or reserved bit (4 bits) can indicate the priority / protection level of the current Co-TDMA operation. Bit 0 can indicate cooperative transmission with priority / protection level 0. This can mean that no separate protection for TXOP sharing and / or TXOP return is required in Co-TDMA operation. Bit 1 can indicate cooperative transmission with priority / protection level 1-1. This can mean that separate protection for TXOP sharing is required in Co-TDMA operation. Bit 2 can indicate cooperative transmission with priority / protection level 1-2. This can mean that separate protection for TXOP return is required in Co-TDMA operation. Bit 3 may indicate cooperative transmission with priority / protection level 2. This may mean that protection is required for both TXOP sharing and TXOP return in Co-TDMA operation.

[0319] A SAP may replace the AID12 field in the user information field of the MAP TF with an ID associated with multi-AP cooperation to select a DAP. That is, the AID12 field may include an AP ID for identifying an AP participating in multi-AP cooperation (or included in a multi-AP set). The ID associated with multi-AP cooperation may include at least one of the BSSID of the target DAP, the BSS color, the multi-AP group ID (i.e., an ID for a set / group of APs participating in multi-AP cooperation), or the DAP ID (i.e., an ID assigned by the SAP within the multi-AP set / group). Alternatively, when the MAP TF is associated with a single DAP, the RA field of the MAP TF may include the MAC address of the target DAP.

[0320] Therefore, an AP receiving a MAP TF of a new trigger type can identify the multi-AP cooperation type by decoding the MAP TF. Alternatively, if the AP receives a MAP TF in which the AID12 field in the user information field contains its own ID or a MAP TF in which the RA field is set to its MAC address, the AP can identify that the MAP TF is a MAP TF for Co-TDMA / multi-AP cooperation and decode / obtain additional information according to the indicated multi-AP cooperation type. Afterwards, the DAP can transmit a TB PPDU to the SAP based on the information obtained from the TF.

[0321] Additionally or alternatively, information contained in the common information fields / user information fields within the MAP TF described above may be contained in one or more special user information fields and may be transmitted from SAP via the special user information fields.

[0322] In a multi-AP selection procedure, a multi-AP selection response frame included in a TB PPDU transmitted by a DAP may include at least one of the contents a to j below. The designations (names) of a to j below may be changed and are not limited thereto.

[0323] a. Multi-AP Group ID: ID for the group / set of APs that constitute multi-AP cooperation (e.g. 0, 1, 2, ...)

[0324] b. AP ID: An ID locally assigned by each AP within a configured multi-AP group / set (e.g. 0, 1, 2, ...)

[0325] c. Address: Address information of the target AP (e.g., BSS color, BSSID for multiple APs, multiple AP group ID, and / or AP ID).

[0326] d. Operating Channel: Information on the primary channel and punctured channels in operation.

[0327] For example, the operating channel information may include commonly operating channel information for smooth cooperation between APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

[0328] For example, the operating channel information may include primary channel information on which APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX X) can commonly operate. In some implementations, a new field that acts as the CCSF0 field in the EHT operating information field may be defined to indicate a channel center frequency index for a 20 / 40 / 80 MHz channel. In some implementations, a new field that acts as the CCSF0 field in the EHT operating information field may be defined to indicate a channel center frequency for a primary 80 MHz channel of a 160 MHz channel or a channel center frequency for a primary 160 MHz channel of a 320 MHz channel. In addition, a new field that acts as the CCSF1 field in the EHT operating information field may be defined to indicate a channel center frequency for a 160 MHz channel or a channel center frequency for a 320 MHz channel.

[0329] For example, the operating channel information may include punctured channel information of an AP participating in multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, a new field that acts as a Disabled subchannel bitmap field in the EHT operating information field may be defined to indicate a punctured 20 MHz subchannel using a bitmap. A bit value of 0 in the bitmap may indicate that the corresponding 20 MHz subchannel is not punctured. A bit value of 1 in the bitmap may indicate that the corresponding 20 MHz subchannel is punctured.

[0330] For example, the operating channel information may include information about the primary channel of the DAP within the channel on which the SAP operates.

[0331] For example, the operating channel information may include information about the primary channel of the DAP within the operating channel excluding the punctured channel of the SAP.

[0332] e. Operating bandwidth information: Operating bandwidth and maximum bandwidth information.

[0333] For example, the operating bandwidth information may include common operating bandwidth (BW) information for smooth cooperation between APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, the above-described operating channel and primary channel information may be utilized.

[0334] For example, the operating bandwidth information may include the maximum bandwidth information of an AP participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, a new field that functions like the channel width field in the control field of the EHT operation information field may be defined to indicate the channel width, which is BSS BW information for each AP, as follows:

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

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

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

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

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

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

[0341] For example, the operating bandwidth information may include BW field information within the SIG-A field.

[0342] For example, the operating bandwidth information may include UL BW field information included within the common information field of the MU-RTS TXS TF.

[0343] For example, the operating bandwidth information may include information about the bandwidth of the DAP within the overall bandwidth over which the SAP operates.

[0344] For example, a new field for bandwidth indication (i.e., operating bandwidth information) can be added by modifying / redefining the Medium Time field of the QoS characteristic element to include a new subfield. In some implementations, a new field that functions similarly to the Channel Width field in the Control field of the EHT Operating Information field can be defined to indicate the channel width, which is BSS BW information for each AP, as follows:

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

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

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

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

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

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

[0351] f. Requested TXOP interval: Information related to the TXOP interval that each AP wishes to share.

[0352] For example, a new field including a required TXOP interval may be defined. In some implementations, a required interval field may be defined to indicate information and a required TXOP interval value required for multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, a C-TDMA operation element may be defined to indicate information and a required TXOP interval value required for multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

[0353] For example, a QoS characteristic element that can be used to include negotiation information / cooperation information during a pre-negotiation process for multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX) or a required TXOP interval can be included within an element that can be newly defined for negotiation for multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

[0354] For example, a UHR operation element that can be used to include broadcast information in the broadcast process of each AP for multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX) or a required TXOP interval can be included within an element that can be newly defined for broadcast for multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

[0355] g. Buffer status: Buffer status information for each AP

[0356] h. TXOP sharing requirement: Indicates whether TXOP sharing is required, as pre-negotiated low-latency traffic information expires and / or TXOP sharing becomes unnecessary (e.g., individual FEs have already been performed). For example, whether TXOP sharing is required can be indicated / responded using bit 1. Bit 0 can indicate that the DAP receiving the selection request frame does not require TXOP sharing. Bit 1 can indicate that the DAP receiving the selection request frame requires TXOP sharing.

[0357] Additionally or alternatively, whether TXOP sharing is required can be indicated by setting certain fields to all 0.

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

[0359] For example, low-latency traffic information may be included in the information of QoS attribute elements included in the SCS request / response frame.

[0360] For example, the Delay Bound field, a QoS attribute element, may be utilized. In some implementations, the Delay Bound field value for QoS traffic intended for transmission by each AP may be utilized as low-latency traffic information. If there is a change from the pre-negotiated low-latency traffic information, updated low-latency traffic information / delay bound field values ​​may be included.

[0361] For example, the MSDU Lifetime field information in the QoS characteristic element can be utilized. In some implementations, the MSDU Lifetime field value for QoS traffic that each AP wishes to transmit can be utilized as low-latency traffic information. If there is a change from the pre-negotiated low-latency traffic information, updated low-latency traffic information / MSDU Lifetime field value can be included.

[0362] For example, the service start time field information in the QoS characteristic element can be utilized. In some implementations, the service start time field value for QoS traffic that each AP wishes to transmit can be utilized as low-latency traffic information. If there is a change from the pre-negotiated low-latency traffic information, the updated low-latency traffic information / service start time field value can be included.

[0363] For example, low-latency traffic information may include TXOP sharing request information requested / instructed by an AP requiring transmission of low-latency traffic.

[0364] For example, the low-latency traffic information may include time bound information of the low-latency traffic requested / instructed by the AP requiring transmission of the low-latency traffic (e.g., minimum time-bound within which transmission of the low-latency traffic must begin / maximum time-bound within which transmission of the low-latency traffic must successfully end).

[0365] For example, the low-latency traffic information may include arrival rate information of low-latency traffic requested / instructed by an AP requiring periodic transmission of low-latency traffic (e.g., the arrival rate of low-latency traffic since the last reporting event).

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

[0367] j. Status Code: Accept / Reject / Propose information for the selection request (i.e., the selection request can be accepted / rejected by SAP based on whether TXOP sharing is currently required for DAP, and this acceptance / rejection indication can replace the TXOP sharing request information described above).

[0368] For example, a status code may indicate acceptance or success.

[0369] For example, the status code may indicate a rejection, or may indicate a rejection while including proposal information. In some implementations, the status code may include a rejection code that includes a reason for the rejection (e.g., REJECTED_BAD_SUPPORTED_CHANNELS). In some implementations, the status code may include a rejection code that includes proposal information (e.g., REJECTED_WITH_SUGGESTED_CHANGES). If the value of the status code includes rejection and / or proposal information, it may also include information for a new selection request. That is, a DAP that receives a selection request frame may include additional information about the operating channel, bandwidth, required TXOP period, low-latency traffic information, and / or UHR STA support in the multi-AP selection response frame.

[0370] II-2. Multi-AP RTS (MAP-RTS) trigger frame

[0371] In some implementations, a MAP-RTS trigger frame may be defined to support multi-AP cooperation / C-TDMA-based transmission. The specific name (designation) of the MAP-RTS trigger frame may be changed. The MAP-RTS TF may be designed based on the structure / format of the MU-RTS TF and / or the MU-RTS TXS TF.

[0372] Figure 22 shows an example of a MAP-RTS trigger frame format for a multi-AP selection procedure.

[0373] Referring to Figure 22, a MAP-RTS trigger frame may include a common information field and a user information field, and the fields included in the common information field / user information field and the number of bits for each field are illustrated. The names and / or number of bits of the fields may be changed and are not limited thereto. In addition, the MAP-RTS trigger frame may further include one or more fields.

[0374] The common information field / user information field of the MAP-RTS trigger frame may contain at least one of the following fields:

[0375] - ICF type: Can indicate the same information as contained in the MAP trigger frame.

[0376] - MAP Cooperation Type: May indicate the same information as contained in the MAP Trigger Frame. Additionally or alternatively, the MAP Cooperation Type field may be defined by some bits and / or subfields of the Cooperation Dependency Information-2 field.

[0377] - Multi-AP Selection (or Multi-AP Procedure): May indicate the same information as contained in the MAP trigger frame. Additionally or alternatively, the Multi-AP Selection (or Multi-AP Procedure) field may be defined by some bits and / or subfields of the Cooperative Dependency Information-2 field.

[0378] - Response type: Indicates the type of response frame to the transmitted TF and / or the type of information derived from the receiving device.

[0379] In some implementations, one or more type dependent signaling bits illustrated in FIG. 22 may be utilized for the response type field.

[0380] In some implementations, some bits of the Cooperation Dependency Information field in the Common Information field illustrated in FIG. 22 may be utilized for the Response Type field, and / or some bits of the Cooperation Dependency Information-2 field in the User Information field may be utilized for the Response Type field. For example, in DPS, IDC, DSP, multi-AP cooperation, it may indicate for what purpose the TF that can be utilized as ICF was transmitted and / or what response frame it elicits. In this case, bit 0 may instruct the receiving device to respond with a CTS frame (or a CTS-to-Self frame). Bit 1 may instruct the receiving device to respond with a QoS Null / Data frame (e.g., including an A-Control field). Bit 2 may instruct the receiving device to respond with a BA (block acknowledgment) frame (e.g., multi-STA BA). Bit 3 may instruct the receiving device to respond with an Action frame (e.g., including an A-Control field). Bit 3 may be reserved. Depending on the derivation type / method, more bits may be used, and bitmaps may be utilized.

[0381] Additionally or alternatively, the reserved bits of the User Information field may be utilized for the Response Type field.

[0382] Additionally or alternatively, there may be one or more user information field(s) with the same AID, and the additional user information fields may include bits / fields to indicate the response type.

[0383] Additionally or alternatively, special user information fields may be utilized for the response type field.

[0384] - General response: Can indicate the same information as included in the MAP trigger frame.

[0385] - Collaborative Dependency Information: This may indicate the same information contained in the MAP trigger frame. Additionally or alternatively, user-specific information of the collaborative dependency information may be indicated by additionally utilizing the Collaborative Dependency Information-2 field within the User Information field.

[0386] The MAP-RTS TF transmitted in the multi-AP selection procedure may further include at least one of the above-described A to I.

[0387] A SAP may replace the AID12 field in the user information field of the MAP-RTS TF with an ID associated with multi-AP cooperation to select a DAP. That is, the AID12 field may include an AP ID for identifying an AP participating in multi-AP cooperation (or included in a multi-AP set). The ID associated with multi-AP cooperation may include at least one of a BSSID of the target DAP, a BSS color, a multi-AP group ID (i.e., an ID for a set / group of APs participating in multi-AP cooperation), or a DAP ID (i.e., an ID assigned by the SAP within the multi-AP set / group). Alternatively, when the MAP-RTS TF is associated with a single DAP, the RA field of the MAP-RTS TF may include the MAC address of the target DAP.

[0388] Therefore, an AP receiving a MAP-RTS TF of a new trigger type can identify the multi-AP cooperation type by decoding the MAP-RTS TF. Alternatively, if the AP receives a MAP-RTS TF in which the AID12 field in the user information field includes an ID related to itself or a MAP-RTS TF in which the RA field is set to its MAC address, the AP can identify that the MAP-RTS TF is a MAP-RTS TF for C-TDMA / multi-AP cooperation and decode / obtain additional information according to the indicated multi-AP cooperation type. Afterwards, the DAP can transmit a CTS frame (or, CTS-to-Self) frame to the SAP based on the information obtained from the TF.

[0389] Additionally or alternatively, information contained in the common information fields / user information fields within the MAP-RTS TF described above may be contained in one or more special user information fields and may be transmitted from SAP via the special user information fields.

[0390] In a multi-AP selection procedure based on the MAP-RTS trigger frame, the transmission of a CTS frame (or a frame indicated by the response type) may indicate a response to the TF transmitted by the SAP and / or acceptance of the multi-AP selection procedure. That is, if no CTS frame (or corresponding response frame) is received from the DAP, the SAP may consider the multi-AP selection procedure to have failed.

[0391] II. Utilization of MU-RTS TXS Trigger Frame

[0392] In order to design a trigger frame that can be transmitted for a multi-AP selection procedure in multi-AP operation / Co-TDMA operation and / or a trigger frame that can be considered as an initial control frame to start multi-AP operation in an individual multi-AP cooperation procedure, the MU-RTS TXS TF used in the triggered TXOP sharing protocol of EHT can be utilized.

[0393] In some implementations, the multi-AP selection procedure may be initiated by transmission of an MU-RTS TXS TF based on the triggered TXOP sharing mode (i.e., mode 1 or 2) illustrated in Table 2. Similar to how a time-allocated STA in TXS mode = 1 or 2 is allowed to forward MPDU(s) to its associated AP, a DAP may forward MPDU(s) to the SAP that transmitted the MU-RTS TXS TF. This may require transmission of MU-RTS TXS trigger frames between unassociated STAs (i.e., between APs).

[0394] MU-RTS TXS TF based on TXS mode can be defined / designed according to the following option(s):

[0395] Option 1) MU-RTS TXS TF for multi-AP selection procedure is based on TXS mode = 1 or 2 defined in EHT, and (new) fields related to multi-AP cooperation / Co-TDMA based transmission can be added separately to MU-RTS TXS TF for signaling for multi-AP selection procedure.

[0396] FIG. 23 illustrates an example of an MU-RTS TXS trigger frame format for a multi-AP selection procedure according to an embodiment of the present disclosure.

[0397] Referring to FIG. 23, the MU-RTS TXS TF may include a common information field / user information field based on option 1), and the fields included in the common information field / user information field and the number of bits for each field are illustrated. The names and / or number of bits of the fields may be changed and are not limited thereto. In addition, the MU-RTS TXS trigger frame may further include one or more fields.

[0398] The common information field / user information field of the MU-RTS TXS trigger frame may include at least one of the following fields:

[0399] - ICF Type: May indicate the same information contained in the MAP trigger frame. Additionally or alternatively, an ICF Type field may be defined using some of the 12 bits following the Trigger Type field.

[0400] - MAP Cooperation Type: May indicate the same information as that contained in the MAP Trigger Frame. Additionally or alternatively, a MAP Cooperation Type field may be defined using some of the 12 bits following the Trigger Type field. Additionally or alternatively, a MAP Cooperation Type field may be defined using reserved bits (32 bits or more). Additionally or alternatively, the MAP Cooperation Type field may be included in the User Information field or the Special User Information field.

[0401] - Multi-AP Selection (or Multi-AP Procedure): May indicate the same information as that contained in the MAP trigger frame. Additionally or alternatively, a Multi-AP Selection (or Multi-AP Procedure) field may be defined using some of the 12 bits following the Trigger Type field. Additionally or alternatively, a Multi-AP Selection (or Multi-AP Procedure) field may be defined using reserved bits (more than 32 bits). Additionally or alternatively, a Multi-AP Selection (or Multi-AP Procedure) field may be defined using some of the bits of the Cooperative Dependency Information-2 field, or may be defined as a subfield of the Cooperative Dependency Information-2 field.

[0402] - Response type: Indicates the type of response frame to the transmitted TF and / or the type of information derived from the receiving device.

[0403] In some implementations, the response type field may be defined using some of the 12 bits following the trigger type field as shown in FIG. 23.

[0404] In some implementations, a Response Type field may be defined by utilizing some of the bits of the Reserved Bits (32 bits) following the TXS Mode field in the Common Information field illustrated in FIG. 23, or by utilizing some of the bits of the Cooperation Dependency Information-2 field in the User Information field. For example, it may indicate for what purpose the TF, which may be utilized as an ICF in DPS, IDC, DSP, or multi-AP cooperation, was transmitted and / or what response frame it elicits. In this case, bit 0 may instruct the receiving device to respond with a CTS frame (or a CTS-to-Self frame). Bit 1 may instruct the receiving device to respond with a QoS Null / Data frame (e.g., including an A-Control field). Bit 2 may instruct the receiving device to respond with a BA (block acknowledgment) frame (e.g., multi-STA BA). Bit 3 may instruct the receiving device to respond with an Action frame (e.g., including an A-Control field). Bit 3 may be reserved. Depending on the derivation type / method, more bits may be used, and bitmaps may be utilized.

[0405] Additionally or alternatively, there may be one or more user information field(s) with the same AID, and the additional user information fields may include bits / fields to indicate the response type.

[0406] Additionally or alternatively, special user information fields may be utilized for the response type field.

[0407] - General response: Can indicate the same information as included in the MAP trigger frame.

[0408] - Collaborative Dependency Information: This may indicate the same information contained in the MAP trigger frame. Additionally or alternatively, user-specific information of the collaborative dependency information may be indicated by additionally utilizing the Collaborative Dependency Information-2 field within the User Information field.

[0409] The MU-RTS TXS TF transmitted in the multi-AP selection procedure may further include at least one content and / or field (e.g., multi-AP group ID, scheduled TXOP interval) among the above-described A to I. For example, at least one content and / or field (e.g., multi-AP group ID, scheduled TXOP interval) among the above-described A to I may be included in a reserved bit (or, EHT reserved bit) of a common information field, a reserved bit of a user information field, one or more other user information fields having the same AID value, and / or a special user information field having the same AID value or a specific AID value. The specific designations (names) of the above-described fields may be changed.

[0410] Option 2) Instead of the encoding method for the TXS mode of the MU-RTS TXS TF as in , a new encoding method for multi-AP cooperation / Co-TDMA based transmission can be defined.

[0411] For example, a novel encoding method for multi-AP cooperation / Co-TDMA based transmission can be defined as shown in below:

[0412] Triggered TXOP Sharing Mode subfield valueDescription0MU-RTS that does not initiate MU-RTS TXOP sharing procedure.1 (for Multi-AP selection)MU-RTS that initiates Multi-AP selection procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated AP.2 (for TXS in Co-TDMA)MU-RTS that initiates triggered TXOP sharing procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated STA.3Reserved.

[0413] In addition to the TXS mode (i.e., TXS mode = 1 for Multi-AP selection) as in Option 2), the MU-RTS TXS trigger frame may include a field for indicating a multi-AP cooperation method (e.g., Co-OFDMA, Co-TDMA, Co-BF, Co-SR), and may separately include information included in the MU-RTS TXS trigger frame (e.g., multi-AP cooperation type, cooperation dependency information) by utilizing a reserved field. That is, at least one of the contents and / or fields among the above-described A to I (e.g., multi-AP cooperation type, cooperation dependency information) may be added and / or defined in the MU-RTS TXS TF transmitted in the multi-AP selection procedure, but is not limited thereto. In addition, the specific designations (names) of the fields included in the MU-RTS TXS TF may be changed. Additionally, the reserved bits (i.e., TXS mode = 3) may be utilized to indicate other multi-AP cooperation schemes or to indicate other procedures in Co-TDMA operation (e.g., TXOP return). Additionally or alternatively, unlike the encoding scheme using 2 bits presented in Table 3, an (extended) TXS mode field may be defined by utilizing some of the reserved bits following the TXS mode field (bits). That is, a new TXS mode for UHR may be defined by utilizing more than 3 bits.

[0414] Additionally or alternatively, new TXS modes for UHR can be utilized to differentiate ICF types, for example, TXS mode = 1: Multi-AP cooperation, TXS mode = 2: DPS, TXS mode = 3: IDC, TXS mode = 4: DSO.

[0415] Additionally or alternatively, a new TXS mode for UHR can be utilized to distinguish MAP cooperation types, for example, TXS mode = 1: Co-TDMA, TXS mode = 2: Co-SR, TXS mode = 3: Co-BF.

[0416] Additionally or alternatively, a new TXS mode for UHR can be utilized to indicate multi-AP selection (or multi-AP procedure). For example, it can be defined as TXS mode = 1: multi-AP selection, TXS mode = 2: TXOP sharing, TXS mode = 3: TXOP return.

[0417] Additionally or alternatively, the reserved values ​​of the TXS modes presented in may be utilized to indicate multi-AP operation (or multi-AP selection or multi-AP procedure). For example, TXS mode = 1: Allow only UL transmission, TXS mode = 2: Allow UL transmission and P2P transmission, TXS mode = 3: Utilize for multi-AP purposes.

[0418] The SAP may replace the AID12 field in the user information field of the MU-RTS TXS TF with an ID associated with multi-AP cooperation to select a DAP. That is, the AID12 field may include an AP ID for identifying an AP participating in multi-AP cooperation (or included in a multi-AP set). The ID associated with multi-AP cooperation may include at least one of the BSSID of the target DAP, the BSS color, the multi-AP group ID (i.e., an ID for a set / group of APs participating in multi-AP cooperation), or the DAP ID (i.e., an ID assigned by the SAP within the multi-AP set / group). Alternatively, when the MU-RTS TXS TF is associated with a single DAP, the RA field of the MU-RTS TXS TF may include the MAC address of the target DAP.

[0419] Therefore, an AP receiving an MU-RTS TXS TF based on Option 1) and / or Option 2) can decode the MU-RTS TXS TF to identify that the MU-RTS TXS TF is transmitted for a multi-AP selection procedure. Alternatively, if the AP receives an MU-RTS TXS TF with its own ID in the AID12 field in the user information field or an MU-RTS TXS TF with its RA field set to its MAC address, the AP can identify that the MU-RTS TXS TF is an MU-RTS TXS TF for Co-TDMA / multi-AP cooperation, and decode / obtain additional information according to the indicated multi-AP cooperation type. Afterwards, the DAP can transmit a CTS frame (or a CTS-to-Self) frame to the SAP based on the information acquired from the TF. Alternatively, the DAP can respond with a response frame guided by the MU-RTS TXS TF.

[0420] Additionally or alternatively, information contained in the common information fields / user information fields within the MU-RTS TXS TF described above may be contained in one or more special user information fields and may be transmitted from SAP via the special user information fields.

[0421] In a multi-AP selection procedure based on the MU-RTS TXS trigger frame, the transmission of a CTS frame (or a corresponding response frame) may indicate a response to the TF transmitted by the SAP and / or acceptance of the multi-AP selection procedure. That is, if no CTS frame (or a corresponding response frame) is received from the DAP, the SAP may consider the multi-AP selection procedure to have failed.

[0422] III. Utilization of BSRP trigger frames

[0423] Among the trigger frame variants, the BSRP (buffer status report poll) trigger frame may be utilized to design a trigger frame that can be transmitted for a multi-AP selection procedure in multi-AP operation / Co-TDMA operation and / or can be considered as an initial control frame to initiate multi-AP operation in an individual multi-AP cooperation procedure. For this purpose, it may be necessary to transmit the BSRP trigger frame between unassociated STAs (i.e., between APs).

[0424] FIG. 24 illustrates an example of a BSRP trigger frame format for a multi-AP selection procedure according to an embodiment of the present disclosure.

[0425] The size of the user information field of the BSRP TF may not be sufficient to include additional information. Therefore, the common information field of the BSRP TF may include the main fields, and other fields may be included in the special user information field. Additionally or alternatively, similar to how the MU-RTS TF defines and utilizes a separate MU-RTS TXS TF based on the triggered TXOP shared mode (2 bits) field, the BSRP initial control (IC) TF may be defined / utilized based on the GI And HE / EHT-LTF Type / triggered TXOP shared mode field. In this case, the common information field / user information field of the BSRP IC TF may be newly designed. The names (titles) and / or the number of bits of the fields may be changed, but are not limited thereto. In addition, the BSRP TF may further include one or more fields, but are not limited thereto.

[0426] The Common Information Field / (Special) User Information Field of the BSRP TF may contain at least one of the following fields:

[0427] - ICF Type: Can indicate the same information as contained in the MAP trigger frame. For example, the ICF Type field can be defined using some bits of the EHT reservation (7 bits).

[0428] - MAP Cooperation Type: This field can indicate the same information as that contained in the MAP Trigger Frame. For example, the MAP Cooperation Type field can be defined using some bits of the EHT Reserved (7 bits). Additionally or alternatively, the MAP Cooperation Type field can be included in the User Information field or the Special User Information field.

[0429] - Response type: Indicates the type of response frame to the transmitted TF and / or the type of information derived from the receiving device.

[0430] In some implementations, some bits of the EHT reserved bits illustrated in FIG. 24 may be utilized to define a response type field. For example, a TF that can be utilized as an ICF in DPS, IDC, DSP, or multi-AP cooperation may indicate for what purpose the TF was transmitted and / or what response frame it elicits. In this case, bit 0 may instruct the receiving device to respond with a QoS Null / Data frame (e.g., including an A-Control field). Bit 1 may instruct the receiving device to respond with a block acknowledgment (BA) frame (e.g., multi-STA BA). Bit 2 may instruct the receiving device to respond with an action frame (e.g., including an A-Control field). Depending on the elicitation type / method, more bits may be used, and a bitmap may also be utilized.

[0431] Additionally or alternatively, there may be one or more user information field(s) with the same AID, and the additional user information fields may include bits / fields to indicate the response type.

[0432] Additionally or alternatively, special user information fields may be utilized for the response type field.

[0433] - Multi-AP ID or AP ID: An ID (e.g., 0, 1, 2, ...) locally assigned by each AP within a configured multi-AP set / group. For example, the multi-AP ID or AP ID may be included in the AID12 field within the user information field of the trigger frame.

[0434] To include additional multi-AP cooperation-related information, new special user information fields for UHR may be defined / included within the BSRP TF. Additionally or alternatively, the ICF Type, MAP Cooperation Type, and Response Type fields described above may also be included in the new special user information fields for UHR.

[0435] For this purpose, a new UHR special user information field flag (or UHR function control indication) field may be defined using 1 bit of the EHT reserved bits (7 bits), and the value of the UHR special user information field flag may be set to 1. Additionally or alternatively, a reserved bit (1 bit) in the user information field may indicate whether a newly defined UHR special user information field exists for multi-AP cooperation and / or according to the operation type indicated by the ICF type field in a user-specific manner (i.e., a UHR special user information field flag may be defined using the reserved bit in the user information field). The UHR special user information field flag may be defined and / or included to indicate whether a UHR special user information field containing additional information exists.

[0436] Accordingly, an indication value of the AID12 field in the UHR special user information field may be newly defined (e.g., AID of the special user information field = 2007) to include at least one of the information A to I for multi-AP cooperative operation and / or additional fields mentioned in the present disclosure (e.g., cooperative dependent information field). In EHT, the special user information field may be identified by the AID12 field value of 2007. Similar to the definition of the special user information field in EHT, a separate UHR special user information field (e.g., UHR special user information field) may be defined to include additional information according to multi-AP operation and / or various ICF types. In order to indicate that the UHR special user information field is a new special user information field in UHR, the value of the AID12 field may be set to a reserved value (e.g., one of the values ​​2008 to 2044 or one of the values ​​2047 to 4094). The UHR special user information field, identified by the new AID12 value, may be positioned following the common information field, following the user information field, or following the special user information field (of the EHT). Additionally or alternatively, the UHR special user information field may be positioned before or after the user information field for the corresponding user.

[0437] FIG. 25 illustrates a first example of a UHR special user information field according to an embodiment of the present disclosure.

[0438] Referring to Figure 25, some fields (e.g., ICF type, MAP collaboration type, response type) may be indicated by utilizing the EHT reserved fields within the common information field, and the remaining additional information (e.g., collaboration dependency information) may be included in the UHR special user information field.

[0439] FIG. 26 illustrates a second example of a UHR special user information field according to an embodiment of the present disclosure.

[0440] Referring to FIG. 26, one bit of the EHT reserved field in the common information field can indicate whether a UHR special user information field exists, and related fields can be included in the UHR special user information field.

[0441] The collaborative dependent information field may include at least one of the contents of A to I described above and / or additional fields mentioned in the present disclosure.

[0442] Additionally or alternatively, there may be one or more user information fields having the same AID12 field value, and subsequent user information fields having the same AID12 field value, arranged consecutively or non-consecutively, may contain additional user-specific information depending on the ICF type.

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

[0444] 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 perform operations performed by the first AP in the present disclosure. The operations include: performing a negotiation procedure for multi-AP cooperation with neighboring APs; configuring a multi-AP set including the neighboring APs based on the negotiation procedure; transmitting a selection request frame to a second AP included in the multi-AP set for initiating multi-AP cooperation with the second AP; receiving a selection response frame for the selection request frame from the second AP; and transmitting a TXOP shared frame including information on an allocation interval to the second AP based on receiving the selection response frame.

[0445] For example, the processor (111) of FIG. 1, the processing chip (114) and / or the processor (510) of FIG. 5 may be configured to execute instructions stored in the memory (112, 520) to perform operations performed by the second AP in the present disclosure. The operations include: performing a negotiation procedure for multi-AP cooperation with neighboring APs; configuring a multi-AP set including the neighboring APs based on the negotiation procedure; receiving, from a first AP included in the multi-AP set, a selection request frame for initiating the multi-AP cooperation with the second AP; transmitting, to the first AP, a selection response frame for the selection request frame; and receiving, after transmitting the selection response frame, a TXOP shared frame including information on an allocation interval from the first AP.

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

[0447] 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 that perform operations performed by the first AP in the present disclosure based on being executed by a processor (e.g., the processor (121) and / or the processing chip (124) of FIG. 1). The operations include: performing a negotiation procedure for multi-AP cooperation with neighboring APs; configuring a multi-AP set including the neighboring APs based on the negotiation procedure; transmitting a selection request frame to a second AP included in the multi-AP set for initiating the multi-AP cooperation with the second AP; receiving a selection response frame for the selection request frame from the second AP; and transmitting a TXOP shared frame including information on an allocation interval to the second AP based on receiving the selection response frame.

[0448] For example, the CRM may be the memory (112) of FIG. 1, the memory (520) of FIG. 5, and / or a separate external memory / storage medium / disk. The CRM may store commands that perform operations performed by the second AP in the present disclosure based on being executed by a processor (e.g., the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5). The operations include: performing a negotiation procedure for multi-AP cooperation with neighboring APs; configuring a multi-AP set including the neighboring APs based on the negotiation procedure; receiving, from a first AP included in the multi-AP set, a selection request frame for initiating the multi-AP cooperation with the second AP; transmitting, to the first AP, a selection response frame for the selection request frame; and receiving, after transmitting the selection response frame, a TXOP shared frame including information on an allocation interval from the first AP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0466] For example, in the present disclosure, the structure / format of a trigger frame transmitted by a SAP to select a DAP to perform multi-AP cooperation-based transmission in multi-AP operation / C-TDMA operation is defined. Using the trigger frame according to various embodiments of the present disclosure, the SAP can perform a multi-AP selection procedure to select a DAP.

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

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

Claims

1. A step in which the first AP (access point) performs a negotiation procedure for multi-AP cooperation with neighboring APs; Based on the above negotiation procedure, the step of the first AP configuring a multi-AP set including the neighboring APs; A step of transmitting a selection request frame to a second AP included in the multi-AP set to initiate multi-AP cooperation with the second AP; A step in which the first AP receives a selection response frame for the selection request frame from the second AP; and A method comprising the step of: based on receiving the selection response frame, the first AP transmitting a TXOP shared frame including information about an allocation interval to the second AP.

2. A method according to claim 1, wherein the selection request frame includes identification information of the second AP for the multi-AP cooperation.

3. In claim 2, the identification information of the second AP for the multi-AP cooperation is included in the AID (association identifier) 12 field in the user information field of the selection request frame, A method wherein the identification information of the second AP includes at least one of a BSSID (basic service set identifier) of the second AP, a BSS color of the second AP, an ID of the multi-AP set, or an ID assigned to the second AP within the multi-AP set.

4. In claim 2, the identification information of the second AP for the multi-AP cooperation includes the address of the second AP, A method in which the RA (receiver address) field of the above selection request frame is set to the address of the second AP.

5. In claim 1, the selection request frame is an initial control frame (ICF) for starting the multi-AP cooperation, The above selection response frame is an ICR (initial control reply) for the ICF.

6. A method according to claim 1, wherein the selection request frame includes at least one of information on the type of ICF, information on a cooperation method, information indicating that the selection request frame requests selection of an AP for the multi-AP cooperation, information on the type of a response to the selection request frame, information on whether ICR is allowed, or cooperation dependency information.

7. A method according to claim 6, wherein the cooperation dependency information includes at least one of an identifier of the multi-AP set, an ID assigned to the second AP within the multi-AP set, information about an address of the second AP, information about an operating channel, information about an operating bandwidth, information about a scheduled TXOP period, information about a timing of the TXOP sharing, low-latency traffic information, or information about a priority of a current cooperation method among cooperation methods.

8. A method according to claim 1, wherein the selection response frame includes at least one of an identifier of the multi-AP set, an ID assigned to the second AP within the multi-AP set, information about an address of the second AP, information about an operating channel, information about an operating bandwidth, information about a TXOP section requested by the second AP, information about a buffer status of the second AP, information about whether TXOP sharing is necessary, low-latency traffic information, or a status code for a request by the selection request frame.

9. In claim 1, the selection request frame is a trigger frame including a trigger type subfield set to a reserved value among the values of the trigger type subfield, A method wherein the above reserved value is one of 9 to 15.

10. A method according to claim 1, wherein the selection request frame is a MU (multi-user)-RTS TXS (TXOP sharing) trigger frame.

11. A method according to claim 1, wherein the selection request frame is a BSRP (buffer status report poll) trigger frame.

12. In claim 11, the common information field of the BSRP trigger frame includes at least one of information on the type of ICF, information on the cooperation method, information indicating that the selection request frame requests selection of an AP for the multi-AP cooperation, information on the type of response to the selection request frame, or information on whether ICR is allowed. A method in which the special user information field of the above BSRP trigger frame includes cooperative dependency information.

13. A method according to claim 11, wherein the special user information field of the BSRP trigger frame includes at least one of information on a type of ICF, information on a cooperation method, information indicating that the selection request frame requests selection of an AP for the multi-AP cooperation, information on a type of a response to the selection request frame, information on whether ICR is allowed, or cooperation dependency information.

14. A method according to claim 12 or 13, wherein the common information field or the user information field of the BSRP trigger frame includes information indicating that the special user information field exists.

15. A method according to claim 1, wherein the selection response frame is a QoS (quality of service) null frame, a QoS data frame, a CTS (clear-to-send) frame, a CTS-to-Self frame, a BA (block acknowledgement) frame, or an action frame.

16. At the first AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The above memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: An action that performs a negotiation procedure for multi-AP cooperation with neighboring APs; An action of configuring a multi-AP set including the neighboring APs based on the above negotiation procedure; An action of transmitting a selection request frame to a second AP included in the multi-AP set to initiate multi-AP cooperation with the second AP; An operation of receiving a selection response frame for the selection request frame from the second AP; and A first AP including an operation of transmitting a TXOP shared frame including information about an allocation interval to the second AP based on receiving the above selection response frame.

17. In the device, at least one processor; and comprising at least one memory functionally coupled with at least one processor; The at least one memory stores instructions that perform operations based on being executed by the at least one processor, the operations comprising: An action that performs a negotiation procedure for multi-AP cooperation with neighboring APs; An action of configuring a multi-AP set including the neighboring APs based on the above negotiation procedure; An action of transmitting a selection request frame to a second AP included in the multi-AP set to initiate multi-AP cooperation with the second AP; An operation of receiving a selection response frame for the selection request frame from the second AP; and A device comprising an operation of transmitting, to the second AP, a TXOP shared frame including information about an allocation interval, based on receiving the above selection response frame.

18. A non-transitory computer readable medium (CRM) storing program code implementing instructions that perform operations based on being executed by at least one processor, said operations comprising: An action that performs a negotiation procedure for multi-AP cooperation with neighboring APs; An action of configuring a multi-AP set including the neighboring APs based on the above negotiation procedure; An action of transmitting a selection request frame to a second AP included in the multi-AP set to initiate multi-AP cooperation with the second AP; An operation of receiving a selection response frame for the selection request frame from the second AP; and A CRM including an operation of transmitting a TXOP shared frame including information about an allocation interval to the second AP based on receiving the above selection response frame.

19. The step where the second AP (access point) performs a negotiation procedure for multi-AP cooperation with neighboring APs; Based on the above negotiation procedure, the second AP configures a multi-AP set including the neighboring APs; A step for the second AP to receive a selection request frame for starting multi-AP cooperation with the second AP from a first AP included in the multi-AP set; The step of the second AP transmitting a selection response frame to the selection request frame to the first AP; and A method comprising the step of: after transmitting the selection response frame, the second AP receiving a TXOP shared frame including information about an allocation interval from the first AP.

20. At the second AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The above memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: An action that performs a negotiation procedure for multi-AP cooperation with neighboring APs; An action of configuring a multi-AP set including the neighboring APs based on the above negotiation procedure; An operation of receiving a selection request frame for starting multi-AP cooperation with the second AP from a first AP included in the multi-AP set; An operation of transmitting a selection response frame to the selection request frame to the first AP; and A second AP including an operation of receiving a TXOP shared frame including information about an allocation interval from the first AP after transmitting the above selection response frame.

Images