Design of trigger frame for multi-AP coordination in wireless LAN system

Abstract

The present disclosure provides a method and a device for designing a trigger frame for multi-AP coordination in a wireless LAN system. According to an embodiment of the present disclosure, a method performed by a first access point (AP) configured to operate in a wireless LAN system comprises the steps of: performing a negotiation procedure for multi-AP coordination with a second AP; determining a coordination scheme for multi-AP coordination with the second AP on the basis of capability information of the second AP, obtained in the negotiation procedure; determining, on the basis of the coordination scheme, information included in an allocation period subfield for the second AP in a trigger frame for triggering the multi-AP coordination; transmitting, to the second AP, the trigger frame in which the allocation period subfield includes the determined information; and performing multi-AP coordination with the second AP on the basis of the information included in the allocation period subfield.

Description

Design of a trigger frame for multi-AP cooperation in a wireless LAN system

[0001] The present disclosure relates to the design of a trigger frame for multi-access point (AP) coordination in a wireless LAN system.

[0002] Next-generation Wi-Fi (e.g., IEEE 802.11be and / or later) aims to support ultra-high reliability in signal transmission to STAs, and various technologies are being considered to support high throughput, low latency, and extended range.

[0003] For example, Radio Resource Management (RRM) technologies based on coordination between multiple APs have been proposed. For example, each AP can share information about its managed Basic Service Set (BSS) with neighboring APs, and based on this information, adjust channel selection, transmission timing, transmission power, and beamforming direction to minimize interference. This type of inter-AP cooperation technique can reduce transmission collisions, increase the efficiency of wireless resource utilization, and contribute to improving the overall quality of service (QoS) of the system in high-density network environments.

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

[0005] According to an embodiment of the present disclosure, a method performed by a first access point (AP) configured to operate in a wireless LAN system includes the steps of: performing a negotiation procedure for multi-AP cooperation with a second AP; determining a cooperation method for multi-AP cooperation with the second AP based on capability information of the second AP obtained in the negotiation procedure; determining information included in an allocation period subfield for the second AP in a trigger frame for triggering the multi-AP cooperation based on the cooperation method; transmitting the trigger frame, in which the allocation period subfield includes the determined information, to the second AP; and performing multi-AP cooperation with the second AP based on the information included in the allocation period subfield.

[0006] According to an embodiment of the present disclosure, a method performed by a second AP (access point) configured to operate in a wireless LAN system includes the steps of: performing a negotiation procedure for multi-AP cooperation with a first AP; receiving a trigger frame for triggering the multi-AP cooperation from the first AP, wherein information included in an allocation period subfield for the second AP in the trigger frame is determined based on a cooperation method for multi-AP cooperation with the first AP, and the cooperation method for multi-AP cooperation with the first AP is determined based on capability information of the second AP transmitted in the negotiation procedure; and performing the multi-AP cooperation with the first AP based on information included in the allocation period subfield.

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

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

[0009] For example, trigger frames can be effectively designed for various multi-AP cooperation methods.

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

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

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

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

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

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

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

[0017] Figure 7 shows the operation according to UL-MU.

[0018] Figure 8 shows an example of a header of a MAC frame.

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

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

[0021] Figure 11 shows an example of multi-AP operation based on Co-TDMA between APs.

[0022] FIG. 12 illustrates an example of a multi-AP negotiation procedure according to an embodiment of the present disclosure.

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

[0024] FIG. 14 illustrates an example of a method performed by a first AP based on the design of a trigger frame for multi-AP cooperation according to an embodiment of the present disclosure.

[0025] FIG. 15 illustrates an example of a method performed by a second AP based on the design of a trigger frame for multi-AP cooperation according to an embodiment of the present disclosure.

[0026] FIG. 16 illustrates an example of a cooperation triggering method based on a TXS triggered for multi-AP cooperation according to an embodiment of the present disclosure.

[0027] FIG. 17 illustrates a first example of a common information field format in an MU-RTS TXS trigger frame for cooperative triggering in multi-AP cooperation according to embodiments of the present disclosure.

[0028] FIG. 18 illustrates a second example of a common information field format in an MU-RTS TXS trigger frame for cooperative triggering in multi-AP cooperation according to embodiments of the present disclosure.

[0029] FIG. 19 illustrates an example of a user information field format in an MU-RTS TXS trigger frame for cooperation triggering in multi-AP cooperation according to an embodiment of the present disclosure.

[0030] FIG. 20 illustrates an example of a UHR special / feedback user information field according to an embodiment of the present disclosure.

[0031] FIG. 21 illustrates an example of a UHR special / feedback user information field containing a user information field and user-specific information in Co-TDMA according to an embodiment of the present disclosure.

[0032] FIG. 22 illustrates an example of a UHR modified user information field format in Co-TDMA containing information for Co-TDMA operation according to an embodiment of the present disclosure.

[0033] FIG. 23 illustrates an example of the structure of a trigger frame in which a new (UHR) special / feedback user information field containing MAPC related information is defined / used according to an embodiment of the present disclosure.

[0034] FIG. 24 illustrates an example of the structure of a trigger frame including one or more (UHR) special / feedback user information fields according to an embodiment of the present disclosure.

[0035] FIG. 25 illustrates an example of the structure of a trigger frame in which a UHR modified user information field including MAPC related information is defined / used 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 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 that generates a transmission / reception signal or performs data processing or operation in advance for a transmission / reception signal may include 1) an operation of determining / obtaining / configuring / computing / decoding / encoding bit information of a subfield (SIG, STF, LTF, Data) field included in a PPDU, 2) an operation of determining / configuring / obtaining time resources or frequency resources (e.g., subcarrier resources) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 3) an operation of determining / configuring / obtaining a specific sequence (e.g., a pilot sequence, an STF / LTF sequence, an extra sequence applied to SIG) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 4) a power control operation and / or a power saving operation applied to an STA, 5) an operation related to determining / obtaining / configuring / computing / decoding / encoding an ACK signal, etc. Additionally, in the examples below, various information (e.g., information related to fields / subfields / control fields / parameters / power, etc.) used by various STAs for determining / acquiring / configuring / computing / decoding / encoding transmission / reception signals can be stored in the memory (112, 122) of FIG. 1.

[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] The 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] Figure 7 illustrates an operation according to UL-MU. As illustrated, a transmitting STA (e.g., AP) can acquire a TXOP (725) by performing channel access through contending (i.e., backoff operation) and transmit a trigger frame (730). That is, the transmitting STA (e.g., AP) can transmit a PPDU including a trigger frame (730). When a PPDU including a trigger frame is received, a TB (trigger-based) PPDU is transmitted after a delay of SIFS.

[0127] TB PPDUs (741, 742) 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 (730). The ACK frame (750) for the TB PPDU can be implemented in various forms. For example, the ACK frame (750) for the TB PPDU can be implemented in the form of a BA (block ACK).

[0128] In FIG. 7, transmission(s) of a Trigger Frame (730), a TB PPDU (741, 742) and / or an ACK frame (750) may be performed within a TXOP (725).

[0129] Below, we explain NAV (Network Allocation Vector).

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

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

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

[0133] In addition to the RTS frame and / or CTS frame, 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.

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

[0135] Below, the structure and types / subtypes of MAC frames are described.

[0136] Figure 8 shows an example of a header of a MAC frame.

[0137] As illustrated, the MAC frame may include a frame control field / information of 2 octets in length, a duration field / information of 2 octets in length, a RA (Receiver Address) field / information of 6 octets in length, and a TA (Transmitter Address) field / information of 6 octets in length. As illustrated in FIG. 8, the four fields may be consecutive to each other. The MAC header of FIG. 8 may be modified in various ways, and a new field may be inserted between the four illustrated fields, or at least one of the illustrated fields may be omitted.

[0138] The MAC header illustrated in Fig. 8 may be positioned at the very front of the MAC frame. That is, the MAC frame may include a MAC header as illustrated in Fig. 8 and MAC body fields / information subsequent to the MAC header. The MAC frame including the MAC header of Fig. 8 is inserted / included in the data field of the PPDU (e.g., UHR PPDU) illustrated in Fig. 5.

[0139] The MAC frames included in the data field of the PPDU of this specification can be classified into various types. For example, the MAC frames of this specification can be classified into control frames, management frames, and data frames.

[0140] 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) in FIG. 8 are set to 00. In addition, the values ​​of the subtype fields (B7, B6, B5, B4) in FIG. 8 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).

[0141] 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 values ​​of the type fields (B3 and B2) in FIG. 8 are set to 01. Also, the values ​​of the subtype fields (B7, B6, B5, B4) of FIG. 8 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).

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

[0143] The MAC frame / signal used in this specification can be identified through the type field / information and subtype field / information described above. For example, the “trigger frame” in this specification 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, B4 bits in the frame control field are also set to 0010. Various MAC frames described in this specification are inserted / included in the data field of various PPDUs (e.g., HE / VHT / HE / EHT / UHR PPDU).

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

[0145] Referring to FIG. 9, 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.

[0146] 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:

[0147] 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

[0148] 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:

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

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

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

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

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

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

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

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

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

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

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

[0160] When the triggered TXOP sharing protocol is utilized for multi-AP cooperation (e.g., Co-TDMA), 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. In this case, the AP in the triggered TXS protocol may be an AP that shares TXOP in multi-AP cooperation operation, and the STA in the triggered TXS protocol may be an AP that shares TXOP in multi-AP cooperation operation.

[0161] 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) (or CAP (coordinated AP)). Here, the term SAP does not limit the entity that shares a TXOP to only AP STAs, and the SAP may also include non-AP STAs that share the TXOP. In addition, the term DAP does not limit the entity that shares a TXOP to only AP STAs, and the DAP may also include non-AP STAs that share the TXOP (or transmit and receive with AP STAs that share the TXOP).

[0162] Additionally, frame exchange performed by a DAP with a non-AP STA or SAP belonging to the DAP BSS during the allocated time (i.e., the allocated period for the DAP 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) may be referred to as a BSS frame exchange (FE) of the DAP. For example, 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.

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

