Trigger frame design for AP selection process in multi-AP collaboration in wireless LAN systems

Abstract

This disclosure relates to the design of trigger frames in the AP selection process during multi-AP cooperation in a wireless LAN system. According to embodiments of this disclosure, a method performed by a first AP in a wireless LAN system includes the following steps: performing a negotiation process with neighboring APs for multi-AP coordination; configuring a multi-AP set including the neighboring APs based on the negotiation process; sending a selection request frame to a second AP included in the multi-AP set for initiating multi-AP cooperation with the second AP; receiving a selection response frame from the second AP in response to the selection request frame; and sending a TXOP sharing frame including information about the allocated time period to the second AP based on the received selection response frame.

Description

Technical Field

[0001] This disclosure relates to the design of trigger frames for the access point (AP) selection process in multi-AP coordination in a wireless local area network (WLAN) system. Background Technology

[0002] Next-generation Wi-Fi (e.g., IEEE 802.11be and / or later) is designed 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. For example, an AP can perform a negotiation process for multi-AP coordination to configure a multi-AP set, and can select an AP from the APs included in the multi-AP set to initiate multi-AP coordination. The trigger frame sent during the AP selection process needs to be designed. Summary of the Invention

[0003] Technical issues

[0004] One aspect of this disclosure is to provide a method and apparatus for designing trigger frames in the AP selection process for multi-AP collaboration in a WLAN system.

[0005] Technical solution

[0006] According to embodiments of the present disclosure, a method performed by a first AP in a wireless LAN system includes: performing a negotiation process with a neighboring AP for multi-AP coordination; configuring a multi-AP set including the neighboring AP based on the negotiation process; sending a selection request frame for initiating multi-AP coordination with the second AP to a second AP included in the multi-AP set; receiving a selection response frame from the second AP in response to the selection request frame; and sending a TXOP sharing frame including information for allocating duration to the second AP based on the received selection response frame.

[0007] According to embodiments of the present disclosure, a method performed by a second AP in a wireless LAN system includes: performing a negotiation process with a neighboring AP for multi-AP coordination; configuring a multi-AP set including the neighboring AP based on the negotiation process; receiving a selection request frame from a first AP included in the multi-AP set for initiating multi-AP coordination with the second AP; sending a selection response frame to the first AP in response to the selection request frame; and after sending the selection response frame, receiving a TXOP shared frame from the first AP including information for allocating duration.

[0008] In various embodiments, apparatus for implementing the above-described method is provided.

[0009] Beneficial effects

[0010] This disclosure can have various beneficial effects.

[0011] For example, this disclosure defines the structure / format of a trigger frame sent to the SAP in multi-AP operation / C-TDMA operation to select the DAP to perform multi-AP coordinated transmission. Using trigger frames according to various embodiments of this disclosure, the SAP can perform a multi-AP selection process for selecting the DAP.

[0012] The beneficial effects that can be obtained through the specific embodiments of this disclosure are not limited to those listed above. For example, there are various technical effects that those skilled in the art can understand and / or derive from this disclosure. Therefore, the specific effects of this disclosure are not limited to those explicitly described herein, but may also include various effects that can be understood or derived from the technical features of this disclosure. Attached Figure Description

[0013] Figure 1 Examples of transmitting and / or receiving devices disclosed herein are illustrated.

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

[0015] Figure 3 The diagram illustrates the general link setup process.

[0016] Figure 4 This diagram illustrates an example of a multi-link (ML) connection.

[0017] Figure 5 The illustration shows an example of a modification to the transmitting and / or receiving device disclosed herein.

[0018] Figure 6 The illustration shows an example of a Physical Protocol Data Unit or Physical Layer (PHY) Protocol Data Unit (PPDU) sent / received by the STA of this disclosure.

[0019] Figure 7 The diagram illustrates the layout of a resource unit (RU) for a 20MHz PPDU.

[0020] Figure 8 The diagram illustrates the layout of a resource unit (RU) for a 40MHz PPDU.

[0021] Figure 9 The diagram illustrates the layout of a resource unit (RU) for an 80MHz PPDU.

[0022] Figure 10 The diagram illustrates operations related to UL-MU.

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

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

[0025] Figure 13 The illustration shows an example of channels used, supported, and defined within the 6GHz band.

[0026] Figure 14 The diagram illustrates an example of a process related to NAV settings.

[0027] Figure 15 The diagram illustrates the trigger frame format. The trigger frame format can also be referred to as the structure of a trigger frame.

[0028] Figure 16 The illustration shows an example of the user information field format in MU-RTS TXS TF.

[0029] Figure 17 An example of an operational diagram of coordinated time division multiple access (Co-TDMA) between coordinated APs based on a single TXOP is shown.

[0030] Figure 18 An example of a multi-AP selection process according to an embodiment of the present disclosure is illustrated.

[0031] Figure 19 An example of a method performed by a first AP according to an embodiment of the present disclosure is illustrated.

[0032] Figure 20 An example of a method performed by a second AP according to an embodiment of this disclosure is shown.

[0033] Figure 21 An example of a MAP trigger frame format for a multi-AP selection process according to an embodiment of the present disclosure is illustrated.

[0034] Figure 22 An example of the MAP-RTS trigger frame format used in the multi-AP selection process is illustrated.

[0035] Figure 23 An example of a MU-RTS TXS trigger frame format for a multi-AP selection process according to an embodiment of the present disclosure is illustrated.

[0036] Figure 24 An example of a BSRP trigger frame format for a multi-AP selection process according to an embodiment of the present disclosure is illustrated.

[0037] Figure 25 The illustration shows a first example of a UHR special user information field according to an embodiment of the present disclosure.

[0038] Figure 26 A second example of a UHR special user information field according to an embodiment of the present disclosure is illustrated. Detailed Implementation

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

[0040] As used in this disclosure, a forward slash ( / ) or a comma can mean "and / or". For example, "A / B" can mean "A and / or B". Thus, "A / B" can mean "A only", "B only", or "both A and B". For example, "A, B, C" can mean "A, B, or C".

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

[0042] Additionally, the parentheses used in this disclosure may mean "for example". Specifically, when indicated as "control information (UHR signal field)", it may mean that "UHR signal field" is presented as an example of "control information". In other words, "control information" in this disclosure is not limited to "UHR signal field", and "UHR signal field" may be presented as an example of "control information". Furthermore, when indicated as "control information (i.e., UHR signal field)", it may also mean that "UHR signal field" is presented as an example of "control information".

[0043] Furthermore, as used in this disclosure, "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".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0064] The mobile terminal, wireless device, wireless transceiver unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, user, subscriber STA, network, base station, node B, access point (AP), repeater, router, relay, receiving unit, transmitting unit, receiving STA, transmitting STA, receiving device, transmitting device, receiving apparatus and / or transmitting apparatus described below may mean Figure 1 The STA 110 and 120 shown in subgraphs (a) / (b) may mean, or Figure 1 The processing chips 114 and 124 are shown in sub-figure (b). That is, the technical features of this disclosure can be... Figure 1 It can be performed in STA 110 and 120 as shown in subgraphs (a) / (b), or it can be performed only in Figure 1 The processing chips 114 and 124 shown in sub-diagram (b) are executed Figure 1 Transceivers 113 and 123 are shown in sub-diagrams (a) and (b). For example, the technical features of transmitting control signals by a STA can be understood as being achieved through... Figure 1 The transceiver 113 shown in sub-diagrams (a) / (b) transmits in Figure 1 The technical features of the control signals generated in processors 111 and 121 are illustrated in sub-figures (a) and (b). Alternatively, the technical features of the STA transmitting control signals can be understood as follows: Figure 1 The technical features of generating control signals to be transmitted to transceivers 113 and 123 in processing chips 114 and 124 are shown in sub-figure (b).

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

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

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

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

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

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

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

[0072] A BSS may include at least one STA, an AP that provides distributed services, and a distributed system (DS) 210 that connects multiple APs.

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

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

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

[0076] Figure 2 The lower part of the diagram is a concept diagram, illustrating IBSS.

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

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

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

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

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

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

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

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

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

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

[0087] Figure 4 This diagram illustrates an example of a multi-link (ML) connection.

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

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

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

[0091] exist Figure 4 In the example, AP1 can initiate the multi-link setup process (ML setup process) by sending an association request frame to a non-AP STA1. Figure 4 In the example, non-AP STA1 is able to send an association response frame in response to the association request frame. Figure 4 Each AP (e.g., AP1 / 2 / 3) shown in the diagram can be associated with Figure 1 and / or Figure 2 The AP shown in the figure is the same, and Figure 4 Each non-AP (e.g., non-AP1 / 2 / 3) shown in the diagram can be associated with Figure 1 and / or Figure 2 The STA (i.e., user STA or non-APSTA) shown in the figure is the same.

[0092] The specific features of this disclosure are not limited to Figure 4 Its specific characteristics include the ability to define the number of links in various ways, and the ability to define multiple links in various ways within at least one band.

[0093] Figure 5 The illustration shows an example of a modification to the transmitting and / or receiving device disclosed herein.

[0094] Figures 1 to 4The devices shown (e.g., AP STA, non-AP STA) are capable of... Figure 5 The modifications shown are as follows. Figure 5 The 530 transceiver is able to communicate with Figure 1 The transceivers 113 and 123 are the same. Figure 5 The transceiver 530 can include a receiver and a transmitter.

[0095] Figure 5 The processor 510 is capable of working with Figure 1 The processors 111 and 121 are the same. Alternatively, Figure 5 The processor 510 is capable of working with Figure 1 The processing chips 114 and 124 are the same.

[0096] Figure 5 The memory 150 can be with Figure 1 The memories 112 and 122 are the same. Alternatively, Figure 5 The memory 150 can be with Figure 1 The memory 112 and 122 are different independent external memories.

[0097] refer to Figure 5 The power management module 511 manages the power supply for the processor 510 and / or transceiver 530. The battery 512 supplies power to the power management module 511. The display 513 outputs the results processed by the processor 510. The keyboard 514 receives input to be used by the processor 510. The keyboard 514 can be displayed on the display 513. The SIM card 515 can be an integrated circuit used to securely store the International Mobile Subscriber Identity (IMSI) and its associated key, which is used to identify and verify subscribers in mobile devices such as mobile phones and computers.

[0098] refer to Figure 5 The speaker (540) can output the sound-related results processed by the processor 510. The microphone (541) can receive sound-related inputs to be used by the processor 510.

[0099] Figure 6 The illustration shows an example of a Physical Protocol Data Unit or Physical Layer (PHY) Protocol Data Unit (PPDU) sent / received by the STA of this disclosure.

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

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

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

[0103] Figure 6 Each block shown can be referred to as a field / subfield / signal, etc. The names of these fields / subfields / signals can be Legacy Short Training Field (L-STF), Legacy Long Training Field (L-DTF), Legacy Signal (L-SIG), Repeated L-SIG (RL-SIG), Universal Signal (U-SIG), UHR Signal (UHR-SIG), etc., such as... Figure 6 As shown in the image.

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

[0105] exist Figure 6 In the PPDU, L-LTF and L-STF can be the same as those in legacy fields (e.g., non-HT LTF and non-HT STF as defined in traditional WLAN standards).

[0106] Figure 6 The L-SIG field can include, for example, 24 bits of bit information. For instance, the 24 bits could include a 4-bit rate field, a 1-bit reserved bit, a 12-bit length field, a 1-bit parity bit, and a 6-bit tail bit. For example, the 12-bit length field could include information related to the length or duration of the PPDU. For example, the 12-bit length field can be determined based on the type of PPDU. For example, when the PPDU is a Non-High Throughput (HT), High Throughput (HT), Very High Throughput (VHT), Extremely High Throughput (EHT), or UHR PPDU, the value of the length field can be determined to be a multiple of 3. For example, when the PPDU is an HE PPDU, the value of the length field can be determined to be a multiple of 3 + 1 or a multiple of 3 + 2. In other words, for non-HT, HT, VHT PPDI, EHT PPDU, or UHR PPDU, the value of the length field can be determined to be a multiple of 3, and for a valid (HE) PPDU, the value of the length field can be determined to be either "a multiple of 3" + 1 or "a multiple of 3" + 2. In other words, the length field in a UHR PPDU is set to a value that satisfies the condition that the remainder when the length is divided by 3 is zero.

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

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

