Transmission of information for multi-AP coordination in wireless LAN system
The method for multi-AP coordination in wireless LAN systems addresses inefficiencies by optimizing transmission power exchange between APs, enhancing reliability and throughput through coordinated actions.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- LG ELECTRONICS INC
- Filing Date
- 2025-12-23
- Publication Date
- 2026-07-02
Smart Images

Figure KR2025022609_02072026_PF_FP_ABST
Abstract
Description
Information transmission for multiple AP cooperation in wireless LAN systems
[0001] The present disclosure relates to the transmission of information for multi-AP coordination (MAPC) in a wireless LAN system.
[0002] Next-generation Wi-Fi (e.g., IEEE 802.11be and / or later) aims to support ultra-high reliability during signal transmission to STAs, and to this end, various technologies are being considered to support high throughput, low latency, and extended range. For example, in wireless LAN systems, Multi-AP Coordination (MAPC) technology, in which multiple APs operate in cooperation to improve network efficiency, has been proposed. MAPC technology aims to reduce channel collisions and improve data transmission efficiency by exchanging necessary information between adjacent APs.
[0003] The present disclosure provides a method and apparatus for transmitting information for MAPC in a wireless LAN system.
[0004] According to an embodiment of the present disclosure, a method performed by a first access point (AP) in a wireless LAN system comprises: establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; transmitting an initial control frame (ICF) to a second AP among the one or more other APs, wherein the ICF includes information regarding a transmission power proposed to the second AP; receiving an initial control response frame (ICR) for the ICF from the second AP; transmitting a trigger frame to trigger MAPC to the second AP; and performing MAPC with the second AP based on the transmission power proposed to the second AP.
[0005] According to an embodiment of the present disclosure, a method performed by a second access point (AP) in a wireless LAN system comprises: establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; receiving an initial control frame (ICF) from a first AP among the one or more other APs, wherein the ICF includes information regarding a transmission power proposed to the second AP; transmitting an initial control response frame (ICR) for the ICF to the first AP; receiving a trigger frame for triggering MAPC from the first AP; and performing MAPC with the first AP based on the transmission power proposed to the second AP.
[0006] In various embodiments, devices for implementing the methods described above are provided.
[0007] The present disclosure may have various advantageous effects.
[0008] For example, based on the exchange of ICF / ICR according to various embodiments of the present disclosure, the Coordinating AP can select an appropriate Coordinated AP. Additionally, the Coordinating AP / Coordinated AP can perform more efficient multi-AP cooperation.
[0009] For example, if the Coordinating AP transmits an ICF containing transmit power information proposed in a multi-AP selection procedure / step (e.g., if the Coordinating AP transmits a Co-SR Invite frame containing transmit power information proposed in the invitation step for Co-SR), the following effects can be expected:
[0010] i) The Coordinated AP can select the accurate / optimal target STA based on the proposed transmit power information;
[0011] ii) Coordinated AP can maximize the number of potential target STAs based on proposed transmit power information;
[0012] iii) The Coordinated AP can determine the MCS and / or packet length early based on the proposed transmit power information; and / or
[0013] iv) The Coordinated AP may transmit an ICR (e.g., Co-SR Response frame) containing Tx power information required for the Coordinated AP in response to the ICF, and thereby the Coordinating AP may improve / modify the MCS value based on the required Tx power information.
[0014] The advantageous effects obtainable through specific embodiments of the present disclosure are not limited to those listed above. For example, there may be various technical effects that a person skilled in the art can understand and / or derive from the present disclosure. Accordingly, the specific effects of the present disclosure are not limited to those explicitly described herein and may include various effects that can be understood or derived from the technical features of the present disclosure.
[0015] FIG. 1 shows an example of a transmitting device and / or receiving device of the present disclosure.
[0016] Figure 2 is a conceptual diagram showing the structure of a wireless LAN (WLAN).
[0017] Figure 3 is a diagram illustrating a general link setup process.
[0018] Figure 4 illustrates an example of a multi-link (ML).
[0019] FIG. 5 shows a modified example of a transmitting device and / or receiving device of the present disclosure.
[0020] FIG. 6 illustrates an example of a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received in an STA of the present disclosure.
[0021] Figure 7 shows the operation according to UL-MU.
[0022] Figure 8 shows an example of a MAC frame header.
[0023] Figure 9 shows a trigger frame format. The trigger frame format can also be referred to as the structure of the trigger frame.
[0024] Figure 10 shows an example of the user information field format of MU-RTS TXS TF.
[0025] Figure 11 shows an example of a MAPC operation procedure including a MAPC search phase and a MAPC Agreement negotiation phase.
[0026] Figure 12 shows an example of a MAPC operation procedure including multiple AP selection steps.
[0027] Figure 13 shows an example of a Co-TDMA procedure.
[0028] Figure 14 shows an example of a case where a BSRP TF containing transmission information for MAPC operation is transmitted as an ICF.
[0029] FIG. 15 shows an example of a method performed by a first AP that transmits information for MAPC.
[0030] FIG. 16 shows an example of a method performed by a second AP receiving information for MAPC.
[0031] Figure 17 shows examples of TF formats including a control information (or feedback) type field and / or a control (or feedback) information field.
[0032] FIG. 18 shows a first example of a (UHR) Special / Feedback User Info field format containing MAPC-related control / feedback / transmission information.
[0033] FIG. 19 shows a second example of a (UHR) Special / Feedback User Info field format containing MAPC-related control / feedback / transmission information.
[0034] FIG. 20 shows a first example of a (UHR) Special / Feedback User Info field format containing Co-TDMA related control / feedback / transfer information.
[0035] Figure 21 shows a second example of a (UHR) Special / Feedback User Info field format containing Co-TDMA related control / feedback / transfer information.
[0036] FIG. 22 shows a first example of a (UHR) Special / Feedback User Info field format containing Co-SR related control / feedback / transmission information.
[0037] FIG. 23 shows a second example of a (UHR) Special / Feedback User Info field format containing Co-SR related control / feedback / transmission information.
[0038] FIG. 24 shows a first example of a (UHR) Special / Feedback User Info field format containing Co-BF related control / feedback / transmission information.
[0039] FIG. 25 shows a second example of a (UHR) Special / Feedback User Info field format containing Co-BF related control / feedback / transmission information.
[0040] Figure 26 shows a third example of a (UHR) Special / Feedback User Info field format containing Co-BF related control / feedback / transmission information.
[0041] Figure 27 shows an example of including MAPC-related information in the Common and / or User Info fields.
[0042] Figure 28 shows an example of a BSRP TF format containing control information within the padding.
[0043] Figure 29 shows an example of a Special User Info field format for Co-TDMA operation.
[0044] Figure 30 shows an example of a Special User Info field format for Co-SR operation.
[0045] Figure 31 shows an example of a Special User Info field format for Co-BF operation.
[0046] Figure 32 shows an example of a data frame format.
[0047] Figure 33 shows an example where MAPC information is included in the frame body of a data frame.
[0048] Figure 34 shows an example where the HT control field and / or frame body of a data frame contains MAPC information.
[0049] FIG. 35 shows a first example of a control frame format that can be transmitted as an ICR.
[0050] FIG. 36 shows a second example of a control frame format that can be transmitted as an ICR.
[0051] Figure 37 shows an example of the A-Control field format within a control frame.
[0052] FIG. 38 shows an example of a control frame format including one or more A-Control field(s).
[0053] Figure 39 shows an example of an A-Control Information element format containing BSR information.
[0054] Figure 40 shows an example of transmitting an Action frame to an ICR for an ICF.
[0055] Figure 41 shows an example of transmitting an Action frame containing an HT control field to an ICR for an ICF.
[0056] Figure 42 shows an example of transmitting a Public Action frame to an ICR for an ICF.
[0057] Figure 43 shows an example of transmitting a Public Action frame containing an HT control field to an ICR for an ICF.
[0058] In the present disclosure, “A or B” may mean “only A,” “only B,” or “both A and B.” Alternatively, in the present disclosure, “A or B” may be interpreted as “A and / or B.” For example, in the present disclosure, “A, B or C” may mean “only A,” “only B,” “only C,” or “any combination of A, B and C.”
[0059] A slash ( / ) or a comma used in the present disclosure may mean “and / or.” For example, “A / B” may mean “A and / or B.” Accordingly, “A / B” may mean “only A,” “only B,” or “both A and B.” For example, “A, B, C” may mean “A, B or C.”
[0060] In the present disclosure, “at least one of A and B” may mean “only A,” “only B,” or “both A and B.” Additionally, in the present disclosure, the expressions “at least one of A or B” or “at least one of A and / or B” may be interpreted as synonymous with “at least one of A and B.”
[0061] Additionally, parentheses used in this disclosure may mean “for example.” Specifically, when indicated as “control information (UHR-Signal field),” the “UHR-Signal field” may be proposed as an example of “control information.” In other words, the “control information” of this disclosure is not limited to the “UHR-Signal field,” and the “UHR-Signal field” may be proposed as an example of “control information.” Furthermore, even when indicated as “control information (UHR-Signal field),” the “UHR-Signal field” may be proposed as an example of “control information.”
[0062] Additionally, “a / an” as used in this disclosure may mean “at least one” or “one or more.” Also, terms ending in “(s)” may mean “at least one” or “one or more.”
[0063] Additionally, the expressions “based on,” “on the basis of,” or “according to” as used in this disclosure mean “based at least in part on,” and do not mean “based only on one.”
[0064] Technical features described individually within one drawing in this disclosure may be implemented individually or simultaneously.
[0065] The following examples of the present disclosure may be applied to various wireless communication systems. For example, the following examples of the present disclosure may be applied to wireless local area network (WLAN) systems. For example, the present disclosure may be applied to IEEE 802.11a / g / n / ac / ax / be / bn standards. Additionally, the examples of the present disclosure may be applied to Ultra High Reliability (UHR) standards or next-generation wireless LAN standards that enhance IEEE 802.11bn. Furthermore, the examples of the present disclosure may be applied to mobile communication systems. For example, they may be applied to mobile communication systems based on Long Term Evolution (LTE) and its evolution based on 3GPP (3rd Generation Partnership Project) standards.
[0066] To explain the technical features of the present disclosure, the technical features to which the present disclosure can be applied are described below.
[0067] FIG. 1 shows an example of a transmitting device and / or receiving device of the present disclosure.
[0068] An example of FIG. 1 can perform various technical features described below. FIG. 1 relates to at least one STA (station). For example, the STA (110, 120) of the present disclosure may also be referred to by various names such as mobile terminal, wireless device, Wireless Transmit / Receive Unit (WTRU), User Equipment (UE), Mobile Station (MS), Mobile Subscriber Unit, or simply user. The STA (110, 120) of the present disclosure may also be referred to by various names such as network, base station, Node-B, Access Point (AP), repeater, router, relay, etc. The STA (110, 120) of the present disclosure may also be referred to by various names such as receiving apparatus, transmitting device, receiving STA, transmitting STA, receiving device, transmitting device, etc.
[0069] For example, the STA (110, 120) can perform the role of an access point (AP) or a non-AP. That is, the STA (110, 120) of the present disclosure can perform the functions of an AP and / or a non-AP. In the present disclosure, an AP may also be indicated as an AP STA.
[0070] The STA (110, 120) of the present disclosure may support various communication standards other than the IEEE 802.11 standard. For example, it may support communication standards according to 3GPP standards (e.g., LTE, LTE-A, 5G NR standards). In addition, the STA of the present disclosure may be implemented in various devices such as mobile phones, vehicles, and personal computers. Furthermore, the STA of the present disclosure may support communication for various communication services such as voice calls, video calls, data communication, and self-driving.
[0071] In the present disclosure, the STA (110, 120) may include a medium access control (MAC) that complies with the specifications of the IEEE 802.11 standard and a physical layer interface for the wireless medium.
[0072] Based on side drawing (a) of Fig. 1, STA (110, 120) is described as follows.
[0073] The first STA (110) may include a processor (111), memory (112), and a transceiver (113). The illustrated processor, memory, and transceiver may each be implemented as separate chips, or at least two blocks / functions may be implemented through a single chip.
[0074] The transceiver (113) of the first STA performs the operation of transmitting and receiving signals. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be, etc.).
[0075] For example, the first STA (110) can perform the intended operation of the AP. For example, the processor (111) of the AP can receive a signal through the transceiver (113), process the received signal, generate a transmitted signal, and perform control for transmitting the signal. The memory (112) of the AP can store the signal received through the transceiver (113) (i.e., the received signal) and the signal to be transmitted through the transceiver (i.e., the transmitted signal).
[0076] For example, the second STA (120) can perform the intended operation of a Non-AP STA. For example, the non-AP transceiver (123) performs the operation of transmitting and receiving signals. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be, etc.).
[0077] For example, the processor (121) of the Non-AP STA can receive a signal through the transceiver (123), process the received signal, generate a transmitted signal, and perform control for transmitting the signal. The memory (122) of the Non-AP STA can store the signal received through the transceiver (123) (i.e., the received signal) and can store the signal to be transmitted through the transceiver (i.e., the transmitted signal).
[0078] For example, the operation of the device indicated as AP in the following specification may be performed in the first STA (110) or the second STA (120). For example, if the first STA (110) is the AP, the operation of the device indicated as AP is controlled by the processor (111) of the first STA (110), and related signals may be transmitted or received through 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 transmission / reception signals of the AP may be stored in the memory (112) of the first STA (110). Additionally, if the second STA (110) is the AP, the operation of the device indicated as AP is controlled by the processor (121) of the second STA (120), and related signals may be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the AP or the transmission / reception signals of the AP can be stored in the memory (122) of the second STA (110).
[0079] For example, the operation of a device indicated as non-AP (or User-STA) in the following specification may be performed in the STA (110) or the second STA (120). For example, if the second STA (120) is non-AP, the operation of the device indicated as non-AP is controlled by the processor (121) of the second STA (120), and related signals may be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120). Additionally, control information related to the operation of the non-AP or the transmission / reception signals of the AP may be stored in the memory (122) of the second STA (120). For example, if the first STA (110) is a non-AP, the operation of the device marked as non-AP is controlled by the processor (111) of the first STA (110), and the related signal can be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (120). Additionally, control information related to the operation of the non-AP or the transmission / reception signal of the AP can be stored in the memory (112) of the first STA (110).
[0080] In the following specification, a device referred to as (transmission / reception) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmission / reception) Terminal, (transmission / reception) device, (transmission / reception) apparatus, network, etc. may refer to the STA (110, 120) of FIG. 1. For example, a device indicated without specific drawing symbols as (transmission / reception) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmission / reception) Terminal, (transmission / reception) device, (transmission / reception) apparatus, network, etc. may also refer to the STA (110, 120) of FIG. 1. For example, in the following example, the operation of various STAs transmitting and receiving signals (e.g., PPPDU) may be performed by the transceiver (113, 123) of FIG. 1. Additionally, in the following example, the operation of various STAs generating transmission and reception signals or performing data processing or calculations in advance for transmission and reception signals may be performed by the processor (111, 121) of FIG. 1.For example, an example of an operation to generate a transmission / reception signal or to perform data processing or operations in advance for a transmission / reception signal may include: 1) an operation to determine / acquire / configure / operate / decode / encode bit information of sub-fields (SIG, STF, LTF, Data) included in the PPDU; 2) an operation to determine / configure / acquire time resources or frequency resources (e.g., subcarrier resources) used for sub-fields (SIG, STF, LTF, Data) included in the PPDU; 3) an operation to determine / configure / acquire specific sequences (e.g., pilot sequence, STF / LTF sequence, extra sequence applied to SIG) used for sub-fields (SIG, STF, LTF, Data) included in the PPDU; 4) a power control operation and / or power saving operation applied to the STA; and 5) an operation related to determining / acquiring / configuring / operating / decoding / encoding of an ACK signal. In addition, in the following example, various information (e.g., information related to fields, subfields, control fields, parameters, power, etc.) used by various STAs for determining / acquiring / configuring / calculating / decoding / encoding of transmission and reception signals can be stored in the memory (112, 122) of FIG. 1.
[0081] The device / STA of the aforementioned supplementary drawing (a) of FIG. 1 can be modified as shown in supplementary drawing (b) of FIG. 1. Below, the STA (110, 120) of the present disclosure will be described based on supplementary drawing (b) of FIG. 1.
[0082] For example, the transceiver (113, 123) shown in side drawing (b) of FIG. 1 can perform the same function as the transceiver shown in side drawing (a) of FIG. 1 described above. For example, the processing chip (114, 124) shown in side drawing (b) of FIG. 1 may include a processor (111, 121) and a memory (112, 122). The processor (111, 121) and the memory (112, 122) shown in side drawing (b) of FIG. 1 can perform the same function as the processor (111, 121) and the memory (112, 122) shown in side drawing (a) of FIG. 1 described above.
[0083] The mobile terminal, wireless device, Wireless Transmit / Receive Unit (WTRU), User Equipment (UE), Mobile Station (MS), Mobile Subscriber Unit, user, User STA, network, Base Station, Node-B, AP (Access Point), repeater, router, relay, receiving device, transmitting device, receiving STA, transmitting STA, receiving Device, transmitting Device, receiving Apparatus, and / or transmitting Apparatus described below may refer to the STA (110, 120) shown in side drawings (a) / (b) of FIG. 1, or the processing chip (114, 124) shown in side drawing (b) of FIG. 1. That is, the technical features of the present disclosure may be performed in the STA (110, 120) shown in side drawings (a) / (b) of FIG. 1, or only in the processing chip (114, 124) shown in side drawing (b) of FIG. 1. For example, the technical feature of the transmitting STA transmitting a control signal may be understood as a technical feature in which a control signal generated in the processor (111, 121) shown in side drawings (a) / (b) of FIG. 1 is transmitted through the transceiver (113, 123) shown in side drawings (a) / (b) of FIG. 1. Alternatively, the technical feature of the transmitting STA transmitting a control signal may be understood as a technical feature in which a control signal to be transmitted from the processing chip (114, 124) shown in side drawing (b) of FIG. 1 is generated to the transceiver (113, 123).
[0084] For example, the technical feature of the receiving STA receiving a control signal can be understood as the technical feature of the control signal being received by the transceiver (113, 123) shown in side view (a) of FIG. 1. Alternatively, the technical feature of the receiving STA receiving a control signal can be understood as the technical feature of the control signal received by the transceiver (113, 123) shown in side view (a) of FIG. 1 being acquired by the processor (111, 121) shown in side view (a) of FIG. 1. Alternatively, the technical feature of the receiving STA receiving a control signal can be understood as the technical feature of the control signal received by the transceiver (113, 123) shown in side view (b) of FIG. 1 being acquired by the processing chip (114, 124) shown in side view (b) of FIG. 1.
[0085] Referring to side view (b) of FIG. 1, software code (115, 125) may be included in memory (112, 122). The software code (115, 125) may include instructions that control the operation of the processor (111, 121). The software code (115, 125) may be included in various programming languages.
[0086] The processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include an application-specific integrated circuit (ASIC), other chipsets, logic circuits, and / or data processing devices. The processor may be an application processor (AP). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may be a SNAPDRAGON® series processor manufactured by Qualcomm®, an EXYNOS® series processor manufactured by Samsung®, an A series processor manufactured by Apple®, a HELIO® series processor manufactured by MediaTek®, an ATOM® series processor manufactured by INTEL®, or a processor enhanced therefrom.
[0087] In the present disclosure, an uplink may refer to a link for communication from a non-AP STA to an AP STA, and uplink PPDUs / packets / signals, etc. may be transmitted through the uplink. Additionally, in the present disclosure, a downlink may refer to a link for communication from an AP STA to a non-AP STA, and downlink PPDUs / packets / signals, etc. may be transmitted through the downlink.
[0088] Figure 2 is a conceptual diagram showing the structure of a wireless LAN (WLAN).
[0089] The top of Figure 2 shows the structure of the IEEE (Institute of Electrical and Electronic Engineers) 802.11 infrastructure BSS (basic service set).
[0090] Referring to the top of FIG. 2, the wireless LAN system may include one or more infrastructure BSSs (200, 205) (hereinafter BSS). The BSS (200, 205) is a set of APs and STAs, such as an AP (access point, 225) and STA1 (Station, 200-1), that can communicate with each other by successfully synchronizing, and is not a concept referring to a specific area. The BSS (205) may include one or more STAs (205-1, 205-2) that can be combined with one AP (230).
[0091] The BSS may include at least one STA, an AP (225, 230) that provides a distribution service, and a distribution system (DS, 210) that connects multiple APs.
[0092] A distributed system (210) can implement an extended service set (ESS, 240) by connecting multiple BSSs (200, 205). The term ESS (240) may be used to refer to a network formed by connecting one or more APs through the distributed system (210). APs included in a single ESS (240) may have the same service set identification (SSID).
[0093] The portal (portal, 220) can act as a bridge to connect a wireless LAN network (IEEE 802.11) with another network (e.g., 802.X).
[0094] In a BSS like the one at the top of Fig. 2, a network between APs (225, 230) and a network between APs (225, 230) and STAs (200-1, 205-1, 205-2) can be implemented. However, it may also be possible to establish a network between STAs and perform communication without APs (225, 230). A network that establishes a network between STAs and performs communication without APs (225, 230) is defined as an ad-hoc network or an independent basic service set (IBSS).
[0095] The bottom of Fig. 2 is a conceptual diagram showing IBSS.
[0096] Referring to the bottom of Fig. 2, the IBSS is a BSS that operates in ad-hoc mode. Since the IBSS does not include an AP, there is no centralized management entity that performs management functions centrally. That is, in the IBSS, the STAs (250-1, 250-2, 250-3, 255-4, 255-5) are managed in a distributed manner. In the IBSS, all STAs (250-1, 250-2, 250-3, 255-4, 255-5) can be mobile STAs, and since access to the distributed system is not allowed, they form a self-contained network.
[0097] Figure 3 is a diagram illustrating a general link setup process.
[0098] In the described S310 step, the STA can perform a network discovery operation. The network discovery operation may include the STA's scanning operation. That is, in order for the STA to access a network, it must find a network it can join. Before joining a wireless network, the STA must identify a compatible network, and the process of identifying networks existing in a specific area is called scanning. Scanning methods include active scanning and passive scanning.
[0099] Figure 3 illustrates a network discovery operation that includes an active scanning process as an example. In active scanning, the STA performing the scanning moves between channels and transmits a probe request frame to search for nearby APs, and waits for a response. The responder transmits a probe response frame as a response to the probe request frame to the STA that transmitted the probe request frame. Here, the responder may be the STA that last transmitted a beacon frame from the BSS of the channel being scanned. In a BSS, the AP becomes the responder because it transmits the beacon frame, whereas in an IBSS, the responder is not constant because STAs within the IBSS take turns transmitting the beacon frame. For example, an STA that transmits a probe request frame on channel 1 and receives a probe response frame on channel 1 can store BSS-related information included in the received probe response frame and move to the next channel (e.g., channel 2) to perform scanning in the same way (i.e., transmit and receive probe request / response on channel 2).
[0100] Although not shown in the example of Fig. 3, scanning operations may also be performed using a passive scanning method. An STA performing scanning based on passive scanning can wait for a beacon frame while switching between channels. A beacon frame is one of the management frames in IEEE 802.11, which announces the presence of a wireless network and is periodically transmitted to allow a scanning STA to find the wireless network and join it. In a BSS, the AP performs the role of periodically transmitting beacon frames, while in an IBSS, STAs within the IBSS take turns transmitting beacon frames. When a scanning STA receives a beacon frame, it stores the information about the BSS included in the beacon frame and records the beacon frame information in each channel while moving to another channel. An STA that has received a beacon frame can store the BSS-related information included in the received beacon frame, move to the next channel, and perform scanning in the next channel in the same manner.
[0101] The STA that discovered the network can perform an authentication process through step S320. This authentication process may be referred to as the first authentication process to clearly distinguish it from the security setup operation of step S340 described later. The authentication process of 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 in the authentication request / response corresponds to a management frame.
[0102] The authentication frame may include information regarding the authentication algorithm number, authentication transaction sequence number, status code, challenge text, RSN (Robust Security Network), Finite Cyclic Group, etc.
[0103] The STA can send an authentication request frame to the AP. Based on the information contained in the received authentication request frame, the AP can determine whether to allow authentication for the STA. The AP can provide the result of the authentication process to the STA through an authentication response frame.
[0104] A successfully authenticated STA may perform an association process based on step S330. The association process includes the STA sending an association request frame to the AP, and in response, the AP sending an association response frame to the STA. For example, the association request frame may include information regarding various capabilities, beacon listen interval, service set identifier (SSID), supported rates, supported channels, RSN, mobility domain, supported operating classes, Traffic Indication Map Broadcast request, interworking service capabilities, etc. For example, a connection response frame may include information related to various capabilities, status code, AID (Association ID), support rate, EDCA (Enhanced Distributed Channel Access) parameter set, RCPI (Received Channel Power Indicator), RSNI (Received Signal to Noise Indicator), mobility domain, timeout interval (association comeback time), overlapping BSS scan parameters, TIM broadcast response, QoS map, etc.
[0105] Subsequently, in step S340, the STA may perform a security setup process. The security setup process of step S340 may include, for example, a process of setting up a private key through a 4-way handshake via an EAPOL (Extensible Authentication Protocol over LAN) frame.
[0106] Figure 4 illustrates an example of a multi-link (ML).
[0107] As illustrated in FIG. 4, multiple multi-link devices (MLDs) can communicate through a multi-link. The MLDs can be classified into an AP MLD containing multiple AP STAs and a non-AP MLD containing multiple non-AP STAs. That is, the AP MLD may include affiliated APs (i.e., AP STAs), and the non-AP MLD may include affiliated STAs (i.e., non-AP STAs, or user-STAs).
[0108] A multilink may include a first link and a second link, and different channels / subchannels / frequency resources may be assigned to the first and second links. The first and second multilinks may be identified by a link ID of 4 bits (or other n bits). The first and second links may be configured in the same 2.4 GHz, 5 GHz, or 6 GHz band. Alternatively, the first link and the link may be configured in different bands.
[0109] The AP MLD of FIG. 4 includes three affiliated APs. In one example of FIG. 4, AP1 may operate in the 2.4 GHz band, AP2 may operate in the 5 GHz band, and AP3 may operate in the 6 GHz band. In one example of FIG. 4, the first link in which AP1 and non-AP1 operate may be defined as a channel / subchannel / frequency resource within the 2.4 GHz band. Additionally, in one example of FIG. 4, the second link in which AP2 and non-AP2 operate may be defined as a channel / subchannel / frequency resource within the 5 GHz band. Additionally, in one example of FIG. 4, the third link in which AP3 and non-AP3 operate may be defined as a channel / subchannel / frequency resource within the 6 GHz band.
[0110] In one example of FIG. 4, AP1 can initiate a multilink setup procedure (ML setup procedure) by transmitting an Association Request frame to non-AP STA1. In one example of FIG. 4, non-AP STA1 can transmit an Association Response frame in response to the Association Request frame. Each AP (e.g., AP1 / 2 / 3) shown in FIG. 4 may be the same as the AP shown in FIG. 1 and / or FIG. 2, and each non-AP (e.g., non-AP1 / 2 / 3) shown in FIG. 4 may be the same as the STA shown in FIG. 1 and / or FIG. 2 (i.e., user-STA or non-AP STA).
[0111] The specific features of the present disclosure are not limited to the specific features of FIG. 4. That is, the number of links can be defined in various ways, and a plurality of links can be defined in various ways within at least one band.
[0112] FIG. 5 shows a modified example of a transmitting device and / or receiving device of the present disclosure.
[0113] The device illustrated in FIGS. 1 to 4 (e.g., AP STA, non-AP STA) can be modified as in FIG. 5. The transceiver (530) of FIG. 5 may be identical to the transceiver (113, 123) of FIG. 1. The transceiver (530) of FIG. 5 may include a receiver and a transmitter.
[0114] The processor (510) of FIG. 5 may be the same as the processor (111, 121) of FIG. 1. Alternatively, the processor (510) of FIG. 5 may be the same as the processing chip (114, 124) of FIG. 1.
[0115] The memory (150) of FIG. 5 may be the same as the memory (112, 122) of FIG. 1. Alternatively, the memory (150) of FIG. 5 may be a separate external memory different from the memory (112, 122) of FIG. 1.
[0116] Referring to FIG. 5, a power management module (511) manages power for a processor (510) and / or a transceiver (530). A battery (512) supplies power to the power management module (511). A display (513) outputs results processed by the processor (510). A keypad (514) receives input to be used by the processor (510). The keypad (514) may be displayed on the display (513). A SIM card (515) may be an integrated circuit used to securely store an international mobile subscriber identity (IMSI) and associated keys used to identify and authenticate a subscriber in a mobile device such as a mobile phone and a computer.
[0117] Referring to FIG. 5, the speaker (540) can output sound-related results processed by the processor (510). The microphone (541) can receive sound-related inputs to be used by the processor (510).
[0118] FIG. 6 illustrates an example of a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received in an STA of the present disclosure.
[0119] The STA of the present disclosure (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) can transmit and / or receive the PPDU of FIG. 6. The PPDU described in the present disclosure may have the structure of FIG. 6, for example. Additionally, the PPDU described in the present disclosure may be referred to by various names such as Ultra High Reliability (UHR) PPDU, Transmit PPDU, Receive PPDU, Type 1, or Type N PPDU. The PPDU described in the present disclosure may be used in WLAN systems defined according to IEEE 802.11bn and / or next-generation WLAN systems that improve upon IEEE 802.11bn.
[0120] The PPDU of FIG. 6 may be related to various PPDU types used in UHR systems. For example, the example of FIG. 6 may be used for at least one of SU (single-user) mode / type / transmission, MU (multi-user) mode / type / transmission, and NDP (null data packet) mode / type / transmission related to channel sounding. For example, if the example of FIG. 6 is related to NDP, the illustrated Data field may be omitted. If the PPDU of FIG. 6 is used for TB (Trigger-based) mode, the UHR-SIG of FIG. 6 may be omitted. In other words, an STA that receives a Trigger frame for UL-MU (Uplink-MU) communication may transmit a PPDU in which the UHR-SIG is omitted in the example of FIG. 6.
[0121] In FIG. 6, L-STF to UHR-LTF can be called a preamble or physical preamble and can be generated / transmitted / received / acquired / decoded at the physical layer (included in the transmitting / receiving STA).
[0122] Each block shown in FIG. 6 can be referred to as a field / subfield / signal, etc. As shown in FIG. 6, the names of these fields / subfields / signals may be L-STF (legacy short training field), L-LTF (legacy long training field), L-SIG (legacy signal), RL-SIG (repeated L-SIG), U-SIG (Universal Signal), UHR-SIG (UHR-signal), etc.
[0123] The subcarrier spacing of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields in Fig. 6 can be set to 312.5 kHz, and the subcarrier spacing of the UHR-STF, UHR-LTF, and Data fields can be set to 78.125 kHz. That is, the tone index (or subcarrier index) of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields can be displayed in units of 312.5 kHz, and the tone index (or subcarrier index) of the UHR-STF, UHR-LTF, and Data fields can be displayed in units of 78.125 kHz.
[0124] The PPDU of Fig. 6, L-LTF and L-STF, may be the same as conventional fields (e.g., non-HT LTF and non-HT STF defined in conventional WLAN standards).
[0125] The L-SIG field of FIG. 6 may contain, for example, 24 bits of bit information. For example, the 24 bits of information may include a 4-bit Rate field, a 1-bit Reserved bit, a 12-bit Length field, a 1-bit Parity bit, and a 6-bit Tail bit. For example, the 12-bit Length field may contain information regarding the length or time duration of the PPDU. For example, the value of the 12-bit Length field may be determined based on the type of the PPDU. For example, if the PPDU is a non-HT (non-High Throughput), HT (High Throughput), VHT (Very High Throughput) PPDU, or an EHT (extremely high throughput) PPDU, or a UHR PPDU, the value of the Length field may be determined as a multiple of 3. For example, if the PPDU is an HE PPDU, the value of the Length field may be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2". In other words, for non-HT, HT, VHT PPDU, or EHT PPDU, UHR PPDU, the value of the Length field can be determined as a multiple of 3, and for HE (High-Efficiency) PPDU, the value of the Length field can be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2". In other words, the Length field in a UHR PPDU is set to a value satisfying the condition that the remainder is zero when LENGTH is divided by 3.
[0126] For example, a (non-AP and AP) STA can apply BCC encoding based on a code rate of 1 / 2 to 24 bits of information in the L-SIG field. Subsequently, the transmitting STA can obtain 48 bits of BCC encoding. BPSK modulation can be applied to the 48 bits of encoding to generate 48 BPSK symbols. The transmitting STA can map the 48 BPSK symbols to positions excluding the pilot subcarrier {subcarrier indices -21, -7, +7, +21} and the DC subcarrier {subcarrier index 0}. Consequently, 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 of {-1, -1, -1, 1} to the subcarrier index {-28, -27, +27, +28}. The above signal can be used for channel estimation for the frequency domain corresponding to {-28, -27, +27, +28}.
[0127] For example, the (non-AP and AP) STA can generate an RL-SIG that is identical to the L-SIG. BPSK modulation may be applied to the RL-SIG. The receiving (non-AP and AP) STA can determine that the received PPDU is a HE PPDU, EHT PPDU, or UHR PPDU based on the presence of the RL-SIG. In other words, the receiving (non-AP and AP) STA can determine that the received PPDU is one of the HE PPDU, EHT PPDU, or UHR PPDU if the RL-SIG is present. In other words, the receiving (non-AP and AP) STA can determine that the received PPDU is one of the non-HT PPDU, HT PPDU, or VHT PPDU if the RL-SIG is not present. In other words, the RL-SIG field is a repeat of the L-SIG field and is used to differentiate an UHR PPDU from a non-HT PPDU, HT PPDU, and VHT PPDU.
[0128] After the RL-SIG in Fig. 6, a U-SIG (Universal SIG) may be inserted. The U-SIG may be referred to by various names such as the first SIG field, first SIG, first type SIG, control signal, control signal field, first (type) control signal, common control field, and common control signal.
[0129] U-SIG may contain N bits of information and may contain information to identify the type of EHT PPDU. For example, U-SIG may be constructed based on two symbols (e.g., two consecutive OFDM symbols). Each symbol for U-SIG (e.g., OFDM symbol) may have a duration of 4 us. Each symbol of U-SIG may be used to transmit 26 bits of information. For example, each symbol of U-SIG may be transmitted and received based on 52 data tones and 4 pilot tones.
[0130] For example, A bit information (e.g., 52 un-coded bits) can be transmitted through U-SIG, and the first symbol of U-SIG can transmit the first X bit information (e.g., 26 un-coded bits) of the total A bit information, and the second symbol of U-SIG can transmit the remaining Y bit information (e.g., 26 un-coded bits) of the total A bit information. For example, the transmitting STA can obtain the 26 un-coded bits included in each U-SIG symbol. The transmitting STA can generate 52-coded bits by performing convolutional encoding (i.e., BCC encoding) based on a rate of R=1 / 2 and can perform interleaving on the 52-coded bits. The transmitting STA can generate 52 BPSK symbols assigned to each U-SIG symbol by performing BPSK modulation on the interleaved 52-coded bits. A single U-SIG symbol can be transmitted based on 56 tones (subcarriers) from subcarrier index -28 to subcarrier index +28, excluding DC index 0. 52 BPSK symbols generated by the transmitting STA can be transmitted based on the remaining tones (subcarriers), excluding the pilot tones -21, -7, +7, and +21.
[0131] For example, A bit information (e.g., 52 un-coded bits) transmitted by U-SIG 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 the tail field may be transmitted through a second symbol of U-SIG. The CRC field may be generated based on 26 bits assigned to the first symbol of U-SIG and the remaining 16 bits within the second symbol excluding the CRC / tail field, and may be generated based on a conventional CRC calculation algorithm. Additionally, the tail field may be used to terminate the trellis of a convolutional decoder and may be set, for example, to "000000".
[0132] A bit information (e.g., 52 un-coded bits) transmitted by U-SIG (or U-SIG field) can be divided into version-independent bits and version-dependent bits. For example, the size of the version-independent bits can be fixed or variable. For example, the version-independent bits may be assigned only to the first symbol of U-SIG, or the version-independent bits may be assigned to both the first and second symbols of U-SIG. For example, the version-independent bits and the version-dependent bits may be referred to by various names, such as the first control bit and the second control bit.
[0133] For example, the version-independent bits of U-SIG may include a 3-bit PHY version identifier. For example, the 3-bit PHY version identifier may include information related to the PHY version of the transmitted and received PPDU. For example, a first value of the 3-bit PHY version identifier (e.g., a value of 000) may indicate that the transmitted and received PPDU is an EHT PPDU. Additionally, a second value of the 3-bit PHY version identifier (e.g., a value of 001) may indicate that the transmitted and received PPDU is a UHR PPDU.
[0134] In other words, when an (AP / non-AP) STA transmits an EHT PPDU, it can set a 3-bit PHY version identifier to a first value. In other words, a receiving (AP / non-AP) STA can determine that the received PPDU is an EHT PPDU based on the PHY version identifier having the first value, and can determine that the received PPDU is a UHR PPDU based on the PHY version identifier having the second value.
[0135] For example, the version-independent bits of U-SIG may include a 1-bit UL / DL flag field. The first value of the 1-bit UL / DL flag field is related to UL communication, and the second value of the UL / DL flag field is related to DL communication.
[0136] For example, the version-independent bits of U-SIG may include information regarding the length of the TXOP (transmission opportunity) and information regarding the BSS color ID.
[0137] For example, if the UHR PPDU is classified into various types (e.g., type related to SU transmission (performed based on UL or DL), type related to DL transmission, type related to NDP transmission, type related to DL non-MU-MIMO, type related to DL MU-MIMO, type related to Multi-AP operation, type related to CO-BF (Coordinated beamforming) and SR (Spatial Reuse), type related to C-OFDMA (Coordinated OFDMA), type related to CO-TDMA (Coordinated TDMA)), information regarding the type of the EHT PPDU (e.g., 2-bit or 3-bit information) may be included in the version-dependent bits of the U-SIG.
[0138] For example, U-SIG may include: 1) a bandwidth field containing information regarding bandwidth; 2) a field containing information regarding the Modulation and Coding Scheme (MCS) technique applied to UHR-SIG; 3) an indication field containing information regarding whether the dual subcarrier modulation (DCM) technique is applied to UHR-SIG; 4) a field containing information regarding the number of symbols used for UHR-SIG; 5) a field containing information regarding whether UHR-SIG is generated across the entire band; 6) a field containing information regarding the type of UHR-LTF / STF; and 7) information regarding a field indicating the length of UHR-LTF and CP length.
[0139] Preamble puncturing may be applied to the PPDU of Fig. 6. Preamble puncturing means applying puncturing to a portion of the total band of the PPDU (e.g., a secondary 20 MHz band). For example, when an 80 MHz PPDU is transmitted, the STA applies puncturing to the secondary 20 MHz band within the 80 MHz band and can transmit the PPDU only through the primary 20 MHz band and the secondary 40 MHz band.
[0140] For example, the pattern of preamble puncturing can be pre-set. For example, when a first puncturing pattern is applied, puncturing may be applied only to a secondary 20 MHz band within an 80 MHz band. For example, when a second puncturing pattern is applied, puncturing may be applied only to one of two secondary 20 MHz bands included in a secondary 40 MHz band within an 80 MHz band. For example, when a third puncturing pattern is applied, puncturing may be applied only to a secondary 20 MHz band included in a primary 80 MHz band within a 160 MHz band (or 80+80 MHz band). For example, when the fourth puncturing pattern is applied, within the 160 MHz band (or 80+80 MHz band), the primary 40 MHz band included in the primary 80 MHz band is present, and puncturing may be applied to at least one 20 MHz channel that does not belong to the primary 40 MHz band.
[0141] Information regarding preamble puncturing applied to the PPDU may be included in the U-SIG and / or UHR-SIG. For example, the first field of the U-SIG may include information regarding the contiguous bandwidth of the PPDU, and the second field of the U-SIG may include information regarding preamble puncturing applied to the PPDU.
[0142] For example, U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following method. If the bandwidth of the PPDU exceeds 80 MHz, the U-SIG may be configured individually in 80 MHz units. For example, if the bandwidth of the PPDU is 160 MHz, the PPDU may include a first U-SIG for the first 80 MHz band and a second U-SIG for the second 80 MHz band. In this case, the first field of the first U-SIG may include information regarding the 160 MHz bandwidth, and the second field of the first U-SIG may include information regarding preamble puncturing applied to the first 80 MHz band (i.e., information regarding the preamble puncturing pattern). Additionally, the first field of the second U-SIG may include information regarding a 160 MHz bandwidth, and the second field of the second U-SIG may include information regarding preamble puncturing applied to the second 80 MHz band (i.e., information regarding a preamble puncturing pattern). Meanwhile, the UHR-SIG following the first U-SIG may include information regarding preamble puncturing applied to the second 80 MHz band (i.e., information regarding a preamble puncturing pattern), and the UHR-SIG following the second U-SIG may include information regarding preamble puncturing applied to the first 80 MHz band (i.e., information regarding a preamble puncturing pattern).
[0143] Additionally or generally, U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following method. U-SIG may include information regarding preamble puncturing for all bands (i.e., information regarding preamble puncturing patterns). That is, UHR-SIG may not include information regarding preamble puncturing, and only U-SIG may include information regarding preamble puncturing (i.e., information regarding preamble puncturing patterns).
[0144] U-SIGs can be configured in 20 MHz units. For example, if an 80 MHz PPDU is configured, U-SIGs can be duplicated. That is, four identical U-SIGs can be included within an 80 MHz PPDU. PPDUs exceeding the 80 MHz bandwidth may contain different U-SIGs.
[0145] The UHR-SIG of FIG. 6 may include control information for a receiving STA. The UHR-SIG may be transmitted through at least one symbol, and one symbol may have a length of 4 us. Information regarding the number of symbols used for the UHR-SIG may be included in the U-SIG.
[0146] UHR-SIG provides additional signals to the U-SIG field, enabling the STA to interpret / decode the UHR PPDU. The UHR-SIG field may include U-SIG overflow bits that apply commonly to all users. Additionally, the UHR-SIG field contains resource allocation information, making it possible for the STA to look up resources used in fields containing data fields / UHR-STF / UHR-LTF (i.e., UHR modulated fields of an UHR PPDU).
[0147] The frequency resources of the UHR-LTF, UHR-STF, and data fields illustrated in FIG. 6 can be determined based on a RU (resource unit) defined by a plurality of subcarriers / tones. That is, the UHR-LTF, UHR-STF, and data fields of the present disclosure can be transmitted / received through a RU (resource unit) defined by a plurality of subcarriers / tones.
[0148] FIG. 7 illustrates the operation according to UL-MU. As illustrated, a transmitting STA (e.g., AP) can acquire a TXOP (725) by performing channel access through contending (i.e., Backoff operation) and transmit a Trigger frame (730). That is, the transmitting STA (e.g., AP) can transmit a PPDU containing the Trigger frame (730). When the PPDU containing the Trigger frame is received, a TB (trigger-based) PPDU is transmitted after a delay of SIFS.
[0149] TB PPDUs (741, 742) are transmitted at the same time and may be transmitted from multiple STAs (e.g., User STAs) with an AID indicated within a Trigger frame (730). An ACK frame (750) for a TB PPDU may be implemented in various forms. For example, an ACK frame (750) for a TB PPDU may be implemented in the form of a BA (block ACK).
[0150] In FIG. 7, the transmission(s) of the Trigger Frame (730), TB PPDU (741, 742) and / or ACK Frame (750) can be performed within TXOP (725).
[0151] The structure and types / subtypes of MAC frames are described below.
[0152] Figure 8 shows an example of a MAC frame header.
[0153] As illustrated, the MAC frame may include a frame control field / information of 2 octets in length, a duration field / information of 2 octets in length, a Receiver Address (RA) field / information of 6 octets in length, and a Transmitter Address (TA) field / information of 6 octets in length. As illustrated in FIG. 8, the four fields may be consecutive with each other. The MAC header of FIG. 8 may be modified in various ways, and a new field may be inserted between the four illustrated fields, or at least one of the illustrated fields may be omitted.
[0154] The MAC header shown in FIG. 8 may be located at the very beginning of the MAC frame. That is, the MAC frame may include a MAC header such as that shown in FIG. 8 and a MAC body field / information following the MAC header. The MAC frame containing the MAC header of FIG. 8 is inserted / included in the data field of the PPDU (e.g., UHR PPDU) shown in FIG. 5.
[0155] MAC frames included in the data fields of the PPDU of this specification may be classified into various types. For example, MAC frames of this specification may be classified into control frames, management frames, and data frames.
[0156] For example, a management frame includes Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Beacon, Disassociation, Authentication, and Deauthentication frames / signals defined in conventional WLANs. For the management frame, the values of the type fields (B3 and B2) in FIG. 8 are set to 00. Additionally, the values of the subtype fields (B7, B6, B5, B4) in FIG. 8 are as follows: Association Request (0000), Association Response (0001), Reassociation Request (0010), Reassociation Response (0011), Probe Request (0100), Probe Response (0101), Beacon (1000), Disassociation (1010), Authentication (1011), Deauthentication (1100).
[0157] For example, the control frame includes the Trigger Beamforming Report Poll, NDP Announcement (NDPA), Control Frame Extension, Control Wrapper, Block Ack Request (BlockAckReq), Block Ack (BlockAck), PS-Poll, RTS, CTS, Ack, and CF-End frames / signals defined in conventional WLANs. For the control frame, the values of the type fields (B3 and B2) in FIG. 8 are set to 01. Also, the values of the subtype fields (B7, B6, B5, B4) in FIG. 8 are as follows: Trigger(0010), Beamforming Report Poll(0100), NDP Announcement(0101), Control Frame Extension(0110), Control Wrapper(0111), BlockAckReq(1000), BlockAck(1001), PS-Poll(1010), RTS(1011), CTS(1100), Ack(1101), CF-End(1110).
[0158] For example, the data frame includes (QoS) Data, (QoS) Null, etc., defined in conventional WLANs. For the management frame, the value of the type field (B3 and B2) in Fig. 8 is set to 10.
[0159] MAC frames / signals used in this specification can be identified through the type field / information and subtype field / information described above. For example, the “trigger frame” in this specification may refer to a MAC frame in which the type bits B3 and B2 within the frame control field of the MAC header are set to 01, and the subtype bits B7, B6, B5, and B4 within the frame control field are set to 0010. Various MAC frames described in this specification are inserted into / included in the data fields of various PPDUs (e.g., HE / VHT / HE / EHT / UHR PPDU).
[0160] Figure 9 shows a trigger frame format. The trigger frame format can also be referred to as the structure of the trigger frame.
[0161] Referring to FIG. 9, a trigger frame may include a frame control field, a duration / ID field, a receiver address (RA) field, a transmitter address (TA) field, a common info field, a user info list field, a padding field, and / or a frame check sequence (FCS) field. Optionally, the trigger frame may further include a special user info field between the common info field and the user info list field. The user info list field may include one or more user info fields. The frame control field, the duration / ID field, the RA field, and the TA field may constitute a MAC header.
[0162] For example, a common information field may include a trigger type subfield. The trigger type subfield value may indicate a trigger frame variant as shown in :
[0163] Trigger type subfield valueTrigger frame variant0Basic1Beamforming Report Poll (BFRP)2MU-BAR3MU-RTS4Buffer Status Report Poll (BSRP)5GCR MU-BAR6Bandwidth Query Report Poll (BQRP)7NDP Feedback Report Poll (NFRP)8Ranging9-15Reserved
[0164] For example, if the value of the trigger type subfield is set to 0, the corresponding trigger frame may be a basic trigger frame. For example, if the value of the trigger type subfield is set to 3, the corresponding trigger frame may be a multi-user (MU) RTS trigger frame. Meanwhile, according to the EHT (or 802.11be) standard, to support Peer-to-Peer (P2P) transmission to non-AP STAs, the AP may allocate a portion of the time interval within a TXOP acquired by the AP. To allocate a portion of the time interval within a TXOP, a TXOP Sharing Mode subfield may be defined within the Common Info Field of a MU-RTS trigger frame. When the value of the TXOP Sharing Mode subfield is a non-zero value, such a MU-RTS trigger frame may be referred to as a MU-RTS TXOP Sharing (TXS) Trigger frame (TF). Descriptions of the values of the TXOP Sharing Mode subfield are shown in below:
[0165] Triggered TXOP Sharing Mode subfield valueDescription0MU-RTS that does not initiate MU-RTS TXOP sharing procedure.1MU-RTS that initiates MU-RTS TXOP sharing procedure wherein a scheduledSTA can only transmit MPDU(s) addressed to its associated AP.2MU-RTS that initiates MU-RTS TXOP sharing procedure wherein a scheduled STA can transmit MPDU(s) addressed to its associated AP or addressed to another STA.3Reserved.
[0166] For example, if the value of the TXOP shared mode subfield is 1, one or more (non-TB) PPDU transmissions to the AP may be supported. If the value of the TXOP shared mode subfield is 2, P2P transmissions as well as (non-TB) PPDU transmissions to the AP may be supported. In this disclosure, the MU-RTS TXS TF may also be briefly referred to as a TXS trigger frame.
[0167] Figure 10 shows an example of the user information field format of MU-RTS TXS TF.
[0168] Referring to FIG. 10, the user information field may include an AID subfield, an RU allocation subfield, an allocation duration subfield, reserve bits and / or a PS160 subfield.
[0169] The AID subfield may indicate the AID for the STA. The RU assignment subfield may indicate the RU assignment for the STA.
[0170] The allocation period subfield can contain 9 bits from B20 to B28 in MU-RTS TXS TF and can indicate the allocation period in units of 16us. In this case, the maximum length of the allocation period that can be indicated by the allocation period subfield can be 2^9 = 8192us.
[0171] The PS160 subfield can indicate a primary 160MHz channel or a second 160MHz channel to which RU or MRU allocation applies.
[0172] Meanwhile, although a large number of APs are installed adjacent to each other to enable terminals to maintain continuous WLAN connectivity over a wider area, issues such as radio interference and transmission collisions between APs may occur as the BSSs of multiple APs overlap. To resolve these issues, various technologies related to coordination between APs in frequency, time, and spatial domains (e.g., RU selection, Joint transmission, Nulling) have been proposed, and it is necessary to address the various issues that may arise during AP coordination.
[0173] In the present disclosure, multi-AP coordination (MAPC) is proposed. MAPC may be based on techniques for reducing various interferences, such as inter-symbol interference (ISI), through coordination with neighboring APs (e.g., APs located in overlapping BSSs).
[0174] For example, MAPC can be classified into MAPC methods (or cooperative methods) based on various technologies / types / formats / protocols. For example, a cooperative method may include Co-TDMA (Coordinated TDMA), which distinguishes wireless resources allocated to multiple APs based on the time axis (time domain). Additionally or generally, a cooperative method may include C-OFDMA (Coordinated OFDMA), which distinguishes wireless resources allocated to multiple APs based on the frequency axis (time domain). Additionally or generally, a cooperative method may include Co-SR (Coordinated Spatial Reuse), which applies Spatial Reuse (SR) to at least one AP. Additionally or generally, a cooperative method may include Coordinated Beamforming (Co-BF) / nulling, which transmits by nulling interference occurring from neighbors (e.g., adjacent AP / STA, and / or OBSS AP / OBSS STA). Additionally or generally, the cooperative method may include AP selection, in which an AP among adjacent APs with good channel conditions (e.g., at least one AP located within a BSS or OBSS with excellent channel conditions) performs transmission. Additionally or generally, the cooperative method may include Joint transmission (JTX) or Joint transmission (JT), in which multiple APs (e.g., multiple APs included in the same BSS / OBSS, or multiple APs included in different BSS / OBSSs) coordinate to perform simultaneous transmission and reception, and the JTX / JT may be implemented based on Joint Beamforming or Joint MU-MIMO.
[0175] In the present disclosure, operations based on MAPC may also be referred to as multiple AP operations / multiple AP transmissions / MAPC operations / MAPC transmissions. Additionally, “MAPC operations / transmissions” and “MAPC methods (or cooperative methods)” may be used interchangeably.
[0176] The Multi-AP Coordination (MAPC) framework is described below.
[0177] The MAPC framework includes various methods and procedures such as Co-BF, Co-SR, Co-TDMA, Co-RTWT, and Co-CR, and APs operating BSS on the same 20MHz basic channel cooperate to reduce interference levels and improve network performance such as media utilization efficiency, communication stability, and latency.
[0178] If an AP has established an Agreement regarding the relevant MAPC method, it may use the MAPC method with other APs.
[0179] The common procedures / steps applicable to all cooperation methods are as follows.
[0180] - MAPC Discovery Procedure / Steps: The AP advertises and discovers the MAPC functions and parameters of other APs.
[0181] - MAPC Agreement Negotiation Procedures / Steps: APs may conduct negotiation procedures for the MAPC and establish an agreement for the MAPC. Accordingly, a set of APs with established agreements for the MAPC may be formed.
[0182] - Multiple AP Selection Procedure / Step: An AP may select an AP to perform the MAPC from the set of APs configured in the MAPC Agreement Negotiation Procedure / Step.
[0183] - Cooperation Trigger Procedure / Step: An AP can trigger MAPC for the selected AP in the Multi-AP Selection Procedure / Step.
[0184] All other specific procedures for each cooperation method are described below in "II. Procedures for Specific Multi-AP Cooperation Methods".
[0185] Figure 11 shows an example of a MAPC operation procedure including a MAPC search phase and a MAPC Agreement negotiation phase.
[0186] Referring to Fig. 11, APs with MAPC capabilities can establish MAPC consensus with neighboring APs and perform MAPC operations. In order for MAPC operations to be performed between two APs, the two APs exchange (i.e., negotiate) their respective capability information and / or requirements in advance, establish consensus based on the acquired information, and perform MAPC operations based on MAPC methods (e.g., Co-TDMA, Co-BF, Co-SR). APs with MAPC capabilities can perform a search and / or negotiation / consensus process to perform MAPC with neighboring APs, thereby establishing MAPC with neighboring APs and / or configuring MAPC. Subsequently, the APs that have configured MAPC can perform MAPC based on the information agreed upon during the negotiation process (e.g., when acquiring a TXOP).
[0187] In the present disclosure, an AP that initiates and / or triggers a MAPC operation may be referred to as a Coordinating AP (or Sharing AP (SAP)), and an AP that receives a TXOP from the Coordinating AP and / or triggers a MAPC operation may be referred to as a Coordinated AP (or Shared AP (DAP) / Triggered AP / Peer AP). Such designations (names) may be changed and are not limited.
[0188] The search and negotiation / consensus process shown in Fig. 11 is a procedure that must be performed in common for various MAPC methods. Based on the negotiation procedures performed by APs with their respective neighboring AP(s), one or more cooperative APs may exist, and before a specific AP acquires a TXOP and performs an actual MAPC operation (e.g., Co-SR / BF / TDMA), a procedure to determine whether to participate in the said MAPC operation, / or a procedure to select a target AP for cooperation, and / or a procedure to notify that a specific MAPC operation is scheduled to start needs to be performed.
[0189] Figure 12 shows an example of a MAPC operation procedure including multiple AP selection steps.
[0190] Referring to FIG. 12, the Coordinating AP that has acquired the TXOP may perform a multi-AP selection procedure. The multi-AP selection procedure may include a procedure to determine whether to participate in the said MAPC operation before performing the actual MAPC operation (e.g., Co-SR / BF / TDMA), a procedure to select the target AP for cooperation, and / or a procedure to notify that a specific MAPC operation is scheduled to start, and may also be referred to as a schedule notification procedure / step, a cooperation notification procedure / step, or cooperation polling. Depending on the type of ICF (or trigger frame / poll request frame / cooperation request frame) transmitted from the Coordinating AP and / or the type of response frame solicited by said frame, the Coordinated AP may transmit an ICR (or management frame).
[0191] I. Common Procedures for All Multi-AP Cooperation Methods
[0192] 1. MAPC Discovery Procedure / Steps
[0193] In the MAPC discovery procedure / step, the AP advertises and discovers the MAPC functions and parameters of other APs.
[0194] An AP can advertise its MAPC capabilities, common MAPC parameters, and MAPC method-specific parameters by sending a MAPC Discovery Request frame to a broadcast address or to other APs as a frame individually addressed.
[0195] When an AP receives a request MAPC Discovery Request frame from a sending AP, the AP must respond by sending a MAPC Discovery Response frame to a broadcast address or by sending a management frame individually addressed to the sending AP. The Dialog Token field value of the MAPC Discovery Response frame sent by the AP must be set to be the same as the Dialog Token field value of the request MAPC Discovery Request frame.
[0196] An AP transmitting a MAPC Discovery Request frame or a MAPC Discovery Response frame may include a Per-Scheme Profile subelement for each MAPC scheme that signals a function to the reported MAPC element. The AP must not include a MAPC Scheme Request Set field in the reported Per-Scheme Profile subelement.
[0197] If an AP sending a MAPC Discovery Request frame or a MAPC Discovery Response frame to a peer AP sets the MAPC Security Supported field included in the MAPC element to 1, the AP must include the RSNE field and the RSNXE field in the Security Profile subelement of the MAPC element.
[0198] 2. MAPC Agreement Negotiation Procedures / Stages
[0199] In the MAPC Agreement negotiation process / stage, APs negotiate with each other to establish the MAPC Agreement.
[0200] A MAPC requesting AP is an AP that initiates MAPC negotiations with other APs regarding one or more MAPC schemes.
[0201] If the peer AP sets the corresponding field for support for that MAPC method in the MAPC Common Info field reported in the MAPC Discovery Request frame, MAPC Discovery Response frame, or MAPC Negotiation Request frame to 0, the MAPC requesting AP does not initiate MAPC negotiation with the peer AP for a specific MAPC method.
[0202] The MAPC response AP is the AP that responds to the MAPC request AP.
[0203] A MAPC requesting AP can initiate MAPC negotiation for one or more MAPC schemes by sending individually addressed MAPC Negotiation Request frames to other APs. The MAPC Negotiation Request frame must include a MAPC element containing one or more Per-Scheme Profile subelements in the MAPC Schemes Info field.
[0204] Additionally, if the MAPC request AP does not indicate support for the corresponding MAPC scheme in the MAPC Capabilities field included in the MAPC element, it must not include a Per-Scheme Profile subelement for that MAPC scheme in the MAPC element. If a Per-Scheme Profile subelement is included in the MAPC element, it must include a MAPC Scheme Request Set field containing one or more MAPC Scheme Request fields.
[0205] Each Per-Scheme Profile subelement in the MAPC Schemes Info field of the MAPC Negotiation Request frame conveys a request for a specific MAPC scheme.
[0206] Upon receiving an individually addressed MAPC Negotiation Request frame from the MAPC requesting AP, the MAPC responding AP must respond by sending an individually addressed MAPC Negotiation Response frame to the MAPC requesting AP. The value of the Dialog Token field in the MAPC Negotiation Response frame must be set to be identical to the value of the Dialog Token field in the MAPC Negotiation Request frame. If the MAPC responding AP accepts one or more of the requests included in the received MAPC Negotiation Request frame, the status code field is set to SUCCESS.
[0207] Otherwise, the MAPC response AP sets the appropriate rejection status code in the corresponding status field. The MAPC Negotiation Response frame must include a MAPC element containing one Per-Scheme Profile subelement in the MAPC Schemes Info field for each Per-Scheme Profile subelement included by the MAPC request AP in the MAPC Negotiation Request frame. In the MAPC Negotiation Response frame, each Per-Scheme Profile subelement must include a MAPC Scheme Request field where the MAPC Operation Type field is set to 3, 4, or 5. If the MAPC Operation Type field is set to 3 or 4, the MAPC Request Parameter Set field is not included. To accept the request, the MAPC Operation Type field must be set to 3. To reject the request, the MAPC Operation Type field must be set to 4. To reject the request and indicate that the MAPC response AP may accept subsequent requests using the same parameter values included in the MAPC Request Parameter Set, the MAPC Operation Type field must be set to 5.
[0208] To request the establishment of a new Agreement, the MAPC requesting AP must set the MAPC Operation Type field to 0. If the MAPC Operation Type field is set to 0, the MAPC Request Parameter Set is included for each specific MAPC method in accordance with the rules defined in "II. Procedures for Specific Multi-AP Cooperation Methods".
[0209] If the MAPC request AP sets the corresponding field that enables the establishment of a MAPC Agreement for the corresponding MAPC method in the MAPC Discovery Request frame, MAPC Discovery Response frame, or MAPC Negotiation Request frame to 0, the MAPC response AP cannot request the establishment of a new Agreement for a specific MAPC method.
[0210] If the MAPC responding AP accepts a request to establish a new MAPC Agreement for a specific MAPC method, the MAPC requesting AP and the MAPC responding AP have established a MAPC Agreement for that specific MAPC method.
[0211] For example, when the MAPC requesting AP transmits a MAPC Negotiation Request frame containing a Co-BF profile and a Co-RTWT profile, the Co-BF profile contains a MAPC method request field for the request to establish a new agreement (MAPC Operation Type is set to 0), and the Co-RTWT profile contains three MAPC method request fields for the request to establish a new agreement. The MAPC responding AP responds with a MAPC Negotiation Response frame containing a Co-BF profile and a Co-RTWT profile. The Co-BF profile contains a MAPC method request field indicating the response to the request to establish an agreement, and the Co-RTWT profile contains three MAPC method request fields indicating the response to the establishment of the agreement. In this example, the MAPC requesting AP and the MAPC responding AP can establish up to one Co-BF Agreement and up to three Co-RTWT Agreements (one per R-TWT schedule).
[0212] The MAPC request AP and the MAPC response AP can establish up to one MAPC Agreement for Co-BF, Co-SR, and Co-TDMA, respectively, and up to one MAPC Agreement per R-TWT schedule for Co-RTWT.
[0213] 3. Multiple AP Selection Procedure / Steps
[0214] In the multi-AP selection procedure / step, an AP may perform cooperative transmission by selecting one or more other APs from the set of APs that have established a MAPC Agreement. The multi-AP selection procedure / step may include a polling step (e.g., Co-TDMA) and / or an invite step (e.g., Co-BF / Co-SR). The multi-AP selection procedure / step is also referred to as the schedule announcement procedure / step, cooperative announcement procedure / step, or cooperative polling. Further details are described in "II. Procedures for Specific Multi-AP Cooperative Methods" below.
[0215] 4. Collaboration Triggering Procedures / Steps
[0216] In the cooperative triggering procedure / step, the AP initiates cooperative transmission by sending a trigger frame to another AP, and performs cooperative transmission with that AP upon receiving a response frame for the trigger frame from that AP. Details are described below in "II. Procedure for Specific Multi-AP Cooperative Methods."
[0217] II. Procedures for Specific Multi-AP Cooperation Methods
[0218] 1. Coordinated beamforming (Co-BF)
[0219] The purpose of Coordinated Beamforming (Co-BF) is to make media usage more efficient by allowing two APs with multiple transmission chains to transmit simultaneously to non-AP STAs connected to each AP. Each AP transmits to connected non-AP STAs within its own BSS, while simultaneously minimizing interference to non-AP STAs connected to other APs by utilizing the CSI of the channel between each AP and the other AP receiving STA in the Co-BF transmission. The number of APs participating in the Co-BF transmission is two. The maximum number of spatial streams for each receiving STA in the Co-BF transmission is two. The AP must obtain the CSI required to perform the Co-BF transmission.
[0220] A Co-BF cooperative AP is an AP where dot11CoBFOptionImplemented is true, acquires a TXOP, and sends a Co-BF Invite frame to invite other APs to perform a Co-BF transmission. A Co-BF cooperative AP is an AP where dot11CoBFOptionImplemented is true, receives a Co-BF Invite frame from a Co-BF cooperative AP, and performs a Co-BF transmission. The Co-BF transmission sequence is initiated by the Co-BF cooperative AP. An STA where dot11CoBFOptionImplemented is false, or where dot11CoBFOptionImplemented is true but Co-BF behavior is disabled, is not scheduled for the Co-BF sounding sequence or Co-BF transmission sequence by the connected AP. A non-AP STA where dot11CoBFOptionImplemented is true can enable or disable Co-BF behavior. An AP must not initiate a Co-BF transmission sequence with another AP unless the two APs establish a MAPC Agreement on Co-BF according to the Co-BF negotiation procedure or other methods.
[0221] When a non-AP STA that supports Co-BF behavior (re)connects with an AP, Co-BF behavior is disabled by default. UHR non-AP STAs that support Co-BF behavior and wish to enable or disable Co-BF behavior must follow the rules regarding the frequency of sending such requests. The connected AP may accept the requests.
[0222] (1) Co-BF negotiation (i.e., MAPC Agreement negotiation procedure / steps for Co-BF)
[0223] The AP requesting the MAPC must include a Co-BF profile in the MAPC element contained in the MAPC Negotiation Request frame that initiates MAPC Agreement negotiations for the Co-BF Agreement. The Co-BF profile must include one MAPC Scheme Request field.
[0224] When the MAPC Response AP responds to the MAPC Request AP during MAPC Agreement negotiation for a Co-BF Agreement, it must include a Co-BF profile in the MAPC element contained within the MAPC Negotiation Response frame. The Co-BF profile must include one MAPC Scheme Request field.
[0225] The MAPC requesting AP must not set the MAPC Operation Type field to 1 or 2 if a Co-BF Agreement has not been established between the MAPC requesting AP and the MAPC responding AP. If a Co-BF Agreement has already been established between the MAPC requesting AP and the MAPC responding AP, the MAPC requesting AP must not set the MAPC Operation Type field to 0.
[0226] The MAPC response AP must not set the MAPC Operation Type field included in the MAPC Scheme Request field of the Co-BF profile included in the MAPC Negotiation Response frame to 5.
[0227] (2) Co-BF invitation stage (i.e., Co-BF multiple AP selection procedure / stage)
[0228] The Co-BF cooperating AP must initiate Co-BF transmission with the Co-BF cooperating AP by sending a Co-BF Invite frame to the Co-BF cooperating AP. The Co-BF Invite frame must be a BSRP NTB trigger frame. The TA field of the Co-BF Invite frame must be set to the MAC address of the Co-BF cooperating AP, and the RA field of the Co-BF Invite frame must be set to the MAC address of the Co-BF cooperating AP. The Co-BF Invite frame requests a Co-BF response frame from the Co-BF cooperating AP specified by the Co-BF Invite frame.
[0229] A Co-BF cooperative AP that receives a Co-BF Invite frame must send a Co-BF acknowledgment frame to the Co-BF cooperative AP after aSIFSTime has passed since the PPDU delivering the Co-BF Invite frame was terminated. The Co-BF acknowledgment frame must be a multi-terminal BlockAck frame. The TA field of the Co-BF acknowledgment frame must be set to the MAC address of the Co-BF cooperative AP, and the RA field of the Co-BF acknowledgment frame must be set to the MAC address of the Co-BF cooperative AP.
[0230] (3) Co-BF cooperation triggering procedure / step
[0231] The Co-BF cooperative AP must send a Co-BF trigger frame to the Co-BF cooperative AP, and then the Co-BF cooperative AP and the Co-BF cooperative AP simultaneously send data PPDUs.
[0232] 2. Coordinated spatial reuse (Co-SR)
[0233] The purpose of Coordinated Spatial Reuse (Co-SR) is to allow for more efficient use of the medium by transmitting simultaneously from multiple APs using transmission power control. The number of APs participating in Co-SR transmission is 2.
[0234] A Co-SR cooperating AP is an AP where dot11CoSROptionImplemented is true, acquires a TXOP, and initiates a Co-SR transport with another AP. A Co-SR cooperating AP is an AP where dot11CoSROptionImplemented is true, and joins the Co-SR transport initiated by the Co-SR cooperating AP. The Co-SR transport must be initiated by the Co-SR cooperating AP. An AP must not perform a Co-SR transport to a STA where dot11CoSROptionImplemented is false or where dot11CoSROptionImplemented is true but Co-SR operation is disabled. A non-AP STA where dot11CoSROptionImplemented is true can enable or disable Co-SR operation.
[0235] Unless the two APs establish a MAPC Agreement on Co-SR through Co-SR negotiation or other methods, an AP must not initiate Co-SR transmission with another AP.
[0236] When a non-AP STA that supports Co-SR operation (re)connects with an AP, Co-SR operation is disabled by default. UHR non-AP STAs that support Co-SR operation and wish to enable or disable Co-SR operation must follow the rules regarding the frequency of sending such requests. The connected AP may accept the requests.
[0237] (1) Co-SR negotiation (i.e., MAPC Agreement negotiation procedure / steps for Co-SR)
[0238] The AP requesting the MAPC must include the Co-SR profile in the MAPC element contained in the MAPC Negotiation Request frame that initiates MAPC Agreement negotiations for the Co-SR Agreement.
[0239] The Co-SR profile must include one MAPC Scheme Request field.
[0240] When the MAPC Response AP responds to the MAPC Request AP during MAPC Agreement negotiation for a Co-SR Agreement, it must include the Co-SR profile in the MAPC element contained in the MAPC Negotiation Response frame. The Co-SR profile must include one MAPC Scheme Request field.
[0241] The MAPC requesting AP must not set the MAPC Operation Type field to 1 or 2 if a Co-SR Agreement has not been established between the MAPC requesting AP and the MAPC responding AP. If a Co-SR Agreement has already been established between the MAPC requesting AP and the MAPC responding AP, the MAPC requesting AP must not set the MAPC Operation Type field to 0.
[0242] The MAPC response AP must not set the MAPC Operation Type field included in the MAPC Scheme Request field of the Co-SR profile included in the MAPC Negotiation Response frame to 5.
[0243] (2) Co-SR invitation stage (i.e., Co-SR multiple AP selection procedure / stage)
[0244] The Co-SR cooperating AP must initiate Co-SR transmission with the Co-SR cooperating AP by sending a Co-SR Invite frame to the Co-SR cooperating AP. The Co-SR Invite frame must be a BSRP NTB trigger frame. The TA field of the Co-SR Invite frame must be set to the MAC address of the Co-SR cooperating AP, and the RA field of the Co-SR Invite frame must be set to the MAC address of the Co-SR cooperating AP. The Co-SR Invite frame requests a Co-SR response frame from the Co-SR cooperating AP specified by the Co-SR Invite frame.
[0245] A Co-SR cooperating AP that receives a Co-SR Invite frame must send a Co-SR acknowledgment frame to the Co-SR cooperating AP after aSIFSTime has elapsed since the PPDU delivering the Co-SR Invite frame was terminated. The Co-SR acknowledgment frame must be a multi-terminal BlockAck frame. The TA field of the Co-SR acknowledgment frame must be set to the MAC address of the Co-SR cooperating AP, and the RA field of the Co-SR acknowledgment frame must be set to the MAC address of the Co-SR cooperating AP.
[0246] (3) Co-SR Triggering Procedure / Steps
[0247] The Co-SR cooperating AP must send a Co-SR trigger frame to the Co-SR cooperating AP, and then the Co-SR cooperating AP and the Co-SR cooperating AP simultaneously send data PPDUs.
[0248] 3. Coordinated time division multiple access (Co-TDMA)
[0249] Coordinated time division multiple access (Co-TDMA) procedures allow an AP with dot11CoTDMAOptionImplemented true to sequentially allocate a portion of the acquired TXOPs to one or more non-collocated APs with dot11CoTDMAOptionImplemented true. As part of the Co-TDMA procedure, an AP that receives a time allocation from another AP exchanges one or more PPDUs during the allocated time.
[0250] If any of the following conditions are met, the AP does not initiate the Co-TDMA procedure with another AP.
[0251] - When there is no MAPC Agreement for Co-TDMA between APs.
[0252] - When the default 20MHz channels of the BSS of the two APs are different.
[0253] - When two APs belong to the same collocated AP set.
[0254] Co-TDMA negotiations for establishing, updating, and releasing the Co-TDMA Agreement must be carried out through MAPC Agreement negotiations / Co-TDMA negotiations or other means.
[0255] Figure 13 shows an example of a Co-TDMA procedure.
[0256] Referring to FIG. 13, the Co-TDMA procedure may include a polling step (i.e., a multiple AP selection procedure / step for Co-TDMA), a TXOP allocation step (i.e., a cooperative trigger procedure / step for Co-TDMA), and / or a TXOP return step. Prior to the Co-TDMA procedure, a MAPC discovery procedure / step and / or Co-TDMA negotiation (i.e., a MAPC Agreement negotiation procedure / step for Co-TDMA) may be performed.
[0257] (1) Co-TDMA negotiation (i.e., MAPC Agreement negotiation procedure / step in the case of Co-TDMA)
[0258] An AP requesting Co-TDMA must include the Co-TDMA profile in the MAPC element contained in the MAPC Negotiation Request frame. The Co-TDMA profile must include a single MAPC Scheme Request field.
[0259] The Co-TDMA requesting AP must not set the MAPC Operation Type field to 0 if a Co-TDMA Agreement has already been established between the Co-TDMA requesting AP and the Co-TDMA responding AP.
[0260] If a Co-TDMA Agreement is not established between the Co-TDMA requesting AP and the Co-TDMA responding AP, the Co-TDMA requesting AP must not set the MAPC Operation Type field to 1 or 2.
[0261] An AP that responds to a Co-TDMA requesting AP during MAPC Agreement negotiation for a Co-TDMA Agreement is called a Co-TDMA responding AP. This is a MAPC responding AP and must respond to the Co-TDMA requesting AP according to the rules defined in the MAPC Agreement negotiation. The Co-TDMA responding AP must not set the MAPC Operation Type field included in the MAPC Scheme Request field of the Co-TDMA profile included in the MAPC Negotiation Response frame to 5.
[0262] An AP that has established a Co-TDMA Agreement with a peer AP can operate as both a Co-TDMA cooperative AP and a Co-TDMA cooperative AP.
[0263] (2) Polling step (i.e., multiple AP selection procedure / step for Co-TDMA)
[0264] The Co-TDMA cooperative AP must indicate its intention to allocate a portion of the acquired TXOP to another AP in the ICF transmitted at the start of the TXOP. The ICF polls one or more APs that have established a MAPC Agreement for Co-TDMA with the Co-TDMA cooperative AP, requests a response from the polled APs, and confirms the intention to receive a time allocation from the Co-TDMA cooperative AP within the TXOP.
[0265] A Co-TDMA cooperative AP may request a Co-TDMA ICR in a TB PPDU from another AP that has entered into a MAPC Agreement for Co-TDMA. However, this is only possible if the AP to be polled indicates that it supports the transmission of a Co-TDMA ICR in a TB PPDU by setting the AP TB PPDU Response Support field of the MAPC element to 1.
[0266] An ICF that polls an AP as part of the Co-TDMA process and requests a Co-TDMA ICR from the polled AP in the TB PPDU is called a Co-TDMA TB ICF.
[0267] The Co-TDMA TB ICF must be a BSRP trigger frame.
[0268] An ICF that requests a Co-TDMA ICR for a non-HT PPDU or a non-HT redundant PPDU from a polled AP as part of the Co-TDMA procedure is called a Co-TDMA NTB ICF.
[0269] The Co-TDMA NTB ICF is a BSRP NTB trigger frame, and the GI and HE / UHR-LTF type fields are set to 3.
[0270] To identify the polled AP in the Co-TDMA TB ICF or Co-TDMA NTB ICF, the Co-TDMA cooperative AP sets the AID12 field of the user information field to the AP ID of the polled AP assigned by the Co-TDMA cooperative AP.
[0271] The Duration field of the Co-TDMA TB ICF and Co-TDMA NTB ICF is set to the sum of the time required to transmit the requested Co-TDMA ICR from the AP polled in 1 SIFS.
[0272] When a Co-TDMA cooperative AP transmits a Co-TDMA TB ICF, the AP must set the Feedback Type field of the Feedback User Info field of the Co-TDMA TB ICF to 3.
[0273] When a Co-TDMA cooperative AP transmits a Co-TDMA NTB ICF, the AP must set the Feedback Type field of the User Info field directed to the polled AP to 3.
[0274] The polled AP must transmit a Co-TDMA ICR in response to a received Co-TDMA TB ICF or Co-TDMA NTB ICF containing a User Info field with an AID12 field set to the AP ID of the polled AP assigned by the Co-TDMA cooperative AP.
[0275] The Co-TDMA ICR must be a Multi-STA BlockAck frame containing the following fields in the Per AID TID Info field.
[0276] ― The Feedback Type field must be set to 3.
[0277] ― The AID11 field must be set to 0.
[0278] ― The Ack Type field and TID field must be set to 0 and 13, respectively.
[0279] ― The TXOP Sharing Solicited field of the Feedback field should be set to 1 if the polled AP intends to receive a time allocation from the Co-TDMA cooperating AP during the current TXOP. Otherwise, it should be set to 0.
[0280] If a Co-TDMA cooperative AP does not receive a Co-TDMA ICR from a polled AP, the Co-TDMA cooperative AP should assume that the polled AP does not want to receive a time allocation from the Co-TDMA cooperative AP during the current TXOP.
[0281] The polled AP can determine the value to be set in the "TXOP Sharing Solicited" field of the multi-terminal BlockAck frame using the duration specified in the "Max TXOP Allocation Under Consideration" field of the Co-TDMA ICF.
[0282] When performing Co-TDMA Agreement according to the rules defined in MAPC negotiation and Co-TDMA negotiation, the AP that receives the MAPC Negotiation Request frame can determine the overlapping BSS bandwidth based on the bandwidth setting information included in the bandwidth control field.
[0283] (3) TXOP allocation step (i.e., Co-TDMA cooperative triggering procedure / step)
[0284] To allocate a portion of the acquired TXOPs, the Co-TDMA cooperative AP must send a MU-RTS TXS trigger frame with a TXS mode field of 2 only to the polled AP that is not collocated with the Co-TDMA cooperative AP and has received a Co-TDMA ICR with a TXOP sharing request field of 1.
[0285] Time allocation for the Co-TDMA cooperative AP must begin at the end of the PPDU containing the MU-RTS TXS trigger frame.
[0286] The duration field of the MU-RTS TXS trigger frame must be set to the value of the time required to send the requested CTS response frame in 1 SIFS plus the time required to send the CTS response frame.
[0287] To identify the Co-TDMA cooperative AP to which a portion of the acquired TXOP will be allocated, the Co-TDMA cooperative AP sets the AID12 field of the user information field of the MU-RTS TXS trigger frame to the AP ID of the Co-TDMA cooperative AP allocated by the Co-TDMA cooperative AP.
[0288] When a Co-TDMA cooperative AP receives a MU-RTS TXS trigger frame containing a user information field from a Co-TDMA cooperative AP, and the AP ID of the Co-TDMA cooperative AP is included in the AID12 field of the user information field, the Co-TDMA cooperative AP may exchange one or more PPDUs within the time allocation specified in the MU-RTS TXS trigger frame. The first PPDU of this exchange must transmit a CTS frame.
[0289] The time allocated to the Co-TDMA cooperative AP identified in the MU-RTS TXS trigger frame is specified in the allocation period field of the MU-RTS TXS trigger frame.
[0290] The Co-TDMA cooperative AP can determine the time allocated to the Co-TDMA cooperative AP within the acquired TXOP.
[0291] All frame exchanges between the Co-TDMA cooperative AP and the non-AP connected during the allocated time must be performed in an AC of the same or higher priority as the Primary AC field of the Co-TDMA TB ICF or the Primary AC of the acquired TXOP indicated in the Co-TDMA NTB ICF transmitted by the Co-TDMA cooperative AP during the polling phase of Co-TDMA.
[0292] In a MU-RTS TXS trigger frame that assigns a TXOP to a Co-TDMA cooperative AP, the Co-TDMA cooperative AP must not assign a RU to the Co-TDMA cooperative AP except for the portion where the BSS bandwidth of the Co-TDMA cooperative AP and the PPDU bandwidth transmitting the MU-RTS TXS trigger frame overlap.
[0293] PPDU transmitting a CTS frame transmitted from a Co-TDMA cooperative AP must be transmitted through the 20MHz channel specified in the RU allocation field within the user information field of the MU-RTS TXS trigger frame that allocated time to the Co-TDMA cooperative AP.
[0294] During the time allocated by the Co-TDMA cooperative AP, the Co-TDMA cooperative AP addressed by the MU-RTS TXS trigger frame must not transmit a PPDU using a subchannel other than the subchannel used when transmitting the CTS frame in response to the MU-RTS TXS trigger frame.
[0295] (4) TXOP return step
[0296] If the Co-TDMA cooperative AP indicates TXOP return support by setting the Rx TXOP return support field of the MAPC element to 1, it may return to the Co-TDMA cooperative AP for the remainder of the allocated time (if any). Otherwise, the Co-TDMA cooperative AP does not return the TXOP. If the Co-TDMA cooperative AP is required to return the TXOP to the Co-TDMA cooperative AP, all NAVs set by the Co-TDMA cooperative AP during the allocated time must be terminated before the AP returns the TXOP to the Co-TDMA cooperative AP. Otherwise, all NAVs set by the Co-TDMA cooperative AP during the allocated time are terminated before the allocated period ends.
[0297] If a Co-TDMA cooperative AP needs to return a TXOP, it must not transmit a CF-End frame to cut the TXOP within the allocated time.
[0298] As part of Co-TDMA operation, when a Co-TDMA cooperative AP returns a TXOP to a Co-TDMA cooperative AP, it must direct the TXOP return within the allotted time via a CAS control field where the RDG / More PPDU field is 0. This CAS control field is included in the HE variant HT control field in the MAC header of a MAPC TXOP return frame that contains only the Action field in the frame body.
[0299] When a Co-TDMA cooperative AP receives a TXOP return instruction from a Co-TDMA cooperative AP, it must respond with an Ack frame.
[0300] Other MAPC Public Action frames must not include a CAS control field in the HT control field of the frame MAC header.
[0301] A Co-TDMA cooperative AP that indicates TXOP return support by setting the Rx TXOP return support field in the MAPC element to 1 and requests a TXOP return from the Co-TDMA cooperative AP must set the TXOP return request field of the Co-TDMA TB ICF or Co-TDMA NTB ICF to 1. Otherwise, the Co-TDMA cooperative AP must set the TXOP return request field to 0.
[0302] The Co-TDMA cooperative AP must return a TXOP after receiving a Co-TDMA TB ICF or Co-TDMA NTB ICF with the TXOP return request field set to 1.
[0303] Meanwhile, trigger frames are defined for the purpose of the AP receiving TB PPDU from the STA during MU transmission situations. For example, the basic trigger frame can be used for the purpose of triggering to receive UL MU transmissions of data from the STAs, and the MU-BAR trigger frame can be used for the purpose of receiving UL MU transmissions of BlockAck frames from the STAs. The BSRP trigger frame can be used for the purpose of receiving buffer status reports for connected STAs.
[0304] In IEEE 802.11bn (or UHR), various features (or feature types) such as In-Device Coexistence (IDC), Dynamic Power Saving (DPS), Multiple AP Coordination (MAPC), and / or Non-Primary Channel Access (NPCA) are discussed, and initial control frame (ICF), initial control response (ICR) frame (or simply ICR), and / or control response frame (CRF) may be defined as control frames for these features. In this case, existing trigger frames / response frames defined for ICF, ICR, and CRF may be reused and / or extended, and frame exchange sequences utilizing ICF, ICR, and CRF may be defined.
[0305] In the present disclosure, "frame exchange (FE)" may include frame transmission and / or reception operations between STAs. The STA may be an AP or a non-AP STA. Herein, the frame may include various types of frames (e.g., data frame, control frame, management frame).
[0306] Figure 14 shows an example of a case where a BSRP TF containing transmission information for MAPC operation is transmitted as an ICF.
[0307] Referring to FIG. 14, STAs that receive a BSRP TF used as an ICF can transmit a response frame containing control information for an IDC and a MAPC in addition to a BSR. That is, the AP can include information (or delivered info) for MAPC operations (e.g., Co-BF, Co-SR, Co-TDMA) within the BSRP TF acting as an ICF. Additionally, the AP can include instructions within the BSRP TF to solicit a response for additional control information (e.g., IDC, DPS, MAPC, and / or NPCA), and STAs supporting IDC, DPS, MAPC, and / or NPCA can transmit a response frame containing the requested control information to the AP in addition to the BSR. For example, STA 1 supporting IDC can transmit a response frame containing control information for the requested IDC to the AP in addition to the BSR. For example, STA 2 that supports MAPC can send a response frame containing control information for the requested MAPC to the AP in addition to BSR.
[0308] In the present disclosure, the AP transmitting the ICF for MAPC operation is referred to as the Coordinating AP (or Sharing AP (SAP)), and the AP addressed and / or polled in the said ICF (e.g., the AP selected in a multiple AP selection procedure / step) is referred to as the Polled AP (PAP). Additionally, among one or more polled APs, the AP on which the MAPC operation is finally performed is referred to as the Coordinated AP (CAP).
[0309] According to various embodiments of the present disclosure, an ICF that may be transmitted to start and / or trigger a MAPC operation of each AP in a MAPC environment may include information for a MAPC operation. In various embodiments, information that may be included in the ICF for a MAPC operation is proposed, and / or a method of including said information in a BSRP trigger frame is proposed.
[0310] According to various embodiments of the present disclosure, a structure of an ICR frame (e.g., a management frame) transmitted in response to an ICF transmitted from a Coordinating AP in a procedure for determining participation in an MAPC operation (e.g., polling / multiple AP selection / cooperation announcement / schedule announcement) and / or a method for transmitting said frame are provided. Based on information contained in the ICR transmitted from the Coordinated AP(s), the Coordinating AP can determine whether the Coordinated APs intend to participate in the MAPC operation and can select an appropriate Coordinated AP.
[0311] In the present disclosure, ICF / ICR may be transmitted / received in multiple AP selection procedures / steps (e.g., a polling step (for Co-TDMA), an invite step (for Co-BF / Co-SR). For example, the ICF may include an ICF in the polling step for Co-TDMA, a Co-BF invite frame in the invite step for Co-BF, and / or a Co-SR invite frame in the invite step for Co-SR. For example, the ICR may include an ICR in the polling step for Co-TDMA, a Co-BF responding frame in the invite step for Co-BF, and / or a Co-SR responding frame in the invite step for Co-SR.
[0312] In the present disclosure, an ICF / ICR may be transmitted / received in a cooperative triggering procedure / step. For example, the ICF may include a MU-RTS TXS trigger frame in a TXOP allocation step for Co-TDMA, a Co-BF trigger frame in a cooperative triggering procedure / step for Co-BF, and / or a Co-SR trigger frame in a cooperative triggering procedure / step for Co-SR. For example, the ICR may include a CTS frame in a TXOP allocation step for Co-TDMA, a response frame to a Co-BF trigger frame in a cooperative triggering procedure / step for Co-BF, and / or a response frame to a Co-SR trigger frame in a cooperative triggering procedure / step for Co-SR.
[0313] In the present disclosure, control information can be used interchangeably with feedback information.
[0314] In the present disclosure, “field” and “subfield” may be used interchangeably.
[0315] Specific designations (names) used in this disclosure may be changed and are not limited thereto.
[0316] FIG. 15 shows an example of a method performed by a first AP that transmits information for MAPC.
[0317] Referring to Fig. 15, in step S1501, the first AP can establish an agreement for MAPC with one or more other APs.
[0318] In step S1503, the first AP may transmit an ICF to the second AP among one or more other APs. The ICF may include information regarding the transmission power proposed for the second AP.
[0319] In step S1505, the first AP can receive an ICR for the ICF from the second AP.
[0320] In step S1507, the first AP can transmit a trigger frame to the second AP to trigger the MAPC.
[0321] In step S1509, the first AP can perform MAPC with the second AP based on the transmission power proposed for the second AP.
[0322] According to various embodiments, the first AP may perform a multiple AP selection procedure for selecting one or more target APs for MAPC from among one or more other APs. In the multiple AP selection procedure, the first AP may transmit an ICF to the second AP and receive an ICR from the second AP. The second AP may be included among one or more target APs.
[0323] According to various embodiments, the first AP can determine the transmission power of the first AP based on the transmission power proposed for the second AP. The first AP can perform MAPC with the second AP based on the transmission power of the first AP.
[0324] According to various embodiments, the first AP can perform MAPC based on an MAPC method. The MAPC method may include at least one of Co-BF (coordinated beamforming), Co-SR (coordinated spatial reuse), Co-TDMA (coordinated time division multiple access), Co-RTWT (coordinated restricted target wake time), or Co-CR (coordinated channel recommendation).
[0325] According to various embodiments, the MAPC method may be Co-BF or Co-SR. In this case, while the second AP performs transmission in a time interval to one or more STAs connected to the second AP, the first AP may perform transmission in a time interval to one or more STAs connected to the first AP.
[0326] According to various embodiments, the MAPC method may be Co-TDMA. Based on Co-TDMA: frame exchange between a first AP and one or more STAs connected to the first AP is performed in a first time interval, and frame exchange between a second AP and one or more STAs connected to the second AP may be performed in a second time interval different from the first time interval.
[0327] According to various embodiments, the ICF may be a Co-BF invite frame, a Co-SR invite frame, or a BSRP (buffer status report poll) trigger frame in the polling step for Co-TDMA.
[0328] According to various embodiments, the transmission power proposed for the second AP may include the maximum transmission power of the second AP that is limited for the second AP.
[0329] According to various embodiments, the maximum transmission power can be set so that the transmission of the second AP does not interfere with the transmission of the first AP.
[0330] According to various embodiments, information regarding the transmission power proposed for the second AP may be included in the common information field, user information field, or special user information field of the ICF.
[0331] According to various embodiments, the ICF may further include at least one of information about the cooperation period during which the MAPC is performed, or information about an acknowledgment (Ack) policy applied to the second AP and one or more STAs connected to the second AP.
[0332] According to various embodiments, the ACK policy may indicate a Normal ACK, an Implicit BAR (block ACK request), or a Block ACK.
[0333] According to various embodiments, the cooperation period may include at least one of: a first ACK period required for an ACK sequence between a first AP and one or more STAs connected to the first AP; or a second ACK period allowed for an ACK sequence between a second AP and one or more STAs connected to the second AP. An ACK sequence between the first AP and one or more STAs connected to the first AP may include transmission of the first AP and reception of an ACK for transmission of the first AP. An ACK sequence between the second AP and one or more STAs connected to the second AP may include transmission of the second AP and reception of an ACK for transmission of the second AP.
[0334] According to various embodiments, the second Ack period may be the maximum Ack sequence period allowed for the second AP.
[0335] According to various embodiments, the ACK policy may be applied during the second ACK period.
[0336] FIG. 16 shows an example of a method performed by a second AP receiving information for MAPC.
[0337] Referring to FIG. 16, in step S1601, the second AP can establish an agreement for MAPC with one or more other APs.
[0338] In step S1603, the second AP may receive an ICF from the first AP among one or more other APs. The ICF may include information regarding the transmission power proposed for the second AP.
[0339] In step S1605, the second AP can transmit the ICR for the ICF to the first AP.
[0340] In step S1607, the second AP can receive a trigger frame from the first AP to trigger the MAPC.
[0341] In step S1609, the second AP can perform MAPC with the first AP based on the transmission power proposed for the second AP.
[0342] A detailed description regarding the transmission of information for MAPC is provided below.
[0343] The present disclosure provides a method and / or examples of control information for MAPC operations within a trigger frame (e.g., BSRP TF) that may be transmitted from a Coordinating AP in an MAPC environment. In the present disclosure, the TF may be used for an ICF that may be transmitted at the start of a TXOP, and / or a control request frame (CRF) that may be transmitted after the start of a TXOP.
[0344] Contents of control / feedback / transmission information included within the ICF (or control request frame)
[0345] Method-specific information related to common and / or MAPC-based technologies for MAPC operation may be defined. One or more pieces of information, fields, and / or signaling bit(s) may be added or defined within the ICF and / or control request frame. Additionally, the specific designations (names) of said information, fields, and / or signaling bit(s) may be changed.
[0346] Within a trigger frame serving as an ICF / CRF that can be commonly used in key functions for UHR (e.g., IDC, DPS, MAPC, NPCA, etc.), there may be a field for distinguishing / indicating the purpose of the function for which the TF was transmitted, and a field containing information about the function according to said distinction / indication. In the present disclosure, such fields may include a control information (or feedback) type field and / or a control (or feedback) information field. Depending on the distinction / indication in the control information (or feedback) type, the control (or feedback) information field may contain common or per-user information for the corresponding function.
[0347] Figure 17 shows examples of TF formats including a control information (or feedback) type field and / or a control (or feedback) information field.
[0348] Referring to FIG. 17, the ICF / CRF may include at least one of a control information type field, a common control information field, or a user-specific control information field.
[0349] - Control Information Type (or Feedback Type): Indicates the UHR function type for the information contained in the ICF / CRF and / or the UHR function type to be received from the receiving device. That is, the Control Information Type (or Feedback Type) field may indicate the purpose (e.g., MAPC) for which the BSRP TF was transmitted.
[0350] For example, according to a new subtype definition utilizing the reserved value (e.g., 3) of the GI And HE / EHT-LTF Type / TXS Mode field, the Reserved fields / bits in the common information field can be utilized for the control information type (or feedback type) field.
[0351] Additionally or alternatively, the EHT Reserved field of the common information field and / or the Reserved field may be utilized for the control information type (or feedback type) field.
[0352] Additionally or alternatively, a UHR Special User Info field (e.g., AID12 >= 2008) that can be newly defined for UHR may include a control information type (or feedback type) field / information.
[0353] For example, the Control Information Type (or Feedback Type) field can indicate the type for which a BSRP TF, which can be utilized as an ICF or CRF in DPS, IDC, NPCA, MAPC, etc., was transmitted. A value of 0 in the Control Information Type (or Feedback Type) field may indicate that the TF is for MAPC operation. A value of 1 in the Control Information Type (or Feedback Type) field may indicate that the TF is for DPS operation. A value of 2 in the Control Information Type (or Feedback Type) field may indicate that the TF is for IDC operation. A value of 3 in the Control Information Type (or Feedback Type) field may indicate that the TF is for NPCA operation.
[0354] For example, the Control Information Type (or Feedback Type) field may indicate the type for which the corresponding TF (e.g., BSRP TF) was transmitted for a specific use within a specific function (e.g., MAPC). A value of 0 in the Control Information Type (or Feedback Type) field may indicate that the corresponding TF was transmitted to an ICF in the MAPC. A value of 1 in the Control Information Type (or Feedback Type) field may indicate that the corresponding TF was transmitted to a coordination triggering (co-triggering) frame in the MAPC. A value of 2 in the Control Information Type (or Feedback Type) field may indicate that the corresponding TF was transmitted to a CRF in the MAPC.
[0355] Additionally or alternatively, the control information type (or feedback type) field may not indicate a single control information / feedback type, but may indicate that the TF has been transmitted for one or more operational purposes, such as DPS, IDC, NPCA, MAPC, etc.
[0356] For example, each of the n bits in the control information type (or feedback type) field may indicate / correspond to a specific function (e.g., DPS, IDC, NPCA, MAPC, etc.). Based on the combination of bits (or bitmap), it may indicate that instruction and / or transmission information (or feedback information) for a function type is included. For example, if bit B0 of the control information type (or feedback type) field / bitmap corresponds to MAPC, bit B1 corresponds to MAPC, bit B2 corresponds to IDC, bit B3 corresponds to NPCA, and the other bits are reserved, the control information type (or feedback type) field / bitmap being set to “1100” may indicate that instruction and / or transmission information (or feedback information) for MAPC and DPS operations is included.
[0357] - Control information (or, transmission information / feedback information): including UHR function-specific control information transmitted to the receiving STA via ICF, CRF (e.g., BSRP TF), and / or including information related to and / or helpful in providing feedback information regarding UHR function-specific feedback information that the transmitting device wishes to receive from the receiving device.
[0358] For example, the control information (or, transmission information / feedback information) field may include control / feedback information (e.g., IDC information, MAPC information, DPS information, NPCA information, etc.) corresponding to the function indicated in the control information / feedback type.
[0359] For example, the control information (or, forwarding information / feedback information) field may include function-specific information (e.g., common information about the function and / or user-specific information about the function) that must be forwarded to the receiving STA to operate as an IDC, MAPC, DPS, or NPCA.
[0360] For example, the control information (or, forwarding information / feedback information) field may include function-specific information (e.g., common information about the function and / or user-specific information about the function) that must be forwarded to the receiving AP to operate as an IDC, MAPC, DPS, or NPCA.
[0361] The control information (or, transmission information / feedback information) may include at least one of common control / feedback / transmission information or user-specific control / feedback / transmission information.
[0362] Common control / feedback / transmission information may include common information for each function (e.g., IDC, MAPC, DPS, NPCA, etc.).
[0363] User-specific control / feedback / transmission information may include user-specific information (e.g., non-AP STA and / or AP) for each function (e.g., IDC, MAPC, DPS, NPCA, etc.).
[0364] Additionally, or alternatively, ICF / CRF may include information that can be included in existing A-Control fields (e.g., BSR) in addition to information related to IDC information, MAPC information, DPS information, NPCA information, etc.
[0365] The following describes MAPC-related information (or the contents of MAPC information) that may be included in control / feedback / transmission information.
[0366] The aforementioned control / transmission / feedback information field(s) may include information required for each function. In this disclosure, information that may be included in the control / transmission / feedback information field for APs to operate as MAPCs in an MAPC environment is described.
[0367] For example, MAPC-related information (or MAPC information) may be included within the control / transmission / feedback information field. MAPC-related information may include at least one of the contents described below (e.g., information / field / signaling bit(s)). At least one of the contents described below (e.g., information / field / signaling bit(s)) may be added to / defined in the (BSRP) TF (or ICF / CRF), but is not limited thereto. Additionally, the specific designation (name) of the information / field / signaling bit(s) may be changed.
[0368] - Address: Address information of the target AP (e.g., BSS color, BSSID for multiple APs, and / or MAC address)
[0369] - Multi-AP Group ID: ID for the set of APs that make up the MAPC (e.g., 0, 1, 2, ...)
[0370] - AP ID: An ID locally assigned to each AP within a configured multi-AP group / set (or, an ID locally assigned to each AP within a multi-AP group / set) (e.g., 0, 1, 2, ...).
[0371] For example, the corresponding AP ID may be included in the AID12 field within the User Info field of TF.
[0372] Additionally or alternatively, the AP ID may be included within the AID12 field of the UHR Special User Info field, which may be newly defined for UHR.
[0373] For example, the corresponding AP ID may be included in the AID11 field within the STA information field of the UHR NDP Announcement frame.
[0374] - MAPC Method Type: Indicates multiple AP cooperative transmission methods such as Co-TDMA / Co-SR / Co-BF.
[0375] For example, according to a new subtype definition utilizing the reserved value (e.g., 3) of the GI And HE / EHT-LTF Type / TXS Mode field, Reserved fields / bits in the common information field can be utilized for the MAPC mode type field.
[0376] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field can be utilized for the MAPC method type field.
[0377] Additionally, or alternatively, the Reserved fields / bits of the User Info field can be utilized for the MAPC method type field.
[0378] Additionally or alternatively, a UHR Special User Info field that can be newly defined for UHR may include MAPC method type information.
[0379] For example, a new field to indicate the MAPC method type can be defined by utilizing one or more bits corresponding to EHT Reserved (e.g., utilizing 1 to n bits depending on the number of multiple AP cooperative transmission methods).
[0380] For example, a new field to indicate the MAPC method type may be defined by utilizing one or more bits corresponding to the Reserved fields / bits (e.g., utilizing 1 to n bits depending on the number of multiple AP cooperative transmission methods).
[0381] For example, a bit value 0 of the MAPC scheme type field can indicate Co-TDMA. A bit value 1 of the MAPC scheme type field can indicate Co-SR. A bit value 2 of the MAPC scheme type field can indicate Co-BF.
[0382] For example, the MAPC method type can be signaled based on a bitmap. Bit B0 of the bitmap can correspond to Co-TDMA, bit B1 can correspond to Co-SR, and bit B2 can correspond to Co-BF.
[0383] Additionally or alternatively, control information regarding the MAPC scheme type and the role for which the corresponding TF was transmitted may be signaled together. For example, a bit value of 0 in the MAPC scheme type field may indicate that the TF acts as an ICF in Co-TDMA. A bit value of 1 in the MAPC scheme type field may indicate that the TF acts as a TXOP return. A bit value of 2 in the MAPC scheme type field may indicate that the TF acts as an ICF (or Invite) for the transmission interval in Co-SR. A bit value of 3 in the MAPC scheme type field may indicate that the TF acts as a Synchronization / Cooperative Trigger Frame in Co-SR. A bit value of 4 in the MAPC scheme type field may indicate that the TF acts as an ICF (or Invite) for the transmission interval in Co-BF. A bit value of 5 in the MAPC scheme type field may indicate that the TF acts as a Synchronization / Cooperative Trigger Frame in Co-BF. Bit value 6 of the MAPC scheme type field may indicate that the TF acts as an ICF (or Invite) for the sounding interval in Co-BF. Bit value 7 of the MAPC scheme type field may indicate that the TF acts as a trigger frame for the purpose of sounding failure recovery in Co-BF.
[0384] - BSRP Type: Separately indicates control information regarding what role the corresponding BSRP TF was transmitted for.
[0385] For example, in the MAPC method type field, control information regarding what role the TF was transmitted for can be indicated through a separate BSRP type field.
[0386] For example, a bit value of 0 in the BSRP type field may indicate that the corresponding TF acts as an ICF or Invite frame during the sounding phase. A bit value of 1 in the BSRP type field may indicate that the corresponding TF acts as an ICF or Invite frame during the transport phase. A bit value of 2 in the BSRP type field may indicate that the corresponding TF acts as a synchronization or cooperative trigger frame during the transport phase. A bit value of 3 in the BSRP type field may indicate that the corresponding TF acts as a trigger frame for the purpose of sounding failure recovery. A bit value of 4 in the BSRP type field may indicate that the corresponding TF acts as an Intermediate control frame during the sounding and / or transport phases. A bit value of 5 in the BSRP type field may indicate that the corresponding TF acts as a TXOP Return frame in Co-TDMA.
[0387] - Multiple AP Ack policy indicators: Indicates the Ack indicator during the Co-SR / Co-BF transmission period, and / or the Ack indicator that the Coordinated AP and / or the STA connected to the Coordinated AP must follow during the cooperation period.
[0388] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field can be utilized for multiple AP Ack policy indicator fields.
[0389] For example, the 2 bits corresponding to EHT Reserved or Reserved can be used to indicate an Ack indicator for frame exchange between cooperating APs during the cooperation period.
[0390] For example, multiple AP Ack policy indicator fields can be defined similarly to the Ack policy indicator fields within the QoS control fields.
[0391] For example, if bit 0 = 0 & bit 1 = 0 of the multiple AP Ack policy indicator field, it may indicate Normal Ack or Implicit BAR. If bit 0 = 1 & bit 1 = 0 of the multiple AP Ack policy indicator field, it may indicate No Ack. If bit 0 = 0 & bit 1 = 1 of the multiple AP Ack policy indicator field, it may indicate Reserve or HETP Ack. If bit 0 = 1 & bit 1 = 1 of the multiple AP Ack policy indicator field, it may indicate Block Ack.
[0392] Additionally, or alternatively, multiple AP Ack policy directives may be included in the UHR Special User Info fields that can be newly defined for UHR.
[0393] Additionally, or alternatively, the Reserved fields / bits of the User Info field can be utilized for multiple AP Ack policy indicator fields.
[0394] - (Scheduled) Coordination Period or Whole TXOP Period: the period during which the Coordinating AP cooperates with Coordinated APs to perform cooperation-based transmission (e.g., the expected allocation TXOP / hour that the Coordinating AP intends to allocate to the Coordinated AP), the period during which the Coordinating AP performs individual FEs and / or allocates to the Coordinated APs (Co-TDMA), and / or the whole cooperation TXOP (whole TXOP) period scheduled for MAPC operation.
[0395] For example, the (scheduled) cooperation period or the whole TXOP period may include the ACK period required for the ACK sequence (e.g., MU-BAR trigger frame transmission and / or BlockAck frame reception) between the coordinating AP (or, Coordinating AP) that performed the Co-SR / Co-BF transmission and the target STA.
[0396] Additionally or alternatively, the (scheduled) cooperation period or the whole TXOP period may include the cooperation ACK period allowed for the coordinated AP (Coordinated AP) that performed the Co-SR / Co-BF transmission to the target STA for the ACK sequence (e.g., sending a MU-BAR trigger frame and / or receiving a BlockAck frame). That is, the (scheduled) cooperation period or the whole TXOP period may include the maximum ACK sequence period allowed for the coordinated AP.
[0397] For example, the (scheduled) cooperation period or the whole TXOP period may indicate the cooperation period (or expected / scheduled allocation period) anticipated / planned by the Coordinating AP.
[0398] For example, a 9-bit scheduled cooperation period / scheduled allocation period field (or, (scheduled) cooperation period or whole TXOP period field) may indicate a value in units of 16 us that may be included in the allocation period field of a MU-RTS TXS trigger frame received by the Coordinated AP that will share / allocate the TXOP.
[0399] For example, the (scheduled) cooperation period or the whole TXOP period may indicate the whole cooperation TXOP period during which the Coordinating AP intends to perform the MAPC operation.
[0400] For example, a new field including a collaboration or whole TXOP period may be defined to indicate the (scheduled) collaboration period or the whole TXOP period. For example, a collaboration or whole TXOP period field may be newly defined to indicate the information required for MAPC operation, the collaboration or whole TXOP period value and / or the (scheduled) collaboration period or the whole TXOP period.
[0401] For example, the Allocation Period field of the User Info field of a MU-RTS TXS trigger frame can be utilized to indicate the (scheduled) cooperation period or the Whole TXOP period. For example, the Allocation Period field may contain the corresponding period value.
[0402] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field can be used for the (scheduled) cooperation period or the whole TXOP period field.
[0403] Additionally or alternatively, the Reserved fields / bits of the User Info field may be used for the (scheduled) cooperation period or the Whole TXOP period field.
[0404] Additionally or alternatively, UHR Special User Info fields that may be newly defined for UHR may include (scheduled) cooperation period or whole TXOP period information.
[0405] - Operating Channel: Information on the primary channel and / or punctured channel currently in operation.
[0406] In some implementations, the operational channel information may include channel information that operates in common to facilitate smooth cooperation between APs participating in the MAPC.
[0407] In some implementations, the operation channel information may include primary channel information that APs participating in the MAPC can operate in common.
[0408] For example, a new field is defined that serves as the CCFS (channel center frequency segment)0 field within the EHT / UHR operation information field to indicate the center frequency index for 20 / 40 / 80 MHz channels.
[0409] For example, a new field is defined that serves as the CCFS0 field within the EHT / UHR operation information field to indicate the channel center frequency for the primary 80 MHz channel of the 160 MHz channel or the channel center frequency for the primary 160 MHz channel of the 320 MHz channel.
[0410] In addition, a new field is defined that serves as the CCFS1 field within the EHT / UHR operation information field, which can indicate the channel center frequency for a 160 MHz channel or the channel center frequency for a 320 MHz channel.
[0411] In some implementations, the operation channel information may include punctured channel information of the AP participating in the MAPC.
[0412] For example, a new field is defined within the EHT / UHR operation information field that serves as an inactive (inactived) subchannel bitmap field, and a punctured 20 MHz subchannel can be indicated using the bitmap. A bit with a value of 0 in the bitmap can indicate that the corresponding 20 MHz subchannel is not punctured, and a bit with a value of 1 in the bitmap can indicate that the corresponding 20 MHz subchannel is punctured.
[0413] In some implementations, information about the primary channel of the PAP / Coordinated AP may be included in the operating channel information within the channel where the Coordinating AP operates.
[0414] In some implementations, information about the primary channel of the PAP / Coordinated AP may be included in the operation channel information, excluding the punctured channel of the Coordinating AP.
[0415] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field can be utilized for the operation channel field.
[0416] Additionally, or alternatively, the Reserved fields / bits of the User Info field can be utilized for the operation channel field.
[0417] Additionally or alternatively, operation channel information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0418] - Operating Bandwidth: Information on the operating bandwidth and / or maximum bandwidth
[0419] In some implementations, the operating bandwidth information may include BW information that operates in common to facilitate smooth cooperation between APs participating in MAPC. For example, the operating channel and primary channel information described above may be used to indicate the operating bandwidth.
[0420] In some implementations, the operation bandwidth information may include the maximum bandwidth information of the APs participating in the MAPC. For example, a new field may be defined that serves the same function as the Channel Width field within the control field of the EHT / UHR operation information field to indicate the Channel Width, which is the BSS BW information of each AP. If the value of the field is set to 0, the field may indicate a 20 MHz bandwidth. If the value of the field is set to 1, the field may indicate a 40 MHz bandwidth. If the value of the field is set to 2, the field may indicate an 80 MHz bandwidth. If the value of the field is set to 3, the field may indicate a 160 / 80+80 MHz bandwidth. If the value of the field is set to 4, the field may indicate a 320 / 160+160 MHz bandwidth. Values from 5 to 7 in the field may be reserved.
[0421] In some implementations, the operating bandwidth information may include BW field information within the SIG-A field.
[0422] In some implementations, the operating bandwidth information may include UL BW field information included within the common information field of the trigger frame.
[0423] In some implementations, the operating bandwidth information may include information about the bandwidth of the PAP / Coordinated AP within the total bandwidth in which the Coordinating AP operates.
[0424] In some implementations, the Medium Time field of the QoS attribute element may be modified / redefined to include a new sub-field, thereby newly including a field for bandwidth indication. For example, a new field can be defined that serves the same function as the Channel Width field within the Control field of the EHT / UHR Operation Information field to indicate the Channel Width, which is the BSS BW information for each AP. If the value of the field is set to 0, the field may indicate a 20 MHz bandwidth. If the value of the field is set to 1, the field may indicate a 40 MHz bandwidth. If the value of the field is set to 2, the field may indicate an 80 MHz bandwidth. If the value of the field is set to 3, the field may indicate a 160 / 80+80 MHz bandwidth. If the value of the field is set to 4, the field may indicate a 320 / 160+160 MHz bandwidth. Values from 5 to 7 in the corresponding field may be reserved.
[0425] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field can be utilized for the operation bandwidth field.
[0426] Additionally, or alternatively, the Reserved fields / bits of the User Info field can be utilized for the operation bandwidth field.
[0427] Additionally or alternatively, operating bandwidth information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0428] - Expected Trigger Time: The trigger time of the cooperation-based transmission expected / planned by the Coordinating AP.
[0429] For example, the expected trigger time may indicate the time when the Co-TDMA transmits the MU-RTS TXS TF and / or the period before transmitting the MU-RTS TXS TF during which the Coordinating AP performs frame exchange with the In-BSS STA.
[0430] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field may be utilized to include expected trigger time information.
[0431] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include expected trigger time information.
[0432] Additionally or alternatively, expected trigger time information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0433] For example, a new field including the expected trigger time may be defined. For example, the expected trigger time field may be newly defined to indicate the corresponding expected trigger time value.
[0434] For example, a new element including an expected trigger time may be defined. For example, a MAPC Operation element may be newly defined to indicate the information required for the MAPC operation and / or the expected trigger time value.
[0435] - Low latency traffic information: Information related to the low latency traffic that each AP intends to transmit and receive.
[0436] For example, low-latency traffic information may include information on QoS Characteristic elements contained in SCS Request / Response frames.
[0437] For example, low-latency traffic information may include Delay Bound field information among the information of the QoS Characteristic element. Specifically, the Delay Bound field value for the QoS traffic that each AP intends to transmit can be used as low-latency traffic information. Through this, the Coordinating AP can use the low-latency traffic information to check whether cooperation is necessary and / or to update existing values with a PAP that can complete the transmission of MSDU and / or A-MSDU within the time when the TXOP interval to be shared ends (e.g., a pre-negotiated low-latency traffic information and / or Delay Bound field value is shorter than the allocated time).
[0438] For example, low-latency traffic information may include MSDU Lifetime field information among the information of the QoS Characteristic element. Specifically, the MSDU Lifetime field value for the QoS traffic that each AP intends to transmit can be used as low-latency traffic information. Through this, the Coordinating AP can use the low-latency traffic information to check whether cooperation is necessary and / or update existing values for PAPs that do not discard the MSDU within the time when the TXOP interval to be shared ends (e.g., pre-negotiated low-latency traffic information and / or MSDU Lifetime field value has not expired within the allocated time).
[0439] For example, low-latency traffic information may include Service Start Time field information among the information of the QoS Characteristic element. Specifically, the Service Start Time field value for the QoS traffic that each AP intends to transmit can be used as low-latency traffic information. Through this, the Coordinating AP can use the low-latency traffic information to check whether cooperation is necessary and / or to update existing values with a PAP that can start the expected Service Period and / or frame exchange within the time when the TXOP interval to be shared ends (e.g., pre-negotiated low-latency traffic information and / or Service Start Time field value is shorter than the allocated time).
[0440] For example, low-latency traffic information may include TXOP sharing request information requested / directed by an AP that requires the transmission of low-latency traffic.
[0441] For example, low-latency traffic information may include time-bound information for low-latency traffic requested / directed by an AP requiring the transmission of low-latency traffic. For example, low-latency traffic information may include / direct the minimum time-bound at which the transmission of low-latency traffic must begin. For example, low-latency traffic information may include / direct the maximum time-bound at which the transmission of low-latency traffic must be successfully completed.
[0442] For example, low-latency traffic information may include arrival rate information for low-latency traffic requested / directed by an AP that requires the periodic transmission of low-latency traffic. For example, low-latency traffic information may include / direct the arrival rate of low-latency traffic since the last reporting event.
[0443] For example, low-latency traffic information may include TID / AC information for low-latency traffic.
[0444] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field can be utilized to include low-latency traffic information.
[0445] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include low-latency traffic information.
[0446] Additionally, or alternatively, low-latency traffic information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0447] - Traffic Priority: Priority information for traffic proposed by the Coordinating AP to the PAP / Coordinated AP, and / or priority information for traffic allowed by the Coordinating AP to the PAP / Coordinated AP.
[0448] For example, traffic priority information may include TID / AC information regarding traffic allowed to the Coordinated AP within a TXOP acquired by the Coordinating AP. Specifically, if only traffic for one of AC_BK, AC_BE, AC_VI, or AC_VO is allowed, the Coordinated AP may transmit only traffic corresponding to that AC within the allocated period and / or cooperation period. Specifically, a new 2-bit field is defined to indicate as follows (ACI-to-AC coding): AC index (ACI) 0 = AC_BE (best effort); AC index (ACI) 1 = AC_BK (background); AC index (ACI) 2 = AC_VI (video); AC index (ACI) 3 = AC_VO (voice).
[0449] Additionally or alternatively, seven User Priorities (UPs) may be provided as traffic categories, and Coordinated APs may transmit only traffic corresponding to ACs that are less than or equal to the corresponding UP within the allocated period and / or cooperation period. Specifically, a new 4-bit field is defined to indicate the following (UP-to-AC mapping): UP 1 = AC_BK; UP 2 = AC_BK; UP 0 = AC_BE; UP 3 = AC_BE; UP 4 = AC_VI; UP 5 = AC_VI; UP 6 = AC_VO; UP 7 = AC_VO.
[0450] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field can be utilized to include traffic priority information.
[0451] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include traffic priority information.
[0452] Additionally, or alternatively, traffic priority information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0453] - Protection Level: Indicates the protection level for the efficient operation of the currently active cooperative transmission.
[0454] For example, the protection level may indicate that protection is required for both TXOP sharing and TXOP return in Co-TDMA operation.
[0455] For example, the protection level can indicate that protection is required until the cooperative trigger is executed in a Co-SR / Co-BF operation.
[0456] For example, the EHT Reserved (7 bits) or Reserved of the common information field can be utilized to indicate the protection level. Specifically, the 2 bits corresponding to EHT / UHR Reserved or Reserved can be utilized to indicate the protection level of the currently operating cooperative transmission.
[0457] A bit value 0 of the above 2-bit field for indicating the protection level may indicate that the currently operating cooperative transmission is a cooperative transmission with a protection level of 0. For example, a bit value 0 may indicate that no separate protection (e.g., long NAV setting) is required for the transmission / reception of the ICF, ICR, and cooperative trigger frames in Co-TDMA / SR / BF operation.
[0458] Bit value 1 of the above 2-bit field for indicating the protection level may indicate that the currently operating cooperative transmission is a cooperative transmission with a protection level of 1. For example, bit value 1 may indicate that separate protection (e.g., NAV setting) is required from the ICF / ICR exchange to the transmission of the cooperative trigger frame in Co-TDMA / SR / BF operation.
[0459] Bit value 2 of the above 2-bit field for indicating the protection level may indicate that the currently operating cooperative transmission is a cooperative transmission with a protection level of 2. For example, bit value 2 may indicate that separate protection (e.g., long NAV setting) is required when transmitting a cooperative trigger frame for the success of a TXOP return in Co-TDMA operation.
[0460] Bit value 3 of the above 2-bit field for indicating the protection level may indicate that the currently operating cooperative transmission is a cooperative transmission with a protection level of 3. For example, bit value 3 may indicate that all procedures from the transmission and reception of the ICF, ICR, and cooperative trigger frames in Co-TDMA / SR / BF operation are protected (e.g., long NAV setting).
[0461] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include protection level information.
[0462] Additionally, or alternatively, protection level information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0463] - Recommended Tx power: Maximum Tx power information limited / suggested by the Coordinating AP to the PAP / Coordinated AP triggering Co-SR transmission.
[0464] For example, in a scenario where a Coordinating AP determines the Tx power of a Coordinated AP performing Co-SR transmission, the Coordinating AP can determine the maximum Tx power proposed to the Coordinated AP that does not cause interference with its transmission.
[0465] For example, the proposed transmit power can indicate the maximum threshold Tx power of the Coordinated AP during the Co-SR transmission period.
[0466] For example, the EHT Reserved (7 bits) or Reserved of the common information field may be utilized to include proposed transmit power information.
[0467] Additionally or alternatively, the proposed transmit power information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0468] Additionally or alternatively, the Reserved fields / bits of the User Info field may be utilized to include the proposed transmission power information.
[0469] When a coordinating AP transmits an ICF containing transmit power information proposed in a multi-AP selection procedure / step (e.g., when a coordinating AP transmits a Co-SR Invite frame containing transmit power information proposed in the invitation step for Co-SR), the following effects can be expected:
[0470] i) The Coordinated AP can select the accurate / optimal target STA based on the proposed transmit power information;
[0471] ii) Coordinated AP can maximize the number of potential target STAs based on proposed transmit power information;
[0472] iii) The Coordinated AP can determine the MCS and / or packet length early based on the proposed transmit power information; and / or
[0473] iv) The Coordinated AP may transmit an ICR (e.g., Co-SR Response frame) containing Tx power information required for the Coordinated AP in response to the ICF, and thereby the Coordinating AP may improve / modify the MCS value based on the required Tx power information.
[0474] - DL / UL Indication: Indicates whether DL transmission or UL transmission is to be performed during the Co-SR / Co-BF transmission period.
[0475] - Tx Power: Maximum Tx power information of the coordinating AP.
[0476] For example, the Coordinated AP can determine an appropriate Tx power that does not cause interference based on the maximum Tx power information transmitted by the Coordinating AP.
[0477] For example, the AP Tx power field of the common information field can be utilized to include Tx power information.
[0478] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field can be utilized to include Tx power information.
[0479] Additionally or alternatively, Tx power information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0480] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include Tx power information.
[0481] - In-BSS STA Information: Indicates information about the target STA on which the Coordinating AP will perform DL / UL transmission and / or information about one or more STAs (or all STAs) connected to the Coordinating AP.
[0482] For example, In-BSS STA information may include identifiers (e.g., AID, MAC address) and / or capability information (MIMO, RF capability information) of one or more STAs (or all STAs) connected to the Coordinating AP.
[0483] For example, In-BSS STA information may include the identifier (e.g., AID, MAC address) and / or capability information (MIMO, RF capability information) of a target STA among the STAs connected to the Coordinating AP that intends to perform DL / UL transmission based on Co-SR / Co-BF.
[0484] For example, In-BSS STA information may include an identifier for an In-BSS STA that is to be included in the multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation.
[0485] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field may be utilized to include In-BSS STA information.
[0486] Additionally or alternatively, In-BSS STA information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0487] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include In-BSS STA information.
[0488] - OBSS STA Information: Indicates information about the OBSS target STA that the PAP / Coordinated AP needs to perform DL / UL transmission on.
[0489] For example, OBSS STA information may include the identifier (e.g., AID, MAC address) and / or capability information (MIMO, RF capability information) of a target OBSS STA among the OBSS STAs connected to the PAP / Coordinated AP that intends to perform DL / UL transmission based on Co-SR / Co-BF.
[0490] For example, OBSS STA information may include an identifier for an OBSS STA that you want to include in the multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation.
[0491] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field may be utilized to include OBSS STA information.
[0492] Additionally or alternatively, OBSS STA information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0493] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include OBSS STA information.
[0494] - Co-SR Mode: Indicates the mode for Co-SR transmission.
[0495] For example, Mode 1 can indicate cases where the target STA for Co-SR transmission is EHT + EHT, EHT + UHR, or UHR + EHT. Through the indication of Mode 1, Co-SR PPDUs transmitted by two APs during the Co-SR transmission period must have a common L-SIG, but the U-SIG contents may differ.
[0496] For example, Mode 2 can indicate the case where the target STA for Co-SR transmission is UHR+UHR. Through the indication of Mode 2, it can be indicated that the Co-SR PPDU transmitted by the two APs during the Co-SR transmission period must have a common L-SIG and a common U-SIG.
[0497] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field can be utilized to include Co-SR Mode information.
[0498] Additionally, or alternatively, Co-SR Mode information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0499] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include Co-SR Mode information.
[0500] - Common L-SIG Information: The Common L-SIG Information field may contain L-SIG information that must be commonly included in the DL PPDU transmitted by each AP during the Co-SR / Co-BF transmission period.
[0501] For example, the Length (B5-B16) information of the L-SIG field within a MU PPDU (e.g., EHT, UHR, etc.) may correspond to (or be included in) the common L-SIG information field. This can be considered as a value indicating the duration of the DL PPDU transmitted by each AP.
[0502] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field may be utilized to include common L-SIG information.
[0503] Additionally, or alternatively, common L-SIG information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0504] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to contain common L-SIG information.
[0505] - Common U-SIG Information: The Common U-SIG Information field may indicate / include U-SIG-1 and / or U-SIG-2 information that must be commonly included in the DL PPDU transmitted by each AP during the corresponding cooperation-based transmission period.
[0506] For example, common U-SIG information may include PHY Version Identifier (B0-B2) information in the U-SIG-1 field within a MU PPDU (e.g., EHT, UHR, etc.). Specifically, the PHY Version Identifier information may indicate the PHY version of the DL PPDU transmitted by each AP during the Co-SR / Co-BF transmission period.
[0507] For example, common U-SIG information may include bandwidth (B3-B5) information of the U-SIG-1 field within a MU PPDU (e.g., EHT, UHR, etc.). Specifically, the bandwidth information may indicate the bandwidth of the DL PPDU transmitted by each AP during the Co-SR / Co-BF transmission period. Additionally or alternatively, the bandwidth information may indicate a bandwidth based on the bandwidth of the PPDU containing the ICF transmitted by the Coordinating AP. Additionally or alternatively, the bandwidth information may indicate a bandwidth based on the bandwidth of the PPDU containing the M-BA frame when a response frame (e.g., an M-BA frame) for the ICF transmitted by the Coordinating AP exists.
[0508] For example, common U-SIG information may include UL / DL (B6) information in the U-SIG-1 field within a MU PPDU (e.g., EHT, UHR, etc.). Specifically, the UL / DL information may indicate whether a DL transmission or a UL transmission is to be performed during the corresponding Co-SR / Co-BF transmission period.
[0509] For example, common U-SIG information may include Punctured Channel information (B3-B7) in the U-SIG-2 field within a MU PPDU (e.g., EHT, UHR, etc.). Additionally or alternatively, a PPDU containing an ICF transmitted by the Coordinating AP may be punctured based on long-term punctured channel information (e.g., all punctured 20 MHz subchannels specified in the TXVECTOR parameter INACTIVE_SUBCHANNELS). Additionally or alternatively, a PPDU containing an ICF transmitted by the Coordinating AP may be punctured based on the dynamic puncturing information of each AP. Additionally or alternatively, the Punctured Channel information may indicate a puncturing pattern composed of the union of the two APs' punctured 20 MHz channels.
[0510] For example, common U-SIG information may include UHR-SIG MCS information that serves the same role as the EHT-SIG MCS (B9-B10) in the U-SIG-2 field within a MU PPDU (e.g., EHT, UHR, etc.). For example, UHR-SIG MCS = 0 may indicate UHR-MCS 0. UHR-SIG MCS = 1 may indicate UHR-MCS 1. UHR-SIG MCS = 2 may indicate UHR-MCS 3. UHR-SIG MCS = 3 may indicate UHR-MCS 15. Additionally or alternatively, UHR-SIG MCS may be set to an MCS value that can be received by all STAs serviced by each AP.
[0511] For example, common U-SIG information may include Number Of UHR-SIG Symbols information that serves the same role as Number Of EHT-SIG Symbols (B11-B15) in the U-SIG-2 field within a MU PPDU (e.g., EHT, UHR, etc.). Additionally, or alternatively, Number Of UHR-SIG Symbols information may be set to OFDM symbol values that take into account all user fields for all STAs connected to each AP.
[0512] For example, common U-SIG information may include UHR-SIG TXOP information that serves the same role as the TXOP (B13-B19) of the U-SIG field within the MU PPDU (e.g., EHT, UHR, etc.).
[0513] For example, common U-SIG information may include Spatial Configuration (B16-B19) information within the User field. Specifically, Spatial Configuration information may indicate the number of spatial streams for each user in MU-MIMO allocation. Additionally or alternatively, Spatial Configuration information may indicate spatial stream allocation information for all STAs connected to each AP. Additionally or alternatively, the Spatial Configuration field may be defined / utilized with 2 or 3 bits.
[0514] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field may be utilized to include common U-SIG information.
[0515] Additionally, or alternatively, common U-SIG information may be included in the UHR Special User Info field, which can be newly defined for UHR.
[0516] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to contain common U-SIG information.
[0517] - Non-OFDMA Common Information: Non-OFDMA information that must be commonly included in the DL PPDU transmitted by each AP during the corresponding cooperative-based transmission period.
[0518] For example, according to a new subtype definition utilizing the GI And HE / EHT-LTF Type / TXS Mode value (e.g., 3), Reserved fields / bits in the common information field may be utilized to include Non-OFDMA common information.
[0519] For example, non-OFDMA common information may include spatial reuse (4 bits) information within the common field for SU (e.g., EHT, UHR, etc.) transmission and / or non-OFDMA transmission.
[0520] For example, non-OFDMA common information may include GI+LTF Size (B4-B5) information within a common field for SU (e.g., EHT, UHR, etc.) transmission and / or non-OFDMA transmission. Specifically, the GI+LTF Size information may be set to a GI+LTF value that allows all STAs serviced by each AP to reliably estimate the channel.
[0521] For example, the Non-OFDMA common information may include Number of UHR-LTF Symbols information that serves the same role as the Number of EHT-LTF Symbols (B6-B8) within the common field for SU (e.g., EHT, UHR, etc.) transmission and / or non-OFDMA transmission. Specifically, the Number of UHR-LTF Symbols may be set to the dimension of the Giant P matrix determined based on the sum of the spatial streams required for each AP. Additionally, or alternatively, the Number of UHR-LTF Symbols may be set to the larger of the LTF symbol values required for each AP.
[0522] For example, the Non-OFDMA common information may include Number Of Non-OFDMA Users (B17-B19) information within the common field for SU (e.g., EHT, UHR, etc.) transmission and / or non-OFDMA transmission. Specifically, the value of the Number Of Non-OFDMA Users field may indicate the sum of the number of Co-BF target users on the Coordinating AP side and the number of Co-BF target users on the Coordinated AP side. Additionally, or alternatively, the Number Of Non-OFDMA Users field may be defined as 2 bits, with each 1 bit used to indicate the number of Co-BF target users of the Coordinating AP and the Coordinated AP. For example, B17 may indicate the number of users of the Coordinating AP (e.g., 0 for a single user, 1 for two users). For example, B18 may indicate the number of users of the Coordinated AP (e.g., 0 for a single user, 1 for two users).
[0523] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field may be utilized to include Non-OFDMA common information.
[0524] Additionally or alternatively, Non-OFDMA common information may be included in UHR Special User Info fields that can be newly defined for UHR.
[0525] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include Non-OFDMA common information.
[0526] -MU-MIMO User Information: MU-MIMO user field information to be included in the DL PPDU transmitted by each AP during the corresponding cooperative-based transmission period, and / or user field format information for MU-MIMO allocation.
[0527] For example, MU-MIMO user information may include STA-ID field (B0-B10) information within the User field. Specifically, the STA-ID field information may include ID information of the STA receiving the DL PPDU transmitted based on Co-BF.
[0528] For example, MU-MIMO user information may include MCS (B11-B15) information within the User field.
[0529] For example, MU-MIMO user information may include Spatial Configuration (B16-B19) information within the User field. Specifically, Spatial Configuration information may indicate the number of spatial streams for each user in the MU-MIMO allocation. Additionally, or alternatively, the Spatial Configuration field may be defined / utilized as 3 bits.
[0530] For example, MU-MIMO user information may include BSS Color Indication (B21) information. Specifically, BSS Color Indication information can be used to indicate which of the two BSSs participating in Co-BF the MU-MIMO User Info field is for a user in that BSS.
[0531] For example, MU-MIMO user information may include 2xLDPC (B22) information.
[0532] For example, the EHT Reserved (7 bits) or Reserved fields / bits of the common information field may be utilized to include MU-MIMO user information.
[0533] Additionally, or alternatively, MU-MIMO user information may be included in UHR Special User Info fields that can be newly defined for UHR.
[0534] Additionally, or alternatively, the Reserved fields / bits of the User Info field may be utilized to include MU-MIMO user information.
[0535] - ICF Required: Indicates whether an additional sequence is required to transmit the ICF to the connected STA before triggering the Co-SR / Co-BF transmission.
[0536] For example, the ICF Required information may indicate that an ICF / ICR exchange procedure is required to switch an EMLSR STA among the connected STAs from listening mode to frame switching mode.
[0537] For example, ICF Required information may indicate that an ICF / ICR exchange procedure is required to switch a DPS STA among the connected STAs from lower capability mode (LCM) to higher capability mode (HCM).
[0538] For example, ICF Required information may indicate that an ICF / ICR exchange procedure is required to switch a DUO STA among the connected STAs.
[0539] - Minimum Number of Data OFDM Symbols (9 bits): Indicates the minimum number of data OFDM symbols that the coordinating AP can transmit.
[0540] - Maximum Number of Data OFDM Symbols (9 bits): Indicates the maximum number of data OFDM symbols that the coordinating AP can transmit.
[0541] - Maximum Total Nss Allowed for Coordinated AP (2 bits): Indicates the maximum number of Total Nss allowed to the Coordinated AP for the purpose of the Coordinating AP controlling the Coordinated AP's Nss value.
[0542] For example, if you do not want the Coordinated AP to use Nss 3 when the maximum Total Nss is 4 and the Coordinating AP is using Nss 1, the Coordinating AP can limit the Nss of the Coordinated AP by setting Maximum Total Nss Allowed for Coordinated AP to 1 or 2.
[0543] - Number of Co-BF Users in sharing BSS: Indicates the number of target users (1~3).
[0544] - BSS Color 1 and BSS Color 2 (6 bits each): Indicates the BSS color of the Coordinating AP and the BSS color of the Coordinated AP.
[0545] -Numbsr of Co-BF Users (3 bits): Indicates the sum of the number of Co-BF users of the Coordinating AP and the Coordinated AP. For example, the maximum number of users can be 4.
[0546] A method including control information (or, feedback information / transmission information) within an ICF
[0547] Control information (or, feedback information / transmission information) may be included in a trigger frame based on at least one of the methods described below. A trigger frame containing control information (or, feedback information / transmission information) may serve as an ICF and / or CRF.
[0548] - How to utilize the new Special User Info field (or Feedback User Info field)
[0549] In some implementations, a new Special User Info field (e.g., for UHR) and / or Feedback User Info field may be defined / utilized to include information that the transmitting STA transmitting the ICF / CRF intends to convey to the receiving STA within the corresponding TF. To this end, a new UHR Special / Feedback User Info field Flag field may be defined using 1 bit of the reserved bits of the common information field and its value may be set to 1. The UHR Special / Feedback User Info field Flag field may be defined / included for the purpose of indicating the presence of a UHR Special / Feedback User Info field containing additional information.
[0550] Additionally or alternatively, a reserved (1 bit) within the User Info field may be used to indicate whether a UHR Special / Feedback User Info field exists that can be newly defined for UHR and / or multi-AP cooperation in a user-specific manner. For example, a UHR Special / Feedback User Info field Flag field may be defined using the reserved field / bit(s) within the User Info field. For example, B25 (reserved) of the EHT variant User Info field may indicate the subsequent existence of an AP-specific UHR Special / Feedback User Info field in multi-AP cooperation. Additionally or alternatively, a specific value of a newly defined field in the UHR variant User Info field may be utilized to indicate the existence of a UHR Special / Feedback User Info field.
[0551] Additionally or alternatively, a reserved field / bit (1 bit) within a Special User Info field with an AID12 value set to 2007 can be used to indicate whether a UHR Special / Feedback User Info field exists that can be newly defined for UHR and / or multi-AP cooperation. For example, a UHR Special / Feedback User Info field Flag field can be defined using the reserved field / bit () within the Special User Info field.
[0552] Additionally or alternatively, a newly defined UHR Special / Feedback User Info field may contain common information by default and may indicate that additional UHR Special / Feedback User Info fields may follow using reserved field / bit(s) within the field.
[0553] For example, the first UHR Special / Feedback User Info field includes a Flag field indicating that there is common information and a subsequent UHR Special / Feedback User Info field, and the second UHR Special / Feedback User Info field may include user-specific information.
[0554] For example, the first UHR Special / Feedback User Info field includes a Flag field indicating the existence of a UHR Special / Feedback User Info field that follows common information, and the second UHR Special / Feedback User Info field includes a Flag field indicating the existence of a UHR Special / Feedback User Info field that follows user-specific information, so that a third UHR Special / Feedback User Info field may exist. That is, there may be one or more UHR Special / Feedback User Info fields and there is no restriction.
[0555] To indicate that the corresponding UHR Special / Feedback User Info field is a new Special / Feedback User Info field in the UHR, the value of the AID12 field may be set to a reserved value (e.g., one of 2008 to 2044 or one of 2047 to 4094). The UHR Special / Feedback User Info field identified by the new AID12 value may be placed following the Common Info field, the User Info field, or the Special User Info field (of the EHT). Additionally, or alternatively, the UHR Special / Feedback User Info field may be placed before or after the User Info field for the corresponding User.
[0556] Additionally or alternatively, a multi-AP group ID (e.g., an ID for a set of APs that have formed a multi-AP collaboration) and / or an AP ID (e.g., an ID assigned by an AP in a cooperative relationship within a formed multi-AP group) may be included in the AID12 field. Specifically, a local AP ID value assigned by the coordinating AP may be mapped / converted / resolved as an AID12 value. Additionally or alternatively, the AID12 field may consist of a combination of the target PAP's BSSID and BSS color. Additionally or alternatively, the AID12 field may consist of part or all of the target PAP's BSS color. Additionally or alternatively, the AID12 field may consist of part of the target PAP's BSSID. Additionally or alternatively, the AID12 field may consist of a combination of the target PAP's AP ID and BSS color.
[0557] FIG. 18 shows a first example of a (UHR) Special / Feedback User Info field format containing MAPC-related control / feedback / transmission information.
[0558] Referring to FIG. 18, a new (UHR) Special / Feedback User Info field may be defined / utilized within the BSRP TF to include MAPC control / feedback / transmission information. The new Special / Feedback User Info field (e.g., the value of the AID12 field is set to a value greater than or equal to 2008) may be located following the User Info field, following the Common Information field, or following the EHT Special User Info (AID12 = 2007). One or more of the common information for the aforementioned UHR functions and / or information for multi-AP cooperation may be included within the control information field of the (UHR) Special / Feedback User Info field. The location where each piece of information may be included and / or the type of information are not limited. Additionally, if the presented information is not used, the corresponding field may be reserved.
[0559] FIG. 19 shows a second example of a (UHR) Special / Feedback User Info field format containing MAPC-related control / feedback / transmission information.
[0560] Referring to FIG. 19, one or more (UHR) Special / Feedback User Info fields may exist. To indicate that one or more (UHR) Special / Feedback User Info field(s) exist, the first (UHR) Special / Feedback User Info field may include a Flag field (1 bit). If common information for MAPC operation cannot be included within a single (UHR) Special / Feedback User Info field, common information may be included by utilizing one or more (UHR) Special / Feedback User Info fields, as shown in the example of FIG. 19.
[0561] Additionally or alternatively, if AP / user-specific information for MAPC operation cannot all be included together with common information within the first (UHR) Special / Feedback User Info field, AP / user-specific information may be included by utilizing one or more (UHR) Special / Feedback User Info fields (e.g., AP-specific Special User Info), as shown in the example of FIG. 19.
[0562] Additionally or alternatively, common information for MAPC operation may be included in the first (UHR) Special / Feedback User Info field, and AP / user-specific information may be separated and included in the second or subsequent (UHR) Special / Feedback User Info field(s), without limitation.
[0563] In this case, when the number of reserved bits is less than the length of the specific information / field to be included in the preceding (UHR) Special / Feedback User Info field, the subsequent (UHR) Special / Feedback User Info field may be used without using the reserved bits. Additionally, or alternatively, the remaining reserved bits in the preceding (UHR) Special / Feedback User Info field may be used to include partial information / bits of the information to be included, and the remaining information / bits may be included in the subsequent (UHR) Special / Feedback User Info field. In this case, the position of the Flag bit in the preceding (UHR) Special / Feedback User Info field may change.
[0564] If two or more (UHR) Special / Feedback User Info fields exist, the second (UHR) Special / Feedback User Info field may also include a Flag field (1 bit). Additionally, subsequent (UHR) Special / Feedback User Info field(s) may not include a control information type field.
[0565] For example, the Special User / feedback information field(s) of the ICF (or CRF) transmitted to operate as Co-TDMA among the cooperative methods may be configured as shown in FIG. 20 and / or FIG. 21.
[0566] FIG. 20 shows a first example of a (UHR) Special / Feedback User Info field format containing Co-TDMA related control / feedback / transfer information.
[0567] Referring to FIG. 20, information that must be transmitted via the ICF (or CRF) for Co-TDMA operation may be contained within a single Special / Feedback User Info field. The AID12 field may contain a Special AID value (e.g., 2008 or another value) to indicate that the field is a new Special / Feedback User Info field for UHR. If all information for Co-TDMA operation can be contained within a single Special / Feedback User Info field, a separate Flag field and additional Special / Feedback User Info fields may not exist.
[0568] Additionally or alternatively, if the value of a specific AID12 field is defined separately for Co-TDMA only (e.g., 2009 indicates Co-TDMA information), the control information type and / or MAPC type fields exemplified in FIG. 20 may be omitted. That is, only common control information for Co-TDMA operation may be included.
[0569] Additionally or alternatively, if the value of a specific AID12 field is defined separately for MAPC (e.g., 2009 is a MAPC information indicator), the control information type exemplified in FIG. 20 may be omitted. That is, only the MAPC type field for distinguishing the MAPC method and common control information for MAPC operation may be included.
[0570] Figure 21 shows a second example of a (UHR) Special / Feedback User Info field format containing Co-TDMA related control / feedback / transfer information.
[0571] Referring to FIG. 21, information to be transmitted via the ICF (or CRF) for Co-TDMA operation may be included in one or more Special / Feedback User Info fields. The AID12 field of the first Special / Feedback User Info field may contain a Special AID value (e.g., 2008 or another value) to indicate that the field is a new Special / Feedback User Info field for UHR. If the information for Co-TDMA operation cannot all be included in a single Special / Feedback User Info field, a Flag field may exist within the preceding Special / Feedback User Info field as shown in FIG. 21. If one or more (UHR) Special User Info fields exist, the first Special / Feedback User Info field may contain common information for Co-TDMA operation, and the subsequent Special / Feedback User Info field(s) may contain user-specific (e.g., per-AP) information for Co-TDMA operation. In this case, the preceding Special / Feedback User Info field and / or User Info field (e.g., AID12 = 2008 or another value, or AID12 = AP ID) may include a Present field / bit indicating the existence of additional User Info fields and / or Special / Feedback User Info fields (e.g., AID12 = AP ID, or AID12 = 2008 or another value). Additionally, or alternatively, multiple Special / Feedback User Info fields containing common information and / or user-specific information may exist. Furthermore, control information type and / or MAPC type fields within the subsequent Special / Feedback User Info field(s) may be omitted.
[0572] In addition to the information exemplified in FIG. 20 and FIG. 21, one or more of the information described above may be included, and the location of the included information is not limited.
[0573] In addition to Co-TDMA, the Special / Feedback User Info field(s) of the ICF (or CRF) transmitted to operate as Co-SR among the cooperative modes can be configured as shown in FIG. 22 and / or FIG. 23.
[0574] FIG. 22 shows a first example of a (UHR) Special / Feedback User Info field format containing Co-SR related control / feedback / transmission information.
[0575] Referring to FIG. 22, information that must be transmitted via the ICF (or CRF) for Co-SR operation may be contained within a single Special / Feedback User Info field. The AID12 field may contain a Special AID value (e.g., 2008 or another value) to indicate that the field is a new Special / Feedback User Info field for UHR. If all information for Co-SR operation can be contained within a single Special / Feedback User Info field, a separate Flag field and / or additional Special / Feedback User Info fields may not exist.
[0576] FIG. 23 shows a second example of a (UHR) Special / Feedback User Info field format containing Co-SR related control / feedback / transmission information.
[0577] Referring to FIG. 23, information that must be transmitted via the ICF (or CRF) for Co-SR operation may be included in one or more Special / Feedback User Info fields. The AID12 field of the first Special / Feedback User Info field may contain a Special AID value (e.g., 2008 or another value) to indicate that the field is a new Special / Feedback User Info field for UHR. If the information for Co-SR operation cannot all be included in a single Special / Feedback User Info field, a Flag field may exist within the preceding Special / Feedback User Info field as shown in FIG. 23. If one or more Special / Feedback User Info fields exist, the first Special / Feedback User Info field may contain common information for Co-SR operation, and the subsequent Special / Feedback User Info field(s) may contain user-specific (e.g., per-AP) information for Co-SR operation. Additionally or alternatively, there may be multiple Special / Feedback User Info fields containing common information and / or user-specific information. Also, control information type and / or MAPC type fields within subsequent Special / Feedback User Info field(s) may be omitted.
[0578] In addition to the information exemplified in FIG. 22 and FIG. 23, one or more of the information described above may be included, and the location of the included information is not limited.
[0579] The Special / Feedback User Info field(s) of the ICF (or CRF) transmitted to operate as Co-BF among the cooperative modes, as well as Co-TDMA and Co-SR, can be configured as shown in FIGS. 24.
[0580] FIG. 24 shows a first example of a (UHR) Special / Feedback User Info field format containing Co-BF related control / feedback / transmission information.
[0581] Referring to FIG. 24, information that must be transmitted via the ICF (or CRF) for Co-BF operation may be included in one or more Special / Feedback User Info fields. The AID12 field of the first Special / Feedback User Info field may contain a Special AID value (e.g., 2008 or another value) to indicate that the field is a new Special / Feedback User Info field for UHR. If the information for Co-BF operation cannot all be included in a single Special / Feedback User Info field, a Flag field may exist within the preceding Special / Feedback User Info field as shown in FIG. 24. If one or more Special / Feedback User Info fields exist, the first Special / Feedback User Info field may contain common information for Co-BF operation, and the subsequent Special / Feedback User Info field(s) may contain user-specific (e.g., per-AP) information for Co-BF operation. Additionally or alternatively, there may be multiple Special / Feedback User Info fields containing common information and / or user-specific information. Also, control information type and / or MAPC type fields within subsequent Special / Feedback User Info field(s) may be omitted.
[0582] FIG. 25 shows a second example of a (UHR) Special / Feedback User Info field format containing Co-BF related control / feedback / transmission information.
[0583] Referring to FIG. 25, one or more Special / Feedback User Info fields (e.g., AID12 = 2008 or other values) may contain common information and / or user-specific information for Co-BF transmission.
[0584] Figure 26 shows a third example of a (UHR) Special / Feedback User Info field format containing Co-BF related control / feedback / transmission information.
[0585] Referring to FIG. 26, one or more Special / Feedback User Info fields (e.g., AID12 = 2008 or other values) may contain common information for Co-BF transmission, and User Info fields (e.g., AID12 = STA ID) may contain user-specific information for Co-BF transmission.
[0586] In addition to the information exemplified in FIG. 24 and 24, one or more of the information described above may be included, and the location of the included information is not limited.
[0587] - How to utilize Common Info fields and / or User Info fields
[0588] Figure 27 shows an example of including MAPC-related information in the Common and / or User Info fields.
[0589] Referring to FIG. 27, a new subtype and / or mode can be defined using the GI And HE / EHT / UHR-LTF Type / TXS Mode field (e.g., 3) within the BSRP TF, and the remaining fields / bits following the GI And HE / EHT-LTF Type / TXS Mode field can be reserved and utilized to include common information for multi-AP cooperation and / or information specific to multi-AP cooperation methods (e.g., Co-SR, Co-BF, Co-TDMA, etc.). One or more of the contents of the control / feedback / transmission information described above may be included in the common information field and / or User Info field of the BSRP (UHR) TF, and are not limited to the example of FIG. 27. That is, each field, the position of the signaling bit, the number of bits, and / or names may be changed. For example, one or more of the contents of the control / feedback / transmission information may be included in the common information field and / or the User Info field and / or the new Special User Info field. For example, reserved bits at other locations within the common information field may be used to include one or more of the contents of the control / feedback / transmission information.
[0590] - How to utilize padding fields / bits in TF
[0591] Figure 28 shows an example of a BSRP TF format containing control information within the padding.
[0592] Referring to FIG. 28, control information type and / or control information (or feedback information / transmission information) may be included in the padding field. For example, as shown in FIG. 28, the padding field / bit(s) within the BSRP TF may include control information type and / or control information (or feedback information / transmission information).
[0593] - How to utilize the Special User Info field (AID12 = 2007)
[0594] In some implementations, some fields within the Special User Info field of the BSRP TF (e.g., AID12 = 2007) may be reserved, and the reserved field / bit(s) may be utilized to contain common information for multi-AP cooperation and / or information specific to multi-AP cooperation methods (e.g., Co-SR, Co-BF, Co-TDMA, etc.). For example, one or more of the contents of the control / feedback / transmission information described above may be included in the Special User Info (2007) field of the BSRP TF, and are not limited to the examples of FIGS. 29 through 31. That is, each field, the position of the signaling bit, the number of bits and / or names may be changed. For example, one or more of the contents of the control / feedback / transmission information may be included in the common information field and / or User Info field and / or a new Special / Feedback User Info field (e.g., AID12 = 2008 or other value). For example, reserved bits at other locations within the common information field may be used to include one or more of the contents of control / feedback / transmission information.
[0595] Figure 29 shows an example of a Special User Info field format for Co-TDMA operation.
[0596] Referring to FIG. 29, the AID12 field of the Special User Info field can be set to 2007. The Special User Info field may include one or more of the contents of the Co-TDMA related control / feedback / transmission information described above.
[0597] Figure 30 shows an example of a Special User Info field format for Co-SR operation.
[0598] Referring to FIG. 30, the AID12 field of the Special User Info field can be set to 2007. The Special User Info field may include one or more of the contents of the control / feedback / transmission information related to Co-SR described above.
[0599] Figure 31 shows an example of a Special User Info field format for Co-BF operation.
[0600] Referring to FIG. 31, the AID12 field of the Special User Info field can be set to 2007. The Special User Info field may include one or more of the contents of the Co-BF related control / feedback / transmission information described above.
[0601] Meanwhile, in the present disclosure, a response frame for an ICF that may be transmitted from a Coordinating AP in a multiple AP selection procedure is defined. For example, the present disclosure provides a method for transmitting a management frame (e.g., Action frame, Public Action frame) containing MAPC-related common information and / or per-scheme information as a response frame / ICR for an ICF (e.g., BSRT TF, MU-RTS TF).
[0602] In the present disclosure, the management frame can be transmitted as an ICR frame in an MAPC environment through the structure of the management frame, information for MAPC operation, and / or a method for transmitting the same.
[0603] In the present disclosure, an Action frame that can be transmitted as an ICR in an ICR for MAPC and / or various UHR functions may be classified / defined as a Class 1 frame to be transmitted between APs. Additionally or alternatively, even if such Action frame is classified / defined as a Class 2 or Class 3 frame, said Action frame may be transmitted between APs that have established MAPC consensus.
[0604] Additionally or alternatively, a management frame may be transmitted as an ICR for a trigger frame even if the trigger frame addressed from the OBSS STA to the AP and / or STA does not contain information for an APC operation.
[0605] Additionally or alternatively, the management frame for the ICR in this disclosure may be utilized in response frames for ICFs (e.g., BSRT TF, MU-RTS TF) that may be transmitted in a multiple AP selection procedure, as well as in various procedures within the MAPC operation (e.g., TXOP sharing, TXOP return in Co-TDMA).
[0606] Contents included in ICR
[0607] In the polling (or multiple AP selection, cooperative announcement) procedure exemplified in FIG. 11, the response frame (i.e., ICR) that the Coordinated AP(s) can transmit as a response frame to the ICF transmitted by the Coordinating AP may contain one or more of the contents of the MAPC information below. The designations (names) of the contents below may change and are not limited thereto.
[0608] - Operating Channel: Information on the primary channel and / or punctured channel currently in operation.
[0609] In some implementations, the operational channel information may include channel information that operates in common to facilitate smooth cooperation between APs participating in the MAPC.
[0610] In some implementations, the operation channel information may include primary channel information that APs participating in the MAPC can operate in common.
[0611] For example, a new field is defined that serves as the CCFS (channel center frequency segment)0 field within the EHT / UHR operation information field to indicate the center frequency index for 20 / 40 / 80 MHz channels.
[0612] For example, a new field is defined that serves as the CCFS0 field within the EHT / UHR operation information field to indicate the channel center frequency for the primary 80 MHz channel of the 160 MHz channel or the channel center frequency for the primary 160 MHz channel of the 320 MHz channel.
[0613] In addition, a new field is defined that serves as the CCFS1 field within the EHT / UHR operation information field, which can indicate the channel center frequency for a 160 MHz channel or the channel center frequency for a 320 MHz channel.
[0614] In some implementations, the operation channel information may include punctured channel information of the AP participating in the MAPC.
[0615] For example, a new field is defined within the EHT / UHR operation information field that serves as an inactive (inactived) subchannel bitmap field, and a punctured 20 MHz subchannel can be indicated using the bitmap. A bit with a value of 0 in the bitmap can indicate that the corresponding 20 MHz subchannel is not punctured, and a bit with a value of 1 in the bitmap can indicate that the corresponding 20 MHz subchannel is punctured.
[0616] In some implementations, information about the primary channel of the Coordinating AP may be included in the operating channel information within the channel (e.g., operating channel width) where the Coordinated AP operates.
[0617] In some implementations, information about the primary channel of the Coordinating AP may be included in the operation channel information, excluding the punctured channel of the Coordinated AP.
[0618] - Operating Bandwidth: Information on the operating bandwidth and / or maximum bandwidth
[0619] In some implementations, the operating bandwidth information may include BW information that operates in common to facilitate smooth cooperation between APs participating in MAPC. For example, the operating channel and primary channel information described above may be used to indicate the operating bandwidth.
[0620] In some implementations, the operation bandwidth information may include the maximum bandwidth information of the APs participating in the MAPC. For example, a new field may be defined that serves the same function as the Channel Width field within the control field of the EHT / UHR operation information field to indicate the Channel Width, which is the BSS BW information of each AP. If the value of the field is set to 0, the field may indicate a 20 MHz bandwidth. If the value of the field is set to 1, the field may indicate a 40 MHz bandwidth. If the value of the field is set to 2, the field may indicate an 80 MHz bandwidth. If the value of the field is set to 3, the field may indicate a 160 / 80+80 MHz bandwidth. If the value of the field is set to 4, the field may indicate a 320 / 160+160 MHz bandwidth. Values from 5 to 7 in the field may be reserved.
[0621] In some implementations, the operating bandwidth information may include BW field information within the SIG-A field.
[0622] In some implementations, the operating bandwidth information may include UL BW field information included within the common information field of the trigger frame.
[0623] In some implementations, the bandwidth of the Coordinating AP may be included within the total bandwidth in which the Coordinated AP operates.
[0624] In some implementations, the Medium Time field of the QoS attribute element may be modified / redefined to include a new sub-field, thereby newly including a field for bandwidth indication. For example, a new field can be defined that serves the same function as the Channel Width field within the Control field of the EHT / UHR Operation Information field to indicate the Channel Width, which is the BSS BW information for each AP. If the value of the field is set to 0, the field may indicate a 20 MHz bandwidth. If the value of the field is set to 1, the field may indicate a 40 MHz bandwidth. If the value of the field is set to 2, the field may indicate an 80 MHz bandwidth. If the value of the field is set to 3, the field may indicate a 160 / 80+80 MHz bandwidth. If the value of the field is set to 4, the field may indicate a 320 / 160+160 MHz bandwidth. Values from 5 to 7 in the corresponding field may be reserved.
[0625] - Required coordination duration: Information regarding the coordination duration desired by each Coordinated AP.
[0626] For example, a new field containing required cooperation period information may be defined. Specifically, the required cooperation period field may be newly defined to indicate information required for Co-SR / Co-BF / TDMA transmission and / or a required cooperation period value.
[0627] For example, a new element including required cooperation period information may be defined. Specifically, multiple AP Operation elements may be newly defined to indicate information required for Co-SR / Co-BF / TDMA operation and / or required cooperation period values.
[0628] Additionally or alternatively, the required cooperation period information may include cooperation Ack period information required by the Coordinated AP performing Co-SR / Co-BF transmission for an Ack sequence with the target STA (e.g., sending a MU-BAR trigger frame and receiving a BlockAck frame). For example, the required cooperation period information may include minimum Ack sequence period information required by the coordinated AP.
[0629] For example, the required cooperation period information may be included within a QoS Characteristic element that can be used to include negotiation information in the pre-negotiation process for Co-SR / Co-BF / TDMA operation and / or an element that can be newly defined for negotiation in Co-SR / Co-BF / TDMA.
[0630] For example, it may include a UHR Operation element that can be used to include announcement information during the announcement process of each AP for Co-SR / Co-BF / TDMA operation, and / or required cooperation period information that can be newly defined for announcement in Co-SR / Co-BF / TDMA.
[0631] Additionally or alternatively, the required cooperation duration field may indicate the length of the PPDU required by the Coordinated AP for Co-SR and / or Co-BF-based transmission. To this end, the Required (DL) PPDU Length field is newly defined to indicate the length of the PPDU required by the Coordinated AP for Co-SR and / or Co-BF-based transmission.
[0632] - Buffer State: The current buffer state of each Coordinated AP and / or the amount of buffer each Coordinated AP intends to transmit to Co-SR / Co-BF / TDMA.
[0633] Additionally or alternatively, the buffer status field may indicate the length of the PPDU required by the Coordinated AP for Co-SR and / or Co-BF-based transmission. To this end, the Required (DL) PPDU Length field is newly defined to indicate the length of the PPDU required by the Coordinated AP for Co-SR and / or Co-BF-based transmission.
[0634] Additionally or alternatively, the BSR Control field, which is one of the control field variants of A-Control, may contain buffer status information of each Coordinated AP.
[0635] - Status Code: The Coordinated AP(s) addressed in the ICF transmitted from the Coordinating AP can indicate whether to participate in the MAPC via a status code (Accept / Reject / Recommend) depending on whether MAPC operation is required.
[0636] For example, the status code can indicate Accept or Success (e.g., SUCCESS).
[0637] For example, the status code may indicate a Reject or a Reject including a Recommendation. Specifically, the status code may indicate a Reject code including a Reject reason (e.g., REJECTED_BAD_SUPPORTED_CHANNELS). Specifically, the status code may indicate a Reject code including a Recommendation (e.g., REJECTED_WITH_SUGGESTED_CHANGES).
[0638] If the status code value includes Reject or Recommendation, the ICR may include information for a new ICF. That is, the Coordinated AP that receives the ICF may transmit an ICR containing additional information regarding the required cooperation period, buffer status, and / or status code, etc., as described above.
[0639] Additionally or alternatively, a participation instruction field / bit to replace the status code may be defined.
[0640] - Participation indication: Indicates whether to participate in the MAPC solicited by the ICF.
[0641] That is, the Coordinated AP(s) that received the ICF can indicate whether they currently require cooperation-based transmission through a participation instruction.
[0642] For example, participation can be indicated using a 1-bit participation indicator field. In this case, a bit value of 0 in the participation indicator field may indicate that the user is not participating in the Solicited MAPC. A bit value of 1 in the participation indicator field may indicate that the user is participating in the Solicited MAPC.
[0643] For example, a 2-bit participation indicator field may be used to indicate whether to participate and / or to include a recommendation. In this case, a bit value of 0 in the participation indicator field may indicate not participating in the Solicited MAPC. A bit value of 1 in the participation indicator field may indicate participating in the Solicited MAPC. A bit value of 2 in the participation indicator field may indicate including a recommendation to participate in the Solicited MAPC.
[0644] For example, a 3-bit (or 2-bit) participation indicator field can be used to indicate whether to participate or to indicate the reason for rejection / recommendation. In this case, a bit value of 0 in the participation indicator field may indicate that the user is not participating in the Solicited MAPC. A bit value of 1 in the participation indicator field may indicate that the user is participating in the Solicited MAPC. A bit value of 2 in the participation indicator field may indicate that the user cannot participate in the Solicited MAPC due to reasons such as DPS or IDC. A bit value of 3 in the participation indicator field may indicate that a change or update of key operational parameters is required for MAPC operation.
[0645] Additionally or alternatively, to indicate whether to participate in the MAPC, the key information / field(s) for the MAPC operation can be set to specific bits (e.g., all 1 or all 0).
[0646] - Low latency traffic information: Information related to the low latency traffic that each AP intends to transmit and receive.
[0647] For example, low-latency traffic information may include information on QoS Characteristic elements contained in SCS Request / Response frames.
[0648] For example, low-latency traffic information may include Delay Bound field information among the information of the QoS Characteristic element. Specifically, the Delay Bound field value for the QoS traffic that each AP intends to transmit may be utilized as low-latency traffic information. If the information changes differently from the pre-negotiated low-latency traffic information, the updated low-latency traffic information and / or Delay Bound field value may be included.
[0649] For example, low-latency traffic information may include MSDU Lifetime field information among the information of the QoS Characteristic element. Specifically, the MSDU Lifetime field value for the QoS traffic that each AP intends to transmit may be utilized as low-latency traffic information. If the information is changed differently from the pre-negotiated low-latency traffic information, the updated low-latency traffic information and / or MSDU Lifetime field value may be included.
[0650] For example, low-latency traffic information may include Service Start Time field information among the information of the QoS Characteristic element. Specifically, the Service Start Time field value for the QoS traffic that each AP intends to transmit may be used as low-latency traffic information. If the information is changed differently from the pre-negotiated low-latency traffic information, the updated low-latency traffic information and / or Service Start Time field value may be included.
[0651] For example, low-latency traffic information may include MAPC operation request information requested / instructed by an AP that requires the transmission of low-latency traffic.
[0652] For example, low-latency traffic information may include time-bound information for low-latency traffic requested / directed by an AP requiring the transmission of low-latency traffic. For example, low-latency traffic information may include / direct the minimum time-bound at which the transmission of low-latency traffic must begin. For example, low-latency traffic information may include / direct the maximum time-bound at which the transmission of low-latency traffic must be successfully completed.
[0653] For example, low-latency traffic information may include arrival rate information for low-latency traffic requested / directed by an AP that requires the periodic transmission of low-latency traffic. For example, low-latency traffic information may include / direct the arrival rate of low-latency traffic since the last reporting event.
[0654] For example, low-latency traffic information may include TID / AC information for low-latency traffic.
[0655] - Preferred Tx Power: Information on the maximum Tx power that the Coordinated AP desires / prefers (e.g., for Co-SR).
[0656] For example, the Coordinated AP can determine its own appropriate preferred Tx power that does not cause interference based on the maximum Tx power information, In-BSS STA information and / or OBSS STA information transmitted by the Coordinating AP, and transmit an ICR containing the preferred Tx power information.
[0657] - In-BSS STA Information: Based on an MAPC method in which the Coordinating AP and the Coordinated AP perform transmissions simultaneously, such as Co-SR / Co-BF, the Coordinated AP indicates information about the target STA to which the Coordinated AP will perform DL / UL transmission and / or information about one or more STAs (or all STAs) connected to the Coordinating AP.
[0658] For example, In-BSS STA information may include identifiers (e.g., AID, MAC address) and / or capability information (MIMO, RF capability information) of one or more STAs (or all STAs) connected to the Coordinated AP.
[0659] For example, In-BSS STA information may include the identifier (e.g., AID, MAC address) and / or capability information (MIMO, RF capability information) of a target STA among the STAs connected to the Coordinated AP that intends to perform DL / UL transmission based on the indicated MAPC method.
[0660] For example, In-BSS STA information may include an identifier for an In-BSS STA that is to be included in the multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation.
[0661] Method for including control information (or feedback information) within an ICR
[0662] - Method for including MAPC information within a data frame and, in that case, the data frame format
[0663] Figure 32 shows an example of a data frame format.
[0664] In a procedure to verify participation in a MAPC operation (e.g., negotiation procedure), a procedure to select a target AP for cooperation (e.g., multiple AP selection procedure), and / or a procedure to notify that a specific cooperation-based transmission is scheduled to begin (e.g., cooperation trigger procedure), the Coordinated AP may transmit a data frame as a response frame to an ICF that may be transmitted from the Coordinating AP.
[0665] The frame body of a data frame transmitted by a Coordinated AP may contain one or more contents of information for MAPC operation, but is not limited thereto.
[0666] Figure 33 shows an example where MAPC information is included in the frame body of a data frame.
[0667] Referring to FIG. 33, information related to MAPC operation may be included within the frame body of a data frame transmitted by the Coordinated AP as a response frame (ICR) for an ICF transmitted by the Coordinating AP. Per-Scheme Info may include separate information for each MAPC scheme (e.g., Co-SR / Co-BF / Co-TDMA).
[0668] - Method for including MAPC information by utilizing HT control fields and / or frame bodies
[0669] In some implementations, depending on the type of frame the Coordinating AP transmits to the ICF, the HT control field within the data frame transmitted by the Coordinated AP as an ICR may be utilized. For example, when the Coordinating AP transmits a BSRP trigger frame, B0 and B1 of the HT control field may be set to 1 to include A-Control information (e.g., BSR) for the HE variant.
[0670] Figure 34 shows an example where the HT control field and / or frame body of a data frame contains MAPC information.
[0671] Referring to FIG. 34, information related to MAPC operation may be included by utilizing the HT control field and / or frame body within the data frame transmitted by the Coordinated AP as a response frame (ICR) for an ICF (e.g., BSRP TF) transmitted by the Coordinating AP. Per-Scheme Info may include separate information for each MAPC scheme (e.g., Co-SR / Co-BF / Co-TDMA). If a BSR is included within the data frame, the aforementioned buffer status information may be replaced by the BSR. Additionally or alternatively, the BSR control field may be utilized to replace the aforementioned participation instruction and / or status code. For example, if configured to indicate information solicited from the ICF, it may indicate participation in the MAPC, and if one or more field(s) within the BSR are all set to 0, it may indicate non-participation in the MAPC. There may be various methods for indicating whether to participate in the MAPC using the BSR control field, but this is not limited thereto.
[0672] - Method for including MAPC information within a control frame and, in that case, the control frame format
[0673] Basically, values from 0000 to 0011 are reserved in the Subtype field of the control frame, which is indicated by type = 01 in the frame control field of the MAC header, so one of the reserved values can be used to define a control frame that serves as an ICR for the MAPC environment and / or one or more UHR functions.
[0674] FIG. 35 shows a first example of a control frame format that can be transmitted as an ICR.
[0675] Referring to FIG. 35, a control frame that can be transmitted as an ICR for a MAPC environment and / or one or more UHR functions is exemplified. The new control frame transmitted by the Coordinated AP may include one or more of the contents of the MAPC information described above, but is not limited thereto.
[0676] Additionally or alternatively, the new control frame as a response frame (or ICR) may include additional information depending on the solicited information and / or solicited response type that may be included in the ICF transmitted from the Coordinating AP. For example, if a request to include A-Control within the ICR is included in the ICF, a control frame such as FIG. 36 may be configured.
[0677] FIG. 36 shows a second example of a control frame format that can be transmitted as an ICR.
[0678] For example, the A-Control field included in a control frame such as FIG. 36 may be an A-Control that is the HE variant of HT Control. As shown in , since the HT Control field consists of 0 or 4 octets and B0 and B1 are utilized to indicate a specific variant, B0 and B1 of the A-Control field within the ICR / control frame in FIG. 36 may be reserved. shows an example of the HT Control field format.
[0679] VariantB0B1B2-B29B30B31HT0HT Control MiddleAC ConstraintRDG / More PPDUVHT10VHT Control MiddleAC ConstraintRDG / More PPDUHE11A-Control
[0680] For example, if the information solicited from the ICF transmitted by the Coordinating AP is BSR control information (e.g., Control ID = 3), the A-Control field format in a control frame such as FIG. 36 may be as shown in FIG. 37. FIG. 37 shows an example of the A-Control field format within a control frame.
[0681] For example, within a control frame, a Present field (or Present Flag field) may exist prior to the A-Control field to indicate the presence or absence of the A-Control field. The presence or absence of the A-Control field and / or the information contained in the A-Control field may be determined by the type of trigger frame transmitted from the Coordinating AP and / or information such as solicited information and the type of solicited response within said trigger frame. For example, if a BSRP trigger frame is transmitted as an ICF or if a response to a BSR is solicited within said ICF, the Coordinated AP may respond with a control frame containing an A-Control field indicating BSR information. Additionally or alternatively, if a MU-RTS trigger frame is transmitted as an ICF or if a response using a (new) control frame other than a CTS frame is solicited within said ICF, the Coordinated AP may respond with the (new) control frame described in this disclosure. In this case, the (new) control frame may include information for MAPC cooperation, but the A-Control field may be omitted.
[0682] Additionally or alternatively, the (novel) control frame described in this disclosure may include one or more A-Control fields according to information such as solicited information, solicited response type, etc., within the ICF transmitted from the Coordinating AP. A separate Present field (or Present Flag field) may exist within the (novel) control frame to indicate that one or more A-Control fields are included in the (novel) control frame.
[0683] FIG. 38 shows an example of a control frame format including one or more A-Control field(s).
[0684] For example, the A-Control Present field may consist of 0 or 2 octets, and each bit of the 2 octets may be mapped one-to-one with each control ID to indicate control information of the A-Control. That is, each bit of the A-Control Present field may be mapped to each control ID based on a bitmap method. If a specific bit of the A-Control Present field is set to 1, it may indicate that control information corresponding to that control ID exists. One or more bits within the A-Control Present field may be set to 1, which may indicate that one or more pieces of control information are included in the A-Control List. For example, if a bit of the A-Control Present field mapped to BSR is set to 1 and a bit of the A-Control Present field mapped to OM is set to 1, BSR information and OM information may be included simultaneously in the A-Control List. The order in which each piece of control information is included in the A-Control List may vary and is not limited to a specific order.
[0685] - Method for including MAPC information within a Management Frame and, in that case, the Management Frame format
[0686] In some implementations, the Management frame can be implemented as a Multi-AP ICR Action frame.
[0687] Basically, the Action frame (i.e., the Action field) consists of a Category field and an Action Details field, and Category values of 33, 38, 40-125, and 128-255 can be reserved. Therefore, as shown in , one of the reserved values can be used to indicate the Multi-AP ICR Action frame.
[0688] CodeMeaning......40Multi-AP ICR......
[0689] Referring to , for example, a category value of 40 can be used to indicate a Multi-AP ICR Action frame. However, category values for indicating a Multi-AP ICR Action frame are not limited to this. With category = 40, the Multi-AP ICR Action field can be defined as shown in .
[0690] ValueMeaning0MAPC Response1MAPC + A-Control Info Response2A-Control Info Response3-255Reserved
[0691] In , if the value of the Multi-AP ICR Action field is 0, it may indicate that the MAPC Response is included in the body of the Action frame, and in this case, the Multi-AP ICR Action field may be configured as shown in .
[0692] OrderMeaning1Category2MAPC Info
[0693] In , if the value of the Multi-AP ICR Action field is 1, it indicates that the MAPC Response and A-Control information are included together in the body of the Action frame, and in this case, the Multi-AP ICR Action field can be configured as shown in .
[0694] OrderMeaning1Category2MAPC Info3A-Control Info
[0695] In , if the value of the Multi-AP ICR Action field is 2, it indicates that only A-Control information is included in the body of the Action frame, and in this case, the Multi-AP ICR Action field can be configured as shown in .
[0696] OrderMeaning1Category2A-Control Info
[0697] To define MAPC information and / or A-Control Information elements, reserved Element IDs can be used as shown in .
[0698] ElementElement IDElement ID ExtensionExtensibleFragmentable… … … … … MAPC Info255120YesNoA-Control Info255121YesNo… … … … …
[0699] By utilizing the reserved Element ID Extension value (120), the MAPC Information element can be defined as shown in .
[0700] Element IDLengthElemlent ID ExtensionMAPC InformationOctets: 111variable
[0701] In addition, the MAPC Info fields included within the MAPC Information element can be defined as shown in .
[0702] LengthCommon MAPC InfoPer-scheme MAPC InfoOctets: 1variablevariable
[0703] Referring to , the MAPC Info field may include a Length field indicating the length of the field, a Common MAPC Info field containing information common to MAPC operations, and / or a Per-scheme MAPC Info field containing information utilized for each method. Additionally, one or more of the contents included in the ICR may be included within the Common MAPC Info field and / or the Per-scheme MAPC Info field. Furthermore, the A-Control Information element utilizing the reserved Element ID Extension value 121 can be defined as shown in .
[0704] Element IDLengthElement ID ExtensionA-Control InformationOctets: 111variable
[0705] The A-Control Info field within the A-Control Information element may contain the same information as the A-Control field defined in the IEEE 802.11 baseline. That is, the A-Control Info field can be defined as shown in :
[0706] Bits: B0 - B1B2 - B5variableReservedControl IDControl Information
[0707] For example, if the information solicited from the ICF transmitted by the Coordinating AP is BSR control information (e.g., control ID = 3), an example of the format of the A-Control Information element may be as shown in FIG. 39. FIG. 39 shows an example of the format of the A-Control Information element containing BSR information.
[0708] The presence of an A-Control Information element and / or the information contained in the A-Control Information element may be determined based on the type of trigger frame transmitted from the Coordinating AP and / or information such as solicited information and solicited response type within said trigger frame. For example, if a BSRP trigger frame is transmitted as an ICF or if a response to a BSR is solicited within said ICF, the Coordinated AP may respond with a new Action frame containing an A-Control Information element indicating BSR information. Additionally or alternatively, if a MU-RTS trigger frame is transmitted as an ICF or if a response using a new Action frame other than a CTS frame is solicited within said ICF, the Coordinated AP may respond with the new Action frame described in this disclosure. In this case, information for MAPC cooperation is included in the Action frame, but the A-Control Information element may be omitted from the Action frame.
[0709] Additionally or alternatively, the novel Action frame described in this disclosure may include one or more A-Control Info field(s) based on information such as solicited information, solicited response type, etc., within the ICF transmitted from the Coordinating AP. A separate Present field (or Present Flag field) may exist in the novel Action frame to indicate that one or more A-Control Info field(s) are included in the novel Action frame. shows an example of an A-Control Information element format including one or more A-Control Info field(s).
[0710] Element IDLengthElement ID ExtensionA-Control Information PresentA-Control Information ListOctets: 1110 or 2variable
[0711] The A-Control Information Present field may consist of 0 or 2 octets, and each bit of the 2 octets may be mapped one-to-one with each control ID to indicate control information of A-Control. That is, each bit of the A-Control Information Present field may be mapped to each control ID based on a bitmap method. If a specific bit of the A-Control Information Present field is set to 1, it may indicate that control information corresponding to the corresponding control ID exists. One or more bits within the A-Control Information Present field may be set to 1, which may indicate that one or more pieces of control information are included in the A-Control Information List. For example, if a bit of the A-Control Information Present field mapped to BSR is set to 1 and a bit of the A-Control Information Present field mapped to OM is set to 1, BSR information and OM information may be included simultaneously in the A-Control Information List. The order in which each control information is included in the A-Control Information List can vary and is not limited to a specific order. Fig. 40 shows an example of transmitting an Action frame to an ICR for an ICF.
[0712] Referring to FIG. 40, the Coordinated AP may transmit an Action frame as a response frame (ICR) to an ICF (e.g., BSRP TF) transmitted by the Coordinating AP. For example, the frame body within the Action frame may contain MAPC operation-related information (MAPC Information element) and / or an A-Control Information element. If BSR information is included within the A-Control Information element of the Action frame, buffer status information may be replaced by BSR information. Additionally or alternatively, the A-Control Info field may be utilized to replace participation instructions and / or status codes. For example, if configured to indicate information solicited from the ICF, the A-Control Info field may indicate participation in the MAPC, and one or more field(s) within the BSR may be set to 0 to indicate non-participation in the MAPC. There may be various methods for indicating participation in the MAPC using the A-Control Info field and are not limited to the examples described above.
[0713] In some implementations, the Management frame can be implemented as a Multi-AP ICR Action frame containing an HT control field.
[0714] A Multi-AP ICR Action frame may basically include a MAPC Information element and / or an A-Control Information element in the frame body of the Action frame. Additionally or alternatively, the A-Control Information element may be included in the HT control field of the Action frame instead of being included in the frame body.
[0715] The Action frame (i.e., the Action field) includes a Category field and an Action Details field, and Category values 33, 38, 40-125, and 128-255 are reserved. Therefore, one of the reserved values can be used to indicate a Multi-AP ICR Action frame. For example, the reserved Category value of 40 can be used to indicate a Multi-AP ICR Action frame.
[0716] With Category = 40, the Multi-AP ICR Action field can be defined as shown in .
[0717] ValueMeaning0MAPC Response1-255Reserved
[0718] If the value of the Multi-AP ICR Action field is 0, the body of the Action frame may contain a MAPC Response, and in this case, the Multi-AP ICR Action field may be configured as shown in :
[0719] OrderMeaning1Category2MAPC Info
[0720] To define the MAPC Information element, reserved Element IDs can be used as shown in .
[0721] ElementElement IDElement ID ExtensionExtensibleFragmentable… … … … … MAPC Info255120YesNo… … … … …
[0722] By utilizing the reserved Element ID Extension value (120), the MAPC Information element can be defined as shown in .
[0723] Element IDLengthElemlent ID ExtensionMAPC InformationOctets: 111variable
[0724] The MAPC Info fields included within the MAPC Information element can be defined as shown in .
[0725] LengthCommon MAPC InfoPer-scheme MAPC InfoOctets: 1variablevariable
[0726] The MAPC Info field may include a Length field indicating the length of the field, a Common MAPC Info field containing information common to MAPC operations, and / or a Per-scheme MAPC Info field containing information utilized for each scheme. Additionally, one or more of the contents included in the ICR may be included within the Common MAPC Info field and / or the Per-scheme MAPC Info field. Furthermore, depending on the type of frame transmitted by the Coordinating AP to the ICF, the HT control field within the Action frame transmitted by the Coordinated AP as the ICR may be utilized. For example, when the Coordinating AP transmits a BSRP trigger frame, B0 and B1 of the HT control field may be set to 1 to include A-Control information (e.g., BSR) for the HE variant.
[0727] The presence of an A-Control field and / or the information contained in the A-Control field may be determined based on the type of trigger frame transmitted from the Coordinating AP and / or information such as solicited information and the type of solicited response within said trigger frame. For example, if a BSRP trigger frame is transmitted as an ICF or if a response to a BSR is solicited within said ICF, the Coordinated AP may respond with a new Action frame containing an A-Control indicating BSR information in the HT control field. Additionally or alternatively, if a MU-RTS trigger frame is transmitted as an ICF or if a response using a new Action frame other than a CTS frame is solicited within said ICF, the Coordinated AP may respond with the new Action frame described in this disclosure. In this case, information for MAPC cooperation is included in the new Action frame, but the A-Control may be omitted from the new Action frame.
[0728] Figure 41 shows an example of transmitting an Action frame containing an HT control field to an ICR for an ICF.
[0729] Referring to FIG. 41, the Coordinated AP may transmit an Action frame containing an HT control field as a response frame (ICR) to an ICF (e.g., BSRP TF) transmitted by the Coordinating AP. The frame body within the Action frame contains MAPC operation-related information (MAPC Information element), and if necessary, the HT control field may contain an A-Control. If BSR information is included within the HT control field of the Action frame, buffer status information may be replaced by BSR information. Additionally or alternatively, the HT control field (e.g., BSR) may be utilized to replace participation instructions and / or status codes. For example, if configured to indicate information solicited from the ICF, the HT control field may indicate participation in the MAPC, and one or more field(s) within the BSR may be set to 0 to indicate non-participation in the MAPC. There may be various methods for indicating participation in the MAPC using the HT control field and are not limited to the examples described above.
[0730] In some implementations, the Management frame can be implemented as a Multi-AP ICR Public Action frame.
[0731] Basically, the Action frame (i.e., the Action field) includes a Category field and an Action Details field, and Category values 33, 38, 40-125, and 128-255 are reserved. On the other hand, the Public Action frame includes a Category field, a Public Action field, and an Action Details field, and Category values 54-59 and 61-255 are reserved. Therefore, one of the reserved values can be used to indicate the Multi-AP ICR Public Action frame. For example, as shown in , the Public Action field value of 54 can be used to indicate the MAPC + A-Control Info Response frame.
[0732] Public Action field valueDescription......54MAPC + A-Control Info Response......
[0733] In this case, an example of the Action field format of the MAPC + A-Control Info Response frame may be as shown in .
[0734] OrderInformation1Category2Public Action3MAPC Info4A-Control Info
[0735] To define MAPC information and A-Control Information elements, reserved Element IDs can be used as shown in .
[0736] ElementElement IDElement ID ExtensionExtensibleFragmentable… … … … … MAPC Info255120YesNoA-Control Info255121YesNo… … … … …
[0737] By utilizing the reserved Element ID Extension value (120), the MAPC Information element can be defined as shown in .
[0738] Element IDLengthElemlent ID ExtensionMAPC InformationOctets: 111variable
[0739] The MAPC Info fields included within the MAPC Information element can be defined as shown in .
[0740] LengthCommon MAPC InfoPer-scheme MAPC InfoOctets: 1variablevariable
[0741] The MAPC Info field may include a Length field indicating the length of the field, a Common MAPC Info field containing information common to MAPC operations, and / or a Per-scheme MAPC Info field containing information utilized for each method. Additionally, one or more of the contents included in the ICR may be included within the Common MAPC Info field and / or the Per-scheme MAPC Info field. Furthermore, the A-Control Information element utilizing the reserved Element ID Extension value 121 may be defined as shown in .
[0742] Element IDLengthElement ID ExtensionA-Control InformationOctets: 111variable
[0743] The A-Control Info field within the A-Control Information element may contain the same information as the A-Control field defined in the IEEE 802.11 baseline. That is, the A-Control Info field can be defined as shown in :
[0744] Bits: B0 - B1B2 - B5variableReservedControl IDControl Information
[0745] For example, if the information solicited from the ICF transmitted by the Coordinating AP is BSR control information (e.g., Control ID = 3), an example of the format of the A-Control Information element may be as shown in FIG. 39. The existence of the A-Control Information element and / or the information contained in the A-Control Information element may be determined by the type of trigger frame transmitted from the Coordinating AP and / or information such as the solicited information and the solicited response type within the trigger frame. For example, if a BSRP trigger frame is transmitted as an ICF or a response to BSR is solicited within the ICF, the Coordinated AP may respond with a new Public Action frame containing an A-Control Information element indicating BSR information. Additionally or alternatively, if a MU-RTS trigger frame is transmitted as an ICF or a response using a new Public Action frame other than a CTS frame is solicited within the ICF, the Coordinated AP may respond with the new Public Action frame described in this disclosure. In this case, information for MAPC cooperation is included in the Public Action frame, but the A-Control Information element can be omitted from the Public Action frame.
[0746] Additionally or alternatively, the novel Public Action frame described in this disclosure may include one or more A-Control Info field(s) based on information such as solicited information, solicited response type, etc., within the ICF transmitted from the Coordinating AP. A separate Present field (or Present Flag field) may exist in the novel Public Action frame to indicate that one or more A-Control Info field(s) are included in the novel Public Action frame. Table 27 shows an example of an A-Control Information element format including one or more A-Control Info field(s).
[0747] Element IDLengthElement ID ExtensionA-Control Information PresentA-Control Information ListOctets: 1110 or 2variable
[0748] The A-Control Information Present field may consist of 0 or 2 octets, and each bit of the 2 octets may be mapped one-to-one with each control ID to indicate control information of A-Control. That is, each bit of the A-Control Information Present field may be mapped to each control ID based on a bitmap method. If a specific bit of the A-Control Information Present field is set to 1, it may indicate that control information corresponding to the corresponding control ID exists. One or more bits within the A-Control Information Present field may be set to 1, which may indicate that one or more pieces of control information are included in the A-Control Information List. For example, if a bit of the A-Control Information Present field mapped to BSR is set to 1 and a bit of the A-Control Information Present field mapped to OM is set to 1, BSR information and OM information may be included simultaneously in the A-Control Information List. The order in which each control information is included in the A-Control Information List can vary and is not limited to a specific order. Figure 42 shows an example of transmitting a Public Action frame to an ICR for an ICF.
[0749] Referring to FIG. 42, the Coordinated AP may transmit a Public Action frame as a response frame (ICR) to an ICF (e.g., BSRP TF) transmitted by the Coordinating AP. For example, the frame body within the Public Action frame may contain MAPC operation-related information (MAPC Information element) and / or an A-Control Information element. If BSR information is included within the A-Control Information element of the Public Action frame, buffer status information may be replaced by BSR information. Additionally, or alternatively, the A-Control Info field may be utilized to replace participation instructions and / or status codes. For example, if configured to indicate information solicited from the ICF, the A-Control Info field may indicate participation in the MAPC, and one or more field(s) within the BSR may be set to 0 to indicate non-participation in the MAPC. There may be various methods for indicating participation in the MAPC using the A-Control Info field and are not limited to the examples described above.
[0750] In some implementations, the Management frame can be implemented as a Multi-AP ICR Public Action frame containing an HT control field.
[0751] The Multi-AP ICR Public Action frame basically includes a MAPC Information element and / or an A-Control Information element in the frame body of the Public Action frame. Additionally or alternatively, the A-Control Information element may be included in the HT control field of the Public Action frame instead of being included in the frame body.
[0752] The Public Action frame includes a Category field, a Public Action field, and Action Details fields, and Category values from 61 to 255 are reserved. Therefore, one of the reserved values can be used to indicate the Multi-AP ICR Public Action frame. For example, as shown in , the Public Action field value of 54 can be used to indicate the MAPC Info Response frame.
[0753] Public Action field valueDescription......54MAPC Info Response......
[0754] The format of the Action field in the MAPC Info Response frame may be as shown in .
[0755] OrderInformation1Category2Public Action3MAPC Info
[0756] To define the MAPC Information element, reserved Element IDs can be used as shown in .
[0757] ElementElement IDElement ID ExtensionExtensibleFragmentable… … … … … MAPC Info255120YesNo… … … … …
[0758] By utilizing the reserved Element ID Extension value (120), the MAPC Information element can be defined as shown in .
[0759] Element IDLengthElemlent ID ExtensionMAPC InformationOctets: 111variable
[0760] The MAPC Info fields included within the MAPC Information element can be defined as shown in .
[0761] LengthCommon MAPC InfoPer-scheme MAPC InfoOctets: 1variablevariable
[0762] The MAPC Info field may include a Length field indicating the length of the field, a Common MAPC Info field containing information common to MAPC operations, and / or a Per-scheme MAPC Info field containing information utilized for each scheme. Additionally, one or more of the contents included in the ICR may be included within the Common MAPC Info field and / or the Per-scheme MAPC Info field. Furthermore, depending on the type of frame transmitted by the Coordinating AP to the ICF, the HT control field within the Public Action frame transmitted by the Coordinated AP as the ICR may be utilized. For example, when the Coordinating AP transmits a BSRP trigger frame, B0 and B1 of the HT control field may be set to 1 to include A-Control information (e.g., BSR) for the HE variant.
[0763] The presence of an A-Control field and / or the information contained in the A-Control field may be determined by the type of trigger frame transmitted from the Coordinating AP and / or information such as solicited information and the type of solicited response within said trigger frame. For example, if a BSRP trigger frame is transmitted as an ICF or if a response to a BSR is solicited within said ICF, the Coordinated AP may respond with a new Public Action frame containing an A-Control indicating BSR information in the HT control field. Additionally or alternatively, if a MU-RTS trigger frame is transmitted as an ICF or if a response using a new Public Action frame other than a CTS frame is solicited within said ICF, the Coordinated AP may respond with the new Public Action frame described in this disclosure. In this case, information for MAPC cooperation is included in the new Public Action frame, but the A-Control may be omitted from the new Public Action frame.
[0764] Figure 43 shows an example of transmitting a Public Action frame containing an HT control field to an ICR for an ICF.
[0765] Referring to FIG. 43, the Coordinated AP may transmit a Public Action frame containing an HT control field as a response frame (ICR) to an ICF (e.g., BSRP TF) transmitted by the Coordinating AP. The frame body within the Public Action frame contains MAPC operation-related information (MAPC Information element), and if necessary, the HT control field may contain an A-Control. If BSR information is included within the HT control field of the Public Action frame, buffer status information may be replaced by BSR information. Additionally or alternatively, the HT control field (e.g., BSR) may be utilized to replace participation instructions and / or status codes. For example, if configured to indicate information solicited from the ICF, the HT control field may indicate participation in the MAPC, and one or more field(s) within the BSR may be set to 0 to indicate non-participation in the MAPC. There may be various methods for indicating participation in the MAPC using the HT control field and are not limited to the examples described above.
[0766] The present disclosure proposes a method for including information for MAPC operations in an ICF that may be transmitted to start and / or trigger MAPC operations of each AP in an MAPC environment. Specifically, it proposes a method for including information that may be included in an ICF for MAPC operations and including this information within a BSRP trigger frame. Using the method for including control information / information for MAPC operations presented in the present disclosure, a Coordinating AP may transmit an ICF and / or CRF containing MAPC-related information to be transmitted to a receiving STA.
[0767] Furthermore, the present disclosure proposes a method for transmitting data frames, control frames, and / or new management frames (e.g., Action, Public Action frames) as response frames to an ICF (or Invite frame) that may be transmitted from a Coordinating AP in an MAPC. Based on information contained in the response frame transmitted from the Coordinated AP(s) and / or information regarding whether they participate in the MAPC, the Coordinating AP can select an appropriate Coordinated AP and perform more efficient multi-AP cooperation.
[0768] The technical features of the present disclosure described above may be applied to various devices and methods. For example, the technical features of the present disclosure described above may be performed or supported through the device of FIG. 1 and / or FIG. 5. For example, the technical features of the present disclosure described above may be applied only to parts of FIG. 1 and / or FIG. 5. For example, the technical features of the present disclosure described above may be implemented based on the processing chip (114, 124) of FIG. 1, or based on the processor (111, 121) and memory (112, 122) of FIG. 1, or based on the processor (510) and memory (520) of FIG. 5.
[0769] For example, the processor (121) and / or processing chip (124) of FIG. 1 may be configured to execute instructions stored in memory (122) to perform operations performed by the first AP in the present disclosure. The operations include: establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; transmitting an initial control frame (ICF) to a second AP among the one or more other APs, wherein the ICF contains information regarding transmission power proposed to the second AP; receiving an initial control response frame (ICR) for the ICF from the second AP; transmitting a trigger frame to trigger MAPC to the second AP; and performing MAPC with the second AP based on transmission power proposed to the second AP.
[0770] For example, the processor (111), processing chip (114) of FIG. 1 and / or the processor (510) of FIG. 5 may be configured to execute instructions stored in memory (112, 520) to perform operations performed by the second AP in the present disclosure. The operations include: establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; receiving an initial control frame (ICF) from the first AP among the one or more other APs, wherein the ICF contains information regarding transmission power proposed to the second AP; transmitting an initial control response frame (ICR) for the ICF to the first AP; receiving a trigger frame for triggering MAPC from the first AP; and the second AP performing MAPC with the first AP based on transmission power proposed to the second AP.
[0771] The technical features of the present disclosure may be implemented based on a computer-readable medium (CRM). For example, the CRM proposed by the present disclosure is at least one computer-readable medium comprising instructions based on execution by at least one processor.
[0772] For example, the CRM may be the memory (122) of FIG. 1 and / or a separate external memory / storage medium / disk. The CRM may store instructions for performing operations performed by the first AP in the present disclosure based on execution by a processor (e.g., the processor (121) and / or processing chip (124) of FIG. 1). The operations include: establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; transmitting an initial control frame (ICF) to a second AP among the one or more other APs, wherein the ICF contains information regarding transmission power proposed for the second AP; receiving an initial control response frame (ICR) for the ICF from the second AP; transmitting a trigger frame to trigger MAPC to the second AP; and performing MAPC with the second AP based on transmission power proposed for the second AP.
[0773] For example, the CRM may be the memory (112) of FIG. 1, the memory (520) of FIG. 5, and / or a separate external memory / storage medium / disk. The CRM may store instructions for performing operations performed by the second AP in the present disclosure based on execution by a processor (e.g., the processor (111) of FIG. 1, the processing chip (114), and / or the processor (510) of FIG. 5). The operations include: establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; receiving an initial control frame (ICF) from the first AP among the one or more other APs, wherein the ICF contains information regarding transmission power proposed for the second AP; transmitting an initial control response frame (ICR) for the ICF to the first AP; and receiving a trigger frame for triggering MAPC from the first AP. and includes an operation in which the second AP performs MAPC with the first AP based on the transmission power proposed for the second AP.
[0774] The technical features of the present disclosure described above are applicable to various applications or business models. For example, the technical features described above may be applied for wireless communication in devices supporting Artificial Intelligence (AI).
[0775] Artificial intelligence refers to the field of researching artificial intelligence or the methodologies to create it, while machine learning refers to the field of researching methodologies to define and solve various problems addressed within the field of artificial intelligence. Machine learning is also defined as an algorithm that improves performance on a task through continuous experience.
[0776] An Artificial Neural Network (ANN) is a model used in machine learning that can refer to any model capable of problem-solving, composed of artificial neurons (nodes) that form a network through the connection of synapses. An artificial neural network can be defined by connection patterns between neurons in different layers, a learning process that updates model parameters, and an activation function that generates output values.
[0777] An artificial neural network may include an input layer, an output layer, and optionally one or more hidden layers. Each layer may include one or more neurons, and the artificial neural network may include synapses connecting the neurons. In an artificial neural network, each neuron may output a function value of an activation function for input signals, weights, and biases input through the synapses.
[0778] Model parameters refer to parameters determined through learning, including synaptic connection weights and neuron biases. Hyperparameters, on the other hand, refer to parameters that must be set prior to training in a machine learning algorithm, including the learning rate, number of iterations, mini-batch size, and initialization function.
[0779] The objective of training an artificial neural network can be viewed as determining model parameters that minimize the loss function. The loss function can be used as an indicator to determine optimal model parameters during the training process of an artificial neural network.
[0780] Machine learning can be classified into supervised learning, unsupervised learning, and reinforcement learning depending on the learning method.
[0781] Supervised learning refers to a method of training an artificial neural network with labels provided for the training data; a label can refer to the correct answer (or result) that the neural network must infer when the training data is input. Unsupervised learning refers to a method of training an artificial neural network without labels provided for the training data. Reinforcement learning refers to a learning method in which an agent defined within an environment is trained to select an action or sequence of actions that maximizes the cumulative reward in each state.
[0782] Machine learning implemented using a Deep Neural Network (DNN) that includes multiple hidden layers among artificial neural networks is also called Deep Learning, and Deep Learning is a part of Machine Learning. Hereinafter, Machine Learning is used in a sense that includes Deep Learning.
[0783] In addition, the aforementioned technical features can be applied to the wireless communication of robots.
[0784] A robot can refer to a machine that automatically processes or operates a given task based on its own capabilities. In particular, a robot that has the ability to perceive its environment, make decisions on its own, and perform actions can be called an intelligent robot.
[0785] Robots can be classified into industrial, medical, domestic, and military types depending on their purpose or field of use. Robots are equipped with drive units, including actuators or motors, to perform various physical movements, such as moving robot joints. Additionally, mobile robots include wheels, brakes, and propellers in their drive units, enabling them to drive on the ground or fly in the air.
[0786] In addition, the aforementioned technical features can be applied to devices that support augmented reality.
[0787] Extended Reality is a collective term for Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR). VR technology provides real-world objects or backgrounds solely as CG images, AR technology provides virtual CG images superimposed on real-world images, and MR technology is a computer graphics technology that mixes and combines virtual objects with the real world.
[0788] MR technology is similar to AR technology in that it displays real-world objects and virtual objects together. However, there is a difference in that while virtual objects in AR technology are used to complement real-world objects, virtual objects and real-world objects are used as equals in MR technology.
[0789] XR technology can be applied to HMDs (Head-Mount Displays), HUDs (Head-Up Displays), mobile phones, tablet PCs, laptops, desktops, TVs, digital signage, etc., and devices to which XR technology is applied can be called XR devices.
[0790] According to embodiments of the present disclosure, the first STA may transmit one or more PPDU / frames including a control information field that may include type-specific information according to the instructions of the control information type field.
[0791] Additionally or alternatively, the control information may include one or more of the following:
[0792] - Control information for MAPC;
[0793] - Control information for DPS;
[0794] - Control information for NPCA;
[0795] - Control information for the IDC; and / or
[0796] - The 1st STA uses existing control information (e.g., BSR)
[0797] Additionally, control information can be transmitted to the receiving STA through a trigger frame.
[0798] Additionally or alternatively, the control information type and / or control information may be included within a new Special User Info field, and a Flag field indicating the presence of control information may exist in the Common Info field and / or User Info field of the trigger frame. That is, a new Special / Specific AID12 value (e.g., 2008 or higher) may be defined in the User Info field of the trigger frame to indicate that it is a new Special User Info field.
[0799] Additionally or alternatively, control information types and / or control information may be included in Common Info fields and / or User Info fields.
[0800] Additionally or alternatively, control information types and / or control information may be included in the padding field.
[0801] Additionally or alternatively, the control information type can indicate the type in a bitmap manner.
[0802] Additionally or alternatively, the type of control information can be based on bit instructions.
[0803] Additionally or alternatively, MAPC types that may be included within the control information can indicate the type in a bitmap manner.
[0804] Additionally or alternatively, the MAPC types that may be included within the control information can be based on bit instructions.
[0805] According to various embodiments of the present disclosure, a second STA receiving one or more PPDU / frames containing control information of a trigger frame from a first STA can perform frame detection, and through frame detection, can obtain control information transmitted by the first STA and perform a subsequent operation.
[0806] A second STA that detects control information from a first STA may transmit a response frame containing information to be conveyed to the first STA in relation to the corresponding type of control information.
[0807] Additionally, the response frame transmitted by the second STA may include one or more of the following:
[0808] - Common and / or per-user control information of the MAPC to be responded to by the 2nd STA;
[0809] - Information on whether to participate in the MAPC directed by the 1st STA;
[0810] - Common and / or user-specific control information of the DPS to be responded to by the 2nd STA;
[0811] - Common and / or user-specific control information of the NPCA to be responded to by the 2nd STA;
[0812] - Common and / or user-specific control information of the IDC to be responded to by the 2nd STA;
[0813] - Baseline control information to be responded to by the 2nd STA (e.g., BSR); and / or
[0814] - Security-related common and / or user-specific control information to be responded to by the 2nd STA.
[0815] Additionally, common and / or user-specific control information transmitted by the second STA may be included in a Multi-STA BA frame and transmitted as a response.
[0816] Additionally or alternatively, common and / or user-specific control information transmitted by the second STA may be included in the definition / extension of a new A-Control field responding to the trigger frame and transmitted as a response.
[0817] Additionally or alternatively, common and / or user-specific control information transmitted by the second STA may be included in a new control frame responding to the trigger frame and transmitted as a response.
[0818] Additionally or alternatively, common and / or user-specific control information transmitted by the second STA may be included in a new (Public) Action frame responding to the trigger frame and transmitted as a response.
[0819] Additionally or alternatively, common and / or user-specific control information transmitted by the second STA may be included in a new (Public) Action frame containing A-Control in the HT Control responding to the trigger frame and transmitted as a response.
[0820] The present disclosure may have various advantageous effects.
[0821] For example, based on the exchange of ICF / ICR according to various embodiments of the present disclosure, the Coordinating AP can select an appropriate Coordinated AP. Additionally, the Coordinating AP / Coordinated AP can perform more efficient multi-AP cooperation.
[0822] For example, if the Coordinating AP transmits an ICF containing transmit power information proposed in a multi-AP selection procedure / step (e.g., if the Coordinating AP transmits a Co-SR Invite frame containing transmit power information proposed in the invitation step for Co-SR), the following effects can be expected:
[0823] i) The Coordinated AP can select the accurate / optimal target STA based on the proposed transmit power information;
[0824] ii) Coordinated AP can maximize the number of potential target STAs based on proposed transmit power information;
[0825] iii) The Coordinated AP can determine the MCS and / or packet length early based on the proposed transmit power information; and / or
[0826] iv) The Coordinated AP may transmit an ICR (e.g., Co-SR Response frame) containing Tx power information required for the Coordinated AP in response to the ICF, and thereby the Coordinating AP may improve / modify the MCS value based on the required Tx power information.
[0827] The advantageous effects obtainable through specific embodiments of the present disclosure are not limited to those listed above. For example, there may be various technical effects that a person skilled in the art can understand and / or derive from the present disclosure. Accordingly, the specific effects of the present disclosure are not limited to those explicitly described herein and may include various effects that can be understood or derived from the technical features of the present disclosure.
[0828] The claims described in this disclosure may be combined in various ways. For example, the technical features of the method claims of this disclosure may be combined to be implemented as a device, and the technical features of the device claims of this disclosure may be combined to be implemented as a method. Additionally, the technical features of the method claims of this disclosure and the technical features of the device claims of this disclosure may be combined to be implemented as a device, and the technical features of the method claims of this disclosure and the technical features of the device claims of this disclosure may be combined to be implemented as a method.
Claims
A step in which the first AP (access point) establishes an agreement with one or more other APs for multi-AP coordination (MAPC); The step of the first AP transmitting an ICF (initial control frame) to the second AP among the one or more other APs, The above ICF includes information regarding the transmission power proposed for the above second AP; The step of the first AP receiving an ICR (initial control response frame) for the ICF from the second AP; The step of the first AP transmitting a trigger frame to the second AP to trigger a MAPC; and A method comprising the step of performing MAPC with the second AP based on the transmission power proposed by the first AP to the second AP. In claim 1, the first AP further comprises the step of performing a multiple AP selection procedure for selecting one or more target APs for MAPC among one or more other APs, and The step of performing the above multiple AP selection procedure is: The step of the first AP transmitting the ICF to the second AP; and The above first AP includes the step of receiving the ICR from the above second AP, and The above second AP is a method included in the above one or more target APs. In claim 1, the step of performing the MAPC is: A step of determining the transmission power of the first AP based on the transmission power proposed to the second AP by the first AP; and A method comprising the step of the first AP performing MAPC with the second AP based on the transmission power of the first AP. In claim 1, the step of performing the MAPC includes the step of performing the MAPC based on the MAPC method, and The above MAPC method is a method comprising at least one of Co-BF (coordinated beamforming), Co-SR (coordinated spatial reuse), Co-TDMA (coordinated time division multiple access), Co-RTWT (coordinated restricted target wake time), or Co-CR (coordinated channel recommendation). In claim 4, the MAPC method is the Co-BF or the Co-SR, and A method comprising the step of performing the above MAPC, wherein while the second AP performs transmission in a time interval to one or more STAs (stations) associated with the second AP, the first AP performs transmission in a time interval to one or more STAs associated with the first AP. In claim 4, the MAPC method is the Co-TDMA, and Based on the above Co-TDMA: Frame exchange between the first AP and one or more STAs (stations) associated with the first AP is performed in a first time interval, and A method in which frame exchange between the second AP and one or more STAs connected to the second AP is performed in a second time interval different from the first time interval. A method according to claim 4, wherein the ICF is a Co-BF invite frame, a Co-SR invite frame, or a BSRP (buffer status report poll) trigger frame in the polling step for Co-TDMA. A method according to claim 1, wherein the transmission power proposed for the second AP includes the maximum transmission power of the second AP limited for the second AP. In claim 8, the maximum transmission power is set so that the transmission of the second AP does not interfere with the transmission of the first AP. A method according to claim 1, wherein information regarding transmission power proposed for the second AP is included in the common information field, user information field, or special user information field of the ICF. A method according to claim 1, wherein the ICF further comprises at least one of information regarding the cooperation period during which MAPC is performed, or information regarding an acknowledgment policy applied to the second AP and one or more STAs associated with the second AP. In claim 11, the Ack policy is a method of indicating a Normal Ack, an Implicit BAR (block Ack request), or a Block Ack. In claim 11, the cooperation period is: A first ACK period required for an ACK sequence between the first AP and one or more STAs connected to the first AP; or A second ACK period allowed for an ACK sequence between the second AP and one or more STAs connected to the second AP. Includes at least one of the following, The ACK sequence between the first AP and one or more STAs connected to the first AP includes transmission of the first AP and reception of an ACK for transmission of the first AP, and A method comprising an ACK sequence between the second AP and one or more STAs connected to the second AP, including transmission of the second AP and reception of an ACK for transmission of the second AP. A method according to claim 13, wherein the second Ack period is the maximum Ack sequence period allowed for the second AP. In claim 13, the Ack policy is a method applied during the second Ack period. At the first AP (access point), Transmitter / Receiver; Memory; and It includes at least one processor functionally coupled with the above-mentioned transceiver and the above-mentioned memory, and The above memory stores instructions for performing operations based on execution by the at least one processor, and the operations are: The action of establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; As an operation of transmitting an ICF (initial control frame) to a second AP among the above one or more other APs, The above ICF includes information regarding the transmission power proposed for the above second AP; The operation of receiving an ICR (initial control response frame) for the ICF from the second AP; The operation of transmitting a trigger frame to trigger the MAPC to the second AP; and A first AP including an operation to perform MAPC with the second AP based on the transmission power proposed for the second AP. In the device, At least one processor; and It includes at least one memory functionally coupled with the above-mentioned at least one processor, and The above at least one memory stores instructions for performing operations based on execution by the above at least one processor, and the operations are: The operation of the first AP (access point) establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; The operation of the first AP transmitting an ICF (initial control frame) to the second AP among the one or more other APs, The above ICF includes information regarding the transmission power proposed for the above second AP; The operation of the first AP receiving an ICR (initial control response frame) for the ICF from the second AP; The operation of the first AP transmitting a trigger frame to the second AP to trigger a MAPC; and A device comprising an operation in which the first AP performs MAPC with the second AP based on the transmission power proposed for the second AP. In a non-transitory computer-readable medium (CRM) storing program code that implements instructions for performing operations based on execution by at least one processor, said operations are: The operation of the first AP (access point) establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; The operation of the first AP transmitting an ICF (initial control frame) to the second AP among the one or more other APs, The above ICF includes information regarding the transmission power proposed for the above second AP; The operation of the first AP receiving an ICR (initial control response frame) for the ICF from the second AP; The operation of the first AP transmitting a trigger frame to the second AP to trigger a MAPC; and A CRM comprising an operation in which the first AP performs MAPC with the second AP based on the transmission power proposed for the second AP. A step in which the second AP (access point) establishes an agreement with one or more other APs for multi-AP coordination (MAPC); The step of the second AP receiving an ICF (initial control frame) from the first AP among the one or more other APs, The above ICF includes information regarding the transmission power proposed for the above second AP; The step of the second AP transmitting an ICR (initial control response frame) for the ICF to the first AP; The step of the second AP receiving a trigger frame for triggering a MAPC from the first AP; and A method comprising the step of performing MAPC with the first AP based on the transmission power proposed for the second AP. In the second AP (access point), Transmitter / Receiver; Memory; and It includes at least one processor functionally coupled with the above-mentioned transceiver and the above-mentioned memory, and The above memory stores instructions for performing operations based on execution by the at least one processor, and the operations are: The action of establishing an agreement for multi-AP coordination (MAPC) with one or more other APs; As an operation of receiving an ICF (initial control frame) from the first AP among the above one or more other APs, The above ICF includes information regarding the transmission power proposed for the above second AP; The operation of transmitting an ICR (initial control response frame) for the ICF to the first AP; The operation of receiving a trigger frame for triggering a MAPC from the first AP; and A second AP including an operation to perform MAPC with the first AP based on the transmission power proposed for the second AP.