[0164] Figure 11 shows an example of multi-AP operation based on Co-TDMA between APs.

[0165] Referring to Fig. 11, SAP and non-AP STA1 may belong to BSS1, and DAP and non-AP STA2 may belong to BSS2. SAP may acquire TXOP and share TXOP with DAP by transmitting MU-RTS TXS TF including information about allocation period within TXOP (time allocated in MU-RTS TXS TF in Fig. 11). DAP may transmit CTS in response to MU-RTS TXS TF and perform frame exchange with non-AP STA2 belonging to its BSS (i.e., BSS2) in the allocation period shared from SAP. Although not shown, after frame exchange is completed (or after allocation period ends), DAP may transmit TXOP return frame to return TXOP to SAP. After frame exchange is completed within a TXOP (or after the allocation period ends), there may be a remaining TXOP period, and the SAP may perform frame exchange with a non-AP STA1 belonging to its own BSS (i.e., BSS1) within the remaining TXOP period.

[0166] 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 Jo-TX (joint transmission)) can be performed based on the obtained information. That is, 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 based on the negotiation procedure. Therefore, the negotiation procedure may also be referred to as a multi-AP set setup / configuration procedure.

[0167] FIG. 12 illustrates an example of a multi-AP negotiation procedure according to an embodiment of the present disclosure.

[0168] Referring to FIG. 12, AP 1 can perform a multi-AP negotiation procedure (or a negotiation procedure for multi-AP cooperation) with AP 2. In the negotiation procedure, AP 1 can transmit a coordination request frame including capability information of AP 1, and AP 2 can transmit a coordination response frame including capability information of AP 2. If AP 2 accepts the cooperation request, the coordination response frame can include information indicating such acceptance, and a cooperation setup for multi-AP cooperation (or a (multi-AP) cooperation setup for AP 1 and AP 2) can be established between AP 1 and AP 2. That is, if the negotiation procedure is successfully completed (or if a cooperation response frame is transmitted / received), a cooperation setup for multi-AP cooperation can be established between AP 1 and AP 2. The cooperative setting can be set to be supported by both AP 1 and AP 2 based on the capability information of AP 1 and the capability information of AP 2, and can include at least one of the information included in the capability information of AP 1 or the information included in the capability information of AP 2.

[0169] Additionally, if the negotiation procedure is successfully completed, a multi-AP set / group including AP 1 and AP 2 may be established (or a multi-AP set / group configuration may be established). Accordingly, the negotiation procedure may include at least one of a procedure for establishing a cooperation configuration for multi-AP cooperation or a procedure for establishing a multi-AP set / group (or a multi-AP set / group configuration). In the present disclosure, a multi-AP set / group may also be referred to as a cooperation group.

[0170] After AP 1 performs a multi-AP negotiation procedure with AP 2, AP 1 can perform a multi-AP negotiation procedure with AP 3 in a similar manner. Upon successful completion of the negotiation procedure: i) a (multi-AP) cooperation configuration is established for AP 1, AP 2, and AP 3 (or for each pair among AP 1, AP 2, and AP 3), and ii) a multi-AP set / group including AP 1, AP 2, and AP 3 can be established (or a multi-AP set / group configuration can be established).

[0171] As described above, when an AP performs a multi-AP negotiation procedure with one or more other APs, and the negotiation procedure is successfully completed: i) a (multi-AP) cooperation configuration is established for the APs that performed the negotiation procedure (or for each pair of APs that performed the negotiation procedure), and ii) a multi-AP set / group including the APs that performed the negotiation procedure may be established (or a multi-AP set / group configuration may be established).

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

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

[0174] Referring to FIG. 13, 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.

[0175] 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) associated with the DAP within the time period (e.g., allocation period) allocated by the TXOP sharing frame.

[0176] In this disclosure, multi-AP selection may be used interchangeably with schedule announcement, coordination announcement, and cooperative polling.

[0177] Meanwhile, in a Co-TDMA environment, since the SAP allocates time to the DAP, the SAP can trigger cooperation by utilizing the existing triggered TXS protocol. That is, the SAP can initiate TXOP sharing between APs by transmitting an MU-RTS TXS TF containing information and / or signaling bits for Co-TDMA operation.

[0178] Among the multi-AP collaboration methods, Co-SR and Co-BF are collaboration methods in which SAP and DAP simultaneously transmit and receive during the collaboration period. Therefore, a new or newly defined collaboration trigger method and / or a device implementing such a method is required, which is different from the existing triggered TXS. In addition, the trigger frame that SAP transmits to DAP for collaboration triggering needs to be newly designed.

[0179] Accordingly, the present disclosure provides various embodiments regarding the structure and / or format of a trigger frame transmitted by a SAP to a DAP to trigger cooperation in a multi-AP cooperation (or transmitted in a cooperation trigger procedure). Using the trigger frame according to various embodiments of the present disclosure, the SAP can notify the DAP of the start of cooperation and / or trigger cooperation. Specifically, the present disclosure can utilize the MU-RTS TXS TF used in the triggered TXS procedure of the EHT.

[0180] The specific designations (names) proposed in this disclosure may be changed and are not limited thereto.

[0181] FIG. 14 illustrates an example of a method performed by a first AP based on the design of a trigger frame for multi-AP cooperation according to an embodiment of the present disclosure.

[0182] Referring to FIG. 14, in step S1401, the first AP can perform a negotiation procedure for multi-AP cooperation with the second AP.

[0183] In step S1403, the first AP may determine a cooperation method for multi-AP cooperation with the second AP based on the capability information of the second AP obtained in the negotiation procedure.

[0184] In step S1405, the first AP may determine information to be included in an allocation period subfield for the second AP in a trigger frame for triggering multi-AP cooperation based on a cooperation method.

[0185] In step S1407, the first AP may transmit a trigger frame including information on which an allocation period subfield is determined to the second AP.

[0186] In step S1409, the first AP can perform multi-AP cooperation with the second AP based on information included in the allocation period subfield.

[0187] According to various embodiments, based on the first collaboration mode, the allocation period subfield may include information about the allocation period associated with the first collaboration mode. Based on the second collaboration mode, the allocation period subfield may include information about the collaboration interval associated with the second collaboration mode instead of information about the allocation period.

[0188] According to various embodiments, the allocation period may be a period during which transmissions by the second AP are performed while transmissions by the first AP are not performed. The cooperation period may be a period during which transmissions by the first AP and transmissions by the second AP are performed.

[0189] According to various embodiments, based on the cooperation mode being the second cooperation mode, the allocation period subfield may further include at least one of information about the length of a physical layer protocol data unit (PPDU) that can be simultaneously transmitted by the first AP and the second AP in the cooperation period, or information about the interval between a PPDU and a response frame to the PPDU.

[0190] According to various embodiments, the allocation period subfield for the second AP may be included in a user information field for the second AP in the trigger frame. In the user information field, an association identifier (AID) subfield may include at least one of at least a portion of a basic service set (BSS) color associated with the second AP, at least a portion of a BSS identifier (BSSID) associated with the second AP, an ID of a cooperative group for the second AP, or an AP ID locally assigned to the second AP within the cooperative group.

[0191] According to various embodiments, the trigger frame may be a MU-RTS (multi-user request to send) TXS (TXOP (transmission opportunity) sharing) trigger frame. The value of the TXS mode subfield of the trigger frame may be related to the cooperation method.

[0192] According to various embodiments, based on whether the cooperation mode is the first cooperation mode, the TXS mode subfield may be set to a value associated with the first cooperation mode. Based on whether the cooperation mode is the first cooperation mode, the TXS mode subfield may be set to a value associated with the second cooperation mode. The first cooperation mode may be associated with soliciting transmission of a CTS (clear to send) frame for a TXS trigger frame. The second cooperation mode may be associated with unsoliciting transmission of a CTS for a TXS trigger frame.

[0193] According to various embodiments, the first cooperation scheme may include coordinated time division multiple access (Co-TDMA). The second cooperation scheme may include at least one of coordinated spatial reuse (Co-SR) or coordinated beamforming (Co-BF).

[0194] According to various embodiments, based on whether the cooperation mode is Co-TDMA, the TXS mode subfield may be set to a value related to Co-TDMA. Based on whether the cooperation mode is Co-SR, the TXS mode subfield may be set to a value related to Co-SR. Based on whether the cooperation mode is Co-BF, the TXS mode subfield may be set to a value related to Co-BF.

[0195] According to various embodiments, the TXS mode subfield may be set to a value indicating that the trigger frame is intended to trigger multi-AP cooperation.

[0196] According to various embodiments, a trigger frame for triggering multi-AP cooperation may include coordination information for multi-AP cooperation. The cooperation information may include at least one of: an address of the second AP, an identifier of a cooperation group for the second AP, an AP ID locally assigned to the second AP within the cooperation group, information on a cooperation method, information included in an allocation period subfield, information on an operating channel, information on an operating bandwidth, information on a traffic priority, information on a cooperation trigger, information on whether a CTS (clear to send) is requested, information on whether a TXOP (transmission opportunity) return is requested, a multi-AP Ack (acknowledgment) policy indicator, information on whether a NAV (network allocation vector) is disabled, information on whether a transmission is performed, information on transmission power, In-BSS (basic service set) STA (station) information, OBSS (overlapping BSS) STA information, information on a Co-SR (coordinated SR) mode, information on a transmission power proposed for Co-SR, common L-SIG (legacy signal) information, or common U-SIG (universal signal) information.

[0197] According to various embodiments, the cooperation information may be included in at least one of the common information field or the user information field for the second AP in the trigger frame.

[0198] According to various embodiments, at least one bit in the uplink (UL) length subfield in the common information field of the trigger frame may be used to include at least a portion of the cooperation information.

[0199] According to various embodiments, at least one bit following the TXS (TXOP (transmission opportunity) sharing) mode subfield in the common information field of the trigger frame may be used to include at least a portion of the cooperation information.