[0109] It is possible Figure 6 A generic SIG (U-SIG) is inserted after the RL-SIG. U-SIG can be referred to by various terms such as first SIG field, first SIG, first type SIG, control signal, control signal field, first (type) control signal, common control field, common control signal, etc.

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

[0111] For example, via U-SIG, A bits of information (e.g., 52 uncoded bits) can be transmitted. The first symbol of U-SIG can transmit the first X bits of the A bits of information (e.g., 26 uncoded bits), and the second symbol of U-SIG can transmit the remaining Y bits of the A bits of information (e.g., 26 uncoded bits). For example, the transmitting STA can obtain the 26 uncoded bits included in each U-SIG symbol. The transmitting STA can perform convolutional coding (i.e., BCC coding) at a rate of R=1 / 2 to generate 52 coded bits, and can 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 to be assigned to each U-SIG symbol. A U-SIG symbol can be transmitted based on 65 tones (subcarriers) from subcarrier index -28 to subcarrier index +28 (excluding DC index 0). The 52 BPSK symbols generated by the transmitting STA can be transmitted based on the remaining tones (subcarriers) other than the pilot tone (i.e., tones -21, -7, +7, +21).

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

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

[0114] 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 TX / RX PPDU. For example, the first value of the 3-bit PHY version identifier (e.g., a value of 000) may indicate that the TX / RX PPDU is an EHT PPDU. Furthermore, the second value of the 3-bit PHY version identifier (e.g., a value of 001) may indicate that the TX / RX PPDU is a UHR PPDU.

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

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

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

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

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

[0120] Lead punching can be applied to Figure 6 The PPDU. A preamble puncture indicates that the puncture is applied to a portion of the full band (e.g., the secondary 20MHz band). For example, when transmitting an 80 MHz PPDU, the STA can apply punctures to the secondary 20 MHz band outside the 80 MHz band, and can transmit the PPDU only through the primary 20 MHz band and the secondary 40 MHz band.

[0121] For example, the pattern of preamble puncturing can be preconfigured. For example, when applying the first puncturing pattern, puncturing can be applied only to the secondary 20MHz band within the 80MHz band. For example, when applying the second puncturing pattern, puncturing can be applied only to either of the two secondary 20MHz bands included in the secondary 40MHz band within the 80MHz band. For example, when applying the third puncturing pattern, puncturing can be applied only to the secondary 20MHz band included in the primary 80MHz band within the 160MHz band (or 80+80MHz band). For example, when applying the fourth puncturing pattern, if the primary 40MHz band included in the 80MHz band within the 160MHz band (or 80+80MHz band) exists, puncturing can be applied to at least one 20MHz channel that does not belong to the primary 40MHz band.

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

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

[0124] Alternatively, U-SIG and UHR-SIG may include information related to the leader punch, based on the following method: U-SIG may include information related to the leader punch for all bands (i.e., information related to the leader punch pattern). That is, UHR-SIG may not include information related to the leader punch, and only U-SIG may include information related to the leader punch (i.e., information related to the leader punch pattern).

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

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

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

[0128] Figure 6 The frequency resources of the UHR-LTF, UHR-STF, and data fields shown can be determined based on RUs (Resource Units) defined by multiple subcarriers / tones. That is, the UHR-LTF, UHR-STF, and data fields of this disclosure can be transmitted / received through RUs (Resource Units) defined by multiple subcarriers / tones.

[0129] Figure 7 The diagram illustrates the layout of a resource unit (RU) for a 20MHz PPDU. In other words, it can be achieved through... Figure 7 At least one of the various RUs defined in the specification is used to transmit / receive the UHR-LTF, UHR-STF, and / or data fields included in the 20MHz PPDU.

[0130] like Figure 7 As shown at the top, 26 units (i.e., units corresponding to 26 tones) can be configured. Six tones can be used for the guard band in the leftmost band of the 20MHz band, and five tones can be used for the guard band in the rightmost band of the 20MHz band. Furthermore, seven DC tones can be inserted in the center band (i.e., the DC band), and 26 units corresponding to 13 tones can be configured on each of the left and right sides of the DC band. 26 units, 52 units, and 106 units can be allocated to other bands. Each unit can be allocated to a receiving STA, i.e., a user.

[0131] Figure 7 The RU layout can be used not only for multiple users (MU) but also for a single user (SU). In this case, a 242 unit can be used, and three DC tones can be inserted, such as... Figure 7 As shown at the very bottom.

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

[0133] Figure 8 The diagram illustrates the layout of a resource unit (RU) for a 40MHz PPDU.

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

[0135] like Figure 8 As shown, a 484-RU can be used when the RU layout is used for a single user. The specific number of RUs can be similar to... Figure 7 It was changed.

[0136] Figure 9 The diagram illustrates the layout of resource units (RUs) for an 80MHz PPDU. The layout of resource units (RUs) used in this disclosure can be varied. For example, the layout of resource units (RUs) used in the 80MHz band can be varied.

[0137] Figure 10 The diagram illustrates operations related to the UL-MU. As shown, a transmitting STA (e.g., an AP) can obtain TXOP 1025 by performing channel access through contention (i.e., backoff operation) and transmitting trigger frame 1030. That is, the transmitting STA (e.g., an AP) can transmit a PPDU including trigger frame 1030. Upon receiving the PPDU including the trigger frame, a trigger-based (TB) PPDU is transmitted after a delay of SIFS.

[0138] TB PPDUs 1041 and 1042 can be transmitted simultaneously from multiple STAs (e.g., user STAs) whose AIDs are indicated in trigger frame 1030. The ACK frame 1050 for the TB PPDU can be implemented in various forms. For example, the ACK frame 1050 for the TB PPDU can be implemented as a block ACK (BA).

[0139] exist Figure 10In this process, the transmission of trigger frame 1030, TB PPDU 1041, 1042 and / or ACK frame 1050 can be performed within TXOP1025.

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

[0141] The 2.4 GHz band can also be referred to by other names such as "first band". Furthermore, the 2.4 GHz band can refer to the frequency range that uses / supports / defines channels with a center frequency adjacent to 2.4 GHz (e.g., channels with center frequencies between 2.4 and 2.5 GHz).

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

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

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

[0145] The 5 GHz band can be referred to by other names such as "second band" or "band". A 5 GHz band can refer to a frequency range that uses / supports / defines channels with a center frequency of 5 GHz or greater but less than 6 GHz (or less than 5.9 GHz). Alternatively, a 5 GHz band can include multiple channels between 4.5 GHz and 5.5 GHz. Figure 12 The specific values ​​shown can vary.

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

[0147] Multiple channels can be configured within the 5 GHz band, with each channel having a variable bandwidth, such as 20 MHz, 40 MHz, 80 MHz, or 160 MHz. For example, the 5170 MHz to 5330 MHz frequency range within UNII-1 and UNII-2 can be divided into eight 20 MHz channels. The 5170 MHz to 5330 MHz frequency range can be divided into four channels across a 40 MHz band. The 5170 MHz to 5330 MHz frequency range can be divided into two channels across an 80 MHz band. Alternatively, the 5170 MHz to 5330 MHz frequency range can be divided into a single channel across a 160 MHz band.

[0148] Figure 13 The illustration shows an example of channels used, supported, and defined within the 6GHz band.

[0149] The 6GHz band can also be referred to by other names such as the third band. The 6GHz band can refer to the frequency range used, supported, and defined by channels with a center frequency higher than 5.9GHz. Figure 13 The specific numbers shown can vary.

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

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

[0152] Simultaneously, STAs with data available for transmission can perform a Clear Channel Assessment (CCA) for sensing the medium during a specific period before data transmission (e.g., the Distributed Coordination Function (DCF) Inter-Frame Space (DIFS)). If the medium is idle at this time, the STA can use it to perform transmission. However, if the medium is busy, it can be assumed that several STAs are already waiting to use the medium, and the STA can transmit data after waiting for a random backoff duration other than DIFS. In this case, the random backoff duration allows for collision avoidance because, when several STAs are assumed to be available to transmit data, each STA probabilistically has a different backoff duration value and ultimately a different transmission time. Once one STA begins transmission, other STAs cannot use the medium.

[0153] During the random backoff process, if a specific medium changes from a busy state to an idle state, several STAs begin preparing to transmit data. At this time, to minimize collisions, the STAs intending to transmit data each select a random backoff counter and wait for the time slot corresponding to their selected counter. The random backoff counter is a pseudo-random integer value, chosen as one of the values ​​uniformly distributed within the range [0 CW]. CW stands for Contention Window. The CW parameter takes the CWmin value as its initial value, but if transmission fails, this value is doubled. For example, if no ACK response has been received for the transmitted data frame, a collision can be considered to have occurred. If the CW value reaches the CWmax value, the CWmax value is maintained until successful data transmission, and if successful, the CW value is reset to the CWmin value. For ease of implementation and operation, CW, CWmin, and CWmax can be expressed as 2^n-1. Simultaneously, when the random backoff process begins, the STA selects a random backoff counter within the range [0 CW] and then continues to monitor the medium while the backoff time slot is counted down. If the medium becomes busy at the same time, it stops counting down and then resumes counting down for the remaining backoff slots when the medium becomes idle again.

[0154] Figure 14 The diagram illustrates an example of a process related to NAV settings.

[0155] refer to Figure 14 When a source intending to send data (e.g., APSTA / non-APSTA) sends a Request to Send (RTS) frame to a destination (e.g., APSTA / non-APSTA) intending to receive data, the destination can send a Clear to Send (CTS) frame to neighboring stations to notify them that it will receive data. In other words, a destination designated as a receiver via an RTS frame can send a CTS frame. If the source sending the RTS frame receives the CTS frame, the source can initiate data transmission to the destination.

[0156] Meanwhile, if an STA receives an RTS frame other than the destination designated as the receiver via the RTS frame, or if an STA other than the source sending the RTS frame receives a CTS frame, the STA can configure a Network Allocation Vector (NAV). A STA with an NAV configured can refrain from sending data during the NAV period, allowing the STA to avoid collisions with the source / destination. On the other hand, if an RTS frame is received as the destination designated as the receiver via the RTS frame, or if the source sending the RTS frame receives a CTS frame, the source / destination does not configure an NAV.