[0200] According to various embodiments, the common information field of the trigger frame may include a first portion of the collaboration information and a flag indicating the presence of a special user information field in the trigger frame. The special user information field may include a second portion of the collaboration information.

[0201] According to various embodiments, the user information field for the second AP in the trigger frame may include a flag indicating that a special user information field for the second AP is present in the trigger frame. The special user information field may include at least a portion of the cooperation information.

[0202] According to various embodiments, the collaboration information may be included in a plurality of special user information fields in the trigger frame. A first special user information field among the plurality of special user information fields may include a first portion of the collaboration information and a flag indicating that another special user information field exists after the first special user information field in the trigger frame. A second special user information field among the plurality of special user information fields may include a second portion of the collaboration information.

[0203] FIG. 15 illustrates an example of a method performed by a second AP based on the design of a trigger frame for multi-AP cooperation according to an embodiment of the present disclosure.

[0204] Referring to FIG. 15, in step S1501, the second AP can perform a negotiation procedure for multi-AP cooperation with the first AP.

[0205] In step S1503, the second AP may receive a trigger frame for triggering multi-AP cooperation from the first AP. Information included in the allocation period subfield for the second AP in the trigger frame may be determined based on the cooperation method for multi-AP cooperation with the first AP. The cooperation method for multi-AP cooperation with the first AP may be determined based on the capability information of the second AP transmitted during the negotiation process.

[0206] In step S1505, the second AP can perform multi-AP cooperation with the first AP based on information included in the allocation period subfield.

[0207] Below, detailed implementation examples regarding the design of trigger frames for multi-AP cooperation are described.

[0208] In the present disclosure, a trigger frame for triggering multi-AP operations based on various cooperation schemes (e.g., Co-TDMA, Co-SR, Co-BF) in multi-AP cooperation is defined. The structure / format of the trigger frame for multi-AP cooperation can be defined / designed according to various embodiments of the present disclosure.

[0209] FIG. 16 illustrates an example of a cooperation triggering method based on a TXS triggered for multi-AP cooperation according to an embodiment of the present disclosure.

[0210] Referring to Fig. 16, AP 1, which acquires TXOP and acts as a SAP, can initiate / trigger cooperation by transmitting an MU-RTS TXS TF. The target DAP (e.g., AP 2 in Fig. 16) that receives the MU-RTS TXS TF transmitted from the SAP to trigger cooperation can transmit a CTS frame as a confirmation of the start of cooperation. Additionally or alternatively, certain cooperation-based transmissions can be defined / implemented to unguide the CTS frame. For example, for Co-TDMA, the CTS frame can be guided similar to the triggered TXS of the existing EHT. On the other hand, for Co-SR / Co-BF, the CTS frame can be unguided. That is, in the case of Co-SR / Co-BF, the DAP may not transmit a CTS frame in response to the received MU-RTS TXS TF.

[0211] According to various embodiments of the present disclosure, the MU-RTS TXS TF for cooperative triggering can be defined / utilized based on the existing triggered TXOP sharing mode (i.e., mode = 1 or 2). For example, since the existing TXS mode = 2 allows a time-allocated STA to forward MPDU(s) to other STAs, in TXS mode = 2, a DAP can be configured to forward MPDU(s) to STAs within its BSS.

[0212] In order for the MU-RTS TXS TF, which is based on the existing TXS mode, to be utilized for cooperation triggering in multi-AP cooperation, existing fields in the MU-RTS TXS TF may be reused and / or new fields may be defined to include common and / or specific parameters related to multi-AP cooperation for multi-AP cooperation.

[0213] For example, common and / or multi-AP cooperation-related information / content (or cooperation information) for multi-AP cooperation may be defined as follows. At least one of the information elements, fields or signaling bit(s) listed below may be added / defined in the MU-RTS TXS TF, and the information added / defined in the MU-RTS TXS TF is not limited thereto.

[0214] -Address: Address information of the target AP (e.g. BSS color, BSSID for multiple APs, MAC address)

[0215] - Multi-AP group (or, cooperation group) ID: ID for the set / group of APs that established multi-AP coordination (MAPC) (e.g., 0, 1, 2, ...)

[0216] - AP ID: Locally assigned ID for each AP within an established multi-AP group / set (e.g. 0, 1, 2, ...)

[0217] In some implementations, the AP ID may be included in the AID12 field within the user information field of the TF.

[0218] Additionally or alternatively, the AP ID may be included within the AID12 field of the UHR special user information field, which may be newly defined for UHR.

[0219] In some implementations, the AP ID may be included in the AID11 field within the STA Information field of the UHR NDP announcement frame.

[0220] -MAPC method type (or MAPC method / cooperation method): Indicates the cooperation method for multi-AP cooperation, such as Co-TDMA / SR / BF.

[0221] In some implementations, reserved fields / bits in the common information field may be used to indicate the cooperation mode, depending on the definition of a new subtype utilizing the reserved values ​​(e.g., 3) in the GI And HE / EHT-LTF Type subfield and / or the TXS Mode subfield.

[0222] In some implementations, the EHT reserved (7 bits) or reserved field / bits in the common information field may be used to indicate the cooperation mode.

[0223] Additionally or alternatively, reserved (sub)fields / bits in the user information field may be used to indicate the mode of cooperation.

[0224] Additionally or alternatively, instructions on how to collaborate may be included in the UHR Special / Feedback user information fields that may be newly defined for UHR.

[0225] In some implementations, a new field may be defined to indicate the MAPC scheme type by utilizing one or more bits in the EHT reserved (sub)field / bits (e.g., utilizing 1 to n bits depending on the number of multi-AP cooperation schemes).

[0226] In some implementations, a new field may be defined to indicate the MAPC scheme type by utilizing one or more bits in the reserved (sub)field / bits (e.g., utilizing 1 to n bits depending on the number of multi-AP cooperation schemes).

[0227] In some implementations, bit value 0 may indicate Co-TDMA, bit value 1 may indicate Co-SR, and bit value 2 may indicate Co-BF. Other cooperative schemes besides Co-TDMA / Co-SR / Co-BF may also be indicated using bit values ​​other than 0, 1, and 2.

[0228] In some implementations, based on the bitmap, B0 (e.g., the first bit) of the bitmap corresponds to Co-TDMA, and Co-TDMA may be indicated when B0 is set to a specific value (e.g., 1). B1 (e.g., the second bit) of the bitmap corresponds to Co-SR, and Co-SR may be indicated when B1 is set to a specific value (e.g., 1). B2 (e.g., the third bit) of the bitmap corresponds to Co-BF, and Co-BF may be indicated when B2 is set to a specific value (e.g., 1).

[0229] Additionally or alternatively, the MAPC scheme type and control information indicating which role the corresponding TF is transmitted for may be signaled together. In some implementations, bit value 0 of the control information (sub)field may indicate that the corresponding TF serves as an ICF in Co-TDMA. Bit value 1 of the control information (sub)field may indicate that the corresponding TF serves as a TXOP Return in Co-TDMA. Bit value 2 of the control information (sub)field may indicate that the corresponding TF serves as an ICF in Co-SR. Bit value 3 of the control information (sub)field may indicate that the corresponding TF serves as a Synchronization / Co-triggering frame in Co-SR. Bit value 4 of the control information (sub)field may indicate that the corresponding TF serves as an ICF in Co-BF. Bit value 5 of the control information (sub)field may indicate that the corresponding TF serves as a Synchronization / Co-triggering frame in Co-BF.

[0230] - (Scheduled) Cooperation Period and / or Total TXOP Period: The period during which SAP cooperates with DAPs to perform cooperation-based transmission / reception (i.e., the expected allocated TXOP / hour that SAP intends to allocate to DAPs), the period during which SAP performs individual FEs, the period that SAP allocates to DAPs (in case of Co-TDMA), and / or the total cooperative TXOP (Total TXOP) period scheduled for MAPC operation.

[0231] In some implementations, the (scheduled) cooperation period and / or the total TXOP period may indicate the cooperation period (or the expected / scheduled allocation period) expected / planned by the SAP. For example, the value that may be included in the allocation period field of the MU-RTS TXS trigger frame received by the DAP that will share / allocate the TXOP may be indicated in units of 16 microseconds in the new 9-bit Scheduled Cooperation Period and / or Scheduled Allocation Period fields.

[0232] In some implementations, the (scheduled) collaboration period and / or the overall TXOP period may indicate the overall collaboration TXOP period over which SAP intends to perform the MAPC operation.

[0233] In some implementations, new fields containing the cooperative and / or total TXOP duration may be defined to indicate the (scheduled) cooperative and / or total TXOP duration. For example, a newly defined cooperative and / or total TXOP duration (sub-)field may indicate information required for MAPC operation and / or the cooperative and / or total TXOP duration value.

[0234] In some implementations, the Assigned Duration field in the User Information field of the MU-RTS TXS trigger frame may be used to indicate the (scheduled) cooperation period and / or the overall TXOP period. For example, the Assigned Duration field may contain a corresponding duration value.

[0235] In some implementations, the EHT reserved (7 bits) and / or reserved (sub)fields / bits of the common information field may be used to indicate the (scheduled) cooperation period and / or the overall TXOP period.

[0236] Additionally or alternatively, reserved (sub)fields / bits in the user information field may be used to indicate the (scheduled) cooperation period and / or the overall TXOP period.

[0237] Additionally or alternatively, UHR special / feedback user information fields that may be newly defined for UHR may include information about the (scheduled) collaboration period and / or the overall TXOP period.

[0238] - Operating Channel: Information about the primary channel and / or punctured channel that is in operation.

[0239] In some implementations, the operating channel information may include common operating channel information for smooth cooperation between APs participating in MAPC.

[0240] In some implementations, the operating channel information may include primary channel information on which APs participating in MAPC can commonly operate.

[0241] For example, a new field may be defined that acts as the channel center frequency segment (CCFS) 0 field within the UHR motion information field to indicate the channel center frequency index for 20 / 40 / 80 MHz channels.