[0157] If no CTS frame (e.g., PHY-RXSTART.indication primitive) is received within a specific time period starting from the time the RTS frame is received (e.g., the time the MAC receives the PHY-RXEND.indication primitive corresponding to the RTS frame), then the STA that has already set or updated the NAV via the RTS frame can reset the NAV (e.g., reset it to 0). This specific time period can be (2... aSIFSTime+CTS_Time+aRxPHYStartDelay+2 (aSlotTime). It is possible to calculate CTS_Time based on the length of the CTS frame indicated by the RTS frame and the data rate.

[0158] For ease of description, Figure 14 The diagram illustrates setting or updating the NAV via RTS or CTS frames. However, NAV setting / resetting / updating can also be performed based on the duration field of various other frames, such as non-HT PPDU, HT PPDU, VHTPPDU, or HE PPDU (e.g., the duration field in the MAC header of a MAC frame). For example, if the RA field in a received MAC / RTS / CTS frame does not match its own address (e.g., MAC address), the STA can set, reset, or update the NAV based on the value of the duration field in the received MAC / RTS / CTS frame.

[0159] Non-AP STAs should 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 intra-BSS PPDUs. The basic NAV can be updated / set by inter-BSS PPDUs or PPDUs that cannot be classified as intra-BSS or inter-BSS.

[0160] The MAC frames included in the data fields of the PPDU disclosed herein can be classified into various types. For example, the MAC frames of this disclosure can be classified into control frames, management frames, and data frames.

[0161] For example, management frames include association requests, association responses, reassociation requests, reassociation responses, probe requests, probe responses, beacons, unassociation, authentication, and deauthentication frames / signals as defined in traditional WLANs. For management frames, the values ​​of the type fields (B3 and B2) in the MAC header are set to 00. Additionally, the values ​​of the subtype fields (B7, B6, B5, B4) in the MAC header are as follows: association request (0000), association response (0001), reassociation request (0010), reassociation response (0011), probe request (0100), probe response (0101), beacon (1000), unassociation (1010), authentication (1011), and deauthentication (1100).

[0162] For example, control frames include trigger beamforming report polling, NDP announcement (NDPA), control frame extension, control packet, block acknowledgment request (BlockAckReq), block acknowledgment (BlockAck), PS polling, RTS, CTS, acknowledgment, and CF end frame / signal as defined in traditional WLANs. For control frames, the values ​​of the type fields (B3 and B2) in the MAC header are set to 01. Additionally, the values ​​of the subtype fields (B7, B6, B5, B4) in the MAC header are as follows: Trigger (0010), Beamforming Report Polling (0100), NDP Announcement (0101), Control Frame Extension (0110), Control Packet (0111), BlockAckReq (1000), BlockAck (1001), PS Polling (1010), RTS (1011), CTS (1100), Acknowledgment (1101), and CF End (1110).

[0163] For example, the data frame includes (QoS) data, (QoS) null, etc., as defined in a traditional WLAN. For this data frame, the values ​​of the type fields (B3 and B2) in the MAC header are set to 10.

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

[0165] Figure 15 The diagram illustrates the trigger frame format. The trigger frame format can also be referred to as the structure of the trigger frame.

[0166] refer to Figure 15 The trigger frame may include a frame control field, a duration / ID field, a receiver address (RA) field, a transmitter address (TA) field, a common information field, a user information list field, a padding field, and / or a frame check sequence (FCS) field. Optionally, the trigger frame may also include a special user information field between the common information field and the user information list field. The user information list field may include one or more user information fields. The frame control field, duration / ID field, RA field, and TA field may constitute the MAC header.

[0167] For example, the public information field may include a trigger type subfield. The value of the trigger type subfield can indicate a variant of the trigger frame, as shown in Table 4: Table 1

[0168] For example, if the value of the trigger type subfield is set to 0, the trigger frame can be a basic trigger frame. For example, if the value of the trigger type subfield is set to 3, the trigger frame can be a multi-user (MU) RTS trigger frame. Meanwhile, according to the EHT (i.e., 802.11be) standard, the AP can allocate a portion of the duration within the TXOP obtained by the AP to support peer-to-peer (P2P) transmissions to non-AP STAs. To allocate a portion of the duration within the TXOP, the TXOP sharing mode subfield can be defined within the common information field of the MU-RTS trigger frame. When the value of the TXOP sharing mode subfield is non-zero, this MU-RTS trigger frame can be called a MU-RTS TXOP sharing (TXS) trigger frame (TF). The values ​​of the TXOP sharing mode subfield are described in Table 5 below: Table 2

[0169] For example, if the value of the TXOP shared mode subfield is 1, one or more (non-TB) PPDU transmissions to the AP can be supported. If the value of the TXOP shared mode subfield is 2, both (non-TB) PPDU transmissions to the AP and P2P transmissions can be supported. In this disclosure, the MU-RTS TXS TF can also be simply referred to as the TXS trigger frame.

[0170] Figure 16 The illustration shows an example of the user information field format in MU-RTS TXS TF.

[0171] Reference Figure 16 The user information field may include the AID subfield, the RU allocation subfield, the allocation duration subfield, the reserved bits and / or the PS160 subfield.

[0172] The AID subfield indicates the AID used for the corresponding STA. The RU allocation subfield indicates the RU allocation used for the corresponding STA.

[0173] The allocation duration subfield can include 9 bits from B20 to B28 in the MU-RTS TXS TF and can indicate the allocation duration in units of 16µs. In this case, the maximum length of the allocation duration indicated by the allocation duration subfield can be 8192µs.

[0174] The PS160 subfield can indicate whether the RU or MRU allocation is applied to the primary 160 MHz channel or the secondary 160 MHz channel.

[0175] Meanwhile, many APs are installed adjacent to each other to enable STAs to maintain continuous WLAN connectivity over a larger area. However, overlapping BSSs of multiple APs can lead to radio interference and transmission conflicts between APs. To address these issues, various techniques related to coordination between APs in the frequency, time, and spatial domains have been proposed (e.g., RU selection, joint transmission, nulling). Various problems that may arise during the coordination process between APs need to be addressed.

[0176] In this disclosure, multi-AP operation is proposed. Multi-AP operation can be based on techniques to reduce various interferences such as inter-symbol interference (ISI) by coordinating with neighboring APs (e.g., APs located in an overlapping BSS).

[0177] For example, multi-AP operation can be categorized into multi-AP coordination schemes (or coordination schemes) based on various technologies / types / formats / protocols. For instance, a coordination scheme may include coordinated TDMA (Co-TDMA) that differentiates radio resources allocated to several APs based on the time axis (time domain). Alternatively, a coordination scheme may include coordinated OFDMA (C-OFDMA) that differentiates radio resources allocated to several APs based on the frequency axis (time domain). Alternatively, a coordination scheme may include coordinated spatial reuse (Co-SR) that applies spatial reuse (SR) to at least one AP. Alternatively, a coordination scheme may include coordinated beamforming (Co-BF) / nulling, which transmits by nulling interference occurring in neighbors (e.g., adjacent APs / STAs, and / or OBSS APs / OBSSSTAs). Alternatively, a coordination scheme may include AP selection, where the AP with good channel conditions among adjacent APs (e.g., at least one AP located in a BSS or OBSS and with excellent channel conditions) performs the transmission. Alternatively, the coordination scheme may include multiple APs (e.g., multiple APs included in the same BSS / OBSS, or multiple APs included in different BSS / OPSS) performing joint transmission (JTX) or JT by coordinating simultaneous transmission and reception, and may be implemented based on joint beamforming or joint MU-MIMO.

[0178] In this disclosure, "multi-AP (coordination) operation" may also be referred to as "multi-AP (coordination) transmission". In addition, "multi-AP (coordination) operation / transmission" and "multi-AP coordination scheme (or coordination scheme)" can be used interchangeably.

[0179] When the triggered TXOP sharing protocol is used for multi-AP coordination, the transmissions within the BSS of each coordinating AP are divided into time units, allowing each coordinating AP to perform frame switching without affecting other coordinating APs.

[0180] In this disclosure, "frame switching (FE)" can include frame transmission and / or reception operations between STAs. STAs can be APs or non-AP STAs. Here, frames can include various types of frames (e.g., data frames, control frames, and management frames).

[0181] Figure 17 An example of an operational diagram of coordinated time division multiple access (Co-TDMA) between coordinated APs based on a single TXOP is shown.

[0182] For example, C-TDMA could mean that each coordinating AP exchanges frames by dividing the transmissions within each coordinating AP's BSS by the time unit, without affecting other coordinating APs.

[0183] When a triggered TXS protocol is applied to a multi-AP coordination operation, the AP triggering the TXS protocol can be an AP sharing a TXOP in the multi-AP coordination operation, and the STA triggering the TXS protocol can be an AP authorized to share a TXOP in the multi-AP coordination operation. In this disclosure, the AP sharing a TXOP can be referred to as the sharing AP (SAP), and the AP authorized to share a TXOP by the SAP can be referred to as the shared AP (DAP). The term "SAP" here does not limit the entity sharing a TXOP to AP STAs; SAP can also include non-AP STAs sharing a TXOP. Furthermore, the term "DAP" does not limit the entity authorized to share a TXOP to only AP STAs; DAP can also include non-AP STAs authorized to share a TXOP (or, those transmitted and received using an AP STA authorized to share a TXBP). Additionally, during the allocated time (i.e., by...) Figure 16 The time allocated by the MU-RTS TXS TF (which is the allocated duration for DAP / AP2 within the TXOP indicated by the MU-RTS TXS TF sent from SAP) and the frame exchange performed by the DAP with a non-AP STA belonging to the DAP BSS or SAP can be referred to as the DAP's BSS frame exchange (FE). For example, RTS / CTS frame exchange between the DAP and non-AP STAs can be performed, followed by data frame transmission and block ACK frame response; UL data frame transmission by a non-AP STA based on a trigger frame sent from the DAP; and / or data frame transmission by the DAP based on a trigger frame sent from SAP.

[0184] To achieve multi-AP coordination between two APs, the two APs can be in a connected / associated state, and / or, after a prior negotiation process involving the exchange of coordination request frames / coordination response frames including each other's capability / demand information, multi-AP transmission can be performed based on the obtained information (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, or Joint Transmission (J-TX)). In other words, for smooth multi-AP transmission, the configuration / management of multi-AP coordination and / or a negotiation process based on a specific multi-AP coordination scheme for transmission needs to be performed beforehand between the SAP and DAP. Through this negotiation process, a multi-AP set can be established / configured. Therefore, the negotiation process can also be referred to as the multi-AP set establishment / configuration process.

[0185] To successfully perform multi-AP coordination, a multi-AP selection process (or, an AP selection process for multi-AP coordination) can be executed to select DAPs with which SAP intends to share TXOPs within a set of multi-APs configured / established through a negotiation process, and / or to notify that TXOPs are scheduled for sharing. Through this multi-AP selection process, SAP can determine whether TXOP sharing with a DAP is necessary within the acquired TXOPs, and when TXOP sharing with a specific DAP is not required, it can determine TXOP sharing with subsequent / other DAPs. Alternatively, SAP can simply notify the target DAP to schedule TXOPs for sharing during the multi-AP selection process, thereby performing multi-AP coordination while reducing the overhead caused by the multi-AP selection process.

[0186] Figure 18 An example of a multi-AP selection process according to an embodiment of the present disclosure is illustrated.

[0187] refer to Figure 18 During a multi-AP selection process, SAP can send a request frame (i.e., a request frame for AP selection / selection request frame) to one or more DAPs to select DAPs from a multi-AP set configured / established through a negotiation process to share the TXOP. The one or more DAPs receiving the request frame can then send a response frame (i.e., a response frame for AP selection / selection response frame) based on whether TXOP sharing is required. When a response frame is received from a DAP indicating that TXOP sharing is not required, or when a response frame cannot be received from a DAP, SAP can send a request frame for AP selection to another DAP—that is, SAP can perform AP reselection. Alternatively, SAP can simply instruct the target DAP to schedule the TXOP for sharing during the multi-AP selection process. For example, SAP can send an AP selection request frame without requesting a response frame to a target DAP with which SAP intends to share the TXOP, and the DAP receiving such an AP selection request frame can prepare for the scheduled TXOP sharing operation.

[0188] SAP can send frames for TXOP sharing (e.g., TXOP sharing frames / MU-RTS TXS trigger frames) to DAPs selected through a multi-AP selection process, and DAPs can perform frame exchanges with non-AP STAs associated with DAPs during the time duration allocated by the TXOP sharing frames (e.g., the allocation duration).

[0189] When performing a multi-AP selection process, the multi-AP selection request frame sent by SAP to the DAP needs to be defined / designed in more detail. Therefore, this disclosure defines the structure / format of the trigger frame sent by SAP for selecting the DAP that will perform a multi-AP coordinated transmission during multi-AP coordination and / or Co-TDMA operations.

[0190] Furthermore, in order to initiate a transmission based on a multi-AP coordination scheme (such as Co-SR, Co-BF), a process may be required for announcing coordination and / or performing short-term negotiations for the respective coordination scheme. Therefore, this disclosure defines the structure / format of trigger frames sent to initiate a transmission based on a multi-AP coordination scheme (e.g., Co-TDMA, Co-SR, Co-BF) and / or perform short-term negotiations.

[0191] According to various embodiments of this disclosure, by sending a multi-AP selection request frame / trigger frame for multi-AP operation, an SAP can share TXOP and / or select the DAP to perform the multi-AP operation and / or announce information related to the multi-AP operation / Co-TDMA operation. Furthermore, the AP can check whether other APs are participating in multi-AP coordination.

[0192] In this disclosure, the multi-AP selection request frame / trigger frame can be used as the initial control frame (ICF) to initiate multi-AP coordination.

[0193] The specific naming / names presented in this disclosure may be changed, and are not limited thereto. For example, in this disclosure, multiple AP selection may be used interchangeably with scheduling announcements, coordination announcements, and coordination polling.

[0194] Figure 19 The illustration shows an example of a method performed by a first AP according to an embodiment of the present disclosure. The first AP may be an AP that sends an ICF (Initial Communication Function) for initiating a multi-AP coordination / multi-AP selection process.

[0195] refer to Figure 19 In step S1901, the first AP may perform a negotiation process with neighboring APs for multi-AP coordination.

[0196] In step S1903, based on the negotiation process, the first AP can be configured to include a set of multiple APs, including neighboring APs.

[0197] In step S1905, the first AP may send a selection request frame to the second AP included in the multi-AP set for initiating multi-AP coordination with the second AP.

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

[0199] In step S1909, based on the received selection response frame, the first AP may send a TXOP shared frame to the second AP, which includes information for allocating duration.

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

[0201] According to various embodiments, the identification information of the second AP used for multi-AP coordination may be included in the Association Identifier (AID) 12 field within the user information field of the selection request frame. The identification information of the second AP may include at least one of the following: the Basic Service Set Identifier (BSSID) of the second AP, the BSS color of the second AP, the ID of the multi-AP set, or the ID assigned to the second AP within the multi-AP set.

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

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

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

[0205] According to various embodiments, coordination-related information may include at least one of the following: an identifier (ID) of the multi-AP set (e.g., MAP group ID), an ID assigned to a second AP within the multi-AP set (e.g., AP ID), information for the address of the second AP (e.g., address), information for the operation channel (e.g., operation channel), information for the operation bandwidth (e.g., operation bandwidth), information for the scheduled TXOP duration (e.g., scheduled TXOP duration), information for the TXOP sharing time (e.g., expected TXOP sharing time), low-latency service information, or information for the priority of the current coordination scheme in the coordination scheme (e.g., coordination priority).

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

[0207] According to various embodiments, the selection request frame may be a trigger frame that includes a trigger type subfield, which is set to a reserved value among the values ​​of the trigger type subfield. The reserved value may be a value from 9 to 15.

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

[0209] According to various embodiments, the selection request frame may be a buffer status report polling (BSRP) triggered frame.

[0210] According to various embodiments, the common information field of the BSRP trigger frame may include at least one of the following: information for the type of ICF, information for the coordination scheme, information indicating that the selection request frame requests the selection of an AP for multi-AP coordination, information for the type of response to the selection request frame, or information regarding whether ICR is allowed. The special user information field of the BSRP trigger frame may include coordination-related information.

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

[0212] According to various embodiments, the public information field or user information field of the BSRP trigger frame may include information indicating the existence of a special user information field.

[0213] According to various embodiments, the selected response frame can be a Quality of Service (QoS) empty frame, a QoS data frame, a Allow Transmission (CTS) frame, a CTS-to-Self frame, a Block Acknowledgment (BA) frame, or an action frame.

[0214] Figure 20An example of a method performed by a second AP according to an embodiment of this disclosure is shown. The second AP may be an AP that sends an ICR for an ICF used to initiate a multi-AP coordination / multi-AP selection process.

[0215] refer to Figure 20 In step S2001, the second AP can perform a negotiation process with the neighboring AP for multi-AP coordination.

[0216] In step S2003, based on the negotiation process, the second AP can be configured to include a set of multiple APs, including neighboring APs.

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

[0218] In step S2007, the second AP may send a selection response frame to the first AP in response to the selection request frame.

[0219] In step S2009, after sending the selection response frame, the second AP can receive a TXOP shared frame from the first AP, which includes information for allocating duration.

[0220] The following describes a detailed implementation of the trigger frame design for the AP selection process in multi-AP coordination.

[0221] In this disclosure, a trigger frame can be defined / designed for transmission during a multi-AP selection process, in which the SAP selects the DAP for sharing the TXOP in a Co-TDMA-based transmission as a multi-AP coordination scheme. Furthermore, a trigger frame can be defined / designed that can be considered as an initial control frame initiating multi-AP operation during a separate multi-AP coordination process. In this disclosure, the structure / format of trigger frames for the multi-AP selection process in multi-AP coordination and / or Co-TDMA operation can be defined / designed.

[0222] I. Define a new trigger frame type

[0223] In some implementations, novel trigger frames can be proposed / designed for the multi-AP selection process in multi-AP coordination and / or Co-TDMA-based transmissions. For example, novel trigger frames that can be utilized in multi-AP coordination and / or Co-TDMA-based transmissions can be implemented using reserved values ​​(e.g., 9 to 15) in the trigger frame type (e.g., trigger type subfield values ​​in ).

[0224] I-1. Multiple AP (Multiple AP, MAP) Trigger Frame

[0225] MAP trigger frames (TFs) can be implemented / defined to support multi-AP coordination / Co-TDMA-based transmissions. The specific name (naming) of the trigger frame can be changed. The MAP TF can allocate and / or request resources for the transmission of one or more TB PPDUs between APs, and the APs responding to the TF can also deliver the information required for the transmission of the TB PPDUs.

[0226] Figure 21 An example of a MAP trigger frame format for a multi-AP selection process according to an embodiment of the present disclosure is illustrated.

[0227] refer to Figure 21 The MAP trigger frame may include a public information field and a user information field, and the diagram illustrates the fields included in the public information field / user information field and the number of bits for each field. The naming (name) and / or number of bits for the fields may be changed and are not limited to this. Furthermore, the MAP trigger frame may include one or more fields.

[0228] Alternatively, a different trigger frame variant than the MAP trigger frame (e.g., the BSRP trigger frame) can be used.

[0229] Alternatively, a Block Acknowledgment Request (BAR) frame, different from the trigger frame, can be used.

[0230] The common information field / user information field of the MAP trigger frame may include at least one of the following fields: - ICF Type: Indicates the type of ICF. For example, the EHT reserved or reserved bits of a public information field can be used for an ICF type field.

[0231] The ICF type field indicates the purpose for which the corresponding trigger frame is sent. For example, the ICF type field can indicate the purpose for which a trigger frame (TF) used as an ICF in Dynamic Power Saving (DPS), Inter-device Coexistence (IDC), Dynamic Subband Operation (DSO), and / or Multi-AP Coordination is sent. For example, bit 0 indicates that the corresponding trigger frame is a base TF. Bit 1 indicates that the corresponding trigger frame is a TF for Multi-AP Coordination / Operation. Bit 2 indicates that the corresponding trigger frame is a TF for DPS Operation. Bit 3 indicates that the corresponding trigger frame is a TF for IDC Operation. Bit 4 indicates that the corresponding trigger frame is a TF for DSO Operation. Other bits can be reserved.

[0232] Figure 21The ICF type / MAP coordination type field can be replaced by the ICF type field. In this case, the MAP coordination type field can use some bits of the coordination-related information field (e.g., using 8 bits as both the MAP coordination type field and the coordination-related information field), or it can be defined as a subfield of the coordination-related information field.

[0233] Alternatively or additionally, the ICF type field may utilize EHT reserved bits (7 bits) and / or reserved bits (4 bits), and may not indicate a specific ICF type, but can be used for one or more operations, such as DPS, IDC, DSO, multi-AP coordination, and / or soliciting Initial Control Response (ICR) information. For example, each of the 7 bits may indicate a specific type (e.g., DPS, IDC, DSO, MAP). Combinations of each bit (e.g., bitmaps) may be set to solicit ICR information. For example, in the case of B56: MAP, B57: DPS, B58: IDC, B59: DSO (or Non-Master Channel Access (NPCA)), other bits: reserved, 1100 may solicit ICR information for MAP and DPS.

[0234] - MAP Coordination Type: Information used for multi-AP coordination schemes (such as Co-OFDMA, Co-TDMA, Co-SR).

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

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

[0237] Alternatively, the MAP coordination type field can be included in the user information field or the special user information field.

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

[0239] In some implementations, the EHT reserved bits (7 bits) or reserved bits (4 bits) of the public information field can be used in the multi-AP selection field. For example, as Figure 21 As illustrated, one bit corresponding to the Type-Related Signaling-1 or Type-Related Signaling-2 field can be used to indicate that it is a TF sent for a multi-AP selection process. In this case, bit 0 indicates that the corresponding TF is not sent for a multi-AP selection process, and bit 1 can indicate that the corresponding TF is sent for a multi-AP selection process.

[0240] Alternatively, one bit may be used to indicate one of the multi-AP coordination processes. For example, the corresponding bit may indicate that it is a TF delivered for a specific process within the multi-AP coordination process. In this case, bit 0 may indicate that the corresponding TF is not sent for the multi-AP selection process. Bit 1 may indicate that the corresponding TF is sent for the multi-AP selection process. Bit 2 may indicate that the corresponding TF is sent for the TXOP process (e.g., time allocation) or the coordination triggering process (i.e., the process used to initiate / trigger another multi-AP coordination-based transmission). Alternatively, bit 2 may replace bit 0. That is, bit 0 may be used for the indication of bit 2. Bit 3 may indicate that the corresponding TF is sent for the TXOP return process.

[0241] In some implementations, the reserved bits of the user information field can be used for the multi-AP selection field.

[0242] Alternatively or additionally, one or more user information fields with the same AID may exist, and additional user information fields may include bits / fields for indicating multi-AP selection (or multi-AP procedure).

[0243] Additional or alternative locations, special user information fields can be used for multi-AP selection fields.

[0244] Additional land or alternative land, Figure 21 Some bits of the coordination-related information field shown in the diagram can be used in the multi-AP selection field.

[0245] - Response type: Indicates the type of response frame for the sent TF and / or the type of information requested from the receiving device.

[0246] In some implementations... Figure 21 One or more type-related signaling bits illustrated can be used in the response type field.

[0247] In some implementations... Figure 21 Some bits of the coordination-related information field illustrated can be used in the response type field. For example, it can indicate the purpose for which the TF, which can be used as an ICF in DPS, IDC, DSP, multi-AP coordination, is sent and / or which response frame it solicits. In this case, bit 0 or value 0 can indicate that the receiving device responds with a QoS null frame / data frame (e.g., including the A-Control field). Bit 1 or value 1 can indicate that the receiving device responds with a block acknowledgment (BA) frame (e.g., multi-STA BA). Bit 2 or value 2 can indicate that the receiving device responds with an action frame (e.g., including the A-Control field). Bit 3 or value 3 can be reserved. More bits can be used depending on the solicitation type / method, and bitmaps can be utilized.

[0248] Alternatively or additionally, reserved bits in the user information field may be used in the response type field.

[0249] Alternatively or additionally, one or more user information fields with the same AID may exist, and additional user information fields may include bits / fields for indicating the response type.

[0250] Additionally or alternatively, special user information fields can be used in response type fields.

[0251] Alternatively or additionally, the response type field may utilize EHT reserved bits (7 bits) and may be integrated with the ICF type field for one or more operations, such as DPS, IDC, DSO, multi-AP coordination, and / or soliciting Initial Control Response (ICR) information. For example, each of the 7 bits may indicate a specific type (e.g., DPS, IDC, DSO, MAP). Combinations of each bit (e.g., bitmaps) may be configured to solicit ICR information. For example, with B56: MAP, B57: DPS, B58: IDC, B59: DSO (or Non-Master Channel Access (NPCA)), and other bits: reserved, 1100 may solicit ICR information for MAP and DPS.

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

[0253] In some implementations, the general response field may allow multiple STA BA (or compressed BA) frames, action frames, and / or QoS empty frames / data frames (including a new A-Control field or one or more A-Control fields) to be sent as a response to the underlying TF.

[0254] In some implementations, the general response field may allow multiple STA BA (or compressed BA) frames, action frames, and / or QoS empty frames / data frames (including a new A-Control field or one or more A-Control fields) to be sent as a response to the BSRP TF.

[0255] In some implementations, the general response field may allow multiple STA BA (or compressed BA) frames, action frames, and / or QoS empty frames / data frames (including a new A-Control field or one or more A-Control fields) to be sent as a response to the MU-RTS (TXS) TF.

[0256] In some implementations, the general response field may allow multiple STA BA (or compressed BA) frames, action frames, and / or QoS empty frames / data frames (including a new A-Control field or one or more A-Control fields) to be sent as a response to a (MU-)BAR trigger frame.

[0257] For example, bit 0 in the General Response field can indicate that a general response to the receiving device is not allowed. Bit 1 in the General Response field can indicate that a general response to the receiving device is allowed.

[0258] - Coordination-related information: Fields that may exist selectively based on the values ​​of the ICF type / MAP coordination type field, and include information / signaling bits that need to be indicated according to the ICF type, and / or include common information for multi-AP coordination or information for a specific coordination scheme.

[0259] In some implementations, the coordination-related information field may include / indicate public information necessary for a particular MAP coordination scheme and / or Co-TDMA operation.

[0260] For example, coordination-related information fields may include information for the nominal TXOP duration, which is the period during which APs participating in a Co-TDMA operation coordinate with each other to perform individual FEs and / or TXOP sharing / returning (e.g., the nominal TXOP duration scheduled by SAP for a Co-TDMA operation). The nominal TXOP duration may refer to "scheduled TXOP duration" as described below.

[0261] For example, coordination-related information fields may include information about the channels and / or bandwidths that SAP is operating (e.g., primary channel, punched channel, BSS operation channel width, maximum bandwidth). Operation channel and / or bandwidth information may include at least one of the "operation channel" information or "operation bandwidth" information hereinafter.

[0262] In some implementations, the coordination-related information field may include / indicate coordination-specific or user-specific information necessary for a particular MAP coordination scheme and / or Co-TDMA operation.

[0263] For example, the coordination-related information field may include information about the expected and / or scheduled TXOP sharing time by SAP. TXOP sharing time may refer to "expected TXOP sharing time" below.

[0264] For example, the coordination-related information field may include notifications to SAP that one or more TXOP-shared signaling bits can be executed throughout the entire TXOP duration obtained by SAP.

[0265] In some implementations, the coordination-related information fields may include the BSS operating channel width and the index information of the primary / secondary channels recommended by the SAP to the DAP scheduled for TXOP sharing in order to increase efficiency in Co-TDMA-based transmissions.

[0266] In some implementations, the TF / coordination-related information fields sent during the multi-AP selection process may also include at least one of the following A to I, and are not limited thereto. Furthermore, the specific naming (name) of the fields may be changed.

[0267] For example, the TF / coordination-related information fields sent during the multi-AP selection process may include "A. Multi-AP Group ID" below to provide group ID information to the corresponding DAP. Additionally, the TF / coordination-related information fields sent during the multi-AP selection process may include "B. Multi-AP ID" below to allow each DAP to identify that the information is for itself.

[0268] For example, the TF / coordination-related information field sent during the multi-AP selection process may include “H. Low-latency service information” below to provide the corresponding DAP with Service Identifier (TID) / Access Class (AC) information and / or Flow Classification Service (SCS) information for low-latency services.

[0269] For example, the TF / coordination-related information fields sent during the multi-AP selection process may include “I. Coordination Priority” below to indicate the priority of the currently applied coordination scheme in the multi-AP coordination scheme, and / or indicate the priority / protection level for efficient operation of Co-TDMA transmission.

[0270] Alternatively or additionally, the coordination-related information field may include at least one of the MAP coordination type field, the multiple AP selection field, or the response type field, or may include the corresponding bits.

[0271] The MAP TF transmitted during the multi-AP selection process may also include at least one of the following A to I. The naming (name) of the following A to I may be changed and is not limited thereto. In addition, at least one of the following A to I may also be included in various trigger frames of the multi-AP selection process (e.g., MAP-RTS trigger frame, MU-RTS (TXS) trigger frame, BSRP trigger frame).

[0272] In addition, one or more (additional) user information fields with the same AID may exist in the MAP TF, and the (additional) user information fields may include at least one of the following A to I.

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

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

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

[0276] D. Operation Channel: Operation main channel and punch channel information.

[0277] For example, operational channel information may include channel information that is used by APs to operate together for smooth coordination in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

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

[0279] For example, operational channel information may include puncturing channel information for APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, a new field can be defined as a disabled sub-channel bitmap field in the EHT operational information field to use a bitmap to indicate punctured 20 MHz sub-channels. When a bit value in the bitmap is 0, it can indicate that the corresponding 20 MHz sub-channel is not punctured. When a bit value in the bitmap is 1, it can indicate that the corresponding 20 MHz sub-channel is punctured.

[0280] For example, operational channel information may include information about the DAP's primary channel within the channel operated by SAP.

[0281] For example, operational channel information may include information about the DAP's main channel within the operational channel excluding SAP's punched channels.

[0282] E. Operational bandwidth information: Operational bandwidth and maximum bandwidth information.

[0283] For example, operational bandwidth information may include bandwidth (BW) information shared by APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX) for smooth coordination. In some implementations, the aforementioned operational channel and primary channel information may be utilized.

[0284] For example, operational bandwidth information may include the maximum bandwidth information of the APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, a new field can be defined in the control field of the EHT operational information field to indicate the channel width, which is the BSS BW information of each AP, as follows: - Setting to 0: Indicates a bandwidth of 20 MHz - Set to 1: Indicates a 40 MHz bandwidth - Set to 2: Indicates 80 MHz bandwidth - Set to 3: Indicates 160 / 80+80 MHz bandwidth - Set to 4: Indicates 320 / 160+160 MHz bandwidth - The remaining values ​​from 5 to 7 can be retained.

[0285] For example, operational bandwidth information may include information from the BW field in the SIG-A field.

[0286] For example, operational bandwidth information may include information from the UL BW field included in the public information field of the MU-RTS TXS TF.

[0287] For example, operational bandwidth information can include information about the bandwidth of the DAP within the entire bandwidth of SAP operations.

[0288] For example, by changing / redefining the media time field of a QoS characteristic element to include a new subfield, a new field for bandwidth indication (i.e., operational bandwidth information) can be added. In some implementations, a new field can be defined in the control field of the EHT operational information field to indicate the channel width, which is the BSS BW information for each AP, as follows: - Setting to 0: Indicates a bandwidth of 20 MHz - Set to 1: Indicates a 40 MHz bandwidth - Set to 2: Indicates 80 MHz bandwidth - Set to 3: Indicates 160 / 80+80 MHz bandwidth - Set to 4: Indicates 320 / 160+160 MHz bandwidth - The remaining values ​​from 5 to 7 can be retained.