[0242] For example, a new field may be defined that acts as the CCFS0 field within the UHR motion information field to indicate the channel center frequency for the primary 80 MHz channel of a 160 MHz channel or the channel center frequency for the primary 160 MHz channel of a 320 MHz channel.

[0243] Additionally, a new field is defined that acts as the CCFS1 field within the UHR motion information field to indicate the channel center frequency for a 160 MHz channel or the channel center frequency for a 320 MHz channel.

[0244] In some implementations, the operating channel information may include punctured channel information of APs participating in MAPC.

[0245] For example, a new field may be defined that serves as the Inactive (Inactived) Subchannel Bitmap field within the UHR Motion Information field to indicate a punctured 20 MHz subchannel using a bitmap. A bit in the bitmap whose value is set to 0 may indicate that the corresponding 20 MHz subchannel is not punctured, and a bit in the bitmap whose value is set to 1 may indicate that the corresponding 20 MHz subchannel is punctured.

[0246] In some implementations, information about the primary channel of a DAP within the channel on which the SAP operates may be included in the operating channel information.

[0247] In some implementations, information about the DAP's primary channel within the operating channel, excluding the punctured channel of the SAP, may be included in the operating channel information.

[0248] In some implementations, the EHT reserved (7 bits) or reserved (sub)field / bit of the common information field may be used to indicate the operating channel.

[0249] Additionally or alternatively, reserved (sub)fields / bits of the user information field may be used to indicate the operating channel.

[0250] Additionally or alternatively, the UHR special / feedback user information fields, which may be newly defined for UHR, may include the operating channel information.

[0251] -Operating Bandwidth: Operating bandwidth and / or maximum bandwidth information.

[0252] In some implementations, the operating bandwidth information may include commonly used BW information to facilitate smooth cooperation between APs participating in MAPC. For example, the operating channel and primary channel information described above may be used to indicate the operating bandwidth.

[0253] In some implementations, the operating bandwidth information may include the maximum bandwidth information of an AP participating in MAPC. For example, a new field that functions similarly to the Channel Width field in the Control field of the UHR Operating Information field may be defined to indicate the channel width, which is BSS BW information, of each AP. If the value of this field is set to 0, it may indicate a 20 MHz bandwidth. If the value of this field is set to 1, it may indicate a 40 MHz bandwidth. If the value of this field is set to 2, it may indicate an 80 MHz bandwidth. If the value of this field is set to 3, it may indicate a 160 / 80+80 MHz bandwidth. If the value of this field is set to 4, it may indicate a 320 / 160+160 MHz bandwidth. The values ​​5 to 7 in this field may be reserved.

[0254] In some implementations, the operating bandwidth information may include BW field information within the SIG-A field.

[0255] In some implementations, the operating bandwidth information may include UL BW field information contained within the common information field of the trigger frame.

[0256] In some implementations, the operating bandwidth information may include information about the bandwidth of the SAP / DAP within the overall bandwidth over which the SAP operates.

[0257] In some implementations, the Medium Time field of the QoS Characteristics element may be modified / redefined to include new subfields, thereby newly including a field for bandwidth indication. For example, a new field that serves the same role as the Channel Width field in the Control field of the UHR Operation Information field may be defined to indicate the channel width, which is BSS BW information of each AP. If the value of this field is set to 0, this field may indicate a 20 MHz bandwidth. If the value of this field is set to 1, this field may indicate a 40 MHz bandwidth. If the value of this field is set to 2, this field may indicate an 80 MHz bandwidth. If the value of this field is set to 3, this field may indicate a 160 / 80+80 MHz bandwidth. If the value of this field is set to 4, this field may indicate a 320 / 160+160 MHz bandwidth. In this field, values ​​5 to 7 may be reserved.

[0258] In some implementations, the EHT reserved (7 bits) or reserved (sub)field / bits of the common information field may be used to indicate the operating bandwidth.

[0259] Additionally or alternatively, reserved (sub)fields / bits in the user information field may be used to indicate the operating bandwidth.

[0260] Additionally or alternatively, motion bandwidth information may be included in UHR special / feedback user information fields that may be newly defined for UHR.

[0261] -Traffic priority: Information on the priority of traffic that SAP recommends to DAP and / or information on the priority of traffic that SAP allows to DAP.

[0262] In some implementations, traffic priority information may include TID / AC information for traffic allowed to the DAP within a TXOP acquired by the SAP.

[0263] For example, if only traffic for one of AC_BK (access category - background), AC_BE (access category - best effort), AC_VI (access category - video), and AC_VO (access category - voice) is allowed, the DAP can only transmit traffic corresponding to that AC within the allocated period / cooperation period.

[0264] For example, a new 2-bit field can be defined to indicate ACI-to-AC coding as follows:

[0265] i) AC index (access category index, ACI) 0 = AC_BE (best effort);

[0266] ii) AC Index (ACI) 1 = AC_BK (background);

[0267] iii) AC Index (ACI) 2 = AC_VI (video); and

[0268] iv) AC Index (ACI) 3 = AC_VO (voice).

[0269] Additionally or alternatively, seven user priorities (UPs) may be provided as traffic categories, and the DAP may only transmit traffic corresponding to ACs less than or equal to the UPs within the allocated period / cooperation period.

[0270] For example, a new 4-bit field could be defined to indicate the following UP-to-AC mapping:

[0271] i) User priority (UP) 1 = AC_BK;

[0272] ii) UP 2 = AC_BK;

[0273] iii) UP 0 = AC_BE;

[0274] iv) UP 3 = AC_BE;

[0275] v) UP 4 = AC_VI;

[0276] vi) UP 5 = AC_VI;

[0277] vii) UP 6 = AC_VO; and

[0278] viii) UP 7 = AC_VO.

[0279] In some implementations, the EHT reserved (7 bits) or reserved (sub)fields / bits in the common information field may be used to indicate traffic priority.

[0280] Additionally or alternatively, reserved (sub)fields / bits in the user information field may be used to indicate traffic priority.

[0281] Additionally or alternatively, UHR special / feedback user information fields that may be newly defined for UHR may contain traffic priority information.

[0282] - Cooperation Trigger: Indicates that the frame is an MU-RTS TXS TF transmitted for the cooperation trigger procedure in multi-AP cooperation.

[0283] In some implementations, the EHT reserved (7 bits) or reserved (sub)field / bit of the common information field may be used to indicate a cooperative trigger.

[0284] For example, one or more bits in the EHT reservation could be used to define a new field to indicate that the frame is an MU-RTS TXS TF for cooperative triggering.

[0285] For example, one or more bits in the reserved (sub)field / bits could be used to define a new field to indicate that the frame is an MU-RTS TXS TF for cooperative triggering.

[0286] Additionally or alternatively, reserved (sub)fields / bits in the user information field may be used to indicate a collaboration trigger.

[0287] Additionally or alternatively, collaboration trigger information may be included in UHR special / feedback user information fields that may be newly defined for UHR.

[0288] - CTS required: Indicates whether a CTS frame should be transmitted in response to the MU-RTS TXS TF (i.e., whether solicited / unsolicited).

[0289] In some implementations, the EHT reserved (7 bits) or reserved (sub)field / bit in the Common Information field may be used to indicate whether a CTS is required.

[0290] For example, one bit in the EHT reservation could be used to define a new field / signaling bit to indicate whether a CTS frame transmission is required.

[0291] For example, one bit in the reserved (sub)field / bit could be used to define a new field / signaling bit to indicate whether a CTS frame transmission is requested.

[0292] In some implementations, the reserved (sub)field / bit (10 bits) of the User Information field may be used to define a new field / signaling bit to indicate whether a CTS frame transmission is required. For example, one bit in the reserved (sub)field / bit may be used to define a new field / signaling bit to indicate whether a CTS frame transmission is required.

[0293] In some implementations, a reserved (sub)field / bit (3 bits) in the Special User Information field may be used to indicate whether a CTS is required. For example, one bit in the reserved (sub)field / bit may be used to define a new field / signaling bit to indicate whether a CTS frame transmission is required.

[0294] In the examples described above, a bit value of 0 in the CTS Required (sub)field may indicate that transmission of a CTS frame for the transmission of the corresponding MU-RTS TXS TF is induced. A bit value of 1 in the CTS Required (sub)field may indicate that transmission of a CTS frame for the transmission of the corresponding MU-RTS TXS TF is not induced.

[0295] Additionally or alternatively, information regarding whether a CTS is required may be included in the UHR Special / Feedback User Information field, which may be newly defined for UHR.

[0296] - Whether to request TXOP return: Indicates whether the TXOP return procedure must be performed within the allocated time.

[0297] For Co-TDMA, the TXOP return request information may indicate that the DAP must transmit a frame whose RA field specifies the address of the SAP within the allocated time, and / or that the DAP must transmit a frame containing information of the SAP (e.g., the AID of the SAP and / or a new AID defined for multi-AP cooperation) within the allocated time.

[0298] In some implementations, the EHT Reserved (7 bits) or Reserved (sub)field / bit of the Common Information field may be used to indicate whether a TXOP return is requested. For example, one bit in the EHT Reserved may be used to define a new field / signaling bit to indicate whether a TXOP return is requested. For example, one bit in the Reserved (sub)field / bit may be used to define a new field / signaling bit to indicate whether a TXOP return is requested.

[0299] In some implementations, a reserved (sub)field / bit (10 bits) in the User Information field may be used to indicate whether a TXOP return is requested. For example, one bit in the reserved (sub)field / bit may be used to define a new field / signaling bit to indicate whether a TXOP return is requested.

[0300] In some implementations, a reserved (sub)field / bit (3 bits) in the Special User Information field may be used to indicate whether a TXOP return is requested. For example, one bit in the reserved (sub)field / bit may be used to define a new field / signaling bit to indicate whether a TXOP return is requested.

[0301] In the examples described above, a bit value of 0 in the TXOP Return Required (sub)field may indicate that the DAP does not have to perform a TXOP return within the allocated time. A bit value of 1 in the TXOP Return Required (sub)field may indicate that the DAP can and / or must perform a TXOP return within the allocated time.