[0289] F. Scheduled TXOP duration: The duration during which APs participating in a multi-AP operation / Co-TDMA operation coordinate with each other to execute individual FEs and / or TXOPs, and / or the nominal TXOP duration scheduled by SAP for the multi-AP operation / Co-TDMA operation.

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

[0291] For example, the scheduled TXOP duration can be included in a QoS feature element that can be used to include negotiation / coordination information during the pre-negotiation process of multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX), or it can be included in an element that can be newly defined for negotiation of multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

[0292] For example, the scheduled TXOP duration can be included in a UHR operation element that can be used to include broadcast information during the broadcast process of each AP in a multi-AP operation (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX), or it can be included in a newly defined element for broadcasting of multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

[0293] G. Expected TXOP sharing timing: The time when SAP expects and / or schedules TXOP sharing.

[0294] In some implementations, a new field may be defined that includes the expected TXOP sharing timing. For example, the expected TXOP sharing timing field may be newly defined to indicate information necessary for Co-TDMA operation and / or the expected TXOP sharing timing value.

[0295] In some implementations, new elements may be defined that include the expected TXOP sharing timing. For example, a new C-TDMA operation element may be defined to indicate the information necessary for Co-TDMA operation and / or the expected TXOP sharing timing value.

[0296] H. Low-latency service information: Information related to the low-latency services that each AP intends to send and receive.

[0297] For example, low-latency service information can be included in the QoS characteristic elements included in the SCS request / response frame.

[0298] For example, information from the delay threshold field in the QoS feature element information can be utilized. In some implementations, the delay threshold field value of the QoS service that each AP intends to send can be used as low-latency service information. In this way, for DAPs capable of completing the transmission of MSDU or A-MSDU within the time limit of the TXOP to be shared (i.e., the pre-negotiated low-latency service information or delay threshold field value is shorter than the allocated time), SAP can use it to check whether TXOP sharing or updating of existing values ​​is necessary.

[0299] For example, information from the MSDU lifetime field within the QoS feature element information can be utilized. In some implementations, the MSDU lifetime field value of the QoS service that each AP intends to send can be used as low-latency service information. In this way, for DAPs that do not discard MSDUs within the duration of the TXOP to be shared (i.e., the pre-negotiated low-latency service information or MSDU lifetime field value has not expired within the allocated time), SAP can use it to check whether TXOP sharing or updating of existing values ​​is necessary.

[0300] For example, information from the Service Start Time field in the QoS feature element information can be utilized. In some implementations, the Service Start Time field value of the QoS service that each AP intends to send can be used as low-latency service information. In this way, for DAPs capable of initiating the expected service period and frame exchange within the timeframe of the end of the TXOP to be shared (i.e., the pre-negotiated low-latency service information or Service Start Time field value is shorter than the allocated time), the SAP can use it to check whether TXOP sharing or updating of existing values ​​is necessary.

[0301] For example, low-latency service information may include TXOP sharing request information requested / instructed by an AP that requires low-latency service transmission.

[0302] For example, low-latency service information may include time limit information for low-latency services requested / indicated by an AP that requires low-latency service transmission (e.g., the minimum time limit for initiating low-latency service transmission / the maximum time limit for successfully completing low-latency service transmission).

[0303] For example, low-latency service information may include arrival rate information of low-latency services requested / indicated by an AP that requires periodic low-latency service transmission (e.g., the arrival rate of low-latency services since the last reported event).

[0304] For example, low-latency service information may include service identifier (TID) / access class (AC) information.

[0305] I. Coordination Priority: Indicates the priority of the currently used coordination scheme in the multi-AP coordination scheme, and / or indicates the priority / protection level for efficient Co-TDMA operation.

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

[0307] SAP can replace the AID12 field in the User Information field of the MAP TF with an ID associated with multi-AP coordination to select a DAP. That is, the AID12 field can include the APID used to identify the AP participating in multi-AP coordination (or included in a multi-AP set). The ID associated with multi-AP coordination can include at least one of the target DAP's BSSID, BSS color, multi-AP group ID (i.e., the ID of the set / group of APs participating in multi-AP coordination), or DAP ID (i.e., the ID granted by SAP within the multi-AP set / group). Alternatively, when the MAP TF is associated with a single DAP, the RA field of the MAP TF can include the MAC address of the target DAP.

[0308] Therefore, an AP that has received a MAP TF of a new trigger type can decode the MAP TF to identify the multi-AP coordination type. Alternatively, when an AP receives a MAP TF in which the AID12 field within the user information field includes its own associated ID, or where the RA field is set to its own MAC address, the AP can identify that the MAP TF is for Co-TDMA / multi-AP coordination and can decode / obtain additional information based on the indicated multi-AP coordination type. Subsequently, the DAP can send a TB PPDU to the SAP based on the information obtained from the TF.

[0309] Additionally or alternatively, the information included in the public information fields / user information fields within the aforementioned MAP TF may be included in one or more special user information fields and may be delivered from SAP through the special user information fields.

[0310] The multi-AP selection response frame included in the TB PPDU sent by the DAP during the multi-AP selection process may include at least one of the following a to j. The naming (name) of the following a to j may be changed and is not limited thereto.

[0311] a. Multi-AP Group ID: The ID of the group / set of APs configured for multi-AP coordination (e.g., 0, 1, 2, ...).

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

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

[0314] d. Operation Channel: Operation main channel and puncturing channel information.

[0315] For example, operational channel information may include channel information that is used by APs to operate together for smooth coordination in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

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

[0317] For example, operational channel information may include puncturing channel information for APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, a new field can be defined as a disabled sub-channel bitmap field in the EHT operational information field to use a bitmap to indicate punctured 20 MHz sub-channels. When a bit value in the bitmap is 0, it can indicate that the corresponding 20 MHz sub-channel is not punctured. When a bit value in the bitmap is 1, it can indicate that the corresponding 20 MHz sub-channel is punctured.

[0318] For example, operational channel information may include information about the DAP's primary channel within the channel operated by SAP.

[0319] For example, operational channel information may include information about the DAP's main channel within the operational channel excluding SAP's punched channels.

[0320] e. Operational bandwidth information: Operational bandwidth and maximum bandwidth information.

[0321] For example, operational bandwidth information may include bandwidth (BW) information shared by APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX) for smooth coordination. In some implementations, the aforementioned operational channel and primary channel information may be utilized.

[0322] For example, operational bandwidth information may include the maximum bandwidth information of the APs participating in multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX). In some implementations, a new field can be defined in the control field of the EHT operational information field to indicate the channel width, which is the BSS BW information of each AP, as follows: - Setting to 0: Indicates a bandwidth of 20 MHz - Set to 1: Indicates a 40 MHz bandwidth - Set to 2: Indicates 80 MHz bandwidth - Set to 3: Indicates 160 / 80+80 MHz bandwidth - Set to 4: Indicates 320 / 160+160 MHz bandwidth - The remaining values ​​from 5 to 7 can be retained.

[0323] For example, operational bandwidth information may include the BW field information in the SIG-A field.