[0302] Additionally or alternatively, information on whether a TXOP return is requested may be included in the UHR Special / Feedback User Information field, which may be newly defined for UHR.

[0303] - Multi-AP Ack (acknowledgement) Policy Indicator: Indicates the Ack policy during the Co-SR / BF transmission / reception period, and / or the Ack policy that the DAP / STA associated with the DAP should follow during the cooperation period.

[0304] In some implementations, the EHT Reserve (7 bits) or Reserve (sub)field / bit in the Common Information field can be used to indicate a multi-AP Ack policy. For example, two bits in the EHT Reserve or Reserve (sub)field / bit can be used to indicate an Ack policy for frame exchanges between cooperating APs during the cooperation period. For example, a multi-AP Ack policy indicator, similar to the Ack Policy Indicator field in the QoS Control field, can indicate a multi-AP Ack policy as follows:

[0305] i) When the values ​​of bit 0 and bit 1 of the multi-AP Ack policy indicator are set to 0, the multi-AP Ack policy indicator indicates Normal Ack or Implicit BAR (block Ack request);

[0306] ii) If the value of bit 0 of the multi-AP Ack policy indicator is set to 1 and the value of bit 1 is set to 0, the multi-AP Ack policy indicator indicates No Ack;

[0307] iii) The multi-AP Ack policy is reserved for cases where the value of bit 0 of the multi-AP Ack policy indicator is set to 0 and the value of bit 1 is set to 1; and

[0308] iv) When the values ​​of bit 0 and bit 1 of the multi-AP Ack policy indicator are set to 1, the multi-AP Ack policy indicator indicates block Ack (BA).

[0309] Additionally or alternatively, a multi-AP Ack policy directive may be included in the UHR Special / Feedback User Information field, which may be newly defined for UHR.

[0310] Additionally or alternatively, reserved (sub)fields / bits in the User Information field may be used to indicate a multi-AP Ack policy.

[0311] -NAVTimeout Disable: Indicates whether NAV is reset even if the NAVTimeout period expires.

[0312] In some implementations, the EHT Reserved (7 bits) or Reserved (sub)field / bit of the Common Information field may be used to indicate NAVTimeout inactivity. For example, a new field may be defined in the EHT Reserved or Reserved (sub)field / bit to indicate that the NAV should not be reset when the NAVTimeout period expires. If the bit value of that field is 0, the field may indicate that the NAV should be reset if the NAVTimeout period expires after receiving an MU-RTS TXS TF (default). If the bit value of that field is 0, the field may indicate that the NAV should not be reset if the NAVTimeout period expires after receiving an MU-RTS TXS TF.

[0313] Additionally or alternatively, information about whether NAVTimeout is disabled may be included in the UHR Special / Feedback User Information field, which may be newly defined for UHR.

[0314] Additionally or alternatively, a reserved (sub)field / bit in the User Information field may be used to indicate whether NAVTimeout is disabled for the field.

[0315] - DL / UL indication (or, indication of whether to perform transmission): Indicates whether to perform DL transmission (or not) or whether to perform UL transmission (or not) through MAPC method where SAP and DAP perform transmission simultaneously, such as Co-SR / BF.

[0316] - Tx Power: Maximum Tx power information of SAP.

[0317] In some implementations, the DAP can determine an appropriate Tx power that does not cause interference based on the maximum Tx power information conveyed by the SAP.

[0318] In some implementations, the AP Tx Power field of the Common Information Field may be used to indicate Tx power.

[0319] In some implementations, the EHT reserved (7 bits) or reserved (sub)field / bit of the common information field may be used to indicate Tx power.

[0320] Additionally or alternatively, Tx power information may be included in the UHR Special / Feedback User Information field, which may be newly defined for UHR.

[0321] Additionally or alternatively, reserved (sub)fields / bits of the user information field may be used to indicate Tx power.

[0322] - In-BSS STA Information: Indicates information about the target STA on which SAP will perform DL / UL transmission and / or information about all associated STAs.

[0323] In some implementations, In-BSS STA information may indicate the identifiers and capabilities of all STAs connected to the SAP. For example, In-BSS STA information may indicate the AID and / or MAC address of the STAs. For example, In-BSS STA information may indicate the MIMO and RF capabilities of the STAs.

[0324] In some implementations, the In-BSS STA information may indicate the identifier and capability information of a target STA that is intended to perform DL / UL transmission based on Co-SR / BF among the STAs connected to the SAP. For example, the In-BSS STA information may indicate the AID and / or MAC address of the target STA. For example, the In-BSS STA information may indicate the MIMO and RF capabilities of the target STA.

[0325] In some implementations, the In-BSS STA information may indicate identifiers for In-BSS STAs that wish to participate in the multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation.

[0326] In some implementations, the EHT reserved (7 bits) or reserved field / bits in the common information field may be used to indicate In-BSS STA information.

[0327] Additionally or alternatively, In-BSS STA information may be included in UHR special / feedback user information fields that may be newly defined for UHR.

[0328] Additionally or alternatively, reserved fields / bits in the user information field may be used to indicate In-BSS STA information.

[0329] - OBSS STA Information: Indicates information about the OBSS target STA to which the DAP must perform DL / UL transmission.

[0330] In some implementations, the OBSS STA information may indicate the identifier and / or capability information of a target OBSS STA that is intended to perform DL / UL transmission based on Co-SR / BF among the OBSS STAs connected to the DAP. For example, the OBSS STA information may indicate the AID and / or MAC address of the target OBSS STA. For example, the OBSS STA information may indicate the MIMO and RF capabilities of the target OBSS STA.

[0331] In some implementations, the OBSS STA information may indicate identifiers for OBSS STAs that wish to participate in the multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation.

[0332] In some implementations, the EHT reserved (7 bits) or reserved field / bits in the common information field may be used to indicate OBSS STA information.

[0333] Additionally or alternatively, OBSS STA information may be included in UHR special / feedback user information fields that may be newly defined for UHR.

[0334] Additionally or alternatively, the reserved field / bit in the user information field may be used to indicate OBSS STA information.

[0335] - Co-SR mode: Indicates the mode for Co-SR transmission.

[0336] In some implementations, Mode 1 may indicate whether the target STA of a Co-SR transmission is EHT + EHT, EHT + UHR, or UHR + EHT. With Mode 1 indication, Co-SR PPDUs transmitted by two APs in a Co-SR transmission period must have a common L-SIG, but the U-SIG contents may be different.

[0337] In some implementations, Mode 2 may indicate that the target STA of a Co-SR transmission is UHR+UHR. The indication of Mode 2 may indicate that the Co-SR PPDUs transmitted by two APs during a Co-SR transmission period must have a common L-SIG and a common U-SIG.

[0338] In some implementations, the EHT reserved (7 bits) or reserved field / bits in the common information field may be used to indicate Co-SR mode.

[0339] Additionally or alternatively, Co-SR mode information may be included in the UHR Special / Feedback User Information fields that may be newly defined for UHR.

[0340] Additionally or alternatively, a reserved field / bit in the user information field may be used to indicate Co-SR mode.

[0341] - Proposed Tx Power: Indicates the maximum Tx power to limit (propose) to the DAP that triggers the Co-SR transmission.

[0342] In some implementations, when a SAP determines the Tx power of a DAP performing Co-SR transmission, the SAP may determine a recommended maximum Tx power for the DAP that does not cause interference to its own transmission, and the suggested Tx power information may indicate the determined maximum Tx power.

[0343] In some implementations, the proposed Tx power information may indicate the maximum threshold Tx power of the DAP during a Co-SR transmission period.

[0344] In some implementations, the EHT reserved (7 bits) or reserved field / bits in the common information field may be used to indicate the proposed Tx power.

[0345] Additionally or alternatively, proposed Tx power information may be included in the UHR Special / Feedback User Information field, which may be newly defined for UHR.

[0346] Additionally or alternatively, a reserved field / bit in the user information field may be used to indicate the proposed Tx power.

[0347] - Common L-SIG Information: The common L-SIG information field may contain L-SIG information that must be commonly included in the DL PPDU transmitted by each AP during the Co-SR / BF transmission period.

[0348] In some implementations, the length (B5-B16) of the L-SIG field in the MU PPDU (e.g., EHT, UHR, etc.) may be included in the common L-SIG information field. The length information of the L-SIG field / common L-SIG information may be considered as a value indicating the duration of the DL PPDU transmitted by each AP.

[0349] In some implementations, the EHT reserved (7 bits) or reserved field / bits in the common information field may be used to indicate common L-SIG information.

[0350] Additionally or alternatively, common L-SIG information may be included in UHR special / feedback user information fields that may be newly defined for UHR.

[0351] Additionally or alternatively, reserved fields / bits in the user information field may be used to indicate common L-SIG information.

[0352] - Common U-SIG Information: The Common U-SIG Information field may indicate / include U-SIG-1 and / or U-SIG-2 information that must be commonly included in the DL PPDU transmitted by each AP during the period in which the corresponding cooperative-based transmission / reception is performed.

[0353] In some implementations, the common U-SIG information may include the PHY version identifier (B0-B2) information in the U-SIG-1 field in the MU PPDU (e.g., EHT, UHR, etc.). For example, the PHY version identifier may indicate the PHY version of the DL PPDU transmitted by each AP during the Co-SR / BF transmission / reception period.

[0354] In some implementations, the common U-SIG information may include bandwidth (B3-B5) information in the U-SIG-1 field within the MU PPDU (e.g., EHT, UHR, etc.). For example, the bandwidth information may indicate the bandwidth of a DL PPDU transmitted by each AP during a Co-SR / BF transmission / reception period. Additionally or alternatively, the bandwidth information may be a bandwidth based on the bandwidth of a PPDU containing an ICF transmitted by the SAP. Additionally or alternatively, the bandwidth information may be a bandwidth based on the bandwidth of a PPDU containing an M-BA frame, when a response frame to an ICF transmitted by the SAP (e.g., an M-BA frame) is present.