[0324] For example, operational bandwidth information may include UL BW field information included in the public information field of MU-RTS TXS TF.

[0325] For example, operational bandwidth information can include information about the bandwidth of the DAP within the entire bandwidth of SAP operations.

[0326] For example, by changing / redefining the media time field of a QoS characteristic element to include a new subfield, a new field for bandwidth indication (i.e., operational bandwidth information) can be added. In some implementations, a new field can be defined in the control field of the EHT operational information field to indicate the channel width, which is the BSS BW information for each AP, as follows: - Setting to 0: Indicates a bandwidth of 20 MHz - Set to 1: Indicates a 40 MHz bandwidth - Set to 2: Indicates 80 MHz bandwidth - Set to 3: Indicates 160 / 80+80 MHz bandwidth - Set to 4: Indicates 320 / 160+160 MHz bandwidth - The remaining values ​​from 5 to 7 can be retained.

[0327] f. Required TXOP duration: Information related to the duration of TXOPs that each AP expects to be shared.

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

[0329] For example, the required TXOP duration can be included in a QoS feature element that can be used to include negotiation / coordination information during the pre-negotiation process of multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX), or in an element that can be newly defined for negotiation of multi-AP operations (e.g., Co-TDMA, Co-OFDMA, Co-SR, Co-BF, AP selection, J-TX).

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

[0331] g. Buffer Status: Buffer status information for each AP

[0332] h. TXOP Sharing Requirement: Indicates whether TXOP sharing is required as the pre-negotiated low-latency service information expires and / or TXOP sharing becomes unnecessary (e.g., when an individual FE has been performed). For example, one bit can be used to indicate / respond to whether TXOP sharing is required. Bit 0 can indicate that a DAP that has received a select request frame does not need TXOP sharing. Bit 1 can indicate that a DAP that has received a select request frame needs TXOP sharing.

[0333] Additional or alternative land can indicate whether TXOP sharing is required by setting all specific fields to 0.

[0334] i. Low-latency service information: Information related to the low-latency services that each AP intends to send and receive.

[0335] For example, low-latency service information can be included in the QoS feature elements in the SCS request / response frame.

[0336] For example, the delay threshold field information in the QoS feature element information can be utilized. In some implementations, the delay threshold field value of the QoS service that each AP intends to send can be used as low-latency service information. When there are changes compared to the pre-negotiated low-latency service information, updated low-latency service information / delay threshold field values ​​can be included.

[0337] For example, the MSDU lifetime field information in the QoS feature element information can be utilized. In some implementations, the MSDU lifetime field value of the QoS service that each AP intends to send can be used as low-latency service information. When there are changes compared to the pre-negotiated low-latency service information, updated low-latency service information / MSDU lifetime field values ​​can be included.

[0338] For example, the service initiation time field information in the QoS feature element information can be utilized. In some implementations, the service start time field value of the QoS service that each AP intends to send can be used as low-latency service information. When there are changes compared to the pre-negotiated low-latency service information, updated low-latency service information / service start time field values ​​can be included.

[0339] For example, low-latency service information may include TXOP sharing request information requested / indicated by an AP that requires low-latency service transmission.

[0340] For example, low-latency service information may include time limit information for low-latency services requested / indicated by the AP that requires low-latency service transmission (e.g., the minimum time limit for initiating low-latency service transmission / the maximum time limit for successfully completing low-latency service transmission).

[0341] For example, low-latency service information may include arrival rate information of low-latency services requested / indicated by an AP that requires periodic low-latency service transmission (e.g., the arrival rate of low-latency services since the last reported event).

[0342] For example, low-latency service information may include service identifier (TID) / access class (AC) information.

[0343] j. Status code: Accept / reject / recommendation information for the selection request (i.e., SAP can accept / reject the selection request based on whether DAP currently needs TXOP sharing, and this acceptance / rejection indication can replace the above TXOP sharing requirement information).

[0344] For example, a status code can indicate acceptance or success.

[0345] For example, a status code may indicate rejection, or it may include recommendation information while indicating rejection. In some implementations, the status code may include a rejection code containing a reason for rejection (e.g., REJECTED_BAD_SUPPORTED_CHANNELS). In some implementations, the status code may include a rejection code containing recommendation information (e.g., REJECTED_WITH_SUGGESTED_CHANGES). If the value of the status code includes rejection and / or recommendation information, it may also include information for a new selection request. That is, a DAP that has received a selection request frame may include the aforementioned operating channel, bandwidth, required TXOP duration, low-latency service information, and / or additional information for UHR STA support in a multi-AP selection response frame.

[0346] II-2. Multi-AP RTS (MAP-RTS) Trigger Frames

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

[0348] Figure 22 An example of the MAP-RTS trigger frame format used in the multi-AP selection process is illustrated.

[0349] refer to Figure 22 The MAP-RTS trigger frame may include a common information field and a user information field, and the diagram illustrates the fields included in the common information field / user information field and the number of bits for each field. The naming (name) and / or number of bits for the fields can be changed and are not limited to this. Furthermore, the MAP-RTS trigger frame may include one or more fields.

[0350] The common information field / user information field of the MAP-RTS trigger frame may include at least one of the following fields: - ICF type: can indicate the same information as that included in the MAP trigger frame.

[0351] - MAP Coordination Type: This can indicate the same information included in the MAP trigger frame. Alternatively or additionally, the MAP Coordination Type field can be defined as some bits and / or subfields of the Coordination-Related Information-2 field.

[0352] - Multiple AP Selection (or Multiple AP Procedure): This field can indicate the same information included in the MAP trigger frame. Alternatively or concurrently, the Multiple AP Selection (or Multiple AP Procedure) field can be defined as some bits and / or subfields of the Coordinated Related Information-2 field.

[0353] - Response type: Indicates the type of response frame for the sent TF and / or the type of information requested from the receiving device.

[0354] In some implementations... Figure 22 One or more type-related signaling bits illustrated can be used in the response type field.

[0355] In some implementations... Figure 22 Some bits of the Coordination-Related Information field in the Public Information field illustrated can be used in the Response Type field, and / or some bits of the Coordination-Related Information-2 field in the User Information field can be used in the Response Type field. For example, it can indicate the purpose for which the TF, which can be used as an ICF in DPS, IDC, DSP, multi-AP coordination, is sent and / or which response frame it solicits. In this case, bit 0 can indicate that the receiving device responds with a CTS frame (or a CTS-to-Self frame). Bit 1 can indicate that the receiving device responds with a QoS empty frame / data frame (e.g., including the A-Control field). Bit 2 can indicate that the receiving device responds with a BA (Block Acknowledgment) frame (e.g., multi-STA BA). Bit 3 can indicate that the receiving device responds with an action frame (e.g., including the A-Control field). Bit 3 can be reserved. More bits can be used depending on the solicitation type / method, and bitmaps can be utilized.

[0356] Alternatively or additionally, reserved bits in the user information field may be used in the response type field.

[0357] Alternatively or additionally, one or more user information fields with the same AID may exist, and additional user information fields may include bits / fields for indicating the response type.

[0358] Additionally or alternatively, special user information fields can be used in response type fields.

[0359] - General response: can indicate the same information as that included in the MAP trigger frame.

[0360] - Coordination-related information: This can indicate the same information included in the MAP trigger frame. Alternatively or additionally, user-specific information related to coordination-related information can be indicated by utilizing the Coordination-related Information-2 field in the User Information field.

[0361] The MAP-RTS TF sent during the multiple AP selection process may also include at least one of A to I mentioned above.

[0362] SAP can replace the AID12 field in the User Information field of the MAP-RTS TF with an ID associated with multi-AP coordination to select a DAP. That is, the AID12 field can include the AP ID used to identify the AP participating in multi-AP coordination (or included in a multi-AP set). The ID associated with multi-AP coordination can include at least one of the target DAP's BSSID, BSS color, multi-AP group ID (i.e., the ID of the set / group of APs participating in multi-AP coordination), or DAP ID (i.e., the ID granted by SAP within the multi-AP set / group). Alternatively, when the MAP-RTS TF is associated with a single DAP, the RA field of the MAP-RTS TF can include the MAC address of the target DAP.

[0363] Therefore, an AP that has received a MAP-RTS TF of a new trigger type can decode the MAP-RTS TF to identify the multi-AP coordination type. Alternatively, when an AP receives a MAP-RTS TF in which the AID12 field within the user information field includes its own associated ID, or where the RA field is set to its own MAC address, the AP can identify that the MAP-RTS TF is for C-TDMA / multi-AP coordination and can decode / obtain additional information according to the indicated multi-AP coordination type. Subsequently, the DAP can send a CTS frame (or CTS-to-Self) frame to the SAP based on the information obtained from the TF.

[0364] Additionally or alternatively, the information included in the public information fields / user information fields within the aforementioned MAP-RTS TF may be included in one or more special user information fields and may be delivered from SAP through the special user information fields.

[0365] In the multi-AP selection process based on MAP-RTS trigger frames, sending a CTS frame (or a frame indicated by the response type) can signify a response to a TF sent by SAP and / or acceptance of the multi-AP selection process. That is, if a CTS frame (or the corresponding response frame) is not received from the DAP, SAP can consider the multi-AP selection process to have failed.

[0366] II. Using MU-RTS TXS to trigger frames

[0367] To design trigger frames that can be sent during the multi-AP selection process in multi-AP operation / Co-TDMA operation and / or that can be regarded as the initial control frame for initiating multi-AP operation during a separate multi-AP coordination process, the MU-RTS TXS TF used in the triggering TXOP sharing protocol of EHT can be utilized.

[0368] In some implementations, the multi-AP selection process can be initiated by sending a MU-RTS TXS TF based on the triggered TXOP sharing mode (i.e., mode 1 or 2) illustrated in Table 2. Similar to how STAs allocated time in TXS mode = 1 or 2 are allowed to deliver MPDUs to their associated APs, DAPs can deliver MPDUs to SAPs that have sent the MU-RTS TXS TF. For this purpose, the MU-RTS TXS trigger frame may need to be sent between unassociated STAs (i.e., between APs).

[0369] The MU-RTS TXS TF based on TXS mode can be defined / designed according to the following options: Option 1) The MU-RTS TXS TF for the multi-AP selection process is based on TXS mode = 1 or 2 as defined in the EHT, and (new) fields related to multi-AP coordination / Co-TDMA-based transmissions can be added separately to the MU-RTS TXS TF for signaling in the multi-AP selection process.

[0370] Figure 23 An example of a MU-RTS TXS trigger frame format for a multi-AP selection process according to an embodiment of the present disclosure is illustrated.

[0371] refer to Figure 23 The MU-RTS TXS TF may include a public information field / user information field based on option 1), and the diagram illustrates the fields included in the public information field / user information field and the number of bits for each field. The naming (name) and / or number of bits for the fields may be changed, and are not limited to this. Furthermore, the MU-RTS TXS trigger frame may also include one or more fields.

[0372] The common information field / user information field of the MU-RTS TXS trigger frame may include at least one of the following fields: - ICF Type: Can indicate the same information included in the MAP trigger frame. Alternatively or concurrently, the ICF type field can be defined using some of the 12 bits following the trigger type field.

[0373] - MAP Coordination Type: This can indicate the same information included in the MAP trigger frame. Alternatively or additionally, the MAP coordination type field can be defined using some of the 12 bits following the trigger type field. Alternatively or additionally, the MAP coordination type field can be defined using reserved bits (32 bits or more). Alternatively or additionally, the MAP coordination type field can be included in a user information field or a special user information field.

[0374] - Multiple AP Selection (or Multiple AP Procedure): This field can indicate the same information included in the MAP trigger frame. Alternatively or additionally, the Multiple AP Selection (or Multiple AP Procedure) field can be defined using some of the 12 bits following the trigger type field. Alternatively or additionally, the Multiple AP Selection (or Multiple AP Procedure) field can be defined using reserved bits (32 bits or more). Alternatively or additionally, the Multiple AP Selection (or Multiple AP Procedure) field can be defined using some bits from the Coordination Related Information-2 field, or it can be defined as a subfield of the Coordination Related Information-2 field.

[0375] - Response type: Indicates the type of response frame for the sent TF and / or the type of information requested from the receiving device.

[0376] In some implementations, the response type field can be used Figure 23 The trigger type field shown in the diagram is defined by some of the 12 bits following it.