[0355] In some implementations, the common U-SIG information may include UL / DL (B6) information in the U-SIG-1 field within the MU PPDU (e.g., EHT, UHR, etc.). For example, the UL / DL information may indicate whether a DL transmission is expected (or not) or whether a UL transmission is expected (or not) during the corresponding Co-SR / BF transmission period.

[0356] In some implementations, the common U-SIG information may include punctured channel information (B3-B7) in the U-SIG-2 field of the MU PPDU (e.g., EHT, UHR, etc.). Additionally or alternatively, the PPDU containing the ICF transmitted by the SAP may be punctured based on long-term punctured channel information (e.g., all punctured 20 MHz subchannels indicated by the TXVECTOR parameter INACTIVE_SUBCHANNELS). Additionally or alternatively, the punctured (sub)channels may be punctured based on dynamic puncturing information of each AP. The punctured (sub)channels may additionally or alternatively have a puncturing pattern consisting of the union of the punctured 20 MHz subchannels of both APs.

[0357] In some implementations, the common U-SIG information may include a UHR-SIG MCS that plays the same role as the EHT-SIG MCS (B9-B10) in the U-SIG-2 field in the MU PPDU (e.g., EHT, UHR, etc.). For example, a value of 0 in the UHR-SIG MCS may indicate UHR-MCS 0. A value of 1 in the UHR-SIG MCS may indicate UHR-MCS 1. A value of 2 in the UHR-SIG MCS may indicate UHR-MCS 3. A value of 3 in the UHR-SIG MCS may indicate UHR-MCS 15. Additionally or alternatively, the UHR-SIG MCS may be set to an MCS value that all STAs served by each AP can receive.

[0358] In some implementations, the common U-SIG information may include Number Of UHR-SIG Symbols, which plays the same role as Number Of EHT-SIG Symbols (B11-B15) in the U-SIG-2 field in the MU PPDU (e.g., EHT, UHR, etc.). Additionally or alternatively, Number Of UHR-SIG Symbols may be set to an OFDM symbol value that takes into account all user fields for all STAs associated with each AP.

[0359] In some implementations, the common U-SIG information may include a UHR-SIG TXOP that plays the same role as the TXOP (B13-B19) in the U-SIG field in the MU PPDU (e.g., EHT, UHR, etc.).

[0360] In some implementations, the common U-SIG information may include Spatial Configuration (B16-B19) information within the User field. For example, the spatial configuration may indicate the number of spatial streams for each user in an MU-MIMO allocation. Additionally or alternatively, it may indicate spatial stream allocation information for all STAs associated with each AP. Additionally or alternatively, the spatial configuration field may be defined / utilized as 2 or 3 bits.

[0361] At least one of the above-described information elements / fields may be included in the common U-SIG information field, but is not limited thereto.

[0362] In some implementations, the EHT reserved (7 bits) or reserved field / bits in the common information field may be used to indicate common U-SIG information.

[0363] Additionally or alternatively, common U-SIG information may be included in UHR special / feedback user information fields that may be newly defined for UHR.

[0364] Additionally or alternatively, reserved fields / bits in the user information field may be used to indicate common U-SIG information.

[0365] The AID12 field within the user information field of the MU-RTS TXS TF may be replaced with an ID associated with multi-AP cooperation. Specifically, the ID associated with multi-AP cooperation may include at least one of a BSSID of the target DAP, a BSS color, a newly defined multi-AP group ID (i.e., an ID for a set of APs that have established multi-AP cooperation), or a DAP ID (i.e., an ID assigned by an AP and / or SAP in a cooperative relationship within a multi-AP group). Additionally or alternatively, the AID12 field may include a combination of the BSSID and the BSS color of the target DAP, or may be composed of a combination of the BSSID and the BSS color of the target DAP. Additionally or alternatively, the AID12 field may include a portion or all of the BSS color of the target DAP, or may be composed of a portion or all of the BSS color of the target DAP. Additionally or alternatively, the AID12 field may include a portion or all of the BSSID of the target DAP. Alternatively, if targeting a single DAP, the RA field may contain the MAC address of the target DAP.

[0366] Additionally or alternatively, when an AP receives an MU-RTS TXS TF in which the RA field is set to its MAC address or the AID 12 field in the user information field contains an ID addressed to itself, the AP may identify that the received frame is an MU-RTS TXS TF forwarded for cooperation triggering in multi-AP cooperation, regardless of the value of the TXS mode, and may decode / obtain additional information. Common and / or multi-AP cooperation-related specific information may be added and / or defined in the MU-RTS TXS TF for one or more multi-AP cooperation. For example, at least one of the above-described information elements / fields may be included in the MU-RTS TXS TF, but is not limited thereto.

[0367] Additionally, the encoding method for the TXS mode of the MU-RTS TXS TF addressed to the AP may differ from the existing method. For example, the MU-RTS TXS TF addressed to the AP may be utilized for multi-AP cooperation and encoded as shown in below:

[0368] Triggered TXOP Sharing Mode subfield valueDescription0MU-RTS that does not initiate Multi-AP coordination1 (for C-TDMA)MU-RTS that initiates coordinated TDMA procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated STA2 (for Co-SR)MU-RTS that initiates coordinated spatial reuse procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated STA3 (for Co-BF)MU-RTS that initiates coordinated beamforming procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated STA

[0369] As shown in , a separate TXS mode for multi-AP cooperation may be defined. For example, an MU-RTS TXS TF addressed to an AP may be classified as a Class 1 frame. Additionally, the format of an MU-RTS TXS TF associated with a specific TXS mode (e.g., TXS mode = 1) may be different from the formats of MU-RTS TXS TFs associated with other TXS modes (e.g., 2 and 3). Additionally, an STA that receives an MU-RTS TXS TF associated with a specific TXS mode may not respond with a CTS frame under certain conditions. Additionally or alternatively, an STA that receives an MU-RTS TXS TF associated with a particular TXS mode may respond with a frame other than a CTS frame. Additionally or alternatively, the MU-RTS TXS TF for cooperation triggering according to various embodiments of the present disclosure may be associated with a new triggered TXOP sharing mode (i.e., mode = 3). For example, a separate TXS mode for multi-AP cooperation may be defined as shown in Table 4.

[0370] Triggered TXOP Sharing Mode subfield valueDescription0MU-RTS that does not initiate Multi-AP coordination1MU-RTS that initiates TXS procedure wherein a scheduled AP can only transmit MPDU(s) addressed to its associated AP2MU-RTS that initiates TXS procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated AP or addressed to another STA3 (for Multi-AP coordination)MU-RTS that initiates coordination triggering procedure for Multi-AP coordination

[0371] For example, an MU-RTS TXS TF with TXS mode = 3 may be classified as a Class 1 frame. Additionally, the format of an MU-RTS TXS TF associated with TXS mode = 3 may be different from the formats of the MU-RTS TXS TF associated with modes = 1 and 2. That is, values ​​from B22 (reserved based on EHT variant) to B53 (reserved based on EHT variant) in the common information field of an MU-RTS TXS TF with the TXS mode field set to 3 may be reserved. The reserved range may be used to include common information for multi-AP cooperation and / or information specific to each multi-AP cooperation scheme (e.g., Co-SR / BF / TDMA, etc.). Additionally, an STA that receives an MU-RTS TXS TF associated with TXS mode = 3 may not respond with a CTS frame depending on certain conditions. Additionally or alternatively, an STA that receives an MU-RTS TXS TF associated with TXS mode = 3 may respond with a frame other than a CTS frame.

[0372] Within the MU-RTS TXS TF, common and / or multi-AP cooperation-related information for one or more of the multi-AP cooperation described / defined above may be added / defined, but is not limited thereto.

[0373] Below, examples of MU-RTS TXS TF format are described.

[0374] In multi-AP cooperation, the value of the triggered TXS mode subfield in the MU-RTS TXS trigger frame for cooperation triggering may be the same as or different from the existing one, and may be encoded differently depending on the information included in the MU-RTS TXS TF. At least one of the above-described cooperation information may be included in the common information field, the user information field, and / or the new special / feedback user information field (where the value of the AID12 field is set to 2008 or higher) of the MU-RTS TXS TF. For example, the TXOP Return Request field and / or the CTS Request field and / or the Multi-AP Ack Policy Indicator field may be included in the user information field and / or the special / feedback user information field (e.g., AID12 = 2008). For example, reserved bits at other positions within the common information field may be used to include at least one of the above-described cooperation information.

[0375] FIG. 17 illustrates a first example of a common information field format in an MU-RTS TXS trigger frame for cooperative triggering in multi-AP cooperation according to embodiments of the present disclosure.

[0376] Referring to FIG. 17, in the MU-RTS TXS trigger frame for cooperation triggering in multi-AP cooperation, the common information field may include at least one of the above-described cooperation information in the UL length subfield (or instead of the UL length subfield). For example, multi-AP coordination type (or cooperation method) information (3 bits), cooperation trigger information (1 bit), CTS request information (1 bit), TXOP return request information (1 bit), and / or multi-AP Ack policy indicator information (2 bits) may be included in the UL length subfield (or instead of the UL length subfield). In addition, reserved (sub)fields / bits prior to the HE / EHT P160 subfield may be used to include NAVTimeout inactivity information.

[0377] FIG. 18 illustrates a second example of a common information field format in an MU-RTS TXS trigger frame for cooperative triggering in multi-AP cooperation according to embodiments of the present disclosure.

[0378] Referring to FIG. 18, in the MU-RTS TXS trigger frame for cooperation triggering in multi-AP cooperation, the common information field may include a triggered TXS mode subfield. When the value of the triggered TXS mode subfield is 3, the common information field may include a multi-AP common information (Multi-AP Common Info) subfield following the triggered TXS mode subfield. The multi-AP common information subfield may include at least one of the cooperation information described above.

[0379] The information / content included in the common information field in the MU-RTS TXS trigger frame for cooperative triggering in multi-AP cooperation is not limited to the examples of FIGS. 17 and 18. In addition, each field, the position of the signaling bits, the number of bits, and / or the name may be changed.

[0380] FIG. 19 illustrates an example of a user information field format in an MU-RTS TXS trigger frame for cooperative triggering in multi-AP cooperation according to an embodiment of the present disclosure. In FIG. 19 , each field, the position of the signaling bits, the number of bits, and / or the name may be changed.

[0381] Referring to FIG. 19, the AID12 field in the user information field of the MU-RTS TXS TF for multi-AP cooperation may be replaced with an ID associated with multi-AP cooperation. For example, the ID associated with multi-AP cooperation may include a BSSID of the target DAP, a BSS color, a newly defined multi-AP group ID (i.e., an ID for a set of APs that established multi-AP cooperation), and / or a DAP ID (i.e., an ID assigned by an AP / SAP of the cooperative relationship within the multi-AP group). Additionally or alternatively, the AID12 field may include a combination of the BSSID and BSS color of the target DAP, or may be composed of a combination of the BSSID and BSS color of the target DAP. Additionally or alternatively, the AID12 field may include a part or all of the BSS color of the target DAP, or may be composed of a part or all of the BSS color of the target DAP. Additionally or alternatively, the AID12 field may contain or consist of a portion of the BSSID of the target DAP. Alternatively, when targeting a single DAP, the RA field may contain the MAC address of the target DAP.

[0382] In addition, the allocation period field of the user information field in the MU-RTS TXS TF may contain different values ​​and / or have different meanings depending on the multi-AP cooperation method. For example, in the case of Co-TDMA, the allocation period field may mean / indicate the time allocated to the cooperative target DAP (e.g., the allocation time in FIG. 16). On the other hand, in the case of Co-SR and / or Co-BF, the allocation period field may mean / indicate the period for performing cooperation with the cooperative target DAP (e.g., the cooperation period in FIG. 16). Additionally or alternatively, the allocation period field may indicate the length of PPDUs that can be simultaneously transmitted during cooperation based on Co-SR and / or Co-BF. Additionally or alternatively, the allocation duration field may indicate the length of one or more PPDUs that may be transmitted simultaneously during cooperation based on Co-SR and / or Co-BF and / or the interval (e.g. SIFS, PIFS) between a PPDU and a response frame (e.g. BA (block acknowledgment)) to the PPDU.

[0383] The reserved (sub)field (10 bits) may contain separate operating parameters for each multi-AP cooperation method and / or user-specific information for each DAP. Additionally or alternatively, at least some of the information contained in the common information field described above may be contained in the reserved (sub)field of the user information field, rather than in the common information field.

[0384] Additionally or alternatively, a new special / feedback user information field for UHR (or multi-AP cooperation) (e.g., AID12 field with value set to 2008 or higher) may be defined within the MU-RTS TXS TF, and this new special / feedback user information field may contain information related to multi-AP cooperation. For example, the special user information field may be identified when the value of the AID12 field is set to 2007. Similar to the definition of the special user information field in EHT, a separate UHR special / feedback user information field (e.g., AID12 = 2008) may be defined to contain additional information about multi-AP cooperation.

[0385] For this purpose, one bit of the reserved (sub)fields / bits of the common information field may be used to newly define a UHR special / feedback user information field flag field, and the value of the flag field may be set to 1 to indicate the presence of the UHR special / feedback user information field. Additionally or alternatively, a reserved (sub)field / bit (1 bit) in the user information field may be used to indicate whether a UHR special / feedback user information field for user-specific UHR (or multi-AP cooperation) (e.g., the value of the AID12 field is set to an AP ID) exists. That is, a reserved (sub)field / bit in the user information field may be used to define a UHR special / feedback user information field flag field. The flag field may be defined / included to indicate the presence of a UHR special / feedback user information field containing additional information.

[0386] To indicate that the corresponding UHR special / feedback user information field is a new special / feedback 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 / feedback user information field identified by the new AID12 value may be positioned subsequent to the common information field, subsequent to the user information field, or subsequent to the special user information field (of the EHT). Additionally or alternatively, the UHR special / feedback user information field may be positioned before (or immediately before) or after (or immediately after) the user information field for the corresponding user.

[0387] FIG. 20 illustrates an example of a UHR special / feedback user information field according to an embodiment of the present disclosure.

[0388] Referring to FIG. 20, reserved (sub)fields / bits within the common information field may be used to include part of the common information for multi-AP cooperation, and if additional information exists, the additional information may be included in the UHR special / feedback user information field. For example, the value of the AID12 subfield may be one of 2008 to 2044, or one of 2047 to 4094. The multi-AP common information field-(1) and the multi-AP common information field-(2) may include at least one of the above-described cooperation information.

[0389] Additionally or alternatively, there may be one or more user information fields having values ​​of the same AID12 field, and subsequent user information fields having values ​​of the same AID12 field, arranged consecutively or non-contiguously, may contain additional user-specific information.

[0390] FIG. 21 illustrates an example of a UHR special / feedback user information field containing a user information field and user-specific information in Co-TDMA according to an embodiment of the present disclosure.

[0391] Referring to FIG. 21, the allocation period field of the user information field may be used to indicate the time allocated to the DAP, and the user information field may include a UHR special / feedback user information field flag following the allocation period field, and the UHR special / feedback user information field flag may indicate the presence of (AP-specific) special / feedback user information containing Co-TDMA operation related information. When the UHR special / feedback user information field flag is set to 1, one or more special / feedback user information fields having the same AID12 value (i.e., the AP ID of the AP) may exist following the user information field. The special / feedback user information field may include information related to Co-TDMA operation.

[0392] Additionally or alternatively, if there is not much common and / or user-specific information for the operation of a particular MAPC scheme that needs to be included within the MU-RTS TXS TF, a separate UHR special / feedback user information field (e.g., AID = 2008 or AP ID) may not be defined, and a UHR variant user information field for the MU-RTS TXS TF (or MU-RTS TF) may be defined to contain the common and / or user-specific information for the operation of the particular MAPC scheme.

[0393] FIG. 22 illustrates an example of a UHR modified user information field format in Co-TDMA containing information for Co-TDMA operation according to an embodiment of the present disclosure.

[0394] Referring to FIG. 22, the UHR variant user information field may include common and / or user-specific information (e.g., information on whether a TXOP return is requested) for operation in a specific MAPC manner. The MU-RTS TXS TF may include information for Co-TDMA operation based on TXS mode = 2 in the UHR variant user information field and may be transmitted to the target DAP.

[0395] FIG. 23 illustrates an example of the structure of a trigger frame in which a new (UHR) special / feedback user information field containing MAPC-related information is defined / used according to an embodiment of the present disclosure. In FIG. 23, the trigger frame may be an MU-RTS TXS TF.

[0396] Referring to FIG. 23, the new special / feedback user information field (e.g., AID12 = 2008) may be positioned subsequent to the user information field within the trigger frame, subsequent to the common information field, or subsequent to the EHT special user information (AID12 = 2007). At least one of the above-described collaboration information may be included within the (UHR) special / feedback user information field. The location and / or type of information that may be included is not limited. Additionally, if some information is not used, the corresponding field may be reserved.

[0397] FIG. 24 illustrates an example of the structure of a trigger frame including one or more (UHR) special / feedback user information fields according to an embodiment of the present disclosure. In FIG. 24, the trigger frame may be an MU-RTS TXS TF.

[0398] Referring to FIG. 24, a first special / feedback user information field may include a flag field (1 bit) to indicate the presence of one or more special / feedback user information fields. If common information for MAPC operation cannot be contained within a single special / feedback user information field, one or more special / feedback user information fields may be used to contain the common information for MAPC operation, as illustrated in FIG. 24. Additionally or alternatively, if AP / user specific information for MAPC operation cannot be contained within the first special / feedback user information field together with the common information, one or more special / feedback user information fields (i.e., AP-specific special user information) may be used to contain the AP / user-specific information, as illustrated in FIG. 24. Additionally or alternatively, common information for MAPC operation may be contained within the first special / feedback user information field, and AP / user specific information may be contained within the second and / or subsequent special / feedback user information field(s).

[0399] At this time, if the number of reserved bits in the preceding special / feedback user information field is less than the number of bits corresponding to the length of the specific information / field, the reserved bits may not be used and the subsequent special / feedback user information field may be used. Additionally or alternatively, the (remaining) reserved bits in the preceding special / feedback user information field may be used to include a partial (bit) of information, and the remaining (bit) of the information may be included in the subsequent special / feedback user information field. In this case, the position of the flag bit in the preceding special / feedback user information field may be different. If there are two or more special / feedback user information fields, a flag field (1 bit) may also be included in the second special / feedback user information field.

[0400] FIG. 25 illustrates an example of the structure of a trigger frame in which a UHR modified user information field including MAPC-related information is defined / used according to an embodiment of the present disclosure. In FIG. 25, the trigger frame may be an MU-RTS TXS TF.

[0401] Referring to Figure 25, only the existing common information and UHR modified user information fields can be used to include MAPC related information without a separate feedback user information field.

[0402] The present disclosure provides various embodiments related to the structure and / or format of a trigger frame transmitted in a cooperation trigger procedure for a SAP to trigger cooperation with a DAP in multi-AP cooperation. Specifically, the MU-RTS TXS TF of the triggered TXS procedure can be utilized to initiate multi-AP operations based on various multi-AP cooperation schemes (e.g., Co-SR, Co-BF, Co-TDMA). For example, the existing TXS mode of the MU-RTS TXS TF can be used as is, or a new mode can be defined. Additionally or alternatively, a separate triggered TXS mode encoding can be defined for the MU-RTS TXS TF transmitted between APs.

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

[0404] 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 a second AP; determining a cooperation method for multi-AP cooperation with the second AP based on capability information of the second AP obtained in the negotiation procedure; determining information included in an allocation period subfield for the second AP in a trigger frame for triggering the multi-AP cooperation based on the cooperation method; transmitting the trigger frame, in which the allocation period subfield includes the determined information, to the second AP; and performing multi-AP cooperation with the second AP based on information included in the allocation period subfield.