[0377] In some implementations, the response type field can be utilized Figure 23 The reserved bits (32 bits) following the TXS mode field in the illustrated public information field are defined, or by utilizing some bits of the coordination-related information-2 field in the user information field. For example, it can indicate the purpose for which the TF, which can be used as an ICF in DPS, IDC, DSP, multi-AP coordination, is sent and / or which response frame it solicits. In this case, bit 0 can indicate that the receiving device responds with a CTS frame (or a CTS-to-Self frame). Bit 1 can indicate that the receiving device responds with a QoS empty frame / data frame (e.g., including the A-Control field). Bit 2 can indicate that the receiving device responds with a BA (Block Acknowledgment) frame (e.g., multi-STA BA). Bit 3 can indicate that the receiving device responds with an action frame (e.g., including the A-Control field). Bit 3 can be reserved. More bits can be used depending on the solicitation type / method, and a bitmap can be utilized.

[0378] Alternatively or additionally, one or more user information fields with the same AID may exist, and additional user information fields may include bits / fields for indicating the response type.

[0379] Additionally or alternatively, special user information fields can be used in response type fields.

[0380] - General response: can indicate the same information as that included in the MAP trigger frame.

[0381] - Coordination-related information: This can indicate the same information included in the MAP trigger frame. Alternatively or additionally, user-specific information related to coordination-related information can be indicated by appending the Coordination-related Information-2 field in the User Information field.

[0382] The MU-RTS TXS TF sent during the multi-AP selection process may also include at least one of the contents and / or fields from A to I above (e.g., multi-AP group ID, scheduled TXOP duration). For example, at least one of the contents and / or fields from A to I above (e.g., multi-AP group ID, scheduled TXOP duration) may be included in reserved bits (or EHT reserved bits) of the common information field, reserved bits of the user information field, one or more other user information fields with the same AID value, and / or special user information fields with the same AID value or a specific AID value. The specific naming (name) of the above fields may be changed.

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

[0384] For example, a new coding method for transmission based on multi-AP coordination / Co-TDMA can be defined as shown in Table 3 below: Table 3

[0385] In addition to the TXS mode as in Option 2) (i.e., TXS mode for multi-AP selection = 1), the MU-RTS TXS trigger frame may include fields indicating a multi-AP coordination scheme (e.g., Co-OFDMA, Co-TDMA, Co-BF, Co-SR), and may include information included in the MU-RTS TXS trigger frame (e.g., multi-AP coordination type, coordination-related information) separately by utilizing reserved fields. That is, at least one of the contents and / or fields of A to I above (e.g., multi-AP coordination type, coordination-related information) may be added to and / or defined in the MU-RTS TXS TF transmitted during the multi-AP selection process, and is not limited thereto. Furthermore, the specific naming (name) of the fields included in the MU-RTS TXS TF may be changed. In addition, reserved bits (i.e., TXS mode = 3) may indicate another multi-AP coordination scheme and may be used to indicate another process in Co-TDMA operation (e.g., TXOP return). Alternatively, unlike the 2-bit encoding scheme presented in Table 3, the TXS mode field can be defined (extended) by utilizing some of the reserved bits following the TXS mode field (bits). That is, the TXS mode for UHR can be redefined using 3 or more bits.

[0386] Additionally or alternatively, the new TXS mode for UHR can be used to differentiate ICF types. For example, it can be defined as TXS mode=1: Multi-AP Coordination, TXS mode=2: DPS, TXS mode=3: IDC, TXS mode=4: DSO.

[0387] Additionally or alternatively, a new TXS mode for UHR can be used to distinguish MAP coordination types. For example, it can be defined as TXS mode = 1: Co-TDMA, TXS mode = 2: Co-SR, TXS mode = 3: Co-BF.

[0388] Additionally or alternatively, the new TXS mode for UHR can be used to indicate multiple AP selection (or multiple AP procedure). For example, it can be defined as TXS mode=1: multiple AP selection, TXS mode=2: TXOP sharing, TXS mode=3: TXOP return.

[0389] Additionally or alternatively, the reserved values ​​in the TXS modes presented in Table 2 can be used to indicate multi-AP operation (or multi-AP selection or multi-AP procedure). For example, it can be defined as TXS mode=1: UL transmission only, TXS mode=2: UL transmission and P2P transmission are allowed, and TXS mode=3: for multi-AP purposes.

[0390] SAP can replace the AID12 field in the User Information field of the MU-RTS TXS TF with an ID associated with multi-AP coordination to select a DAP. That is, the AID12 field can include the AP ID used to identify the AP participating in multi-AP coordination (or included in a multi-AP set). The ID associated with multi-AP coordination can include at least one of the target DAP's BSSID, BSS color, multi-AP group ID (i.e., the ID of the set / group of APs participating in multi-AP coordination), or DAP ID (i.e., the ID granted by SAP within the multi-AP set / group). Alternatively, when the MU-RTS TXS TF is associated with a single DAP, the RA field of the MU-RTS TXS TF can include the MAC address of the target DAP.

[0391] Therefore, an AP that has received a MU-RTS TXS TF based on option 1) and / or option 2) can decode the MU-RTS TXS TF to identify that the MU-RTS TXS TF was sent for a multi-AP selection process. Alternatively, when an AP receives a MU-RTS TXS TF in which the AID12 field within the user information field includes its own associated ID, or in which the RA field is set to its own MAC address, the AP can identify that the MU-RTS TXS TF is for Co-TDMA / multi-AP coordination and can decode / obtain additional information according to the indicated multi-AP coordination type. Subsequently, the DAP can send a CTS frame (or CTS-to-Self) frame to the SAP based on the information obtained from the TF. Alternatively, the DAP can respond with a response frame solicited by the MU-RTS TXS TF.

[0392] Additionally or alternatively, the information included in the public information fields / user information fields within the aforementioned MU-RTS TXS TF may be included in one or more special user information fields and may be delivered from SAP through the special user information fields.

[0393] In the multi-AP selection process based on the MU-RTS TXS trigger frame, sending a CTS frame (or the corresponding response frame) can signify a response to the TF sent by the SAP and / or acceptance of the multi-AP selection process. That is, if a CTS frame (or the corresponding response frame) is not received from the DAP, the SAP can consider the multi-AP selection process to have failed.

[0394] III. Using BSRP to trigger frames

[0395] To design trigger frames that can be sent during multi-AP selection in multi-AP operation / Co-TDMA operation and / or that can be considered as initial control frames initiating multi-AP operation during separate multi-AP coordination processes, Buffer Status Report Polling (BSRP) trigger frames, a variant of trigger frames, can be utilized. For this purpose, BSRP trigger frames may need to be sent between unassociated STAs (i.e., between APs).

[0396] Figure 24 An example of a BSRP trigger frame format for a multi-AP selection process according to an embodiment of the present disclosure is illustrated.

[0397] The size of the user information field in the BSRP TF may be insufficient to include additional information. Therefore, the common information field of the BSRP TF may include the main field, and other fields may be included in special user information fields. Alternatively or additionally, similar to how the MU-RTS TF is defined and utilized based on the triggered TXOP sharing mode (2 bits) field, the BSRP Initial Control (IC) TF can be defined / utilized based on the GI and HE / EHT-LTF type / triggered TXOP sharing mode fields. In this case, the common information field / user information field of the BSRP IC TF can be redesigned. The field names (naming) and / or bit counts can be changed, and are not limited to this. Furthermore, the BSRP TF may include one or more fields, and is not limited to this.

[0398] The BSRP TF's public information fields / (special) user information fields may include at least one of the following fields: - ICF Type: Can indicate the same information included in the MAP trigger frame. For example, the ICF type field can be defined using some bits from the EHT reserved (7 bits).

[0399] - MAP Coordination Type: This can indicate the same information included in the MAP trigger frame. For example, the MAP coordination type field can be defined using some bits from the EHT reserves (7 bits). Alternatively or concurrently, the MAP coordination type field can be included in a user information field or a special user information field.

[0400] - Response type: Indicates the type of response frame for the sent TF and / or the type of information requested from the receiving device.

[0401] In some implementations, the response type field can be utilized Figure 24The EHT shown in the diagram uses some reserved bits for definition. For example, it can indicate the purpose for which a TF (Transaction Forwarder) used as an ICF (Integrated Function) in DPS, IDC, DSP, or multi-AP coordination is sent and / or which response frame it solicits. In this case, bit 0 can indicate that the receiving device responds with a QoS empty frame / data frame (e.g., including the A-Control field). Bit 1 can indicate that the receiving device responds with a Block Acknowledgment (BA) frame (e.g., multi-STA BA). Bit 2 can indicate that the receiving device responds with an action frame (e.g., including the A-Control field). More bits can be used depending on the solicitation type / method, and bitmaps can be utilized.

[0402] Alternatively or additionally, one or more user information fields with the same AID may exist, and additional user information fields may include bits / fields for indicating the response type.

[0403] Additionally or alternatively, special user information fields can be used in response type fields.

[0404] - Multiple AP ID or AP ID: An ID (e.g., 0, 1, 2, ...) granted locally from each AP within the configured multiple AP set / group. For example, the corresponding multiple AP ID or AP ID can be included in the AID12 field within the user information field of the trigger frame.

[0405] To include additional multi-AP coordination-related information, new special user information fields for UHR can be defined / included within the BSRP TF. Additionally or alternatively, the aforementioned ICF type, MAP coordination type, and response type fields can also be included in the new special user information fields for UHR.

[0406] For this purpose, one bit from the EHT reserved bits (7 bits) can be used to define a new UHR Special User Information Field Flag (or UHR Function Control Indicator) field, and the value of the UHR Special User Information Field Flag can be set to 1. Alternatively or additionally, the reserved bits (1 bit) in the user information field can indicate, in a user-specific manner, whether a newly defined UHR Special User Information Field exists for multi-AP coordination and / or according to the operation type indicated by the ICF type field (i.e., the UHR Special User Information Field Flag can be defined using the reserved bits in the user information field). The UHR Special User Information Field Flag can be defined and / or included to indicate whether a UHR Special User Information Field with additional information exists.

[0407] Therefore, in order to include at least one of the information A through I for multi-AP coordination operations and / or the additional fields mentioned in this disclosure (e.g., coordination-related information fields), the indicator value of the AID12 field within the UHR special user information field can be redefined (e.g., AID = 2007 for the special user information field). In the EHT, the special user information field can be identified by the AID12 field value 2007. Similar to the definition of the special user information field in the EHT, separate UHR special user information fields (e.g., UHR special user information fields) can be defined to include additional information based on multi-AP operations and / or various ICF types. To indicate that the corresponding UHR special user information field is a new special user information field in the UHR, the value of the AID12 field can be set to a reserved value (e.g., a value from 2008 to 2044 or a value from 2047 to 4094). The UHR special user information field identified by the new AID12 value can be placed after the public information field, after the user information field, or after the (EHT) special user information field. Additionally or alternatively, UHR special user information fields can be placed before or after the corresponding user's user information fields.

[0408] Figure 25 The illustration shows a first example of a UHR special user information field according to an embodiment of the present disclosure.

[0409] refer to Figure 25 Some fields (e.g., ICF type, MAP coordination type, response type) can be indicated by using the EHT reserved fields in the public information fields, and the remaining additional information (e.g., coordination-related information) can be included in the UHR special user information fields.

[0410] Figure 26 A second example of a UHR special user information field according to an embodiment of the present disclosure is illustrated.

[0411] refer to Figure 26 One bit of the EHT reserved field in the public information field can indicate whether the UHR special user information field exists, and the relevant field can be included in the UHR special user information field.

[0412] The coordination-related information fields may include at least one of the contents of A to I above and / or the additional fields mentioned in this disclosure.

[0413] Alternatively or additionally, one or more user information fields may exist with the same AID12 field value, and subsequent user information fields with the same AID12 field value arranged consecutively or non-consecutively may include user-specific additional information according to the ICF type.

[0414] The technical features of this disclosure described above can be applied to various devices and methods. For example, the technical features of this disclosure described above can be used by... Figure 1 and / or Figure 5 The device execution / support. For example, the technical features of this disclosure described above can be applied only to... Figure 1 and / or Figure 5 Part of it. For example, the technical features of the present disclosure described above can be based on Figure 1 The processing chips 114 and 124 are used to implement this, or based on... Figure 1 Implemented by processors 111, 121 and memories 112, 122, or based on Figure 5 The processor 510 and memory 520 are implemented.