[0405] For example, the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5 may be configured to execute instructions stored in the memory (112, 520) to perform operations performed by the second AP in the present disclosure. The operations include: performing a negotiation procedure for multi-AP cooperation with the first AP; receiving a trigger frame for triggering the multi-AP cooperation from the first AP, wherein information included in an allocation period subfield for the second AP in the trigger frame is determined based on a cooperation method for multi-AP cooperation with the first AP, and the cooperation method for multi-AP cooperation with the first AP is determined based on capability information of the second AP transmitted in the negotiation procedure; and performing the multi-AP cooperation with the first AP based on information included in the allocation period subfield.

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

[0407] 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 a second AP; determining a cooperation method for multi-AP cooperation with the second AP based on capability information of the second AP acquired in the negotiation procedure; determining information included in an allocation period subfield for the second AP in a trigger frame for triggering the multi-AP cooperation based on the cooperation method; transmitting the trigger frame, in which the allocation period subfield includes the determined information, to the second AP; and performing multi-AP cooperation with the second AP based on the information included in the allocation period subfield.

[0408] For example, the CRM may be the memory (112) of FIG. 1, the memory (520) of FIG. 5, and / or a separate external memory / storage medium / disk. The CRM may store commands for performing 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 a first AP; receiving a trigger frame for triggering the multi-AP cooperation from the first AP, wherein information included in an allocation period subfield for the second AP in the trigger frame is determined based on a cooperation method for multi-AP cooperation with the first AP, and the cooperation method for multi-AP cooperation with the first AP is determined based on capability information of the second AP transmitted in the negotiation procedure; and performing the multi-AP cooperation with the first AP based on information included in the allocation period subfield.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0426] For example, trigger frames can be effectively designed for various multi-AP cooperation methods.

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

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

Claims

1. A step in which the first AP (access point) performs a negotiation procedure for multi-AP cooperation with the second AP; A step in which the first AP determines a cooperation method for multi-AP cooperation with the second AP based on the capability information of the second AP obtained in the negotiation procedure; A step in which the first AP determines information included in an allocation period subfield for the second AP in a trigger frame for triggering the multi-AP cooperation based on the cooperation method; The step of the first AP transmitting the trigger frame including the determined information in the allocation period subfield to the second AP; and A method comprising a step of performing multi-AP cooperation with the second AP based on information included in the allocation period subfield.

2. In claim 1, based on the cooperation method being the first cooperation method, the allocation period subfield includes information about the allocation period related to the first cooperation method. A method in which the allocation period subfield includes information about a collaboration section related to the second collaboration method instead of information about the allocation period, based on the above-mentioned cooperation method being a second collaboration method.

3. In claim 2, the allocation period is a period during which transmission by the second AP is performed while transmission by the first AP is not performed. The above cooperation section is a method in which transmission by the first AP and transmission by the second AP are performed.

4. In claim 2, based on the cooperation method being the second cooperation method, the allocation period subfield further includes at least one of information about the length of a PPDU (physical layer protocol data unit) that can be simultaneously transmitted by the first AP and the second AP in the cooperation period, or information about the interval between the PPDU and a response frame for the PPDU.

5. In claim 1, the allocation period subfield for the second AP is included in the user information field for the second AP in the trigger frame, A method in which an AID (association identifier) ​​subfield in the user information field includes at least one of a BSS (basic service set) color associated with the second AP, at least a portion of a BSSID (BSS identifier) ​​associated with the second AP, an ID of a cooperative group for the second AP, or an AP ID locally assigned to the second AP within the cooperative group.

6. In claim 1, the trigger frame is a MU-RTS (multi-user request to send) TXS (TXOP (transmission opportunity) sharing) trigger frame, The value of the TXS mode subfield of the above trigger frame is related to the above cooperation method.

7. In claim 6, based on the cooperation method being the first cooperation method, the TXS mode subfield is set to a value related to the first cooperation method, Based on the above cooperation method being the first cooperation method, the TXS mode subfield is set to a value related to the second cooperation method, The above first cooperation method relates to soliciting transmission of a CTS (clear to send) frame for the TXS trigger frame, The second cooperative method is a method involving unsoliciting transmission of CTS for the TXS trigger frame.

8. In claim 2 or 7, the first cooperative method includes Co-TDMA (coordinated-time division multiple access), A method wherein the second cooperative method comprises at least one of Co-SR (coordinated spatial reuse) or Co-BF (coordinated beamforming).

9. In claim 6, based on the fact that the cooperative method is Co-TDMA (coordinated-time division multiple access), the TXS mode subfield is set to a value related to Co-TDMA, Based on the above cooperation method being Co-SR (coordinated spatial reuse), the TXS mode subfield is set to a value related to Co-SR, A method in which the TXS mode subfield is set to a value related to Co-BF, based on the above cooperation method being Co-BF (coordinated beamforming).

10. A method according to claim 6, wherein the TXS mode subfield is set to a value indicating that the trigger frame is for triggering the multi-AP cooperation.

11. In claim 1, the trigger frame for triggering the multi-AP cooperation includes coordination information for the multi-AP cooperation, A method in which the cooperation information includes at least one of: an address of the second AP, an identifier of a cooperation group for the second AP, an AP ID locally assigned to the second AP within the cooperation group, information on the cooperation method, information included in the allocation period subfield, information on an operating channel, information on an operating bandwidth, information on a traffic priority, information on a cooperation trigger, information on whether a CTS (clear to send) is requested, information on whether a TXOP (transmission opportunity) return is requested, a multi-AP Ack (acknowledgment) policy indicator, information on whether a NAV (network allocation vector) is disabled, information on whether a transmission is performed, information on transmission power, In-BSS (basic service set) STA (station) information, OBSS (overlapping BSS) STA information, information on a Co-SR (coordinated SR) mode, information on a transmission power proposed for Co-SR, common L-SIG (legacy signal) information, or common U-SIG (universal signal) information.

12. A method according to claim 11, wherein the cooperation information is included in at least one of a common information field or a user information field for the second AP in the trigger frame.

13. A method according to claim 11, wherein at least one bit in the UL (uplink) length subfield in the common information field of the trigger frame is used to include at least a part of the cooperation information.

14. A method according to claim 11, wherein at least one bit following the TXS (TXOP (transmission opportunity) sharing) mode subfield in the common information field of the trigger frame is used to include at least a part of the cooperation information.

15. In claim 11, the common information field of the trigger frame includes a first part of the cooperation information and a flag indicating that a special user information field exists in the trigger frame, A method wherein the special user information field includes a second part of the collaboration information.

16. In claim 11, the user information field for the second AP in the trigger frame includes a flag indicating that a special user information field for the second AP exists in the trigger frame, A method wherein the special user information field includes at least a portion of the collaboration information.

17. In claim 11, the cooperation information is included in a plurality of special user information fields in the trigger frame, Among the plurality of special user information fields, a first special user information field includes a first part of the cooperation information and a flag indicating that another special user information field exists after the first special user information field in the trigger frame, A method wherein a second special user information field among the plurality of special user information fields includes a second part of the collaboration information.

18. In the first AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: An action to perform a negotiation procedure for multi-AP cooperation with the second AP; An operation of determining a cooperation method for multi-AP cooperation with the second AP based on the capability information of the second AP obtained in the above negotiation procedure; An operation of determining information included in an allocation period subfield for the second AP in a trigger frame for triggering the multi-AP cooperation based on the above cooperation method; An operation of transmitting the trigger frame including the determined information in the allocation period subfield to the second AP; and A first AP including an operation for performing multi-AP cooperation with the second AP based on information included in the above allocation period subfield.

19. In the device, at least one processor; and At least one memory functionally coupled with at least one processor, The at least one memory stores instructions that perform operations based on being executed by the at least one processor, the operations being: An action to perform a negotiation procedure for multi-AP cooperation with a second AP (access point); An operation of determining a cooperation method for multi-AP cooperation with the second AP based on the capability information of the second AP obtained in the above negotiation procedure; An operation of determining information included in an allocation period subfield for the second AP in a trigger frame for triggering the multi-AP cooperation based on the above cooperation method; An operation of transmitting the trigger frame including the determined information in the allocation period subfield to the second AP; and A device including an operation for performing multi-AP cooperation with the second AP based on information included in the above allocation period subfield.

20. A non-transitory computer readable medium (CRM) storing program code that implements instructions that perform operations based on being executed by at least one processor, wherein the operations are: An action to perform a negotiation procedure for multi-AP cooperation with a second AP (access point); An operation of determining a cooperation method for multi-AP cooperation with the second AP based on the capability information of the second AP obtained in the above negotiation procedure; An operation of determining information included in an allocation period subfield for the second AP in a trigger frame for triggering the multi-AP cooperation based on the above cooperation method; An operation of transmitting the trigger frame including the determined information in the allocation period subfield to the second AP; and A CRM including an operation for performing multi-AP cooperation with the second AP based on information included in the above allocation period subfield.

21. A step in which the second AP (access point) performs a negotiation procedure for multi-AP cooperation with the first AP; As a step for the second AP to receive a trigger frame for triggering the multi-AP cooperation from the first AP, The information included in the allocation period subfield for the second AP in the trigger frame is determined based on a cooperation method for multi-AP cooperation with the first AP, The cooperation method for the above first AP and multi-AP cooperation is determined based on the capability information of the second AP transmitted in the above negotiation procedure; and A method comprising a step of performing multi-AP cooperation with the first AP based on information included in the allocation period subfield.

22. In a STA (station) connected to a second AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: An action to perform a negotiation procedure for multi-AP cooperation with the first AP; As an operation of receiving a trigger frame for triggering the multi-AP cooperation from the first AP, The information included in the allocation period subfield for the second AP in the trigger frame is determined based on a cooperation method for multi-AP cooperation with the first AP, The cooperation method for the above first AP and multi-AP cooperation is determined based on the capability information of the second AP transmitted in the above negotiation procedure; and A second AP including an operation for performing multi-AP cooperation with the first AP based on information included in the above allocation period subfield.

Images