[0415] For example, Figure 1 The processor 121 and / or processing chip 124 may be configured to execute instructions stored in memory 122 to perform operations performed by the first AP in this disclosure. The operations include: performing a negotiation process with neighboring APs for multi-AP coordination; configuring a multi-AP set including neighboring APs based on the negotiation process; sending a selection request frame to a second AP included in the multi-AP set for initiating multi-AP coordination with the second AP; receiving a selection response frame from the second AP in response to the selection request frame; and sending a TXOP shared frame including information for allocating duration to the second AP based on the received selection response frame.

[0416] For example, Figure 1 The processor 111, the processing chip 114 and / or Figure 5 The processor 510 can be configured to execute instructions stored in memories 112, 520 to perform operations performed by the second AP in this disclosure. The operations include: performing a negotiation process with neighboring APs for multi-AP coordination; configuring a multi-AP set including neighboring APs based on the negotiation process; receiving a selection request frame from a first AP included in the multi-AP set for initiating multi-AP coordination with the second AP; sending a selection response frame to the first AP in response to the selection request frame; and receiving a TXOP shared frame from the first AP after sending the selection response frame, including information for allocating duration.

[0417] The technical features of this disclosure can be implemented based on a computer-readable medium (CRM) (e.g., a non-transitory CRM). For example, the CRM in this disclosure may include at least one CRM having program code stored thereon that implements instructions executable by at least one processor.

[0418] For example, CRM can be Figure 1 The memory 122 and / or a separate external memory / storage medium / disk. The CRM can store data based on data generated by a processor (e.g., ...). Figure 1 The processor 121 and / or processing chip 124 executes instructions to perform operations performed by the first AP in this disclosure. The operations include: performing a negotiation process with neighboring APs for multi-AP coordination; configuring a multi-AP set including neighboring APs based on the negotiation process; sending a selection request frame to a second AP included in the multi-AP set for initiating multi-AP coordination with the second AP; receiving a selection response frame from the second AP in response to the selection request frame; and sending a TXOP shared frame including information for allocating duration to the second AP based on the received selection response frame.

[0419] For example, CRM can be Figure 1 memory 112, Figure 5 The CRM can store data based on a processor (e.g., memory 520 and / or a separate external memory / storage medium / disk). Figure 1 The processor 111, the processing chip 114 and / or Figure 5 The processor 510 executes instructions to perform operations performed by the second AP in this disclosure. The operations include: performing a negotiation process with neighboring APs for multi-AP coordination; configuring a multi-AP set including neighboring APs based on the negotiation process; receiving a selection request frame from a first AP included in the multi-AP set for initiating multi-AP coordination with the second AP; sending a selection response frame to the first AP in response to the selection request frame; and, after sending the selection response frame, receiving a TXOP shared frame from the first AP including information for allocating duration.

[0420] The aforementioned technical features disclosed herein can be applied to various applications or business models. For example, the aforementioned technical features can be applied to wireless communication in devices that support artificial intelligence (AI).

[0421] Artificial intelligence (AI) refers to the field of study of AI itself or the methodologies used to create AI, while machine learning refers to the field of study of the methodologies used to define and solve various problems within the field of AI. Machine learning is also defined as algorithms that improve operational performance through stable experience of operations.

[0422] Artificial neural networks (ANNs) are models used in machine learning, and can refer to an overall problem-solving model that includes artificial neurons (nodes) forming a network through the combination of synapses. An artificial neural network can be defined by the connection patterns between neurons in different layers, the learning process that updates model parameters, and the activation function that generates the output values.

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

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

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

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

[0427] Supervised learning refers to the method of training an artificial neural network using labels provided for the training data, where the labels indicate the correct (or resulting) value that the artificial neural network should infer when the training data is input. Unsupervised learning refers to the method of training an artificial neural network without providing labels for the training data. Reinforcement learning refers to the training method used to train an agent defined in an environment to select an action or sequence of actions that maximizes the cumulative reward in each state.

[0428] Machine learning implemented in deep neural networks (DNNs) that include multiple hidden layers in an artificial neural network is called deep learning, and deep learning is a part of machine learning. In the following text, machine learning is interpreted as including deep learning.

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

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

[0431] Robots can be categorized by their purpose or field, such as industrial, medical, household, and military robots. A robot may include actuators or drives including electric motors to perform various physical operations, such as moving robot joints. Furthermore, mobile robots may include wheels, brakes, propellers, etc., within drives to move on the ground or fly in the air via drives.

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

[0433] Extended Reality refers to Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR). VR technology is a computer graphics technology that provides real objects and backgrounds only in CG images; AR technology is a computer graphics technology that provides virtual CG images on top of real object images; and MR technology is a computer graphics technology that provides virtual objects that are mixed and combined with the real world.

[0434] MR technology is similar to AR technology in that real and virtual objects are displayed together. However, in AR technology, virtual objects are used as a supplement to real objects, while in MR technology, virtual and real objects are treated as equals.

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

[0436] This disclosure can have various beneficial effects.

[0437] For example, this disclosure defines the structure / format of a trigger frame sent by SAP in multi-AP operation / C-TDMA operation to select the DAP to perform a multi-AP coordinated transmission. Using trigger frames according to various embodiments of this disclosure, SAP can perform a multi-AP selection process for selecting a DAP.

[0438] The beneficial effects obtainable through the specific embodiments of this disclosure are not limited to those listed above. For example, those skilled in the art can understand and / or derive various technical effects from this disclosure. Therefore, the specific effects of this 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 this disclosure.

[0439] The claims in this disclosure can be combined in various ways. For example, the technical features in the method claims of this disclosure can be combined to be implemented or performed in an apparatus, and the technical features in the apparatus claims can be combined to be implemented or performed in a method. Furthermore, the technical features in the method claims and apparatus claims can be combined to be implemented or performed in an apparatus, and the technical features in the method claims and apparatus claims can be combined to be implemented or performed in a method.

Claims

1. A method comprising: The negotiation process for multi-AP coordination is performed by the first access point (AP) and neighboring APs; Based on the negotiation process, the first AP configures a multi-AP set including the neighboring APs; The first AP sends a selection request frame to the second AP included in the multi-AP set to initiate coordination with the second AP among the multi-AP sets; The first AP receives a selection response frame from the second AP in response to the selection request frame; as well as Based on the received selection response frame, the first AP sends a TXOP shared frame, including information for allocating duration, to the second AP.

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

3. The method according to claim 2, wherein, The identification information of the second AP used for the multi-AP coordination is included in the Association Identifier (AID) 12 field within the user information field of the selection request frame, and The identification information of the second AP includes at least one of the following: the Basic Service Set Identifier (BSSID) of the second AP, the BSS color of the second AP, the ID of the multi-AP set, or the ID assigned to the second AP within the multi-AP set.

4. The method according to claim 2, wherein, The identification information of the second AP used for the multi-AP coordination includes the address of the second AP, and In this case, the receiver address (RA) field of the selection request frame is set to the address of the second AP.

5. The method according to claim 1, wherein, The selection request frame is an initial control frame (ICF) used to initiate the multi-AP coordination, and The selected response frame is the initial control response (ICR) for the ICF.

6. The method according to claim 1, wherein, The selection request frame includes at least one of the following: information for the type of ICF, information for the coordination scheme, information indicating that the selection request frame requests the selection of an AP for the multi-AP coordination, information for the type of response to the selection request frame, information about whether ICR is allowed, or coordination-related information.

7. The method according to claim 6, wherein, The coordination-related information includes at least one of the following: the identifier (ID) of the multi-AP set, the ID assigned to the second AP within the multi-AP set, information for the address of the second AP, information for the operation channel, information for the operation bandwidth, information for the duration of the scheduled TXOP, information for the time point of the TXOP sharing, low-latency service information, or information for the priority of the current coordination scheme in the coordination scheme.

8. The method according to claim 1, wherein, The selection response frame includes at least one of the following: an identifier (ID) of the multi-AP set, an ID assigned to the second AP within the multi-AP set, information for the address of the second AP, information for channel operation, information for bandwidth operation, information for the TXOP duration required by the second AP, information for the buffer status of the second AP, information regarding whether the TXOP sharing is required, low-latency service information, or a status code for the request to the selection request frame.

9. The method according to claim 1, wherein, The selection request frame is a trigger frame, which includes a trigger type subfield. The trigger type subfield is set to a reserved value from the values ​​of the trigger type subfield. The reserved value is a value between 9 and 15.

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

11. The method according to claim 1, wherein, The selection request frame is a buffer status report polling (BSRP) triggered frame.

12. The method according to claim 11, wherein, The common information field of the BSRP trigger frame includes at least one of the following: information about the type of ICF, information about the coordination scheme, information indicating that the selection request frame requests the selection of an AP for the multi-AP coordination, information about the type of response to the selection request frame, or information about whether ICR is allowed. The special user information field of the BSRP trigger frame includes coordination-related information.

13. The method according to claim 11, wherein, The special user information field of the BSRP trigger frame includes at least one of the following: information for the type of ICF, information for the coordination scheme, information indicating that the selection request frame requests the selection of APs for the multi-AP coordination, information for the type of response to the selection request frame, information on whether ICR is allowed, or coordination-related information.

14. The method according to claim 12 or 13, wherein, The public information field or user information field of the BSRP trigger frame includes information indicating the existence of the special user information field.

15. The method according to claim 1, wherein, The selection response frame is a Quality of Service (QoS) empty frame, a QoS data frame, a Allow Transmission (CTS) frame, a CTS-to-Self frame, a Block Acknowledgment (BA) frame, or an action frame.

16. A first access point (AP), comprising: transceiver; Memory; as well as At least one processor, said at least one processor being operatively coupled to the transceiver and the memory, The memory stores instructions, which are based on operations performed by the at least one processor, including: Perform the negotiation process with neighboring APs for multi-AP coordination; Based on the negotiation process, configure a multi-AP set including the neighboring APs; Send a selection request frame to the second AP included in the multi-AP set for initiating coordination with the second AP among the multi-AP sets; Receive a selection response frame from the second AP in response to the selection request frame; and Based on the received selection response frame, a TXOP shared frame including information for allocating duration is sent to the second AP.

17. An apparatus comprising: At least one processor; as well as At least one memory, said at least one memory being operatively coupled to said at least one processor, Wherein, the at least one memory stores instructions, the instructions being executed by the at least one processor to perform operations, the operations including: Perform the negotiation process with neighboring APs for multi-AP coordination; Based on the negotiation process, configure a multi-AP set including the neighboring APs; Send a selection request frame to the second AP included in the multi-AP set for initiating coordination with the second AP among the multi-AP sets; Receive a selection response frame from the second AP in response to the selection request frame; and Based on the received selection response frame, a TXOP shared frame including information for allocating duration is sent to the second AP.

18. A non-transitory computer-readable medium (CRM) storing program code implementing instructions that perform operations based on execution by at least one processor, the operations including: Perform the negotiation process with neighboring APs for multi-AP coordination; Based on the negotiation process, configure a multi-AP set including the neighboring APs; Send a selection request frame to the second AP included in the multi-AP set for initiating coordination with the second AP among the multi-AP sets; Receive a selection response frame from the second AP in response to the selection request frame; as well as Based on the received selection response frame, a TXOP shared frame including information for allocating duration is sent to the second AP.

19. A method comprising: The second access point (AP) performs the negotiation process with neighboring APs for multi-AP coordination; Based on the negotiation process, the second AP configures a multi-AP set including the neighboring APs; The second AP receives a selection request frame from the first AP included in the multi-AP set for initiating coordination with the second AP among the multi-APs; The second AP sends a selection response frame to the first AP in response to the selection request frame; as well as After sending the selection response frame, the second AP receives a TXOP shared frame from the first AP, which includes information for allocating duration.

20. A second access point (AP), comprising: transceiver; Memory; as well as At least one processor, said at least one processor being operatively coupled to the transceiver and the memory, The memory stores instructions, which are based on operations performed by the at least one processor, including: Perform the negotiation process with neighboring APs for multi-AP coordination; Based on the negotiation process, configure a multi-AP set including the neighboring APs; Receive a selection request frame from the first AP included in the multi-AP set for initiating coordination with the second AP among the multi-APs; Send a selection response frame to the first AP in response to the selection request frame; and After sending the selection response frame, a TXOP shared frame including information for allocating duration is received from the first AP.

Images