Method and apparatus for requesting partial information for AP in transmission MLD in wireless LAN system

The method of requesting partial information for an AP within a transmitting MLD in wireless LAN systems addresses the challenge of efficiently utilizing increased spatial streams by reducing frame overhead and enhancing link usage efficiency.

JP2025061153AActive Publication Date: 2025-04-10LG ELECTRONICS INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025003388
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2020-11-20
Filing Date
2025-01-09
Publication Date
2025-04-10
Estimated Expiration
2041-11-18

AI Technical Summary

Technical Problem

Existing wireless LAN systems face challenges in efficiently utilizing increased spatial streams due to limitations in signaling techniques, particularly in next-generation systems like IEEE802.11be.

Method used

A method and apparatus for requesting partial information for an AP within a transmitting MLD in wireless LAN systems, utilizing a probe request frame with a multiple link element that includes a request element, allowing for efficient data exchange and reduced frame overhead.

Benefits of technology

This approach enables non-AP MLDs to request partial information for specific links, reducing frame overhead and improving the efficiency of link usage in next-generation wireless LAN systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025061153000001_ABST
    Figure 2025061153000001_ABST
Patent Text Reader

Abstract

To provide a method and an apparatus for requesting partial information for an AP in a transmitting MLD.SOLUTION: A receiving MLD transmits a probe request frame to a transmitting MLD via a first link. The receiving MLD receives a probe response frame from the transmitting MLD via the first link. The receiving MLD includes a first receiving STA operating in the first link and a second receiving STA operating in the second link. The probe request frame includes a profile field of the second receiving STA. The profile field of the second receiving STA includes a first overall information profile subfield. When the first receiving STA requests partial information for the second link, the value of the first overall information profile subfield is set to 0, and the profile field of the second receiving STA further includes a first request element. The partial information for the second link is requested on the basis of the first request element.SELECTED DRAWING: Figure 65
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present specification relates to multi-link operation in a wireless LAN system, and more particularly, to a method and apparatus for requesting partial information for an AP in a transmitting MLD. [Background technology]

[0002] WLAN (wireless local area network) has been improved in various ways, for example, the IEEE 802.11ax standard proposed an improved communication environment using OFDMA (orthogonal frequency division multiple access) and DL MU MIMO (downlink multi-user multiple input, multiple output) technologies.

[0003] This specification proposes technical features that can be utilized in a new communication standard. For example, the new communication standard is the Extreme high throughput (EHT) standard that has been recently discussed. The EHT standard can use newly proposed bandwidth increases, improved PHY layer protocol data unit (PPDU) structure, improved sequences, and Hybrid automatic repeat request (HARQ) techniques. The EHT standard can be referred to as the IEEE 802.11be standard.

[0004] New WLAN standards will use an increased number of spatial streams, which requires improved signaling techniques within the WLAN system to properly use the increased number of spatial streams. Summary of the Invention [Problem to be solved by the invention]

[0005] This specification proposes a method and apparatus for requesting partial information for an AP in a sending MLD in a wireless LAN system. [Means for solving the problem]

[0006] An example of this specification proposes a method to request partial information for an AP in a sending MLD.

[0007] This embodiment is executed in a network environment in which a next-generation wireless LAN system (IEEE 802.11be or EHT wireless LAN system) is supported. The next-generation wireless LAN system is an improved wireless LAN system of the 802.11ax system and can satisfy backward compatibility with the 802.11ax system.

[0008] In this embodiment, when a non-AP STA requests partial information for another AP that is not a peer AP through a probe request frame in MLD communication, a method and apparatus are proposed for including a request element in a multiple link element of the probe request frame and requesting partial information for a specific AP based on the request element. Here, the sending MLD corresponds to the AP MLD and the receiving MLD corresponds to the non-AP MLD. If the non-AP STA is a first receiving STA, the first receiving STA and the first sending STA connected to the first link can be said to be a peer AP, and the second and third sending STAs connected to another link can be said to be another AP.

[0009] A receiving MLD (Multi-link Device) transmits a probe request frame to a transmitting MLD via a first link.

[0010] The receiving MLD receives a probe response frame from the transmitting MLD via the first link.

[0011] The transmitting MLD includes a first transmitting STA (station) operating in the first link and a second transmitting STA operating in the second link, and the receiving MLD includes a first receiving STA operating in the first link and a second receiving STA operating in the second link.

[0012] The probe request frame includes a profile field of the second receiving STA, and the profile field of the second receiving STA includes a first overall information profile subfield.

[0013] When the first receiving STA requests partial information for the second link, the value of the first full information profile subfield is set to 0. The profile field of the second receiving STA further includes a first request element. In this case, the partial information for the second link is requested based on the first request element. Effect of the Invention

[0014] According to the embodiment proposed in this specification, by setting an indicator for whether or not to include a request element in the profile field of each receiving STA included in a multiple link element, and proposing a method of requesting partial information for a specific AP based on the request element, non-AP MLD can always request partial information rather than full information for another link, thereby reducing frame overhead. [Brief description of the drawings]

[0015] [Figure 1] 1 illustrates an example of a transmitting device and / or a receiving device of the present specification. [Diagram 2] 1 is a conceptual diagram showing the structure of a wireless LAN (WLAN). [Diagram 3] 1 is a diagram illustrating a typical link setup process. [Figure 4] 1 is a diagram showing an example of a PPDU used in the IEEE standard. [Diagram 5] The operation related to UL-MU is shown. [Figure 6] 1 shows an example of a trigger frame. [Figure 7] 1 shows an example of a common information field of a trigger frame. [Figure 8] An example of subfields included in a per user information field is shown below. [Figure 9] Explain the technical features of UORA technology. [Figure 10] 1 shows an example of a PPDU used in this specification. [Figure 11] 1 shows a variation of the transmitting device and / or the receiving device of the present specification. [Figure 12] 1 shows an example of a non-AP MLD structure. [Figure 13] 1 shows an example in which an AP MLD and a non-AP MLD are connected via a link setup process. [Figure 14] Here is an example where a link is changed or reconnected. [Figure 15] Here is a specific example of how a link is changed or reconnected. [Figure 16] 4 shows the operation of AP MLD and non-AP MLD for link change or reconnection. [Figure 17] 4 shows the operation of AP MLD and non-AP MLD for link change or reconnection. [Figure 18] 4 shows the operation of AP MLD and non-AP MLD for link change or reconnection. [Figure 19] 4 shows the operation of AP MLD and non-AP MLD for link change or reconnection. [Figure 20] 13 shows the operation of non-AP MLD to request information about other APs. [Figure 21] A specific example of STA ratio per Link is shown below. [Figure 22] 4 shows the operation of AP MLD and non-AP MLD for link change or reconnection. [Figure 23] 4 shows the operation of AP MLD and non-AP MLD for link change or reconnection. [Figure 24] 4 shows the operation of AP MLD and non-AP MLD for link change or reconnection. [Diagram 25] An example of a multi-link element added to a probe request is shown below. [Figure 26] An example of using the link range field in a multi-link element is shown below. [Figure 27] An example of the newly proposed field for indicating link changes and reconnections is shown below. [Figure 28] An example of the Request IE format is shown below. [Figure 29] An example of the Extended Request IE format is shown below. [Diagram 30] An example of the PV 1 Probe Response Option element format is shown below. [Diagram 31] An example of an MLD Request element is shown below. [Diagram 32] Another example of the MLD Request element is shown below. [Diagram 33] Here is an example of defining a new element based on the MLD Request element. [Diagram 34] Another example of the MLD Request element is shown below. [Diagram 35] Another example of the MLD Request element is shown below. [Diagram 36] Another example of the MLD Request element is shown below. [Figure 37] Another example of the MLD Request element is shown below. [Figure 38] An example of a field requesting common information is shown below. [Figure 39]An example of the ML IE format defined in 802.11be is shown below. [Diagram 40] An example of a multi-link element format and a multi-link control field format is shown below. [Diagram 41] An example of a Multi-link Control field format is shown below. [Diagram 42] An example of the ML IE format is shown below. [Diagram 43] Another example of the ML IE format is shown below. [Diagram 44] Another example of the ML IE format is shown below. [Diagram 45] Another example of the ML IE format is shown below. [Diagram 46] 13 shows an example of a Probe request frame including an ML IE format. [Figure 47] 13 shows another example of a Probe request frame including an ML IE format. [Figure 48] 13 shows another example of a Probe request frame including an ML IE format. [Figure 49] 13 shows another example of a Probe request frame including an ML IE format. [Figure 50] An example of a Multi-link Control field format is shown below. [Figure 51] An example of the ML IE format including the Critical update request field is shown below. [Figure 52] An example of an MLD Probe request that uses the Change sequence element when requesting critical update information is shown below. [Figure 53] Here is another example of an MLD Probe request that uses the Change sequence element when requesting critical update information: [Figure 54]An example of the ML IE format including the Critical update request field is shown below. [Figure 55] An example of the ML IE format including the Change sequence element is shown below. [Figure 56] An example of the MLD Change Sequence format is shown below. [Figure 57] Another example of the MLD Change Sequence format is shown below. [Figure 58] An example of an MLD Change sequence element is shown below. [Figure 59] An example of a change sequence element in an existing standard is shown below. [Figure 60] Another example in which the Change sequence element is included in the ML IE format is shown below. [Figure 61] 13 shows an example of a probe request frame for requesting critical update information. [Figure 62] 13 shows another example of a probe request frame for requesting critical update information. [Figure 63] 13 shows another example of a probe request frame for requesting critical update information. [Figure 64] 13 shows another example of a probe request frame for requesting critical update information. [Figure 65] 11 is a flow diagram showing a procedure in which a transmitting MLD according to the present embodiment provides partial information to a receiving MLD based on a probe response frame. FIG. [Figure 66] 11 is a flow diagram showing a procedure in which a receiving MLD according to the present embodiment requests partial information from a sending MLD based on a probe request frame. FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] As used herein, "A or B" can mean "only A," "only B," or "both A and B." Also, as used herein, "A or B" can be interpreted as "A and / or B." For example, as used herein, "A, B or C" can mean "only A," "only B," "only C," or "any combination of A, B and C."

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

[0018] In this specification, "at least one of A and B" can mean "only A," "only B," or "both A and B." In addition, in this specification, the expressions "at least one of A or B" and "at least one of A and / or B" can be interpreted similarly to "at least one of A and B."

[0019] In addition, in this specification, "at least one of A, B and C" can mean "only A," "only B," "only C," or "any combination of A, B and C." In addition, "at least one of A, B or C" or "at least one of A, B and / or C" can mean "at least one of A, B and C."

[0020] In addition, parentheses used in this specification may mean "for example." Specifically, when "control information (PDCCH)" is used, "PDCCH" is proposed as an example of "control information." In addition, "control information" in this specification is not limited to "PDCCH," and "PDDCH" is proposed as an example of "control information." In addition, when "control information (i.e., PDCCH)" is used, "PDCCH" is proposed as an example of "control information."

[0021] In this specification, technical features individually described in one drawing may be embodied individually or simultaneously.

[0022] The following example of the present specification applies to various wireless communication systems. For example, the following example of the present specification applies to a wireless local area network (WLAN) system. For example, the present specification applies to the IEEE 802.11a / g / n / ac standard and the IEEE 802.11ax standard. The present specification also applies to the newly proposed EHT standard or IEEE 802.11be standard. The present specification also applies to a new WLAN standard that is an enhancement of the EHT standard or IEEE 802.11be. The present specification also applies to a mobile communication system. For example, the present specification applies to a mobile communication system based on LTE (Long Term Evolution) based on the 3GPP (registered trademark) (3rd Generation Partnership Project) standard and its evolution. The present specification also applies to a 5GNR standard communication system based on the 3GPP standard.

[0023] In the following, technical features to which this specification is applied will be described in order to explain the technical features of this specification.

[0024] FIG. 1 shows an example of a transmitting device and / or a receiving device according to the present specification.

[0025] The example of FIG. 1 may implement various technical features described below. FIG. 1 relates to at least one STA (station). For example, the STA (110, 120) in this specification may be referred to by various names such as a mobile terminal, a wireless device, a wireless transmit / receive unit (WTRU), a user equipment (UE), a mobile station (MS), a mobile subscriber unit, or simply a user. The STA (110, 120) in this specification may be referred to by various names such as a network, a base station, a Node-B, an access point (AP), a repeater, a router, a relay, etc. The STA (110, 120) in this specification may be referred to by various names such as a receiving device, a transmitting device, a receiving STA, a transmitting STA, a receiving device, a transmitting device, etc.

[0026] For example, the STAs (110, 120) can perform an AP (Access Point) role or a non-AP role. That is, the STAs (110, 120) in this specification can perform the functions of an AP and / or a non-AP. In this specification, an AP can also be referred to as an AP STA.

[0027] The STAs (110, 120) of this specification can support various communication standards other than the IEEE 802.11 standard. For example, communication standards related to the 3GPP standard (e.g., LTE, LTE-A, 5GNR standard) can be supported. The STAs of this specification are implemented in various devices such as mobile phones, vehicles, and personal computers. The STAs of this specification can support communication for various communication services such as voice calls, video calls, data communications, self-driving, autonomous driving, etc.

[0028] As used herein, the STAs (110, 120) may include a medium access control (MAC) and physical layer interface to the wireless medium as defined by the IEEE 802.11 standard.

[0029] The STAs (110, 120) will be described below based on FIG. 1(a).

[0030] The first STA 110 includes a processor 111, a memory 112, and a transceiver 113. The depicted processor, memory, and transceiver may each be implemented as a separate chip, or at least two or more of the blocks / functions may be implemented via a single chip.

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

[0032] For example, the first STA (110) can perform the intended operations of the AP. For example, the processor (111) of the AP can receive signals via the transceiver (113), process the received signals, generate transmission signals, and perform control for signal transmission. The memory (112) of the AP can store signals received via the transceiver (113) (i.e., received signals) and can store signals transmitted via the transceiver (i.e., transmitted signals).

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

[0034] For example, the processor (121) of the Non-AP STA can receive signals via the transceiver (123), process the received signals, generate transmission signals, and execute control for signal transmission. The memory (122) of the Non-AP STA can store signals received via the transceiver (123) (i.e., received signals) and can store signals transmitted via the transceiver (i.e., transmitted signals).

[0035] For example, in the following specification, the operation of the device indicated as AP is executed in the first STA (110) or the second STA (120). For example, when the first STA (110) is an AP, the operation of the device indicated as AP is controlled by the processor (111) of the first STA (110), and related signals are transmitted or received via a transceiver (113) controlled by the processor (111) of the first STA (110). In addition, control information related to the operation of the AP and transmitted / received signals of the AP are stored in the memory (112) of the first STA (110). In addition, when the second STA (110) is an AP, the operation of the device indicated as AP is controlled by the processor (121) of the second STA (120), and related signals are transmitted or received via a transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the AP and transmitted / received signals of the AP are stored in the memory (122) of the second STA (110).

[0036] For example, in the following specification, the operation of the device indicated as non-AP (or User-STA) is executed in the first STA (110) or the second STA (120). For example, if the second STA (120) is a non-AP, the operation of the device indicated as non-AP is controlled by the processor (121) of the second STA (120), and related signals are transmitted or received via the transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the non-AP and the transmission / reception signals of the AP are 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 indicated as non-AP is controlled by the processor (111) of the first STA (110), and related signals are transmitted or received via the transceiver (113) controlled by the processor (111) of the first STA (120). In addition, control information related to the operation of the non-AP and transmission / reception signals of the AP are stored in the memory (112) of the first STA (110).

[0037] In the following specification, devices called (transmitting / receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting / receiving) Terminal, (transmitting / receiving) Device, (transmitting / receiving) apparatus, network, etc. refer to the STAs (110, 120) in Fig. 1. For example, devices indicated as (transmitting / receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting / receiving) Terminal, (transmitting / receiving) Device, (transmitting / receiving) apparatus, network, etc. without specific reference numerals also refer to the STAs (110, 120) in Fig. 1. For example, in the following example, the operations of various STAs transmitting and receiving signals (e.g., PPPDUs) may be performed in the transceivers (113, 123) in Fig. 1. In the following example, various STAs may generate transmission / reception signals or perform data processing or calculations in advance for transmission / reception signals in the processors (111, 121) of Fig. 1. For example, an example of an operation for generating transmission / reception signals or performing data processing or calculations in advance for transmission / reception signals may include: 1) an operation for determining / obtaining / configuring / calculating / decoding / encoding bit information of subfields (SIG, STF, LTF, Data) included in a PPDU; 2) an operation for determining / configuring / acquiring time resources and frequency resources (e.g., subcarrier resources) used for the subfields (SIG, STF, LTF, Data) included in a PPDU; 3) an operation for determining / configuring / acquiring specific sequences (e.g., pilot sequences, STF / LTF sequences, extra sequences applied to SIGs) used for the subfields (SIG, STF, LTF, Data) included in a PPDU; 4) an operation for power control and / or power saving applied to the STA; and 5) an operation related to determining / obtaining / configuring / calculating / decoding / encoding 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 to determine / acquire / configure / calculate / decode / encode transmitted / received signals is stored in memories (112, 122) of FIG. 1.

[0038] The above-mentioned device / STA in Fig. 1(a) is modified as shown in Fig. 1(b). The STA (110, 120) of this specification will be described based on Fig. 1(b) below.

[0039] For example, the transceivers (113, 123) shown in FIG. 1(b) may perform the same functions as the transceivers shown in FIG. 1(a) described above. For example, the processing chips (114, 124) shown in FIG. 1(b) may include processors (111, 121) and memories (112, 122). The processors (111, 121) and memories (112, 122) shown in FIG. 1(b) may perform the same functions as the processors (111, 121) and memories (112, 122) shown in FIG. 1(a) described above.

[0040] In the following description, a mobile terminal, a wireless device, a wireless transmit / receive unit (WTRU), a user equipment (UE), a mobile station (MS), a mobile subscriber unit, a user, a user STA, a network, a base station, a Node-B, an access point (AP), a repeater, a router, a relay, a receiving device, a transmitting device, a receiving STA, a transmitting STA, a receiving device, a transmitting device, a receiving apparatus, and / or a transmitting apparatus may refer to the STA (110, 120) shown in FIG. 1(a) / (b) or the processing chip (114, 124) shown in FIG. 1(b). That is, the technical features of this specification may be performed in the STA (110, 120) shown in FIG. 1(a) / (b) or may be performed only in the processing chip (114, 124) shown in FIG. 1(b). For example, the technical feature of the transmitting STA transmitting a control signal can be understood as the technical feature of the control signal generated in the processor (111, 121) shown in Fig. 1(a) / (b) being transmitted via the transceiver (113, 123) shown in Fig. 1(a) / (b). Alternatively, the technical feature of the transmitting STA transmitting a control signal can be understood as the technical feature of the control signal to be transmitted to the transceiver (113, 123) being generated in the processing chip (114, 124) shown in Fig. 1(b).

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

[0042] 1(b), software code (115, 125) is included within the memories (112, 122). The software code (115, 125) includes instructions that control the operation of the processors (111, 121). The software code (115, 125) may be included in a variety of programming languages.

[0043] The processors (111, 121) or processing chips (114, 124) shown in FIG. 1 may include an application-specific integrated circuit (ASIC), other chipsets, logic circuits, and / or data processing devices. The processors are application processors (APs). For example, the processors (111, 121) or processing chips (114, 124) shown 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 processors (111, 121) or processing chips (114, 124) shown in FIG. 1 may include a SNAPDRAGON 3.0 GHz processor manufactured by Qualcomm®. TMEXYNOS series processors, manufactured by Samsung TM Series processors, A-series processors manufactured by Apple®, HELIO manufactured by MediaTek® TM ATOM series processors, manufactured by INTEL® TM It is a series processor or an enhanced version of the series processor.

[0044] In this specification, an uplink refers to a link for communication from a non-AP STA to an AP STA, and an uplink PPDU / packet / signal, etc. are transmitted via the uplink. Also, in this specification, a downlink refers to a link for communication from an AP STA to a non-AP STA, and a downlink PPDU / packet / signal, etc. are transmitted via the downlink.

[0045] FIG. 2 is a conceptual diagram showing the structure of a wireless LAN (WLAN).

[0046] The top part of Figure 2 shows the structure of an IEEE (Institute of electrical and eletronic engineers) 802.11 infrastructure basic service set (BSS).

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

[0048] The BSS can include at least one STA, APs (225, 230) that provide a distribution service, and a distribution system (DS, 210) that connects multiple APs.

[0049] The distribution system (210) can implement an extended service set (ESS, 240) by connecting multiple BSSs (200, 205). The term ESS (240) is used to indicate a network formed by connecting one or multiple APs via the distribution system (210). APs included in one ESS (240) have the same service set identification (SSID).

[0050] The portal (220) can act as a bridge to connect a wireless LAN network (IEEE 802.11) to other networks (eg, 802.X).

[0051] In the BSS shown in the upper part of Figure 2, a network between APs (225, 230) and a network between APs (225, 230) and STAs (200-1, 205-1, 205-2) are implemented. However, it is also possible to set up a network between STAs without APs (225, 230) and communicate with each other. A network that sets up a network between STAs without APs (225, 230) and communicates with each other is defined as an Ad-Hoc network or an independent basic service set (IBSS).

[0052] The lower part of Figure 2 is a conceptual diagram showing the IBSS.

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

[0054] FIG. 3 is a diagram illustrating a typical link setup process.

[0055] In the illustrated step S310, the STA can perform a network discovery operation. The network discovery operation can include a scanning operation of the STA. That is, in order for the STA to access a network, it needs to find a joinable network. The STA needs to identify a compatible network before joining a wireless network, and the process of identifying networks that exist in a specific area is called scanning. There are two scanning methods: active scanning and passive scanning.

[0056] FIG. 3 shows an example of a network discovery operation including an active scan process. In active scan, a STA performing scanning moves channels and transmits a probe request frame to search for APs in the vicinity, and waits for a response to the probe request frame. A responder transmits a probe response frame to the STA that transmitted the probe request frame in response to the probe request frame. Here, the responder is the STA that transmitted a beacon frame last in the BSS of the channel being scanned. In the BSS, the AP transmits a beacon frame, so the AP becomes the responder, and in the IBSS, the STA in the IBSS returns and transmits a beacon frame, so the responder is not constant. For example, a 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, move to the next channel (e.g., channel 2), and perform scanning in the same manner (i.e., probe request / response transmission / reception on channel 2).

[0057] Although not shown as an example in FIG. 3, the scanning operation may be performed by a passport scan method. A STA performing scanning based on passport scan can wait for a beacon frame while moving between channels. A beacon frame is one of management frames in IEEE 802.11, and is periodically transmitted to inform a scanning STA of the presence of a wireless network and to allow the scanning STA to find and join the wireless network. In a BSS, an AP periodically transmits a beacon frame, and in an IBSS, a STA in the IBSS returns and transmits a beacon frame. When a scanning STA receives a beacon frame, it stores information about the BSS included in the beacon frame, and moves to another channel while recording beacon frame information in each channel. A STA receiving a beacon frame can store 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.

[0058] The STA that has discovered the network can perform an authentication process through step S320. This authentication process is called a first authentication process to clearly distinguish it from the security setting operation in step S340 described below. The authentication process in S320 may include a process in which the STA transmits an authentication request frame to the AP, and in response, the AP transmits an authentication response frame to the STA. The authentication frame used in the authentication request / response corresponds to a management frame.

[0059] The authentication frame can include information on the authentication algorithm number, authentication transaction sequence number, status code, challenge text, Robust Security Network (RSN), Finite Cyclic Group, etc.

[0060] The STA can send an authentication request frame to the AP. The AP can determine whether to allow authentication for the STA based on the information contained in the received authentication request frame. The AP can provide the STA with the result of the authentication process via an authentication response frame.

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

[0062] Thereafter, the STA may perform a security setup process in step S340. The security setup process in step S340 may include, for example, a private key setup process via a four-way handshake using an Extesible Authentication Protocol over LAN (EAPOL) frame.

[0063] FIG. 4 is a diagram showing an example of a PPDU used in the IEEE standard.

[0064] As shown, various types of PPDUs (PHY protocol data units) are used in standards such as IEEEa / g / n / ac. Specifically, the LTF and STF fields contain training signals, SIG-A and SIG-B contain control information for the receiving station, and the data field contains user data corresponding to the PSDU (MAC PDU / Aggregated MAC PDU).

[0065] Also, Figure 4 includes an example of an HE PPDU of the IEEE 802.11ax standard. The HE PPDU in Figure 4 is an example of a PPDU for multiple users, and HE-SIG-B is included only for multiple users, and the corresponding HE-SIG-B is omitted in a PPDU for a single user.

[0066] As shown, an HE-PPDU for a Multiple User (MU) may include a legacy-short training field (L-STF), a legacy-long training field (L-LTF), a legacy-signal (L-SIG), a high efficiency-signal A (HE-SIG-A), a high efficiency-signal-B (HE-SIG-B), a high efficiency-short training field (HE-STF), a high efficiency-long training field (HE-LTF), a data field (or MAC payload), and a Packet Extension (PE) field. Each field is transmitted during the indicated time interval (i.e., 4 or 8 μs, etc.).

[0067] The resource unit (RU) used in the PPDU is described as follows. The resource unit can include multiple subcarriers (or tones). The resource unit is used when transmitting signals to multiple STAs based on OFDMA technology. The resource unit is also defined when transmitting a signal to one STA. The resource unit is used for STF, LTF, data field, etc.

[0068] The RU described in this specification is used for UL (Uplink) communication and DL (Downlink) communication. For example, when UL-MU communication solicited by a Trigger frame is performed, a transmitting STA (e.g., AP) can assign a first RU (e.g., 26 / 52 / 106 / 242-RU, etc.) to a first STA and a second RU (e.g., 26 / 52 / 106 / 242-RU, etc.) to a second STA through the Trigger frame. Thereafter, the first STA can transmit a first Trigger-based PPDU based on the first RU, and the second STA can transmit a second Trigger-based PPDU based on the second RU. The first and second Trigger-based PPDUs are transmitted to the AP in the same time period.

[0069] For example, when a DL MU PPDU is configured, the transmitting STA (e.g., AP) can assign a first RU (e.g., 26 / 52 / 106 / 242-RU, etc.) to the first STA and a second RU (e.g., 26 / 52 / 106 / 242-RU, etc.) to the second STA. That is, the transmitting STA (e.g., AP) can transmit the HE-STF, HE-LTF, and Data fields for the first STA via the first RU and the HE-STF, HE-LTF, and Data fields for the second STA via the second RU in one MU PPDU.

[0070] 5 shows the operation related to the UL-MU. As shown, a transmitting STA (e.g., AP) can perform channel connection through contending (i.e., Backoff operation) and transmit a Trigger frame 1030. That is, the transmitting STA (e.g., AP) can transmit a PPDU including a Trigger frame 1330. If a PPDU including a Trigger frame is received, a TB (trigger-based) PPDU is transmitted after a delay of SIFS.

[0071] The TB PPDUs 1041 and 1042 are transmitted during the same time period, and are transmitted from multiple STAs (eg, User STAs) whose AIDs are indicated in the Trigger frame 1030. The ACK frame 1050 for the TB PPDU is implemented in various ways.

[0072] Specific features of the trigger frame are described with reference to Figures 6 to 8. When UL-MU communication is used, Orthogonal Frequency Division Multiple Access (OFDMA) technology or MU MIMO technology is used, or OFDMA and MU MIMO technology are used simultaneously.

[0073] An example of a trigger frame is shown in Fig. 6. The trigger frame in Fig. 6 allocates resources for uplink MU transmission (Uplink Multiple-User transmission) and is transmitted, for example, from an AP. The trigger frame is composed of a MAC frame and is included in a PPDU.

[0074] Each of the fields shown in Figure 6 may be omitted, other fields may be added, and the length of each of the fields may vary differently than shown.

[0075] The frame control field 1110 in FIG. 6 includes information regarding the version of the MAC protocol and other additional control information, and the duration field 1120 includes information regarding time information for NAV setting and an STA identifier (e.g., AID).

[0076] Also, the RA field 1130 includes address information of the STA receiving the trigger frame, and can be omitted if necessary. The TA field 1140 includes address information of the STA (e.g., AP) transmitting the trigger frame, and the common information field 1150 includes common control information applied to the receiving STA receiving the trigger frame. For example, a field indicating the length of the L-SIG field of the up PPDU transmitted corresponding to the trigger frame and information controlling the contents of the SIG-A field (i.e., the HE-SIG-A field) of the up PPDU transmitted corresponding to the trigger frame are included. Also, the common control information includes information regarding the length of the CP of the up PPDU transmitted corresponding to the trigger frame and information regarding the length of the LTF field.

[0077] In addition, it is preferable to include per user information fields (1160#1 to 1160#N) corresponding to the number of receiving STAs that receive the trigger frame in Fig. 6. The per user information fields may also be called "assignment fields."

[0078] The trigger frame of FIG. 6 may also include a padding field 1170 and a frame check sequence field 1180.

[0079] As shown in FIG. 6, each of the per user information fields (1160#1 through 1160#N) may again include multiple subfields.

[0080] Figure 7 shows an example of a common information field of a trigger frame. Some of the subfields in Figure 7 can be omitted and others can be added. Also, the length of each of the subfields shown can vary.

[0081] The indicated length field 1210 has the same value as the length field of the L-SIG field of the up PPDU transmitted corresponding to the trigger frame, and the length field of the L-SIG field of the up PPDU indicates the length of the up PPDU. As a result, the length field 1210 of the trigger frame is used to indicate the length of the corresponding uplink PPDU.

[0082] In addition, the cascade indicator field 1220 indicates whether or not cascade operation is performed. Cascade operation means that both downlink MU transmission and uplink MU transmission are performed within the same TXOP. In other words, it means that after downlink MU transmission is performed, uplink MU transmission is performed after a previously set time (e.g., SIFS). In cascade operation, there can be only one transmitter (e.g., AP) performing downlink communication, and multiple transmitters (e.g., non-AP) performing uplink communication.

[0083] The CS request field 1230 indicates whether the receiving device that received the trigger frame needs to take into account the state of the wireless medium, NAV, etc., when transmitting the corresponding uplink PPDU.

[0084] The HE-SIG-A information field 1240 includes information that controls the content of the SIG-A field (ie, the HE-SIG-A field) of the up PPDU transmitted in response to the trigger frame.

[0085] The CP and LTF type field 1250 may include information about the LTF length and CP length of the up PPDU transmitted corresponding to the trigger frame. The trigger type field 1060 may indicate the purpose for which the trigger frame is used, such as a normal trigger, a trigger for beamforming, a request for Block Ack / NACK, etc.

[0086] In this specification, the trigger type field 1260 of the trigger frame may be assumed to indicate a Basic type trigger frame for normal triggering, for example, a Basic type trigger frame may be referred to as a Basic trigger frame.

[0087] Figure 8 shows an example of subfields included in a per user information field. The user information field 1300 in Figure 8 can be understood as any one of the individual user information fields (1160#1 to 1160#N) mentioned in Figure 6. Some of the subfields included in the user information field 1300 in Figure 8 can be omitted and other subfields can be added. Also, the length of each of the subfields shown can be modified.

[0088] The User Identifier field 1310 in FIG. 8 indicates an identifier of the STA (i.e., the receiving STA) corresponding to the per user information, and an example of the identifier is all or part of the AID (association identifier) ​​value of the receiving STA.

[0089] Also included is an RU Allocation field 1320. That is, when a receiving STA identified by the user identifier field 1310 transmits a TB PPDU in response to the trigger frame, the TB PPDU is transmitted via an RU indicated by the RU allocation field 1320.

[0090] 8 may include a coding type field 1330. The coding type field 1330 may indicate a coding type of the TB PPDU. For example, if BCC coding is applied to the TB PPDU, the coding type field 1330 is set to '1', and if LDPC coding is applied, the coding type field 1330 is set to '0'.

[0091] 8 may include an MCS field 1340. The MCS field 1340 may indicate an MCS technique applied to the TB PPDU. For example, if BCC coding is applied to the TB PPDU, the coding type field 1330 is set to '1', and if LDPC coding is applied, the coding type field 1330 is set to '0'.

[0092] The following describes UORA (UL OFDMA-based Random Access) technology.

[0093] Figure 9 illustrates the technical features of the UORA technology.

[0094] A transmitting STA (e.g., AP) can allocate 6 RU resources through a trigger frame as shown in Fig. 9. Specifically, the AP can allocate 1 RU resource (AID 0, RU 1), 2 RU resource (AID 0, RU 2), 3 RU resource (AID 0, RU 3), 4 RU resource (AID 2045, RU 4), ​​5 RU resource (AID 2045, RU 5), and 6 RU resource (AID 3, RU 6). Information on AID 0, AID 3, or AID 2045 is included, for example, in the user identification field 1310 in Fig. 8. Information on RU 1 to RU 6 is included, for example, in the RU allocation field 1320 in Fig. 8. AID=0 means UORA resource for associated STAs, and AID=2045 means UORA resource for un-associated STAs. Accordingly, the first to third RU resources in FIG. 9 are used as UORA resources for associated STAs, the fourth to fifth RU resources in FIG. 9 are used as UORA resources for un-associated STAs, and the sixth RU resource in FIG. 9 is used as a resource for a normal UL MU.

[0095] In the example of Fig. 9, the OBO (OFDMA random access Back Off) counter of STA1 is decremented to 0, and STA1 randomly selects the second RU resource (AID 0, RU 2). Also, since the OBO counter of STA2 / 3 is greater than 0, no uplink resource is assigned to STA2 / 3. Also, in Fig. 9, STA4 includes its own AID (i.e., AID=3) in the trigger frame, so it is assigned the resource of RU 6 without backoff.

[0096] Specifically, since STA1 in Fig. 9 is an associated STA, there are a total of three eligible RA RUs for STA1 (RU 1, RU 2, RU 3), and accordingly STA1 decrements its OBO counter by 3, so that the OBO counter is now 0. Also, since STA2 in Fig. 9 is an associated STA, there are a total of three eligible RA RUs for STA2 (RU 1, RU 2, RU 3), and accordingly STA2 decrements its OBO counter by 3, but the OBO counter is now greater than 0. Also, since STA3 in Fig. 9 is an un-associated STA, there are a total of two eligible RA RUs for STA3 (RU 4, RU 5), and accordingly STA3 decrements its OBO counter by 2, but the OBO counter is now greater than 0.

[0097] The PPDU transmitted / received in the STA in this specification is described as follows.

[0098] FIG. 10 shows an example of a PPDU used in this specification.

[0099] 10 may be referred to by various names such as EHT PPDU, transmit PPDU, receive PPDU, first type or Nth type PPDU, etc. For example, in this specification, PPDU or EHT PPDU may be referred to by various names such as transmit PPDU, receive PPDU, first type or Nth type PPDU, etc. Also, EHT PPU is used in EHT systems and / or new wireless LAN systems that improve on EHT systems.

[0100] The PPDU in FIG. 10 may indicate some or all of the PPDU types used in the EHT system. For example, the example in FIG. 10 is used for both the single-user (SU) mode and the multi-user (MU) mode. In other words, the PPDU in FIG. 10 may be a PPDU for one receiving STA or multiple receiving STAs. When the PPDU in FIG. 10 is used for the Trigger-based (TB) mode, the EHT-SIG in FIG. 10 may be omitted. In other words, a STA that receives a Trigger frame for Uplink-MU (UL-MU) communication may transmit a PPDU in the example in FIG. 10 with the EHT-SIG omitted.

[0101] In FIG. 10, the L-STF to the EHT-LTF can be called a preamble or a physical preamble, and are generated / transmitted / received / acquired / decoded in the physical layer.

[0102] The subcarrier spacing of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and EHT-SIG fields in Fig. 10 is set to 312.5 kHz, and the subcarrier spacing of the EHT-STF, EHT-LTF, and Data fields is 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 EHT-SIG fields can be expressed in units of 312.5 kHz, and the tone index (or subcarrier index) of the EHT-STF, EHT-LTF, and Data fields can be expressed in units of 78.125 kHz.

[0103] In the PPDU of FIG. 10, the L-LTF and L-STF may be the same as conventional fields.

[0104] The L-SIG field in FIG. 10 may include, for example, 24-bit bit information. For example, the 24-bit information may include a 4-bit Rate field, a 1-bit Reserved bit, a 12-bit Length field, a 1-bit Parity bit, and a 6-bit Tail bit. For example, the 12-bit Length field may include information regarding the length or time duration of the PPDU. For example, the value of the 12-bit Length field is determined based on the type of PPDU. For example, if the PPDU is a non-HT, HT, VHT PPDU, or an EHT PPDU, the value of the Length field is determined as a multiple of 3. For example, if the PPDU is an HE PPDU, the value of the Length field is determined as a "multiple of 3+1" or a "multiple of 3+2". In other words, for a non-HT, HT, VHT PPDU, or an EHT PPDU, the value of the Length field may be determined as a multiple of 3, and for a HE PPDU, the value of the Length field is determined as a "multiple of 3+1" or a "multiple of 3+2".

[0105] For example, the transmitting STA may apply coding that is BCC based on a code rate of 1 / 2 to the 24-bit information of the L-SIG field. Then, the transmitting STA may obtain 48 BCC coded bits. BPSK modulation is applied to the 48 coded bits to generate 48 BPSK symbols. The transmitting STA may map the 48 BPSK symbols to positions other than the pilot subcarrier {subcarrier index -21, -7, +7, +21} and the DC subcarrier {subcarrier index 0}. As a result, the 48 BPSK symbols are mapped to subcarrier indexes -26 to -22, -20 to -8, -6 to -1, +1 to +6, +8 to +20, and +22 to +26. The transmitting STA may further map signals of {-1, -1, -1, 1} to subcarrier indexes {-28, -27, +27, 28}. The above signal is used for channel estimation for the frequency domain corresponding to {-28, -27, +27, 28}.

[0106] The transmitting STA can generate a RL-SIG, which is generated the same as the L-SIG. BPSK modulation is applied to the RL-SIG. The receiving STA can determine that the received PPDU is an HE PPDU or an EHT PPDU based on the presence of the RL-SIG.

[0107] A Universal SIG (U-SIG) is inserted after the RL-SIG in Figure 10. The U-SIG can be called by various names such as the first SIG field, first SIG, first type SIG, control signal, control signal field, and first (type) control signal.

[0108] The U-SIG can include N-bit information and can include information for identifying the type of EHT PPDU. For example, the U-SIG is configured based on two symbols (e.g., two consecutive OFDM symbols). Each symbol (e.g., OFDM symbol) for the U-SIG can have a duration of 4 us. Each symbol of the U-SIG is used to transmit 26-bit information. For example, each symbol of the U-SIG is transmitted and received based on 52 data tones and 4 pilot tones.

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

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

[0111] The A-bit information (e.g., 52 uncoded bits) transmitted by a 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 are assigned only to the first symbol of the U-SIG, or the version-independent bits are assigned to both the first and second symbols of the U-SIG. For example, the version-independent bits and version-dependent bits can be referred to by various names, such as the first control bits and the second control bits.

[0112] For example, the version-independent bits of the U-SIG may include a 3-bit PHY version identifier. For example, the 3-bit PHY version identifier may include information related to the PHY version of the transmitted / received PPDU. For example, a first value of the 3-bit PHY version identifier may indicate that the transmitted / received PPDU is an EHT PPDU. In other words, when a transmitting STA transmits an EHT PPDU, the transmitting STA may set the 3-bit PHY version identifier as a first value. In other words, a receiving STA may determine that the received PPDU is an EHT PPDU based on the PHY version identifier having the first value.

[0113] For example, the version-independent bits of the U-SIG may include a one-bit UL / DL flag field, where a first value of the one-bit UL / DL flag field is associated with UL communication and a second value of the UL / DL flag field is associated with DL communication.

[0114] For example, the version-independent bits of the U-SIG can include information about the length of the TXOP and information about the BSS color ID.

[0115] For example, if the EHT PPDU is divided into different types (e.g., EHT PPDUs associated with SU mode, EHT PPDUs associated with MU mode, EHT PPDUs associated with TB mode, EHT PPDUs associated with Extended Range transmission, etc.), the information about the type of EHT PPDU is included in the version-dependent bits of the U-SIG.

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

[0117] In the following example, signals indicated as (transmit / receive / up / down) signals, (transmit / receive / up / down) frames, (transmit / receive / up / down) packets, (transmit / receive / up / down) data units, (transmit / receive / up / down) data, etc. may be signals transmitted and received based on the PPDU of FIG. 10. The PPDU of FIG. 10 is used to transmit and receive various types of frames. For example, the PPDU of FIG. 10 is used for a control frame. Examples of the control frame may include RTS (request to send), CTS (clear to send), PS-Poll (Power Save-Poll), Block ACK Req, Block Ack, NDP (Null Data Packet) announcement, and Trigger frame. For example, the PPDU of FIG. 18 is used for a management frame. Examples of the management frame may include a Beacon frame, a (Re-)Association Request frame, a (Re-)Association Response frame, a Probe Request frame, and a Probe Response frame. For example, the PPDU in Fig. 10 is used for a data frame, and for example, the PPDU in Fig. 10 is also used for simultaneously transmitting at least two or more of a control frame, a management frame, and a data frame.

[0118] FIG. 11 shows a variation of the transmitting device and / or the receiving device of this specification.

[0119] Each device / STA in (a) / (b) of Figure 1 can be modified as shown in Figure 11. The transceiver 630 in Figure 11 can be the same as the transceivers 113 and 123 in Figure 1. The transceiver 630 in Figure 11 can include a receiver and a transmitter.

[0120] The processor 610 in Figure 11 may be the same as the processors 111, 121 in Figure 1. Or, the processor 610 in Figure 11 may be the same as the processing chips 114, 124 in Figure 1.

[0121] The memory 150 in Figure 11 may be the same as the memories 112, 122 in Figure 1. Alternatively, the memory 150 in Figure 11 may be a separate external memory that is different from the memories 112, 122 in Figure 1.

[0122] 11, a power management module 611 manages power to the processor 610 and / or transceiver 630. A battery 612 provides power to the power management module 611. A display 613 outputs results processed by the processor 610. A keypad 614 receives inputs used by the processor 610. The keypad 614 may be represented on the display 613. A SIM card 615 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 mobile phone devices such as mobile phones and computers.

[0123] 11, the speaker 640 can output sound-related results processed by the processor 610. The microphone 641 can receive sound-related inputs used by the processor 610.

[0124] The technical features of the Multi-link (ML) supported by the STA in this specification are described below.

[0125] The STA (AP and / or non-AP STA) in this specification can support MultiLink (ML) communication. ML communication means communication that supports multiple links. Links related to ML communication can include channels in the 2.4 GHz band, 5 GHz band, and 6 GHz band (e.g., 20 / 40 / 80 / 160 / 240 / 320 MHz channels).

[0126] The multiple links used for ML communication are set in various ways. For example, the multiple links supported by one STA for ML communication may be multiple channels in the 2.4 GHz band, multiple channels in the 5 GHz band, or multiple channels in the 6 GHz band. Or, the multiple links supported by one STA for ML communication may be a combination of at least one channel in the 2.4 GHz band (or the 5 GHz / 6 GHz band) and at least one channel in the 5 GHz band (or the 2.4 GHz / 6 GHz band). On the other hand, at least one of the multiple links supported by one STA for ML communication may be a channel to which preamble puncturing is applied.

[0127] STA can perform ML setup to perform ML communication. ML setup can be performed based on management frames and control frames such as Beacon, Probe Request / Response, and Association Request / Response. For example, information about ML setup is included in element fields included in Beacon, Probe Request / Response, and Association Request / Response.

[0128] When the ML setup is completed, an enabled link for ML communication is determined. The STA can perform frame exchange through at least one of the multiple links determined as the enabled link. For example, the enabled link is used for at least one of the management frame, control frame, and data frame.

[0129] When one STA supports multiple links, the transceiver supporting each link can operate as one logical STA. For example, one STA supporting two links can be represented as one ML device (Multi Link Device; MLD) including a first STA for the first link and a second STA for the second link. For example, one AP supporting two links can be represented as one AP MLD including a first AP for the first link and a second AP for the second link. Also, one non-AP supporting two links can be represented as one non-AP MLD including a first STA for the first link and a second STA for the second link.

[0130] As follows, more specific aspects regarding the ML setup are described.

[0131] MLD (AP MLD and / or non-AP MLD) can transmit information about links that the MLD can support through ML setup. The information about the links can be configured in various ways. For example, the information about the links can include at least one of the following: 1) information about whether the MLD (or STA) supports simultaneous RX / TX operation, 2) information about the number / upper limit of uplink / downlink links supported by the MLD (or STA), 3) information about the location / band / resource of uplink / downlink links supported by the MLD (or STA), 4) information about frame types (management, control, data, etc.) available or preferred in at least one uplink / downlink link, 5) ACK policy information available or preferred in at least one uplink / downlink link, and 6) information about traffic identifiers (TIDs) available or preferred in at least one uplink / downlink link. TIDs are related to the priority of traffic data and are expressed by eight types of values ​​according to conventional WLAN standards. That is, eight TID values ​​are defined corresponding to four access categories (AC) (AC_BK (background), AC_BE (best effort), AC_VI (video), and AC_VO (voice)) according to the conventional wireless LAN standard.

[0132] For example, all TIDs are pre-configured by mapping to uplink / downlink links. Specifically, if no negotiation is performed through ML setup, all TIDs are used for ML communication, and if mapping between uplink / downlink links and TIDs is negotiated through additional ML setup, the negotiated TID is used for ML communication.

[0133] Through ML setup, multiple links that can be used by the sending MLD and receiving MLD related to ML communication are set, which can be called "enabled links." An "enabled link" can be called by various expressions, such as the first link, the second link, the sending link, and the receiving link.

[0134] After the ML setup is completed, the MLD can update the ML setup. For example, if an update is required for the link information, the MLD can send information about a new link. The information about the new link is sent based on at least one of a management frame, a control frame, and a data frame.

[0135] The device described below may be the device in Fig. 1 and / or Fig. 11, and the PPDU may be the PPDU in Fig. 10. The device may be an AP or a non-AP STA. The device described below may be an AP MLD (multi-link device) that supports multi-link or a non-AP STA MLD.

[0136] Since 802.11ax, the standard EHT (Extremely High Throughput) under discussion takes into account a multi-link environment that uses one or more bands simultaneously. If a device supports multi-link, it can use one or more bands (e.g., 2.4 GHz, 5 GHz, 6 GHz, 60 GHz, etc.) simultaneously or alternately.

[0137] In the following specification, MLD means multi-link device. MLD has one or more connected STAs and one MAC SAP (service access point) that leads to the upper link layer (Logical Link Control, LLC). MLD means physical device or logical device. In the following, device means MLD.

[0138] In the following specification, the transmitting device and the receiving device refer to MLD. The first link of the receiving / transmitting device may be a terminal (e.g., STA or AP) included in the receiving / transmitting device that performs signal transmission / reception through the first link. The second link of the receiving / transmitting device may be a terminal (e.g., STA or AP) included in the receiving / transmitting device that performs signal transmission / reception through the second link.

[0139] In IEEE 802.11be, two types of multi-link operation can be supported. For example, STR (simultaneous transmit and receive) and non-STR operation are considered. For example, STR can be called asynchronous multi-link operation, and non-STR can be called synchronous multi-link operation. Multi-link can include multiple bands. That is, multi-link can mean links included in multiple frequency bands, and can also mean multiple links included in one frequency band.

[0140] EHT (11be) takes into account multi-link technology, where multi-link can include multi-band. In other words, multi-link can refer to links of multiple bands, and can simultaneously refer to multiple multi-links within one band. Broadly speaking, two types of multi-link operation are considered: Asynchronous operation, which allows simultaneous TX / RX on multiple links, and Synchronous operation, which does not. In the following, the capability to simultaneously receive and transmit on multiple links is called STR (simultaneous transmit and receive), and STAs with STR capability are called STR MLD (multi-link Device), and STAs without STR capability are called non-STR MLD.

[0141] In the following description, for convenience of explanation, the MLD (or a processor of the MLD) is described as controlling at least one STA, but this is not limited thereto. As described above, the at least one STA can also transmit and receive signals independently of the MLD.

[0142] According to one embodiment, the AP MLD or non-AP MLD is configured with a structure having multiple links. In other words, the non-AP MLD can support multiple links. The non-AP MLD can include multiple STAs. Each of the multiple STAs can have its own link.

[0143] The EHT standard (802.11be standard) considers the MLD (Multi-Link Device) structure, in which one AP / non-AP MLD supports multiple links, as its main technology. STAs included in a non-AP MLD can transmit information to other STAs in the non-AP MLD via one link. This reduces the overhead of frame exchange. It also increases the link usage efficiency of STAs and reduces power consumption.

[0144] FIG. 12 shows an example of the structure of a non-AP MLD.

[0145] Referring to FIG. 12, the non-AP MLD is configured with a structure having multiple links. In other words, the non-AP MLD can support multiple links. The non-AP MLD can include multiple STAs. Each of the multiple STAs can have its own link. Although FIG. 12 shows an example of the non-AP MLD structure, the AP MLD structure is also configured in the same manner as the example of the non-AP MLD structure shown in FIG. 12.

[0146] For example, a non-AP MLD may include STA1, STA2, and STA3. STA1 may operate on Link 1, which is included in the 5 GHz band. STA2 may operate on Link 2, which is included in the 6 GHz band. STA3 may operate on Link 3, which is included in the 6 GHz band. The bands that Link 1 / 2 / 3 are included in are exemplary and are included in 2.4, 5, and 6 GHz.

[0147] In this way, in the case of AP / non-AP MLD supporting multi-link, each AP of AP MLD and each STA of non-AP MLD are connected to each link through the link setup process. Then, the connected link is changed or reconnected to another link by AP MLD or non-AP MLD depending on the situation.

[0148] In addition, in the EHT standard, a link can be divided into an anchored link and a non-anchored link to reduce power consumption. Anchored links and non-anchored links can be called variously. For example, an anchored link can be called a primary link, and a non-anchored link can be called a secondary link.

[0149] According to one embodiment, an AP MLD that supports multi-link can be managed by designating each link as an anchored link or a non-anchored link. An AP MLD can support one or more of multiple links as an anchored link. A non-AP MLD can be used by selecting one or more of its own anchored links from the anchored link list (a list of anchored links supported by the AP MLD).

[0150] For example, the anchored link is used not only for frame exchange for synchronization but also for non-data frame exchange (i.e., Beacon and Management frames), and the non-anchored link is used only for data frame exchange.

[0151] Non-AP MLD can only monitor the anchored link to receive beacons and management frames during the idle period. Therefore, in the case of non-AP MLD, it is necessary to connect to at least one anchored link to receive beacons and management frames. The one or more anchored links must always be kept in an enabled state. In contrast, non-anchored links are used only for data frame exchange. Therefore, STAs corresponding to non-anchored links (or STAs connected to non-anchored links) can enter doze during the idle period when the channel / link is not being used. This has the effect of reducing power consumption.

[0152] Therefore, in the following specification, a protocol is proposed in which AP MLD or non-AP MLD dynamically recommends or requests link reconnection depending on the situation for efficient link connection. In addition, in the following specification, an anchored link reconnection protocol is further proposed that takes into account the characteristics of not only normal links but also anchored links used for the purpose of power reduction.

[0153] Example of Link Change and Reconnection

[0154] According to one embodiment, each link between the AP MLD and the non-AP MLD is determined in an association or (re)association process. At this time, the AP MLD and the non-AP MLD can perform frame exchange via the connected link. A specific embodiment in which the AP MLD and the non-AP MLD are connected via the link setup process will be described with reference to FIG. 13.

[0155] FIG. 13 shows an example in which an AP MLD and a non-AP MLD are connected via a Link setup process.

[0156] 13, the AP MLD can include AP1, AP2, and AP3. The non-AP MLD can include STA1 and STA2. AP1 and STA1 are connected via Link 1. AP2 and STA2 are connected via Link 2.

[0157] For example, AP1 and STA1 are connected via Link 1 through a first link setup process. AP2 and STA2 are connected via Link 2 through a second link setup process. In another example, AP MLD and non-AP MLD are connected via one link setup process. In other words, AP MLD and non-AP MLD are connected via Link 1 and Link 2 based on one link setup process.

[0158] As described above, each AP and STA can exchange frames through the connected links, and information of other APs or other STAs on other links is transmitted and received through one link.

[0159] However, after this link setup process, the AP MLD or non-AP MLD may request a link change or reconnection for more efficient frame exchange (eg, load balancing or interference avoidance) depending on the situation / environment.

[0160] An embodiment relating to link change or reconnection will be described with reference to FIG.

[0161] FIG. 14 shows an example where a Link is changed or reconnected.

[0162] Referring to FIG. 14, STA2 is conventionally connected to AP2. Then, the data load of AP2 may be excessive. STA2 is reconnected to AP3, which has a relatively small data load. In this case, AP MLD and non-AP MLD can perform efficient data exchange.

[0163] FIG. 15 shows a specific example in which a link is changed or reconnected.

[0164] 15, AP1 of AP MLD is connected to STA1 of non-AP MLD via link 1. AP2 of AP MLD is connected to STA2 of non-AP MLD via link 2. Thereafter, STA2 can attempt / request connection to AP3 via link change or reconnection, and STA2 is connected to AP3 via link 2 based on the link change or reconnection.

[0165] According to an embodiment, the non-AP MLD and the AP MLD can request a link transition to improve performance. The AP MLD and the non-AP MLD can transmit / receive / exchange various information per current link and information on the link state. Therefore, the AP MLD and the non-AP MLD can select a more suitable link for transmitting / receiving a signal based on the various information per current link and the link state, and can transmit the above information to support the selection. For example, the various information per current link can include information on the data traffic load per link and the channel access capability between links. For example, the link state is set as disable or enable.

[0166] In the following specification, the process in which the AP MLD / non-AP MLD negotiates with the non-AP MLD / AP MLD to request a change or reconnection to another link other than the connected link in order to improve performance is called "Link switching negotiation." The name "Link switching negotiation" may be called in various ways and may be subject to change.

[0167] In the link switching negotiation process, the non-AP MLD (or AP MLD) requests that the link connected to a specific STA be changed to another link, and the AP MLD (or non-AP MLD) can respond to this request via a request acknowledge or reject message.

[0168] As an example, as shown in FIG. 15, if a link change is agreed upon through link switching negotiation, the STA can perform a link re-setup process in which the existing link is changed from AP2 to AP3 and reconnected.

[0169] In the following, the link change or reconnection process will be described separately for the case where AP MLD is requested and the case where non-AP MLD is requested.

[0170] An embodiment in which AP MLD requests a link change or reconnection

[0171] According to one embodiment, the AP MLD can request a non-AP MLD to change or reconnect a link for efficient data transmission. For example, for load balancing, the AP MLD can request a STA to change or reconnect to a more efficient link based on the data traffic of each AP.

[0172] For example, the AP MLD can calculate / check / determine a link suitable for a non-AP MLD STA based on data traffic load information for each AP and / or channel access capability information between each link (e.g., information on STR (Simultaneous TX / RX) capability, etc.) Thereafter, the AP MLD can request a link change or reconnection to the STA (or non-AP MLD) based on data traffic load information for each AP and / or channel access capability information between each link, etc.

[0173] As described above, when a link change request is made, the AP MLD can transmit the link information that it considers to be the most suitable to the non-AP MLD via a request message. For example, the request message can include a beacon or a management frame.

[0174] In relation to the above-described embodiment, an element or field including the most suitable link information is newly proposed. The newly proposed element or field is defined as a "recommended link." The "recommended link" is merely an example, and the name of the specific element or field may be changed.

[0175] recommend link(element / field) : An element or field for the AP MLD to recommend the most suitable link to a non-AP MLD STA based on various information for each link (e.g., data load for each link, etc.). For example, the recommend link (element / field) is indicated by AP MLD Link ID information or AP BSS information, etc. In other words, the recommend link (element / field) can include AP MLD Link ID information or AP BSS information, etc.

[0176] According to one embodiment, the recommend link (element / field) is optionally included in the Link switching Response and transmitted. For example, the STA can establish a connection to the link recommended by the AP based on the element / field (i.e., the recommend link). In another example, the STA can execute a connection request to a link other than the indicated link based on the element / field (i.e., the recommend link) and additional information that the STA has.

[0177] A specific signal exchange process of AP MLD and non-AP MLD according to the above embodiment is described via FIG.

[0178] FIG. 16 shows the operation of AP MLD and non-AP MLD for link change or reconnection.

[0179] 16, when STA2 is connected to AP2 via link2, a lot of data traffic may be concentrated on AP2. In other words, when STA2 is connected to AP2 via link2, a lot of data traffic occurs on AP2.

[0180] The AP MLD (or AP2) can request the non-AP MLD (or STA2) to reconnect to AP3, which has relatively few STA connections. Normally, a message to request reconnection is sent to the STA that desires to reconnect (i.e., STA2), but depending on the situation (e.g., channel situation or link state), it may be sent to any STA (i.e., other STA). In other words, the STA to which a request message (e.g., Link switching request frame) to request reconnection is sent can be changed based on the channel situation or link state.

[0181] For example, if the STA (i.e., STA2) that has received the request message for requesting reconnection approves the request, it can transmit a response message (e.g., a Link switching Response frame) of "Accept." In another example, if the STA (i.e., STA2) rejects the request, it can transmit a response message of "Decline."

[0182] Normally, the STA that approves the reconnection (i.e., STA2) sends a response message to the existing link (the link connected before the reconnection), but the response message can be sent via any link (i.e., another STA) using the multi-link characteristic.

[0183] If STA2 accepts the link reconnection request, after sending a response message, STA2 can disconnect from the existing AP2 and request a link reconnection to AP3. At this time, the reconnection request process can be performed in the same way as the existing link setup process between MLDs. After the link setup process between AP3 and STA2 is completed, STA2 can perform frame exchange with AP3 through Link2.

[0184] Conversely, if STA2 rejects the link reconnection request, STA2 and AP2 can continue to use the existing connected link (i.e., link2).

[0185] According to one embodiment, when an AP requests a STA to change a link, if the AP recommends a suitable link, the STA may or may not change the link to the recommended link. For example, the above-mentioned recommend link is used for the AP to recommend a suitable link to the STA.

[0186] For example, the STA may approve a link change in a response message to a request message for requesting reconnection to the AP. The STA may approve / confirm a link change to a recommended link, and may also request another link change from the AP based on information other than the information included in the request message.

[0187] Therefore, the AP needs to inform the STA of the approval or disapproval of the response message. To this end, the AP can transmit to the STA a Confirmation message (e.g., a link switching confirmation frame) in response to the response message (e.g., a Link Switching Response frame) of the STA.

[0188] The specific operations of AP MLD and non-AP MLD in the above-mentioned embodiment will be described with reference to FIG.

[0189] FIG. 17 shows the operation of AP MLD and non-AP MLD for link change or reconnection.

[0190] 17, the AP2 can include the recommended link information to request a link change to the STA2. In other words, the AP2 can send a link switching request frame including the recommended link information to the STA2.

[0191] STA2 can transmit whether or not the link request is approved via a Link switching Response frame.

[0192] For example, when link switching is approved, STA2 can transmit a link switching response frame including link information to be changed. At this time, the link information to be changed may or may not be the same as the recommended link.

[0193] In another example, if STA2 selects a link other than the recommended link provided by AP2 and responds with a Link switching Response frame, the AP may send a message to the STA regarding the final approval or disapproval of the link, which may be called a Link switching confirmation frame.

[0194] For example, AP2 can approve the link change to the link determined by STA2 via the link switching confirmation frame. STA2 can attempt to change the link to the link specified by itself based on the link switching confirmation frame.

[0195] As another example, AP2 can refuse to change the link to the link determined by STA2 via the link switching confirmation frame. STA2 and AP2 can maintain the connection with the already connected link without changing the link.

[0196] The embodiment shown in Fig. 17 is also applicable to the case where the AP transmits a Link switching request frame without including recommended link information. For example, when an AP (e.g., AP2) transmits a Link switching request frame to a STA (e.g., STA2) without recommended link information, the STA can directly specify a changed Link based on its own information and then respond to the AP via a Link switching Response frame. Even in this case, the AP must ultimately transmit a Link switching confirmation frame for approval. Therefore, the embodiment in which the AP transmits a Link switching confirmation frame is also applicable even when the Link switching request frame does not include recommended link information.

[0197] Embodiment in which non-AP MLD requests link change or reconnection

[0198] According to one embodiment, the non-AP MLD can request a link change or reconnection to the AP MLD for efficient data transmission. For example, in order to use the STR capability during data transmission, the non-AP MLD can request a link change or reconnection to the AP MLD.

[0199] FIG. 18 shows the operation of AP MLD and non-AP MLD for link change or reconnection.

[0200] Referring to Fig. 18, AP MLD and non-AP MLD can perform link switching negotiation. STA2 of non-AP MLD can transmit a link switching request frame to AP2 of AP MLD. AP2 of AP MLD can transmit a link switching response frame to STA2 of non-AP MLD in response to the link switching request frame. The link switching request frame or the link switching response frame is transmitted and received via the link to be changed, but is not limited to this. The link switching request frame or the link switching response frame is transmitted and received via various links, not just the link to be changed.

[0201] Non-AP MLD can request link change or reconnection through various methods. Three methods are proposed below for non-AP MLD to request link change or reconnection. Specifically, the three methods are Solicited method, Unsolicited method, and General method are described in order.

[0202] 1) Solicited method: A method in which a non-AP MLD requests various information for link (re)selection from an AP MLD and receives various information through this. For example, the various information may include information on capability, operation element, and BSS Parameters.

[0203] According to one embodiment, the method in which a STA requests information on other APs in the connected AP MLD is used not only when re-setting a link but also in various other cases. For example, after multi-link setup, a STA can request BSS parameter information of other APs for link switching and select the best link based on the received information. Or, in a discovery process, a STA can request BSS load information of each AP from the AP MLD and select a link for executing link setup based on the received information. (However, it is assumed that the number of APs in the AP MLD is greater than the number of STAs in non-AP MLD.)

[0204] Therefore, the AP that receives the information request message can send any information, such as capability information, BSS parameter information, critical parameters, and / or operation element information, to all APs in the AP MLD. The above examples are all applicable to the embodiments described below.

[0205] 2) Unsolicited Method: A method in which an AP transmits various information for link (re)selection without a separate information request from a non-AP MLD. A STA can utilize the received information in various situations. According to one embodiment, a method in which an AP in an AP MLD transmits information on other APs without a separate information request from a STA is used not only in the case of reconfiguring a link but also in various other cases. Therefore, an AP that receives an information request message can transmit any information, such as capability information, BSS parameter information, critical parameters, and / or operation element information, for all APs in the AP MLD. The above examples are all applicable to the embodiments described below.

[0206] 3) General Method: A method in which a non-AP MLD requests link (re)selection without additional information based on information previously acquired through a beacon frame, etc.

[0207] 1)Solicited method

[0208] In the following, an embodiment relating to the above-mentioned solicited method will first be described.

[0209] According to one embodiment, the non-AP MLD may request information for selecting a link suitable for the AP MLD before changing or reconnecting the link. The STA may use data load information for each AP or capability information for each link (or information for other links) to select a suitable link.

[0210] For example, the Capability information for each link is included in a Beacon frame and is periodically transmitted.

[0211] In another example, the link-specific capability information may not be included in the beacon frame transmitted periodically as optional information. Or, to reduce frame overhead, only information on the link to which the STA is connected or some related links is received. Or, if the beacon reception period is long due to the characteristics of the non-AP MLD (e.g., a low-power device), the non-AP MLD may not be able to receive link-specific capability information for more appropriate link selection.

[0212] In the above case, the non-AP MLD can request the latest information of link-specific capability information and each link-specific information of the AP MLD (e.g., BSS parameter information or operation element information, etc.). The link-specific capability information and the link-specific information can include not only the link being transmitted or received but also other links. For example, a field of a QoS data frame (A-Control field of the 11ax standard), a management frame, a probe response / request frame, a PS-Poll frame, or a null frame can be used to request / send the latest information. Alternatively, a separate new frame is defined to request / send the latest information.

[0213] According to one embodiment, in order to request the latest information of the link-specific capability information and the AP MLD information for each link, the STA may transmit a request message to the AP to request information required for link reselection. For example, the previously defined Probe Request frame for the request message is reused. In another example, a new frame for the request message is defined.

[0214] According to an embodiment, the STA may specify specific information required through the request message and request it from the AP. The specific information that can be specified may be changed depending on the situation. That is, the STA may request only information corresponding to a specific link or only information corresponding to a specific capability. For example, the information corresponding to a specific link may include information regarding the BSS load / parameters of the specific link. Also, the information corresponding to a capability may include BSS load information of all links or BSS load information of a specific link. In this case, the AP may transmit only the information specified by the STA through a response message. Specific embodiments regarding specific information request and response will be described through embodiments regarding IOM definition and operation.

[0215] As another example, the STA may request all capability information (including other link information) currently held by the AP MLD via the request message.

[0216] As in the above example, an embodiment for transmitting all information possessed by the AP or an embodiment for transmitting only specific information designated by the STA may be defined / configured in various ways. For example, the AP may transmit all information or designated information based on a separate field or bitmap to indicate (or transmit) only specific information.

[0217] Normally, a message requesting information from the AP MLD is sent via the STA that wishes to reconnect, but depending on the situation (channel conditions or link state), it may be sent to any STA (ie, other STA).

[0218] The AP MLD that receives the request message can transmit a response message (i.e., information message) including information requested by the STA (e.g., link-specific data load information, link-to-link STR capability information, etc.) to the non-AP MLD. For example, if a conventional Probe Request frame is reused for the request message, the AP (or AP MLD) needs to respond using a Probe Response frame in the response message.

[0219] The response message is also normally sent via the AP that received the Request message, but can also be sent to any AP (ie, other APs) using the multi-link characteristic.

[0220] Alternatively, the AP MLD can send a "recommend link" element recommending a suitable link for the STA together with a response message including the above-mentioned information (e.g., the latest information required for link reselection).

[0221] In this specification, the case where a non-AP MLD STA requests information about other APs will be defined in detail.

[0222] When a Non-AP MLD STA sends an MLD Probe request frame to a peer AP to request the full information of other APs, the peer AP responds with an MLD Probe Response frame that includes the full information of the AP requested by the STA. In this case, the peer AP can respond with the full information of the AP in the MLD Probe Response frame as follows:

[0223] 1-1) When a STA requests full information on other APs, the method of including the full information of the peer AP in the MLD Probe Response as mandatory

[0224] This method includes the overall information of the peer AP even if the STA requests the overall information of other APs of the same AP MLD excluding the peer AP. Currently, 802.11be uses an inheritance model to reduce the overhead of MLD Probe Response. Therefore, when the STA requests the overall information of other APs, the AP can apply the inheritance model by always including the overall information of the peer AP. In other words, when the AP MLD responds to a request for the overall information of a specific AP and includes the information of the peer AP, the common value within the same MLD is included in the Common info in the ML IE, and the information that differs for each AP can be included in the non-inheritance element in the Per-STA Profile in the ML IE and different information for each AP. When the STA requests the overall information of multiple other APs, the overhead of the overall MLD Probe Response frame can be reduced by configuring the same existing information only once as Common info. However, in this case, if the STA does not request all information from the peer AP, there will be some overhead because unrequested information from the peer AP will be included. However, if information from multiple other APs is requested, the overhead that can be reduced by using the inheritance model may be even greater, making it convenient to use.

[0225] 1-2) When a STA requests the overall information of other APs, the MLD Probe Response does not include the overall information of the peer AP as mandatory (i.e., the MLD Probe Response only includes the overall information of the requested other AP and transmits it)

[0226] In this method, when a STA requests the overall information of other APs from a peer AP, only the overall information of the requested AP is included in the MLD Probe Response and sent. When the STA also requests the information of the peer AP, this method can reduce overhead by applying the inheritance model, but if the STA requests only the information of other APs of the same AP MLD excluding the information of the peer AP, the inheritance model cannot be applied. Therefore, if the information of the peer AP is not included, the overhead may increase slightly because the inheritance model is not applied, but if the STA requests the overall information only for a specific AP, not for multiple APs, the overhead may be less because unnecessary peer AP information is not included. The method of responding by including only the information of the AP requested by the STA is somewhat simpler than the first mandatory method, but the more other APs in the same AP MLD from which the STA requests the overall information increase, the more efficient the first mandatory method using the inheritance model becomes.

[0227] 1-3) A method in which the peer AP is configured to transmit all information on the side with less overhead depending on the situation

[0228] In this method, the AP compares the frame overhead that occurs in the first case (if the STA does not request any information about the peer AP, the peer AP information is included in the response as mandatory) and the second case (if the STA does not request any information about the peer AP, the peer AP information is not included in the response as mandatory) depending on the configuration of the MLD Probe Response frame related to the Common info information of the AP requested by the STA, and then configures and sends the MLD Probe Response in the most efficient case. In other words, the efficiency of applying the Inheritance model is compared depending on the information of the AP requested by the STA, and a format with less overhead is configured and sent in response. However, the criteria for determining which of the two cases is more efficient in this method can be determined by the implementation of the AP.

[0229] The above-described methods for multiple options are for when a STA requests full information of other APs, and may not be applicable when a STA requests partial information of other APs because they request information for a specific IE. However, when a STA requests full information for some APs and partial information for some APs in one MLD Probe request frame, the Inheritance model can be applied, so the three methods mentioned above can be used.

[0230] The above-mentioned solicited method can be used by a non-AP MLD STA to change or reconnect a link. For example, if a non-AP MLD STA wants to reselect a link due to link congestion, the non-AP MLD STA can request BSS load information and BSS parameter information for each link of the connected AP MLD via the solicited method. The AP that receives this request message can send a response message including the link and information specified by the STA.

[0231] Hereinafter, the above-mentioned request message and response message will be described as an information request message and an information response message to distinguish them from a request message for link modification and a response message for link modification.

[0232] Based on the information included in the above-mentioned information response message, the STA can reselect a suitable link and request a link change or reconnection to the AP MLD via a link change request message. The link change request message can include AP information and link information to which the STA will reconnect.

[0233] When the AP MLD receives the request message, it can send a response message of "Accept" if it accepts the request, or it can send a response message of "Decline" if it rejects the request.

[0234] If the request is accepted, the AP can perform link (re)setup based on frame exchange via the link of the reselected AP after sending the response message. Conversely, if the request is rejected, the STA can continue to use the existing link.

[0235] An example of specific AP MLD and non-AP MLD operations related to the Solicited method is illustrated in FIG.

[0236] FIG. 19 shows the operation of AP MLD and non-AP MLD for link change or reconnection.

[0237] 19, when STA2 of non-AP MLD wants to reselect a connected link, STA2 can transmit an Info request message to AP MLD via Link2. The AP MLD receiving this can transmit an Info response message including information required for link reselection of non-AP MLD. Based on the information included in the above-mentioned Info response message, STA2 of non-AP MLD can transmit a request message for link change (i.e., link switching request frame) to AP2 of AP MLD. Thereafter, STA2 can receive a response message for link change (i.e., link switching request frame) and perform link(re)set-up for link change.

[0238] The embodiments of the information request proposed in this specification are also used / applied when the STA requests necessary information from the AP. If the information included in the frame (e.g., beacon) that the STA receives from the AP is insufficient, the STA can request the AP for the missing information. For example, if the AP does not include information on the other link and only transmits information on the connected link or transmits only information on whether the information on the other link is updated, the STA can request the AP for the missing information.

[0239] A specific example of said embodiment is illustrated in FIG.

[0240] FIG. 20 shows the operation of non-AP MLD to request information about Other APs.

[0241] 20, AP MLD (or AP1 to AP3) can transmit only information regarding whether information on other APs (i.e., links) has been updated to STAs via a beacon frame. Therefore, STA2 can transmit an Info request message (or Info request frame) to AP2. STA2 can receive an Info response message (or Info message) based on the Info request message. STA2 can receive / acquire information regarding other APs based on the Info response message.

[0242] For example, the Beacon may not include Other AP information (eg, BSS load information, etc.) of the AP MLD, or AP2 may transmit only information regarding whether the Other AP information has been updated (eg, version / update version).

[0243] STA2 may require information on AP1 (or information about AP1). STA2 can request the required information via AP2. STA2 can obtain the information on AP1 via a response message to the request. STA2 can use the information on AP1 to reselect an appropriate link for link switching. For example, a frame for link switching can be set in various ways.

[0244] Furthermore, the above-mentioned solicited method is used for a STA to obtain information on APs held by AP MLD even before multi-link setup. In the multi-link setup process of non-AP MLD and AP MLD, if the number of APs held by AP MLD is greater than the number of STAs held by non-AP MLD, the non-AP MLD STA needs to decide whether to set up a link with an AP with AP MLD. In this case, the non-AP MLD STA can request specific information for each link (e.g., BSS load information of APs held by AP MLD) to the AP of AP MLD before multi-link setup in order to grasp the status of each link. As an example, the STA can use a Probe request as a request message. As another example, a new frame for the request message is defined. The STA can transmit a request message including an indicator for requesting a specific element (e.g., Request element, Extended Request element, or PV 1 Probe Response Option element) and an indicator for indicating specific link information (e.g., Link ID).

[0245] For example, a STA in a non-AP MLD can send a request message including instructions requesting current BSS load information for all APs in the AP MLD to which it connects. The AP that receives the request message can send the necessary information (BSS load information of all APs in the AP MLD to which the AP is connected) in a response message based on the STA's instructions to the STA. In this case, the STA that has checked the BSS load information for each AP can select a link to connect to in the order of the BSS (i.e., AP) with the least BSS load. The STA can indicate the selected link during multi-link setup. That is, it can send information about the selected link during multi-link setup to the AP.

[0246] In this way, the STA can use the above-mentioned solicited method to acquire AP MLD information for each AP in order to select a link to connect to before multi-link setup.

[0247] In the following, a new element / field is proposed that contains information for a non-AP MLD STA to select a suitable link.

[0248] For example, 'ratio per Link' (element / field) is proposed. 'STA ratio per Link' can include information on the ratio of the number of STAs connected per Link. A specific example of 'STA ratio per Link' is described in FIG. 21.

[0249] FIG. 21 shows a specific example of the STA ratio per Link.

[0250] Referring to FIG. 21, STA ratio per Link (element / field) may include information regarding the number or ratio of STAs connected to each Link in the entire AP MLD.

[0251] For example, if a total of 50 STAs are connected to an AP MLD with 3 links, 10 STAs are connected to Link 1 and 20 STAs are connected to Link 2. The AP MLD can transmit information on the STAs connected to each link as a value or ratio (%) to the non-AP MLD via the STA ratio per Link (element / field).

[0252] For example, if information on the STAs connected to each Link is expressed as a value, Link1 can be expressed / set as 10 and Link2 can be expressed / set as 20. Therefore, the value of the STA ratio per Link1 can be set to 10. Also, the value of the STA ratio per Link2 can be set to 20.

[0253] In another example, when information on STAs connected to each link is expressed as a ratio, Link1 can be expressed / set as 20 (10 / 50)% and Link2 can be expressed / set as 40 (20 / 50)%. Therefore, the value of STA ratio per Link1 can be set to 20. Also, the value of STA ratio per Link2 can be set to 40.

[0254] The above examples are merely illustrative, and information for STAs connected to each link can be set in various ways. In addition to the above examples, information for STAs connected to each link can be set as relative values.

[0255] Based on the information on the STAs connected to each link described above, the STA can confirm / acquire the number and ratio of STAs connected to each link and use this as information for link selection.

[0256] According to one embodiment, various information / elements / fields are included in the information response message in addition to the above-mentioned "ratio per Link" (element / field). For example, the following information / elements / fields are included in the information response message:

[0257] -BSS load information for each AP

[0258] -Inter-Link STR Capability Information

[0259] -TX OP information for each link

[0260] -NAV information for each link

[0261] -Recommended Link information (i.e., "recommend Link" element)

[0262] -Connected STA ratio information by link (i.e., 'STA ratio per Link' element)

[0263] -others

[0264] In addition to the above-mentioned information / element / field, various other information required for link selection is transmitted in the information response message.

[0265] A STA that receives information such as the above example can select an AP to change or reconnect to based on the received information, and then transmit a request message to request reconnection of the link. If the AP MLD that receives the request message accepts the request, it can transmit an "Accept" response message. If the AP MLD rejects the request, it can transmit a "Decline" response message.

[0266] If the request is accepted, the AP can perform frame exchange with the reselected AP via the link after sending the response message. If the request is rejected, the STA can continue to use the existing link.

[0267] 2)Unsolicited method

[0268] Unlike the Solicited method in which the non-AP MLD directly requests additional information, according to the Unsolicited method, the AP MLD can transmit additional information to the non-AP MLD via a Beacon frame or a separate frame (e.g., a field of a QoS data frame (A-Control field in the 11ax standard), a management frame, a FILS discovery frame, an unsolicited Probe Response frame, a PS-Poll frame, or a Null frame, etc.) without requesting additional information from the non-AP MLD. As another example, a new frame is defined as a frame for transmitting additional information to the non-AP MLD.

[0269] For example, if the beacon period is somewhat long, the non-AP MLD may lack the necessary information required for link switching or may not be the latest information. Therefore, the AP can transmit a frame including the link capability information of the AP MLD to the non-AP MLD. Thereafter, the non-AP STA can obtain the latest information on the capability of each link of the AP MLD. The frame is transmitted periodically or aperiodically.

[0270] As an example, if the frame is transmitted periodically, the AP may transmit a frame to share the latest information of the AP at a certain time interval. In this case, the time interval must be shorter than the period of the beacon transmitted by the AP. Also, if the FILS discovery frame is used in the frame, the frame is transmitted every 20 us. As another example, a period agreed upon by the AP and the STA through capability negotiation is used. For example, the transmission period may be indicated through the values ​​of the "periodic" field and the "interval" field / subfield of the IOM capability element.

[0271] As another example, if the frame is transmitted aperiodically, the AP may transmit the frame whenever an update event occurs for AP information (capability, BSS parameter, operation element). As a specific example, whenever the AP's link capability in the AP MLD changes, the changed information is transmitted to the connected STA. In this case, the STA may maintain the latest information on the link capability.

[0272] According to the above example, since the non-AP STA does not transmit a separate request message for acquiring the link capability, there is an effect that the frame exchange overhead is relatively small compared to the solicited method. Also, since the STA can receive updated information every time the main information is updated, there is an effect that the STA can conveniently use the received information.

[0273] A specific example of the operation of AP MLD and non-AP MLD according to the Unsolicited method is illustrated in FIG.

[0274] FIG. 22 shows the operation of AP MLD and non-AP MLD for link change or reconnection.

[0275] Referring to FIG. 22, the AP MLD can transmit the necessary information required for link reselection to the non-AP in a separate frame (e.g., a PS-Poll frame or a Null frame) without a separate request message of the non-AP MLD.

[0276] According to an embodiment, unlike Fig. 22, the AP MLD can transmit information on the link capability to the STA through a field of a DL frame (e.g., QoS data frame) that the AP MLD transmits to the non-AP MLD without a separate request message of the non-AP MLD. The operation of the AP MLD and the non-AP MLD according to the embodiment is described in Fig. 23.

[0277] FIG. 23 shows the operation of AP MLD and non-AP MLD for link change or reconnection.

[0278] Referring to FIG. 23, AP2 can transmit information about the other AP (or information about the other AP) to STA2 based on a DL frame (i.e., DL1). That is, the DL frame can include information about the other AP. For example, information about the other AP is included in the A-Control field of the 802.11ax standard. According to the above embodiment, since an existing DL frame is used without a separate message, it is possible to reduce frame overhead. If the critical information of the other AP is changed and real-time information is required, updated information is transmitted via a separate message as in the embodiment of FIG. 23.

[0279] For example, the Critical information of an AP may include A to Q below.

[0280] A. Inclusion of a Channel Switch Announcement element

[0281] B. Inclusion of an Extended Channel Switch Announcement element

[0282] C. Modification of the EDCA parameters element

[0283] D. Inclusion of a Quiet element

[0284] E. Modification of the DSSS Parameter Set

[0285] F. Modification of the CF Parameter Set element

[0286] G. Modification of the HT Operation element

[0287] H. Inclusion of a WideBand width Channel Switch element

[0288] I. Inclusion of a Channel Switch Wrapper element

[0289] J. Inclusion of an Operating Mode Notification element

[0290] K. Inclusion of a Quiet Channel element

[0291] L. Modification of the VHT Operation element

[0292] M. Modification of the HE Operation element

[0293] N. Insertion of a Broadcast TWT element

[0294] O. Inclusion of the BSS Color Change Announcement element

[0295] P. Modification of the MU EDCA Parameter Set element

[0296] Q. Modification of the Spatial Reuse Parameter Set element

[0297] Therefore, non-AP MLD can obtain the latest link capability information regardless of the beacon frame period. Based on the received information, non-AP MLD can select a suitable link during link switching. Based on the received information, STA can reselect a suitable link and request AP MLD to change or reconnect the link. The request message can include AP information and link information to which it will reconnect. In addition, when AP MLD receives this message, it can send an "Accept" response message if it accepts the request, or a "Decline" response message if it rejects the request.

[0298] If the request is accepted, the AP can perform link (re)setup through frame exchange with the reselected AP's link after sending the response message. Conversely, if the request is rejected, the STA can continue to use the existing link.

[0299] 3)General method

[0300] According to the general method, a non-AP MLD can request a link change or reconnection without requesting additional information based on its current information. The information used at this time can include AP MLD information and non-AP MLD information (e.g., STR capability information for each link, link state (enable / disable) information, etc.) included in previously received beacons or management frames.

[0301] Unlike the Solicited method, a STA can directly send a request message to the AP MLD for link change or reconnection without requesting separate information from the AP MLD. The request message can include AP information and link information to which the STA will reconnect. If the AP MLD receives the request message, it can send an "Accept" response message if it accepts the request, or a "Decline" response message if it rejects the request.

[0302] If the request is accepted, the AP can perform frame exchange with the reselected AP via the link after sending the response message. If the request is rejected, the STA can continue to use the existing link.

[0303] An example of specific AP MLD and non-AP MLD operations according to the general method is illustrated in FIG.

[0304] FIG. 24 shows the operation of AP MLD and non-AP MLD for link change or reconnection.

[0305] 24, STA2 may wish to directly change the link for QoS guarantee reasons. If STA2 has received information from the existing AP MLD (e.g., information received via a Beacon frame or a Management frame) or has already determined the link to be reconnected, STA2 can request a link change or reconnection without requesting additional information.

[0306] STA2 can send a Link switching request frame including STA information (eg. STA ID, etc.) and Link information to be changed (eg. Link ID or APBSS information, etc.). If the AP MLD that receives this approves the change, it can send an "approved" Link switching Response frame to STA3 via the existing Link2. After that, non-AP MLD STA2 executes the Link(re)setup process and reconnects to AP3.

[0307] Signaling to indicate link changes and reconnection methods

[0308] In order to indicate the proposed method, a mutual agreement process may be required through negotiation between AP MLD and non-AP MLD. For this purpose, a signaling method for enabling the method proposed in the following specification is proposed.

[0309] First, a new element is proposed to indicate the proposed method. In the following, an embodiment related to signaling for indicating a link change and reconnection method is described, but the above embodiment is also applied to an embodiment related to signaling for indicating an anchored link change and reconnection method.

[0310] The signaling process for indicating a link change and a reconnection method is performed during or after multi-link setup. In addition, new elements proposed below can be used in the signaling process for indicating a link change and a reconnection method. For example, the elements may be included in a (re)association frame of a conventional standard or a new frame.

[0311] IOM (Information Obtain Method) Capability Element

[0312] The IOM capability element can include information on whether to enable the method of acquiring additional information for multiple links. For example, in a process (e.g., capability negotiation process) in which AP MLD and non-AP MLD exchange messages for operation agreement in a multi-link setup process, the IOM capability value may be present in the element in the message. The presence of the IOM capability value in the element in the message means that the IOM capability is supported.

[0313] According to one embodiment, when the AP MLD supports the IOM capability, the AP may have information of the Other AP by internally sharing the information of the Other AP. The MLD in which the information of the Other AP is not shared cannot support the IOM capability.

[0314] According to one embodiment, when the value of the IOM capability element is set to a first value (e.g., 1), the IOM capability element indicates that the IOM is to be activated and operate with the indicated functionality. Conversely, when the value of the IOM capability element is set to a second value (e.g., 0), the IOM capability element indicates that the IOM is to be deactivated.

[0315] According to an embodiment, the IOM capability element may include various fields / elements to indicate various operations. For example, the IOM capability element may include various fields / elements described below. However, the fields / elements added to the IOM capability element may be set differently depending on whether an AP MLD requests a link change or a non-AP MLD requests a link change. Also, at least some of the fields / elements added to the IOM capability element may be omitted. As an example, a field / element including information that does not need to be indicated may be omitted from the fields / elements added to the IOM capability element.

[0316] Examples of various fields / elements that are defined / configured to obtain additional information regarding multiple links are described below. The various fields / elements described below may be configured independently, or two or more fields / elements may be combined and transmitted through various frames. For example, the various fields / elements described below may be included in another element to perform the operations they define. As another example, the various fields / elements described below may be added to another element and used as respective elements or independent fields.

[0317] Method type (or Method) field / element

[0318] The Method type field / element (hereinafter, Method field / element) can include information about the operation method of the IOM. That is, the Method field / element can indicate the operation method of the IOM. For example, when the Non-AP MLD activates an IOM method to obtain information from an AP, the Non-AP MLD can select and indicate the method to be used from among the proposed methods (e.g., the Solicited method, the Unsolicited method, and the General method).

[0319] As an example, a Solicited method can be indicated / used based on the value of the Method field / element being a first value (e.g., 0); an Unsolicited method can be indicated / used based on the value of the Method field / element being a second value (e.g., 1); a General method can be indicated / used based on the value of the Method field / element being a third value (e.g., 2); and both Solicited and Unsolicited methods can be indicated / used based on the value of the Method field / element being a fourth value (e.g., 3).

[0320] As another example, one bit can be used as the Method field / element. In this case, the Solicited method can be indicated / used based on the value of the Method field / element being a first value (e.g., 0). The Unsolicited method can be indicated / used based on the value of the Method field / element being a second value (e.g., 1).

[0321] As another example, 2 bits can be used as the method field / element. In this case, each method can be specified to be used alone or in combination.

[0322] Link range field / element

[0323] When a non-AP MLD requests information from an AP MLD, it can indicate the range of links to be requested through the link range field / element. The link range field / element can include information on whether the STA wishes to request information on all links in the AP MLD or information on some links in the AP MLD.

[0324] For example, when the value of the link scope field / element is a first value (e.g., 0), the link scope field / element requests information on all links in the AP MLD, and when the value of the link scope field / element is a second value (e.g., 1), the link scope field / element requests information on some links in the AP MLD.

[0325] In this case, if the value of the link range field / element is a first value (e.g., 0), it is a request for all links in the AP MLD, so no separate link indication (e.g., "Link condition" field) information is required. Conversely, if the value of the link range field / element is a second value (e.g., 1), it is a request for information on some links in the AP MLD, so link indicator information is required. For example, this field can be included and used in the multi-link element defined in 802.11be. The currently defined multi-link element is as shown in Figure 25.

[0326] FIG. 25 shows an example of a multi-link element added in a probe request.

[0327] As shown in FIG 25, when a non-AP MLD transmits a request message to request information from an AP MLD, a 'Range' field can be added to the Multi-link element and used. An example of this is shown in FIG 26.

[0328] FIG. 26 shows an example of using the link range field in a multi-link element.

[0329] As shown in Figure 26, the link range is used together with the MLD MAC address field to indicate whether information on all links in the MLD is requested or only some of the links is requested. In this case, if the value of the field is 0, it indicates a request for information on all links, so no additional link indicator information is required and the "Per-STA Profile(x)" sub-element can be omitted.

[0330] Also, this field is not included in the multi-link element defined in 802.11be, but is added to a separate element for use. An example of this is shown in FIG.

[0331] FIG. 27 shows an example of the newly proposed field for indicating link changes and reconnections.

[0332] As shown in Fig. 27, a number of fields proposed in this specification can be used together to indicate the range and conditions of information requested by the STA from the AP MLD in an integrated form as shown in Fig. 27. Alternatively, when the STA requests information from the AP MLD, each proposed field can be included independently in the request message, and can be omitted if not required.

[0333] Info range field / element

[0334] The Info range field can be used to indicate the range of information when a non-AP MLD requests information.

[0335] For example, if the value of the Info range field is a first value (e.g., 0), the Info range field may indicate that only a portion of the information possessed by the AP is provided, and if the value of the Info range field is a second value (e.g., 1), the Info range field may indicate that all information possessed by the AP (or all information) is provided.

[0336] According to one embodiment, an information range field can be defined to indicate a request for all or part of information elements held by the AP, but the STA can also request more detailed information via additional subfields. For example, a subfield for indicating the range of information to be provided (e.g., all information or partial information) may be included in the information range field. For example, the subfield for indicating the range of information to be provided can be defined / set as an all / partial subfield.

[0337] According to one embodiment, a subfield is newly proposed to indicate whether all information is provided or only changed information among all the information is provided. That is, the newly proposed subfield can indicate whether all information is provided or only changed information among all the information is provided.

[0338] For example, a subfield for indicating whether all information is provided or only changed information among all the information is provided may be defined / set as a only updated subfield.

[0339] If a STA wishes to receive only changed information, the value of the only updated subfield can be set to 1. That is, if a STA wishes to receive only changed information, the STA can set the value of the only updated subfield to 1. For example, if the value of the only updated subfield is set to 1, according to the solicited method, when a STA requests information, the AP (or AP MLD) can transmit only changed information (i.e., updated information) of the requested information. As another example, if the value of the only updated subfield is set to 1, according to the unsolicited method, the AP can notify only changed information within the information range set by the STA.

[0340] In the above example, the only updated subfield in the Info range field is proposed to receive only changed information, but this is not limiting. A separate field or element can also be defined / set to receive only changed information.

[0341] According to the above embodiment, the range of information that the STA can request can be set to updated information or all information. In this case, the STA that does not want a lot of frame overhead can request to receive only the changed information. Therefore, the overhead can be reduced.

[0342] Link condition field / element

[0343] The link condition field can be used to indicate a specific link to be requested. That is, the link condition field can include information about a specific link to be requested. The link condition field can be used when the STA wishes to be provided with only specific link information from the AP.

[0344] The link condition field can be indicated as a link identifier (e.g., Link ID, BSS ID). That is, the link condition field can include information about the link identifier (e.g., Link ID, BSS ID). That is, the link identifier can be used to specify the link for which information is to be obtained.

[0345] For example, if a STA connected to Link1 wishes to request only information on Link2 and Link3 from the AP, the STA can display link2 and link3 in the link condition field to request information on Link2 and Link3 from the AP. For example, when the value of the above-mentioned Info range field is 1, all information corresponding to link2 and link3 is transmitted. As another example, when the value of the above-mentioned Info range field is 0, part of the information designated by the STA in link2 and link3 is transmitted. According to one embodiment, the part of the information designated by the STA can be determined via the following Info condition field.

[0346] According to one embodiment, if the value of the Link condition field is absent or 0, the AP may determine that there is no link condition. Therefore, the AP may provide / send information about all links to the STA.

[0347] Info condition field / element

[0348] The Info condition field can be used to indicate the specific type of information requested. That is, the Info condition field can be used when the STA wishes to receive only specific information from the AP.

[0349] For example, the information condition field can be used only if the Info range field is set to 0. As another example, the information condition field can be used by the STA to indicate specific information even if the Info range field is not present.

[0350] For example, in the information condition field, information that the STA can specify (e.g., BSS load, STR capability, etc.) can be represented as a bitmap. For example, the type of information provided by the AP and the instruction method or procedure in the bit can be set in various ways.

[0351] According to one embodiment, the information condition field can be used together with the above-mentioned link condition field. According to one embodiment, the information condition field can send request information of various conditions to the STA (or AP) based on the combination of various fields / elements.

[0352] In this regard, an element of an existing standard can be reused to request that the STA indicate specific information. For example, a Request IE or an Extended Request IE can be used. The corresponding element information is as shown in FIG. 28 and FIG. 29.

[0353] FIG. 28 shows an example of the Request IE format.

[0354] FIG. 29 shows an example of the Extended Request IE format.

[0355] The elements in Figs. 28 and 29 can be used to request specific information in a Probe request frame or an Information request frame. If the STA specifies a list of information for which it wishes to receive a response in the Request element IDs, the AP transmits the corresponding information in a Probe Response frame or an Information Response frame. Therefore, this element can be reused as an indicator for requesting specific information in this specification, and can also be used to request information on a desired link together with a link identifier (e.g., Link Identifier). For example, if an element ID for BSS load information is specified in the Request element mentioned in Figs. 28 and 29 and information on AP2 is desired, only the BSS load information of AP2 can be requested by specifying the Link Identifier. Such element ID information can be used to specify specific information of a specific AP in various combinations together with the Link Identifier information. If a new frame for requesting information that is not an existing frame is defined in the present invention, the Request element and Extended Request element in Figs. 28 and 29 can be reused.

[0356] In addition, existing standards provide a PV 1 Probe Response Option element to request specific information, and such an element can be reused to indicate specific information. The STA uses the information it wants to acquire as a probe request to request optional information, and the Probe Response Option bitmap indicates each piece of information for frequently used information as follows. However, in the case of 11be, since it is necessary to provide multi-link information in consideration of MLD, the STA can request specific information for specific links in various combinations using a Link Identifier with a bitmap indicator as shown below. However, in this case, since there may be optional information (e.g. STR Capability) newly defined along with multi-link in 802.11be, if this PV 1 Probe Response Option element is reused, a bitmap for information that is newly defined or needs to be acquired in 11be must be newly or additionally defined.

[0357] FIG. 30 shows an example of the PV 1 Probe Response Option element format.

[0358] Transmission periodic field / element

[0359] If a STA wishes to provide information in an unsolicited manner, it can indicate via a transmission periodic field whether it will receive a message containing the information periodically or aperiodically.

[0360] For example, if a STA wishes to receive the information non-periodically, the AP can notify the updated information whenever an update occurs to the information of other APs.

[0361] As another example, if the STA instructs to receive the information periodically, the STA may receive a message including the information at periodic intervals set by the STA.

[0362] According to one embodiment, the transmission periodicity field may be set to 1 bit. If the value of the transmission periodicity field is set to 1, the STA may receive / acquire information via a periodic method of periodically receiving messages. If the value of the transmission periodicity field is set to 0, the STA may receive / acquire information via a method of aperiodically receiving messages.

[0363] Transmission interval field / element

[0364] According to an embodiment, if a STA wants to receive information of other APs periodically, the STA can directly set the period. The STA can transmit information about the period for receiving other AP information based on the transmission period (interval) field. However, the period needs to be set shorter than the beacon transmission period. For example, when the FILS discovery frame is used, the period needs to be set to 20us.

[0365] As described above, it is defined as a separate field in an element that indicates the transmission period, and is also defined as a subfield in a transmission periodic field.

[0366] According to an embodiment, the fields / elements defined / set to obtain additional information regarding multiple links are not limited to the above-mentioned fields / elements, and various fields / elements may be further set.

[0367] Therefore, MLD (AP MLD or non-AP MLD) can indicate IOM capability through negotiation between AP MLD and non-AP MLD using at least one of the above elements / fields in the multi-link setup process. Also, MLD can update the agreement between MLDs through separate message exchange after multi-link setup is completed.

[0368] According to one embodiment, when the IOM capability is activated, AP MLD and non-AP MLD can operate according to the embodiment for link change and reconnection.

[0369] The following describes an example of the operation of AP MLD and non-AP MLD when the IOM capability is activated. For example, non-AP MLD can request additional information for multiple links by sending the above-mentioned fields / elements to AP MLD. Non-AP MLD can send an IOM capability element including the above-mentioned fields / elements to AP MLD. The above-mentioned fields / elements are included in the IOM capability element for illustrative purposes only, and are sent as independent fields / elements.

[0370] For example, in the multi-link setup process, the non-AP MLD can send an IOM capability element including "Method field=0" and "Info range field=1" to the AP MLD and agree on this with the AP MLD. In this case, after the multi-link setup, the non-AP MLD operates in the Solicited method and can request information for multiple links (e.g., information about other APs) including all information included in the beacon when requesting information. Therefore, the AP MLD can provide / send information about the link in a response message only when it receives a request message from the STA. When the AP MLD receives a request message, it can send a response message including information about all links in the AP MLD to the STA. The information about all links in the AP MLD can include all information included in the beacon.

[0371] As another example, non-AP MLD can send an IOM capability element including "Method field=1", "Info range field=0", "Link range=Link ID2", and "Info condition field=(value indicating BSS load via bitmap)" to AP MLD and agree on this with AP MLD. In this case, non-AP MLD can operate in UnSolicited method after multi-link setup. Therefore, AP can send BSS load information of Link2 to STA via a separate message without a separate request message.

[0372] As another example, non-AP MLD can send an IOM capability element including "Method field=0", "Info range field=0", "only updated field or subfield=1", and "Info condition field=(value indicating BSS load via bitmap)" to AP MLD and agree on this with AP MLD. In this case, non-AP MLD can operate in the Solicited method after multi-link setup. Therefore, when a STA requests information, AP MLD (or AP) can send only the updated (changed) information of the BSS load information of all APs in the connected AP MLD in the response message to the STA.

[0373] In this specification, several options are proposed for a new element for a STA to request some information (i.e., target information) of other APs in the associated AP MLD.

[0374] FIG. 31 shows an example of an MLD Request element.

[0375] Referring to FIG. 31, "The number of Link IDs" is a field for indicating the number of APs (i.e., links) requested when a STA requests information on a specific AP.

[0376] "Link ID" is a field that contains indicator information of the AP requested by the STA.

[0377] For example, if an STA transmits a probe request frame including the above MLD Request element, the AP that receives the request message will respond with a probe response including all information of the AP specified in the element. If the STA wants to request partial information of the specified AP but not all information, it can transmit a probe request frame including a Request element or Extended Request element defined in the existing standard along with the MLD Request element, and the AP that receives this will respond with a probe response including only the information specified in the Request element or Extended Request element.

[0378] In addition, we also propose the new element in Figure 32.

[0379] FIG. 32 shows another example of the MLD Request element.

[0380] Referring to FIG. 32, 'The number of Link IDs' is a field for indicating the number of APs (i.e., links) requested when a STA requests information on a specific AP.

[0381] "Link ID" is a field that contains indicator information of the AP requested by the STA.

[0382] "Requested element IDs / Requested element ID extensions" is a field that contains the element ID information of the requested information when the STA requests specific information (i.e., element). If the element ID is 0-254, this field contains only the element ID information, but if it is a value of 255 or more, it must be recognized as an Extended Element ID and the Requested element ID extensions information must also be included. In this case, the information corresponding to "Requested element IDs / Requested element ID extensions" can be defined in the form of a field, but it is defined as a new element as shown in Figure 33 and is included in the MLD Request element in the form of a sub-element. The corresponding new element can be defined as shown in Figure 33. The element has the advantage of being able to specify one element without distinguishing between existing Request elements and Extended Request elements, thereby reducing overhead.

[0383] FIG. 33 shows an example of a new element defined based on the MLD Request element.

[0384] For example, when a STA transmits a Probe request frame including the above-mentioned MLD Request element, an AP that receives the request message replies with a Probe Response including information about the AP specified in the element.

[0385] 33, the AP recognizes the information requested by the STA as the whole or part of the information depending on whether the "Requested element IDs / Requested element ID extensions" field in the corresponding element is omitted. The standard-defined Element ID value information is defined in the 802.11 standard. The definitions of "Requested element IDs" and "Element ID extensions" mentioned in this specification are the same as those in the existing standard.

[0386] For example, if a STA requests information about an AP or other APs from an AP, it sends a Probe request frame including the above MLD Request element. The AP that receives this sends a Probe Response frame including only the information requested via the "Requested element IDs / Requested element ID extensions" field among the AP information requested via the "Link ID" field.

[0387] In this case, if the STA omits the "Requested element IDs / Requested element ID extensions" field when transmitting, the AP that receives it will respond with a Probe Response frame including the entire information of the requested AP via the "Link ID" field.

[0388] The format proposed above allows you to request only the same information for all links.

[0389] However, the STA may in some cases require different information for different links, and several options for this purpose are proposed herein.

[0390] First, we further propose a format for requesting different information for each link, as shown in FIG.

[0391] FIG. 34 shows another example of the MLD Request element.

[0392] As shown in Figure 34, the STA requests different information for each link by including existing Request element or / and Extended Request element information for each link in the MLE Request element. At this time, a new field or element "The number of Elements" is defined to indicate the length of the requested element. This information indicates the number of elements requested for Link ID(x).

[0393] The AP that receives this checks the requested information, which differs for each link, based on the MLD Request element, and responds by including it in a Response frame.

[0394] In this case, when a field proposed in the present invention is used instead of the existing Request element or / and Extended Request element, the embodiment is as shown in Figure 35. Each field or element may be omitted as necessary.

[0395] FIG. 35 shows another example of the MLD Request element.

[0396] Secondly, when an STA requests information, a format is proposed as shown in FIG. 36, which distinguishes between common information that is requested equally for all links and link specific information that is requested differently for each link.

[0397] FIG. 36 shows another example of the MLD Request element.

[0398] As shown in Figure 36, if a Request element or / and Extended Request element is included before the number of Link ID field, it means elements for common information commonly requested for the links specified later, and the information arranged after the number of Elements together with Link ID(x) after the number of Link ID field means element information requested for each link. Each field or element can be omitted as necessary.

[0399] In this case, when a field proposed in the present invention is used instead of the existing Request element or / and Extended Request element, the embodiment is as shown in Figure 37. Each field or element may be omitted as necessary.

[0400] FIG. 37 shows another example of the MLD Request element.

[0401] As shown in Figure 37, if a Request element or / and Extended Request element is included before the number of Link ID field, it means elements for common information commonly requested for the links indicated later, and the information arranged after the number of Elements together with Link ID(x) after the number of Link ID field means element information requested for each link. Each field or element can be omitted as necessary.

[0402] Fourth, when a STA requests information, common information that is requested for all links is used to indicate, along with the MLD Request element, a separate Request element or an Extended Request element, as shown in FIG.

[0403] FIG. 38 shows an example of a field requesting common information.

[0404] When an STA requests information for multiple AP MLD links via a Request frame, the commonly requested information is specified via the existing Request or / and Extended Request element, and when information is requested differently for each link, it is specified via the MLD Request element. In this case, the format of the MLD Request element is defined in multiple forms. The AP that receives this request message recognizes the information included in the Request or / and Extended Request element as information commonly requested for the links specified in the MLD Request element, and transmits the corresponding element information for all links specified in the MLD Request element by including it in a response message. Furthermore, when an STA requests different information for each link, the AP transmits the response message based on the information specified for each link in the MLD Request element.

[0405] We also propose a method in which a STA requests partial information on Other APs in the MLD of the connected AP using the ML (Multi-Link) IE defined in the 802.11be standard.

[0406] FIG. 39 shows an example of the ML IE format defined in 802.11be.

[0407] In 802.11be, ML IE (Multi-Link Information Element) is defined as shown in Figure 39 to define information for each link. After that, elements or fields are added depending on the proposed function. Per-STA Profile(x) sub-element can contain multiple pieces of information for the link. The sub-element contains the link ID and the contents of the information range contained in the sub-element via the Per-STA Control field, and then lists the information (elements) that correspond to the information requested by the STA. At this time, if there is non-inheritance information, the information can also be included using a non-inheritance element. Complete Profile in the Per-STA Control sub-element is a field that distinguishes whether the included information is complete information or partial information for the link.

[0408] Therefore, by including such an ML IE in a request frame (eg, a Probe request frame), a STA can utilize it to request partial information from other APs, and we propose various options for this purpose.

[0409] In this specification, the following restriction elements are defined for using the ML IE for MLD Probing. When an STA uses an ML IE in a Probe request frame for MLD Probing, the Element information (e.g., Element x, ..., Element n) provided in the Per-STA Profile(x) may be omitted and transmitted to reduce overhead. (However, when an ML IE is used in an Association request / Response frame used for Association, Element information must be included.) When the information requested by the STA is Complete information of a link, the Complete information bit is indicated via the Per-STA Control field, and then the element information list is omitted and transmitted. Otherwise, the Partial information bit is indicated via the Per-STA Control field, and then information for the requested element ID is added. However, several options for when an STA requests partial information for a specific element (Element) rather than the entire information are defined in detail below.

[0410] As described above, the information included in the ML IE defined in 802.11be changes depending on whether the element is included in an association frame or a probe frame, and whether the frame is a request or a response. For example, when an STA uses the ML IE when making a probe request, an element including multiple pieces of information in the Per-STA Profile(X) is omitted, but in other cases, the element information must be included. Therefore, a control field to indicate this is proposed.

[0411] The multi-link element and multi-link control field format currently defined in the 802.11be standard is as shown in Figure 40.

[0412] FIG. 40 shows an example of a multi-link element format and a multi-link control field format.

[0413] At this time, a field for indicating the type of frame including the current Multi-link element is added to the Multi-link Control field element. The proposed field is defined as "Elements per-STA Present". The name of this field may be redefined as necessary. This field indicates the presence or absence of STA-specific element list information currently requested by the ML IE. When this value is 1, it means that element information is included after the Per-STA Control field in the Per-STA Profile(x) field, and when this value is 0, it means that element information is omitted after the Per-STA Control field in the Per-STA Profile(x) field. An embodiment of this is shown in FIG.

[0414] FIG. 41 shows an example of a Multi-link Control field format.

[0415] Furthermore, as described above, the information included in the ML IE defined in 802.11be changes depending on whether the element is included in an association frame or a probe frame, and whether the frame is a request or a response. Therefore, a field that can indicate this is proposed. The field is included in the ML IE of a request / response frame and indicates the frame type currently being transmitted by the STA, and the contents and arrangement of the further configured element (element configured as 0 or variable) may differ depending on this.

[0416] "Frame type": An indicator that indicates the frame type currently being transmitted by the STA. The value of this field indicates the type of frame that currently includes the ML IE. For example, it can be indicated by dividing it into 0: Association request, 1: Association response, 3: Probe request, 4: Probe response, etc. This can be indicated as an integer value, or it can be indicated by a bitmap. In addition, if MLD Probing configured in 802.11be is divided, it is possible to add 5: MLD Probe request frame, 6: MLD Probe Response frame, etc. In this way, it is an indicator that indicates that the element configuration of the ML IE differs depending on the frame type. Each frame type is arranged in the form of a subfield in the "Frame type" field, and when it is 1, it is configured to indicate the frame type being indicated.

[0417] In this case, it can be further classified into multiple subfields in the "Frame type" according to multiple functions of the frame to be transmitted. Therefore, in this specification, a "request type" is defined as a subfield that classifies in detail according to the purpose of the frame in the "Frame type". The "request type" subfield classifies in more detail the form of the message classified by the "Frame type", and is classified according to the purpose of the currently transmitted frame. For example, when the "Frame type" transmits an MLD Probe request frame to request full or partial information for a specific AP, the "Frame type" field is set to the MLD Probe request frame (field = 5), and the "request type" can be classified in detail according to whether the requested information is full or partial, and whether the information requests certain information (e.g., Critical update related information, link subset information that is not set up for link re-setup, etc.) If 'Frame type' is set to a (re)Association request frame for link switching to a specific AP, the 'Frame type' field is set to (re)Association request frame (for reference, currently in 802.11be, all frames except MLD Probe request frames are classified as the same basic type, so the (re)Association request frame is classified as the basic type. However, the frame type classification may change later), and this can be indicated in the 'request type' subfield depending on the purpose of requesting the frame (e.g. TID-link mapping, inter-MLD link switching, link switching within the same MLD).A non-AP STA or AP that receives this can obtain a more detailed understanding of the purpose of the frame sent by the STA via the value of the subfield transmitted along with the type of the currently received frame, and can then include the appropriate information in the Response frame and send it.

[0418] When a STA requests partial information for a specific element rather than the entire information, several format options and operations for the ML IE are proposed as follows.

[0419] The first method is to include a Request element or / and Extended Request element for indicating the information that the STA wishes to request from the AP in the Per-STA Profile(x) in the existing ML IE and transmit it.

[0420] The AP that receives the request message indicating the relevant information knows the partial information of the link that the STA is requesting through the ML IE information, and transmits the information in a response frame (e.g., Probe Response frame). The STA indicates the link ID it wishes to request and whether the currently requested information is complete or partial through the Per-Control field in the Per STA Profile(x) in the ML IE in the Request frame, and further indicates the specific information it wishes to request through the Request element or / and Extended Request element. The STA can request specific information for each link using the format shown in FIG. 42. If the Request element or / and Extended Request element is omitted, it means that the entire information of the AP (i.e., complete information) is requested. However, as proposed above, the element information listed after the Per-STA Control field can be omitted if necessary.

[0421] FIG. 42 shows an example of the ML IE format.

[0422] The second method is to include a Requested element IDs / Requested element ID extensions field for indicating information that the STA is going to request from the AP in the Per-STA Profile(x) in the existing ML IE and transmit it. This field is defined in Figure 43 as a field proposed in this specification.

[0423] FIG. 43 shows another example of the ML IE format.

[0424] The AP that receives this information knows the partial information of the link that the STA is requesting through the ML IE information, and transmits this information in a response frame (e.g., Probe Response frame). In this method, the STA indicates the link ID to be requested and whether the currently requested information is complete or partial through the Per-STA Control field in the Per STA Profile(x) in the ML IE in the Request frame, and further indicates the specific information to be requested through the Requested element IDs / Requested element ID extensions field. When the Requested element IDs / Requested element ID extensions field is omitted, it means that all information of the AP (i.e., all elements information) is requested. An embodiment of this format is as follows. However, as proposed above, the element information listed after the Per-STA Control field can be omitted if necessary.

[0425] The format in Figure 43 has the advantage that the element indication information defined in the 802.11 standard is not divided into Request element or / and Extended Request element, but is sent as a single piece of information, thereby reducing default field overhead (e.g., element ID, Length, etc.).

[0426] Third, the STA sends a Request element or / and Extended Request element to indicate the information it wishes to request from each AP, and requests Common info and Link specific info that the STA wishes to request from all APs separately. The format is defined in Figure 44.

[0427] FIG. 44 shows another example of the ML IE format.

[0428] When an STA requests information of each AP through a request frame (e.g., Probe request frame), it may request the same information for some information, and may request different information for each AP for other information. A format for indicating this is defined and an embodiment is proposed. As shown in FIG. 44, an indicator for indicating the same information requested by the STA from the APs requesting information through the request frame is used as a Request or / and Extended Request element together with the ML IE in the request frame, and an indicator for indicating different information requested for each AP is used as a Request or / and Extended Element in the Per-STA Profile(x). However, as proposed above, the element information arranged after the Per-STA Control field may be omitted if necessary.

[0429] For example, when a STA indicates information corresponding to the TIM element (eg. Element5 = 11) in the Request element of a Probe request frame, instructs the Per-STA Control of Per-STA Profile (x) in the ML IE to set Link ID = 1 and Complete Profile = 0 (conversely, a value of 1 indicates a request for all elements information), indicates information corresponding to the BSS load element (eg. Element ID = 11) in the Request element, instructs the Per-STA Control of Per-STA Profile (y) to set Link ID = 2 and Complete Profile = 0, and indicates information corresponding to the non-inheritance element (eg. Element ID = 255, Element ID extension = 56) in the Extended Request element and sends it, the AP will respond with a Probe Response frame including the following information:

[0430] -TIM element information for Link1 and Link2

[0431] -BSS load element information for Link1

[0432] -Non-inheritance element information for Link2

[0433] The STA can request different information for each link by classifying the information it requests as common or link specific according to the element layer within the frame.

[0434] In this way, in 802.11be, the inheritance model can be applied to the ML Probe request frame. As described above, when an STA transmits an ML Probe request including an (Extended) Request element, the inheritance model is applied to the AP requested via the ML IE (ie Probe request variant Multi-Link element) as well as the peer AP, and the peer AP accepts the request for common information for all APs. Therefore, when a Probe request frame including an (Extended) Request element outside the ML IE is received from the STA as shown in FIG. 44, it is analyzed as a request for common information for the peer AP and requested APs (ie APs specified for the Other AP information request in the ML IE), and the requested information specified in the (Extended) Request element in the ML Probe Response is confirmed, and the information corresponding to each AP in the ML IE (ie basic variant Multi-Link element) is included in the Per-STA Profile to respond.

[0435] Fourth, a format in which a STA transmits a Request element or / and Extended Request element included in a Multi-link element to indicate information it wishes to request from each AP, and requests Common info and Link specific info that the STA wishes to request in common to all APs separately. The format is defined in FIG. 45.

[0436] FIG. 45 shows another example of the ML IE format.

[0437] When a STA requests information on each AP through a request frame (e.g., Probe request frame), it may request the same information for some information, and may request different information for each AP for other information. A format for indicating this is defined and an embodiment is proposed. If a Request or / and Extended Request element is included along with a Multi-link element in a Request frame (e.g., Probe request), this means that the STA requests partial information for the link to which it is connected (i.e., associated AP). If the STA requests information on an AP that is not its own link among the APs in the AP MLD to which it is connected, the instruction information for this is included in the ML IE (multi-link element). Therefore, as described above, if a Request or / and Extended Request element is included before the Per-STA Profile(x) element in the ML IE, the STA can indicate information commonly requested for Other APs (APs that are not its own link among the APs included in the AP MLD to which the STA is connected) of the AP MLD requested by the STA through the element. Information commonly requested from other APs is indicated via a Request or / and Extended Request element in the ML IE, and information differently requested for each other AP can be indicated by considering the Request or / and Extended Request element after the Per-STA Control field in the Per-STA Profile(x). In this case, if the ML IE includes an indicator of an AP corresponding to its own link that is not an Other AP in the Per-STA Profile(x), the STA can also obtain information of the AP corresponding to its own link via the ML IE. In this case, the Request or / and Extended Request element included with the ML IE to request partial information of the AP corresponding to its own link can be omitted.

[0438] However, as proposed above, the element information listed after the Per-STA Control field can be omitted if necessary.

[0439] Fifth, the STA can request partial or whole information from the Peer AP (i.e., transmitting link) and other APs (i.e., other link) via an MLD Probe request. Several related cases and embodiments are as follows.

[0440] 1) When requesting overall information from the peer AP and overall information from the other AP

[0441] An EHT non-AP STA can transmit a message requesting all information to the Peer AP and other APs in one Probe request frame.

[0442] FIG. 46 shows an example of a probe request frame including the ML IE format.

[0443] Referring to FIG. 46, when requesting overall information from a Peer AP, the Core of Probe request frame (frame body of the Probe request frame) does not include an (Extended) Request element, and the Complete Profile subfield in the “Per-STA Control” field in the Per-STA Profile of the Multi-Link element (i.e., Probe request variant Multi-Link element) is set to 1 to indicate a request for overall information from the Other AP.

[0444] 2) When requesting full information from a peer AP and full or partial information from other APs

[0445] 2) When requesting full information from a peer AP and full or partial information from other APs

[0446] An EHT non-AP STA can request all information from a peer AP in one probe request frame and can transmit a message requesting all or part of information from an other AP designated via an ML IE.

[0447] FIG. 47 shows another example of a probe request frame including the ML IE format.

[0448] 47, when requesting full information from a Peer AP, the Core of Probe request frame does not include an (Extended) Request element, and when requesting partial information from an Other AP, the (Extended) Request element is included in the Per-STA Profile of the Multi-Link element (i.e., Probe request variant Multi-Link element) and the "Complete Profile" subfield in the "Per-STA Control" field is set to 0 to indicate a request for partial information from the Other AP. In this case, if requesting full information from another Other AP, the "Complete Profile" subfield in the "Per-STA Control" field is set to 1 without the (Extended) Request element in the Per-STA Profile. In this way, requests for full information or partial information for each AP from other APs are possible in one Probe request frame.

[0449] 3) When requesting partial information from a peer AP and requesting full or partial information from other APs

[0450] An EHT non-AP STA can request partial information from a Peer AP in one Probe request frame and can request all or partial information from other APs designated via a Multi-Link element.

[0451] FIG. 48 shows another example of a probe request frame including the ML IE format.

[0452] Referring to FIG. 48, when requesting partial information from a Peer AP, an (Extended) Request element is included in the Core of Probe request frame, and when requesting complete information from an Other AP, the “Complete Profile” subfield in the “Per-STA Control” field can be set to 1 without an (Extended) Request element in the Per-STA Profile of a Multi-Link element (i.e., a Probe request variant Multi-Link element) to indicate a request for complete information from the Other AP.

[0453] At this time, if you want to request partial information from other APs, include an (Extended) Request element in the Per-STA Profile and set the "Complete Profile" subfield in the "Per-STA Control" field to 0. At this time, if an inheritance model is applied to the MLD Probe request, if the partial information requested from the Peer AP and AP(x) (i.e., Link) specified in the Per-STA Profile(x) is the same information, the (Extended) Request element in the Per-STA Profile(x) can be omitted. In other words, the (Extended) Request element is included in the Per-STA Profile(x) only if it corresponds to a non-inheritance element for the (Extended) Request element included in the Core of Probe request frame, and can be omitted if not.

[0454] When the inheritance model is applied to the MLD Probe request, the embodiment is as shown in FIG.

[0455] FIG. 49 shows another example of a probe request frame including the ML IE format.

[0456] 49, when an EHT non-AP STA requests partial information from a peer AP via an MLD Probe request, it includes an (Extended) Request element in the Core of Probe request frame. In this case, when requesting partial information different from the peer AP for some APs (i.e., Per-STA Profile(x)) among the APs specified in the Multi-Link element, it can request different information by including an (Extended) Request element corresponding to a non-inheritance element in the Per-STA Profile(x). In this case, the Complete Profile value of the Per-STA Control field is set to 0.

[0457] Or, when requesting the same partial information as the peer AP from some APs (i.e., Per-STA Profile(y)) among the APs specified in the Multi-Link element, the (Extended) Request element is omitted in the Per-STA Profile(y). In this case, the value of the Complete Profile in the Per-STA Control field is set to 0. When applying the inheritance model to the MLD Probe request in this way, if an EHT non-AP STA requests Element(a) and Element(b) from the peer AP and requests Element(a) and Element(c) from AP(x) specified in Per-STA Profile(x), the information requested is the same for the peer AP and AP(x) (eg. Element(a)), but since it also contains other information (eg. Element(c)), the AP needs to include an (Extended) Request element in the Per-STA Profile(x) to request information for Element(a) and Element(c) in order to distinguish between them. (When applying the inheritance model, if the AP has an (Extended) Request element in the Per-STA Profile(x), even if there is partial information requested that overlaps with that of the Peer AP, it recognizes this as a non-inheritance element, and therefore unless it is requesting the same partial information as the Peer AP, the (Extended) Request element included in the Per-STA Profile(x) must specify all element information requested to the AP (e.g. AP(x)) via the Per-STA Profile(x) regardless of the partial information requested from the Peer AP).However, if an EHT non-AP STA requests Element (a) and Element (b) from the Peer AP and then requests the same Element (a) and Element (b) from AP(x) specified in Per-STA Profile(x), since the information requested from the Peer AP and AP(x) is all the same, the inheritance model can be applied, the “Complete Profile” subfield in Per-STA Profile(x) can be set to 0, and the (Extended) Request element indicating the request for information on Element (a) and Element (b) can be omitted.

[0458] In this case, when the Complete Profile value of the Per-STA Control field is set to 1, it does not mean that the inheritance model is applied to the request information of the Peer AP, but rather that the request is for all information from AP(y). In other words, in order to apply the inheritance model to the Multi-Link element for the partial information request content from the Peer AP, the Complete Profile value of the Per-STA Control field must be set to 0.

[0459] The STA can request different information for each link by classifying the information it requests as common or link specific according to the arrangement of elements in the frame.

[0460] For this purpose, a new field is proposed in the Multi-Link Control field to indicate whether the information requested by the corresponding ML IE is classified as Common information. As described above, the STA can indicate the Common information for the corresponding link by arranging the Request element or / and Extended Request element. This means that the Request element or / and Extended Request element may exist before the per-STA Profile(x) in the ML IE in the request frame depending on whether the Common information is requested. Therefore, a control field to indicate this is proposed as shown in FIG. 50.

[0461] FIG. 50 shows an example of a Multi-link Control field format.

[0462] The field in Figure 50 may be defined as a "Common info Present" field, and this name will be defined as other names hereafter. If the field is designated as 1, when the STA requests information on other APs from the AP MLD, it transmits a Request element or / and Extended Request element, which means a request for the same information, before the Per-STA Profile(x) element. And, for link specific information that is requested differently for each AP, it is indicated through a Request element or / and Extended Request element included in the Per-STA Profile(x) element. If the field is designated as 0, it means that the STA does not have the same information requested from other APs, and it means that there is no separate Request element or / and Extended Request element before the Per-STA Profile(x) element.

[0463] An embodiment for this is as follows.

[0464] The STA can also make a partial request only for critical update information to the AP in the AP MLD. Two options are proposed for this purpose. In this case, the APs correspond to all APs (reporting AP and reported AP) that the STA can acquire through beacons. Reported APs refer to other APs that the STA can acquire through the RNR element of a beacon, and include not only other APs in the same AP MLD as the reporting AP, but also other APs that belong to the TxBSS ID group and other APs that belong to the non-TxBSS ID group. In other words, the STA can request critical update information from all other APs from which it can acquire CSN (Change Sequence Number) information through beacons (for reference, 802.11be agreed to include other AP change sequence field information in the RNR element of a beacon frame).

[0465] The first method is to define a new "Critical update request" field for requesting critical update information from other APs.

[0466] -'Critical update request' field: A field that requests only system information defined as a critical update of the AP. It can be used when requesting system information defined as a critical update of a specific link, together with the link indicator.

[0467] When a STA requests information on other APs in AP MLD, if the STA sends a Request frame (e.g., Probe request frame) with the link indicator information set to 1, the AP that receives the Request frame will respond by including Critical update information for the specified link in a Response frame. In this case, the Critical update information means a number of system information items (a) Inclusion of an Extended Channel Switch Announcement, b) Modification of the EDCA parameters, and c) Modification of the S1G Operation element) that are defined as Critical update in the System Information Update Procedure of the existing 802.11 standard. However, in the case of 802.11be hereafter, new information can be defined in addition to the system information already defined for Critical update, and the Critical update information referred to in this specification means information including the Critical update information newly defined in 802.11be. If the STA sends a Request frame with the value set to 0, the AP will respond with a Response frame with the same existing operation. The proposed field can be included in an element in the Request Frame, and is used by including it in the MLD Request element or ML IE mentioned above. An embodiment for this is shown in FIG.

[0468] FIG. 51 shows an example in which the Critical update request field is included in the ML IE format.

[0469] Referring to FIG. 51, when a STA requests information for a specific link through the ML IE in the Probe request, it can request information for the specific link through the Per-STA Profile(x). In this case, when the newly defined "Critical update request" field is included in the Per-STA Control in the Per-STA Profile(x) and is set to 1 and transmitted, the AP responds with a Response frame including the current system information defined as a Critical update for the link indicated in the Per-STA Profile(x). In this case, when a non-AP STA of the non-AP MLD sets the value of the "Critical update request" field to 1 to request Critical update information through the MLD Probe request and transmits it, it can also include and transmit CSN (Change Sequence Number) information (e.g. Change sequence element, Change Sequence field, etc.) for each non-AP STA of the non-AP MLD, or omit it depending on the implementation of the STA. In this case, if an MLD Probe request is used to request critical update information from an AP (i.e., "Critical update request" field = 1), no additional indicator is required if a Change sequence element is used to include CSN information (because the AP can check the element ID of the Change sequence element to check its presence), but if a Change Sequence field is used in the CSN information, additional definition is required for a (sub)field (e.g., "CSN Presence" subfield) to indicate the presence or absence of the Change Sequence field. Therefore, this specification proposes to add an indicator to indicate the presence or absence of CSN information in the Per-STA Profile of the ML IE as follows.

[0470] "CSN Presence" (sub)field: A field for indicating the presence of a Change Sequence field. When the value is set to 1, it indicates that the Change Sequence field is present, and when the value is set to 0, it indicates that the Change Sequence field is not present.

[0471] -> This field can be used together with the "Critical update request" field when a STA requests critical update information from another AP (for example, the "CSN Presence" (sub)field can be used together with the "Critical update request" (sub)field in the per-STA Control field of the Per-STA Profile element in the ML IE).

[0472] -> This field can also be used when the AP advertises the CSN information of the AP (including the reporting AP and the reported AP) through the Beacon / Probe Response. If the Change sequence element is used to advertise the CSN information, the field is not required, but if the Change Sequence field is used, the "CSN Presence" (sub)field indicating the presence of the field is required. In this case, the (sub)field is included in various ways depending on the location where the CSN information of each AP is included. It is included in the Beacon / Probe Response frame (e.g. when the CSN information of the reporting AP is located in the Beacon / Probe Response frame), in the Common info part of the ML IE (e.g. when the CSN information of the reported AP is located in the Common info part of the ML IE), or in the per-STA Profile (e.g. when the CSN information of the reported AP is located in the link info part of the ML IE).

[0473] In this case, if a non-AP STA uses an MLD Probe request to request critical update information for each STA(x), (y) ... (i.e., AP(x), (y) ...) by setting the value of the "Critical update request" field of the Per-STA Control in the Per-STA Profile(x) of the Multi-Link element (e.g. Probe request variant Multi-Link element) to 1 to request critical update information for STA(x), the AP that receives this can respond to the MLD Probe Response as follows, depending on whether it is included in the CSN information.

[0474] 1) When a Non-AP STA sends an MLD Probe request including its own CSN information (i.e., the most recently received CSN information included in the form of a Change sequence element or Change Sequence field) with the “Critical update request” field = 1 in the Per-STA Profile (x)

[0475] A. The AP can compare the CSN information of the non-AP STA(x) with the current CSN information of the AP(x) connected to the non-AP STA(x) and respond by including only the updated Critical update information (i.e., elements classified as Critical update events in 802.11be) in the MLD Probe Response.

[0476] B. However, even in this case, if the receiving AP MLD does not implement a function for tracking update information for each AP's CSN, it is not possible to know which information has been updated for each CSN version. Therefore, the non-AP STA(x) can respond by including all current Critical update information (i.e., elements classified as Critical update events in 802.11be) of the connected AP(x) in the MLD Probe Response.

[0477] C. In this specification, in order to reduce the overhead of MLD Probe Response, when requesting Critical update information, it is proposed to respond with all current Critical update information of AP(x) rather than the entire information of AP(x). However, depending on the AP implementation, even if an MLD Probe request with the "Critical update request" field set to 1 is received from a non-AP STA in Per-STA Profile(x), it may be possible to respond with the Complete Profile (i.e., the entire information) of AP(x).

[0478] 2) When a Non-AP STA sends an MLD Probe request to Per-STA Profile(x) with the "Critical update request" field set to 1, omitting its own CSN information (i.e., the most recently received CSN information).

[0479] A. Since the AP does not know the CSN information of the non-AP STA(x), it can respond by including all current Critical update information (i.e., elements classified as Critical update events in 802.11be) of the AP(x) connected to the non-AP STA(x) in the MLD Probe Response.

[0480] B. In this specification, in order to reduce the overhead of MLD Probe Response, when requesting Critical update information, it is proposed to respond with all current Critical update information of AP(x) rather than the entire information of AP(x). However, depending on the AP implementation, it is also possible to receive an MLD Probe request with the "Critical update request" field set to 1 in Per-STA Profile(x) from a non-AP STA and respond with the Complete Profile (i.e., the entire information) of AP(x).

[0481] FIG. 52 shows an example of an MLD Probe request using the Change sequence element when requesting Critical update information.

[0482] FIG. 53 shows another example of an MLD Probe request using the Change sequence element when requesting Critical update information.

[0483] For example, even if a non-AP STA requests Critical update information for a specific STA(x), it can set Critical update request=1 as shown in 53 and send Change Sequence Number information (e.g. Change sequence element or Change Sequence field) together. In this case, the non-STA can omit the Change Sequence Number information depending on the circumstances. However, in this case, the information included in the MLD Probe Response that the AP responds with is limited as defined above.

[0484] FIG. 54 shows an example in which the Critical update request field is included in the ML IE format.

[0485] Referring to FIG. 54, when the Critical update request field is positioned in the ML IE as described above, it is possible to request Critical update information for all links indicated via Per-STA Profile(x). If the Critical update request field is included in a position including Common information in the ML IE and the field value is specified as 1 and transmitted, the AP receiving this responds with a response frame including Critical update information for the link requested in the request frame. Alternatively, the Critical update request field can be included and indicated in a subfield in the Multi-link Control field in the ML IE. The form of the field defined in this way (field, subfield, subelement, etc.) or the position in the ML IE can be variously defined according to the standard definition.

[0486] The second method is to use a Change sequence element to request Critical update information from other APs. In 802.11ah, when a Probe request frame is sent with a Change sequence element, the AP sends a Probe Response frame with only the changed Critical update information for the link in the Compressed Probe Response frame. This can also be used in 802.11be.

[0487] When a STA requests a Probe request frame including a Change sequence element together with a link indicator for Other APs, the AP that receives the frame includes only the changed Critical update information for the indicated link in the Probe Response and transmits it. The Change sequence element can be included in an element or sub-element in the Request Frame, and is used by being included in the MLD Request element or ML IE mentioned above. An embodiment of this is shown in FIG.

[0488] FIG. 55 shows an example in which the ML IE format includes a Change sequence element.

[0489] For example, when the Change sequence element in the ML IE is included and transmitted as shown in FIG. 55, the AP compares the value of the Change Sequence field currently held by the AP for the link indicated through the ML IE with the value of the Change Sequence field in the Change sequence element transmitted by the STA, and if there is a change, the AP responds by including the changed Critical update information in the Probe Response. In this case, the Change sequence element transmitted by the STA needs to include Change Sequence information for all links for which information is requested in the ML IE. Therefore, when using an existing Change sequence element, further requested link indicator information may be required. Furthermore, in this specification, when the Change sequence element in the ML IE is included and transmitted as described above, an option is also considered in which the AP includes and transmits all information related to the Critical update currently held by the AP. If the AP compares the value of the Change Sequence field transmitted by the STA with the field currently held by the AP and if they are different, the AP transmits all information related to the Critical update currently held by the AP to the STA. Although this method may increase the overhead for the information transmitted by the AP, it is easier to implement because there is no need to store change information for each version of the Critical update for each AP.

[0490] Furthermore, this specification further proposes a new element that takes MLD into consideration.

[0491] "MLD Change sequence element": An element that can contain change sequence information for multiple links.

[0492] An embodiment of this is shown in FIG. 56 and FIG.

[0493] FIG. 56 shows an example of the MLD Change Sequence format.

[0494] FIG. 57 shows another example of the MLD Change Sequence format.

[0495] As shown in FIG. 56, the MLD Change Sequence value can be displayed by repeating the Change Sequence value for each link, or as shown in FIG. 57, the number of links can be specified in "The number of Link ID" and then the Link ID information and Change Sequence information can be specified separately.

[0496] An embodiment of the MLD Change sequence element is as shown in FIG.

[0497] Figure 58 shows an example of an MLD Change sequence element.

[0498] As shown in Figure 58, when the MLD Change sequence element is included in the ML IE in the Probe request frame and transmitted, the AP can compare the received Change Sequence value for each link with its own Change Sequence value, and respond by including the changed Critical update information for the link corresponding to the updated Change Sequence value in the Response frame. In this case, if the STA does not request different information for each link, the Per-STA Profile(x) sub-element can be omitted and transmitted.

[0499] In this case, if an existing Change sequence element is used, it can be used as shown in FIG. 59.

[0500] Figure 59 shows an example of a change sequence element in the existing standard.

[0501] It is also possible to request Critical update information updated for each link by using the existing Change sequence element in the ML IE as it is. An embodiment of this is shown in FIG.

[0502] FIG. 60 shows another example in which the ML IE format includes a Change sequence element.

[0503] 60, when a STA transmits a Change sequence element in Per-STA Profile(x) in a ML IE in a Probe request, it means a request for changed Critical update information of the link indicated in Per STA Profile(x). Therefore, an AP that checks the Change sequence element included in the Request frame compares the received Change Sequence value with its own Change Sequence value, and if there is an update (i.e., there is changed information that the STA needs to update), it can transmit a Response frame including changed Critical update information or a Response frame including all critical update related information.

[0504] The third method is to use the Change Sequence field together with the "Critical update request" field defined above to request critical update information from other APs. The "Critical update request" field is defined as follows as an indicator for the STA to request information from other APs.

[0505] -'Critical update request' field: This field requests only system information defined as a critical update of the AP. It can be used together with the link indicator to request system information defined as a critical update of a specific link.

[0506] However, when a STA requests critical update information for a specific link in a 1-bit indicator as described above, if the AP that receives this does not know the version of critical update information currently held by the STA (i.e., the value of the Change Sequence field of the critical update information held by the STA), the AP must transmit a response message including all critical update information for the requested link. The response frame can also include a Change sequence element together with the critical update information and transmit it. This is a somewhat simple method, but since there is a possibility of duplicate transmission of information that the STA already has, an additional format is proposed to reduce the overhead for this. An embodiment of this is as follows.

[0507] FIG. 61 shows an example of a probe request frame for requesting critical update information.

[0508] Referring to FIG. 61, the STA can transmit a Request frame including a Critical update request field, which is an indicator for requesting Critical update information, and Change Sequence fields (or Change sequence elements) indicating version information of the Critical update currently held by the STA. At this time, the Change Sequence fields refer to an indicator indicating a Change Sequence value for each link. In 802.11be, the STA can receive a Change Sequence value for the AP of the AP MLD connected periodically through a beacon or a probe response, and since the STA is defined to store this value, the STA is aware of the Change Sequence value information for each link that it currently receives. Therefore, the Change Sequence fields field defined in this specification refers to information on the version (i.e., Change Sequence value) of the Critical update information for the AP of the connected AP MLD that the STA previously acquired through a beacon or a probe response.

[0509] At this time, if the value of the "Critical update request" field is 1, it means that the STA requests critical update information, and if not, the value is set to 0. If the value of the "Critical update request" field is 1, it means that the STA requests critical update information, so the Change Sequence fields field (or Change sequence element) is included in the transmission, but if the value is 0, this field is omitted when the transmission is made. That is, if the value of the "Critical update request" field is 1, the STA adds and transmits the Change Sequence fields (or Change sequence element), so that the AP that receives this can add and transmit only the information that has been changed compared with the current information it has (i.e., only the changed information that the STA needs to update) to the response message, and if the value of the "Critical update request" field is 0, the Change Sequence fields (or Change sequence element) are omitted when the transmission is made to reduce overhead. Furthermore, in this specification, when the Change Sequence fields in the ML IE are included and transmitted as described above, an option of including and transmitting all information related to the critical update currently held by the AP is also considered. If the AP compares the value of the Change Sequence field sent by the STA with the field it currently has and finds that they are different, it sends all information related to the critical update that the AP currently has to the STA. This method can increase the overhead of the information sent by the AP, but it is easier to implement because it does not need to store change information for each critical update version for each AP.

[0510] As described above, the presence or absence of the Change Sequence field (or Change sequence element) may be defined according to the value of the "Critical update request" field, but the value of the "Critical update request" field and the Change Sequence field (or Change sequence element) may be defined and used independently according to the option. In this case, if the request message sent by the STA does not include the Change Sequence field (or Change sequence element) along with the "Critical update request" field with a value of 1, the AP that receives this assumes that it wants to receive all critical update information, not just updated critical update information, and responds by including all critical update information in the response message. This specification proposes a method in which the STA transmits previously acquired Change Sequence value information along with the "Critical update request" field, and the AP compares it with its current Change Sequence value information and transmits only changed information in the Response frame. In this case, the Change Sequence field is provided as an example to transmit the Change Sequence information of the link in this section, but the STA can also request it as a Change sequence element other than the Change Sequence field. However, since the use of the Change sequence element has already been mentioned in the above section, an embodiment in which the Change sequence element is used together with the "Critical update request" field in this section is omitted.

[0511] For example, when a STA transmits a Probe request frame including an ML IE for MLD Probing, information for requesting a Critical update is included in a Per-STA Profile(x) subelement for requesting information for each STA as shown in Figure 61. At this time, a Critical update request field is included in a Per-STA Control field, and a Change Sequence field field having Critical update information of the current STA can be located in Per-STA Profile(x). At this time, the Critical update request field can be located together with the Change Sequence fields in Per-STA Profile(x) but not in the Per-STA Control field. An embodiment for this is shown in Figure 62.

[0512] FIG. 62 shows another example of a probe request frame for requesting critical update information.

[0513] The AP that receives the Request frame as shown in Figure 62 reports the ML IE information in the Request frame and transmits a response message including the Critical update information of the specific link requested by the STA. At this time, if the Critical update request field exists in the Per-STA Profile(x) element in the ML IE and its value is 1, it is recognized that the STA has requested the Critical update information. At this time, the AP compares the Change Sequence information held by the STA through the received Change Sequence fields information with the current Change Sequence information for the link (X) requested by the STA, and if there are any updated items (i.e., there is changed information that the STA needs to update), it transmits a Compressed Probe Response frame including only the updated information, or if there are any updated items, it can respond with all information related to the Critical update in the Probe Response frame.

[0514] The above mentioned information is included in the common info level, not the link specific level, in the ML IE, and it is also possible to request critical update information for all links at once, not just for a specific link.

[0515] An embodiment of this is shown in FIG.

[0516] FIG. 63 shows another example of a probe request frame for requesting critical update information.

[0517] As shown in FIG. 63, the STA can send a request frame including a Critical update request field (i.e., set the value to 1) and Change Sequence fields in the Common information position that is not the Link specific information position (e.g. Per-STA Profile(x)) in the ML IE. The AP that receives this recognizes that the STA is requesting all links it owns and not a specific link, compares the Change Sequence field information sent by the STA with the current Change Sequence information for all links it owns, and if there are updated items (i.e., if there are changed information that the STA needs to update), it can send a Compressed Probe Response frame containing only the updated information for all links, or if there are updated items, it can respond with all information related to the Critical update in a Probe Response frame.

[0518] FIG. 64 shows another example of a probe request frame for requesting critical update information.

[0519] At this time, the STA may indicate a request for critical update information with link changes by placing a critical update request field in the multi-link control field as shown in FIG.

[0520] In addition to the above method in which an STA requests critical update change information from a specific AP, this specification proposes an additional response operation by an AP. Currently, in the 802.11ax standard, when a 6GHz AP receives a probe request, if the AP does not specify the actual SSID of the SSID element of its own beacon frame when transmitting a probe response frame, a rule is already defined that the Address 1 field is set to a broadcast address and transmitted. With reference to this, in the 802.11be standard, when an MLD probe request frame requesting complete information is received from an AP operating in the 2.4GHz band or 5GHz band, if the AP does not specify the actual SSID of the SSID element of its own beacon frame when responding with an MLD probe response frame, a method is discussed in which the Address 1 field is set to a broadcast address.

[0521] In response to this, this specification proposes a method in which, even if a STA requests critical update-related information for a specific AP via an MLD Probe request frame (for example, when a STA transmits an MLD Probe request frame including Change Sequence field information), the Address 1 field is set to the broadcast address if the AP does not specify the actual SSID of the SSID element of its own Beacon frame when responding with an MLD Probe Response frame. Critical update information is important change information for the AP and is information that all STAs should know before sending / receiving data. Therefore, in order to prevent a storm caused by MLD Probing, this specification proposes a method in which, when a STA requests partial information on a critical update for a specific AP, the AP responds with a broadcast message unless otherwise specified.

[0522] Also, as described above, depending on the implementation of AP MLD, AP MLD may implement a method of storing which information (i.e., IEs) has been updated for each CSN (Change Sequence Number, each time a critical update occurs) of each AP, or may not be implemented depending on the memory size. If this method is supported, the AP needs to remember which IE information has been updated each time its CSN is changed. For example, if a critical update event occurs for Element X in CSNn=1 and an update occurs for Elements Y and Z in CSN=n+1, the AP needs to maintain information on which information has been changed in CSN=n and CSNn+1. If the AP can track which IE has been changed for each CSN in this way, when a STA transmits a Request frame containing certain CSN information that it currently stores, it can transmit only the information that has been changed compared with the current CSN value of the AP, not the entire information, in the Response frame, which is convenient in terms of overhead. However, such tracking may not be easy and may require additional memory in the AP, so that the AP may or may not be able to support this capability depending on the implementation specifications of the AP. Therefore, the present invention proposes a capability for indicating the AP's capability for tracking update information by CSN as follows.

[0523] - "Critical update Tracking Support" field: This field indicates whether the STA or AP currently supports the function of storing which information (e.g., EI (Element ID) information) has been updated for each CSN value. If the value is 1, it means that the STA or AP supports the ability to store which information has been updated for each CSN value, and if the value is 0, it means that the STA or AP does not support the function. For example, this field is included in the Extended Capabilities element or the EHT Capabilities element.

[0524] During the association process, the STA can check whether the AP (or STA) supports this function and use it to request critical update information for a specific AP (or STA). This function is supported at the MLD level and at the STA level for each STA.

[0525] In this way, when the "Critical update Tracking Support" field that indicates whether or not MLD critical update tracking is supported is defined, the detailed operation of the STA related to this is defined as follows.

[0526] For example, if AP MLD supports Critical update Tracking Support (eg, "Critical update Tracking Support" field = 1), non-AP MLD will know about it in the multi-link setup process.

[0527] If AP MLD supports critical update tracking, when a non-AP MLD STA requests only partial information related to a critical update, it can send a Probe request frame including CSN (Change Sequence Number) information. The AP that receives this can compare the current CSN of the AP with the CSN information received from the STA and send a Probe Response frame including only the updated information. However, even in this case, if the STA wants to obtain all information related to the AP's critical update, not just the changed information, it can obtain the desired information (all information related to the AP's critical update) by sending a Probe request frame without including CSN information when requesting partial information related to the critical update.

[0528] If AP MLD does not support critical update tracking (e.g., "Critical update Tracking Support" field = 0), when a non-AP MLD STA requests only information related to a critical update, it may not send the Probe request frame including CSN information. The AP that receives this may send a Probe Response frame including element information related to all critical updates corresponding to the CSN of the current AP (or the entire information of the requested AP (i.e., Complete Profile) if there is no other instruction). However, even in this case, when a STA requests partial information related to a critical update, it may send the Probe request frame including CSN information. However, since the AP that receives this cannot track update information by CSN, it may send the Probe Response frame including element information related to all critical updates corresponding to the CSN of the current AP (or the entire information of the requested AP (i.e., Complete Profile) if there is no other instruction).

[0529] In this way, by defining the "Critical update Tracking Support" field in the MLD, if a non-AP MLD knows whether or not the AP MLD supports tracking of update information by CSN, it can conveniently decide whether or not to include CSN information in the Probe request frame when the non-AP MLD requests partial information related to a critical update.

[0530] According to one embodiment, AP MLD and non-AP MLD can activate the proposed IOM method through the signaling method proposed in this specification during or after the multi-link setup process. In addition, AP MLD and non-AP MLD can limit the range and type of information they request through the values ​​of various fields in the IOM capability element.

[0531] According to one embodiment, the IOM operation can be performed after the precise operation negotiation between the MLDs through the above-mentioned IOM signaling method, but the IOM operation can also be performed in the MLD implementation without a separate signaling process, which means that the IOM operation can be performed in the AP MLD implementation or in the non-AP MLD implementation without negotiation between AP MLD and non-AP MLD.

[0532] Based on the above-described embodiment, AP MLD and non-AP MLD can operate, but when MLD performs IOM operation without separate signaling exchange, the following restrictions may occur.

[0533] 1) Restrictions on the Solicited Method: If info sharing is not supported between APs in AP MLD, when a STA requests information for another link, it cannot respond.

[0534] 2) Restrictions on the Unsolicited Method: The AP can determine which STAs require additional link information and provide them with a separate message (eg, during the beacon period). Therefore, the STAs cannot predict in advance whether they will receive this information.

[0535] If MLD implements IOM without a separate signaling method, the operation process is simplified, but there is a problem that the above-mentioned restrictions may occur.

[0536] According to an embodiment, a method for requesting information on multiple links can be set based on the agreement between AP MLD and non-AP MLD performed using the above-mentioned IOM capability element. In contrast, in the case of the Solicited method, a STA may wish to temporarily obtain specific information that is not the agreed content by indicating that information. In this case, when a STA dynamically transmits a request message, the request may include the indicated content (e.g., IOM capability information).

[0537] For example, at or after multi-link setup, AP MLD and non-AP MLD may agree on the content agreed upon, and the STA may provide information from the AP based on the agreed content. However, there may be cases where the STA wants to temporarily request information of a specific AP or specific parameter information of the AP. In this case, when the STA requests information, it may send an "IOM capability" element in a request frame (e.g., a probe request frame, a (re)association frame, or a new frame, etc.) including an instruction for the information to be requested. Based on the request frame, the AP may send / provide a response message including the information to be requested by the STA to the STA. According to one embodiment, if the field in the IOM capability element is omitted, the AP may provide information to the STA based on the existing agreed content.

[0538] Therefore, the MLD (AP MLD or non-AP MLD) can perform negotiation between the AP MLD and non-AP MLD using the above elements during or after the multi-link setup process. The non-AP MLD can agree on the information to be provided (or received) based on the negotiation and receive it. In addition, the STA can temporarily receive only the requested information by sending a request message including instructions for the requested information. However, if special instructions are omitted from the request message, the non-AP MLD and AP MLD can basically operate based on the agreed instructions.

[0539] According to an embodiment, if there is a need to change the agreement contents after the completion of the multi-link setup, the non-AP MLD and the AP MLD can update the agreement contents between the MLDs through a separate message exchange.

[0540] The procedure for critical updates of BSS parameters is described as follows:

[0541] If an AP in an AP MLD does not belong to a multiple BSS ID or if the AP corresponds to a transmitted BSS ID in a multiple BSS ID set, the AP transmits a BPCC (BSS parameter change count) subfield for each AP belonging to the same AP MLD in the beacon and probe response frame.

[0542] The value of the BPCC subfield for each AP is initialized to 0 and must be incremented (modulo 256) when a critical update occurs to the operational parameters for the AP.

[0543] The BPCC subfield for each other AP in the AP MLD must be transmitted in the MLD Parameters subfield of the Target Beacon Transmission Time (TBTT) Information field of the Reduced Neighbor Report (RNR) element corresponding to that AP.

[0544] The BPCC subfield for the AP must be transmitted in the Common info field of the Basic Multi-Link element.

[0545] The AP provides a Critical update Flag subfield in the Capability Information field of the beacon and probe response frames and transmits an update indicator for the value transmitted in the BPCC subfield of the MLD Parameters field of the RNR element (or the value transmitted in the BPCC subfield of the Common info field of the Basic Multi-Link element) for any AP in the same AP MLD.

[0546] If there is a change in the value transmitted in the BPCC subfield of the MLD Parameters field of the RNR element for an AP with the same AP MLD (or the value transmitted in the BPCC subfield of the Common info field of the Basic Multi-Link element), the AP sets the Critical update Flag subfield of the Capability Information field in the beacon frame to 1 and includes a next DTIM beacon frame for the link on which the AP is operating.

[0547] Otherwise, the AP sets the Critical update Flag subfield of the Capability Information field to 1.

[0548] The non-AP MLD needs to maintain a record of the most recently received BPCC subfield value for each AP in the AP MLD that has multi-link configuration.

[0549] The above-mentioned embodiments will be described below with reference to FIGS.

[0550] FIG. 65 is a flow diagram showing a procedure in which a transmitting MLD according to this embodiment provides partial information of an AP to a receiving MLD based on a probe response frame.

[0551] The example of Figure 65 is executed in a network environment in which a next-generation wireless LAN system (IEEE 802.11be or EHT wireless LAN system) is supported. The next-generation wireless LAN system is an improved wireless LAN system of the 802.11ax system and can satisfy backward compatibility with the 802.11ax system.

[0552] In this embodiment, when a non-AP STA requests partial information for another AP that is not a peer AP through a probe request frame in MLD communication, a method and apparatus are proposed for including a request element in a multiple link element of the probe request frame and requesting partial information for a specific AP based on the request element. Here, the sending MLD corresponds to the AP MLD and the receiving MLD corresponds to the non-AP MLD. If the non-AP STA is a first receiving STA, the first receiving STA and the first sending STA connected to the first link can be said to be a peer AP, and the second and third sending STAs connected to another link can be said to be another AP.

[0553] In step S6510, a transmitting MLD (Multi-link Device) receives a probe request frame from a receiving MLD via a first link.

[0554] In step S6520, the transmitting MLD transmits a probe response frame to the receiving MLD via the first link.

[0555] The transmitting MLD includes a first transmitting STA (station) operating in the first link and a second transmitting STA operating in the second link, and the receiving MLD includes a first receiving STA operating in the first link and a second receiving STA operating in the second link.

[0556] The probe request frame includes a profile field of the second receiving STA, and the profile field of the second receiving STA includes a first overall information profile subfield.

[0557] When the first receiving STA requests partial information for the second link, the value of the first full information profile subfield is set to 0. The profile field of the second receiving STA further includes a first request element. In this case, the partial information for the second link is requested based on the first request element.

[0558] When the first receiving STA requests global information for the second link, the value of the first global information profile subfield may be set to 1. The profile field of the second receiving STA may not include the first request element. In this case, the global information for the second link is not requested based on the profile field of the second receiving STA.

[0559] That is, the probe response frame is configured based on the value of the first overall information profile subfield and / or the first request element. When the value of the first overall information profile subfield is 0, the receiving MLD can request partial information for the second link based on the first request element in the probe request frame, and the transmitting MLD can include the partial information for the second link in the probe response frame and transmit it. When the value of the first overall information profile subfield is 1, the receiving MLD can request full information for the second link only from the profile field of the second receiving STA, and the transmitting MLD can include the full information for the second link in the probe response frame and transmit it.

[0560] Also, the receiving MLD can request partial information for multiple APs in the transmitting MLD.

[0561] The transmitting MLD may further include a third transmitting STA operating in a third link. The receiving MLD may further include a third receiving STA operating in the third link.

[0562] The probe request frame may further include a profile field of the third receiving STA, The profile field of the third receiving STA may include a second overall information profile subfield.

[0563] When the first receiving STA requests partial information for the third link, the value of the second full information profile subfield may be set to 0. The profile field of the third receiving STA may further include a second request element. In this case, the partial information for the third link is requested based on the second request element.

[0564] When the first receiving STA requests global information for the third link, the value of the second global information profile subfield may be set to 1. The profile field of the third receiving STA may not include the second request element. In this case, the global information for the third link is not requested based on the profile field of the third receiving STA.

[0565] Similarly, the probe response frame is configured based on the value of the second overall information profile subfield and / or the second request element. When the value of the second overall information profile subfield is 0, the receiving MLD can request partial information for the third link based on the second request element in the probe request frame, and the transmitting MLD can include the partial information for the third link in the probe response frame and transmit it. When the value of the second overall information profile subfield is 1, the receiving MLD can request the overall information for the third link only from the profile field of the third receiving STA, and the transmitting MLD can include the overall information for the third link in the probe response frame and transmit it.

[0566] If the probe request frame includes both the first and second request elements, the probe response frame is constructed based on the values ​​of the first and second overall information profile subfields and the first and second request elements.

[0567] Also, the probe request frame may include a third request element and a multi-link element. When the first receiving STA requests partial information for the first link, the partial information for the first link is requested based on the third request element. The profile fields of the second and third receiving STAs are included in the multi-link element. That is, in MLD communication, a non-AP STA may request partial information for a peer AP via a request element not included in a multi-link element, and may request partial information for another AP that is not the peer AP via the multi-link element.

[0568] Also, the first request element may include first identifier information indicating partial information for the second link. The second request element may include second identifier information indicating partial information for the third link. Elements of the partial information for the second link may be separated according to the first identifier information. Elements of the partial information for the third link may also be separated according to the second identifier information.

[0569] That is, the present embodiment proposes a method of setting an indicator for whether or not to include a request element in the profile field of each receiving STA included in the above-mentioned multiple link element, and requesting partial information for a specific AP based on the request element. Then, the AP MLD decodes the full information profile subfield to check whether the request element is included in the profile field of each receiving STA, checks the requested partial information in the request element, and can include the partial information in the probe response frame. Thus, the non-AP MLD can always request partial information, not the full information, for another link, which has the effect of reducing frame overhead.

[0570] FIG. 66 is a flow diagram showing a procedure in which a receiving MLD according to this embodiment requests partial information of an AP from a sending MLD based on a probe request frame.

[0571] The example of Figure 66 is executed in a network environment in which a next-generation wireless LAN system (IEEE 802.11be or EHT wireless LAN system) is supported. The next-generation wireless LAN system is an improved wireless LAN system of the 802.11ax system and can satisfy backward compatibility with the 802.11ax system.

[0572] In this embodiment, when a non-AP STA requests partial information for another AP that is not a peer AP through a probe request frame in MLD communication, a method and apparatus are proposed for including a request element in a multiple link element of the probe request frame and requesting partial information for a specific AP based on the request element. Here, the sending MLD corresponds to the AP MLD and the receiving MLD corresponds to the non-AP MLD. If the non-AP STA is a first receiving STA, the first receiving STA and the first sending STA connected to the first link can be said to be a peer AP, and the second and third sending STAs connected to another link can be said to be another AP.

[0573] In step S6610, a receiving MLD (Multi-link Device) transmits a probe request frame to a transmitting MLD via a first link.

[0574] In step S6620, the receiving MLD receives a probe response frame from the transmitting MLD via the first link.

[0575] The transmitting MLD includes a first transmitting STA (station) operating in the first link and a second transmitting STA operating in the second link, and the receiving MLD includes a first receiving STA operating in the first link and a second receiving STA operating in the second link.

[0576] The probe request frame includes a profile field of the second receiving STA, and the profile field of the second receiving STA includes a first overall information profile subfield.

[0577] When the first receiving STA requests partial information for the second link, the value of the first full information profile subfield is set to 0. The profile field of the second receiving STA further includes a first request element. In this case, the partial information for the second link is requested based on the first request element.

[0578] When the first receiving STA requests global information for the second link, the value of the first global information profile subfield may be set to 1. The profile field of the second receiving STA may not include the first request element. In this case, the global information for the second link is not requested based on the profile field of the second receiving STA.

[0579] That is, the probe response frame is configured based on the value of the first overall information profile subfield and / or the first request element. When the value of the first overall information profile subfield is 0, the receiving MLD can request partial information for the second link based on the first request element in the probe request frame, and the transmitting MLD can include the partial information for the second link in the probe response frame and transmit it. When the value of the first overall information profile subfield is 1, the receiving MLD can request full information for the second link only from the profile field of the second receiving STA, and the transmitting MLD can include the full information for the second link in the probe response frame and transmit it.

[0580] Also, the receiving MLD can request partial information for multiple APs in the transmitting MLD.

[0581] The transmitting MLD may further include a third transmitting STA operating in a third link. The receiving MLD may further include a third receiving STA operating in the third link.

[0582] The probe request frame may further include a profile field of the third receiving STA, The profile field of the third receiving STA may include a second overall information profile subfield.

[0583] When the first receiving STA requests partial information for the third link, the value of the second full information profile subfield may be set to 0. The profile field of the third receiving STA may further include a second request element. In this case, the partial information for the third link is requested based on the second request element.

[0584] When the first receiving STA requests global information for the third link, the value of the second global information profile subfield may be set to 1. The profile field of the third receiving STA may not include the second request element. In this case, the global information for the third link is not requested based on the profile field of the third receiving STA.

[0585] Similarly, the probe response frame is configured based on the value of the second overall information profile subfield and / or the second request element. When the value of the second overall information profile subfield is 0, the receiving MLD can request partial information for the third link based on the second request element in the probe request frame, and the transmitting MLD can include the partial information for the third link in the probe response frame and transmit it. When the value of the second overall information profile subfield is 1, the receiving MLD can request the overall information for the third link only from the profile field of the third receiving STA, and the transmitting MLD can include the overall information for the third link in the probe response frame and transmit it.

[0586] If the probe request frame includes both the first and second request elements, the probe response frame is constructed based on the values ​​of the first and second overall information profile subfields and the first and second request elements.

[0587] Also, the probe request frame may include a third request element and a multi-link element. When the first receiving STA requests partial information for the first link, the partial information for the first link is requested based on the third request element. The profile fields of the second and third receiving STAs are included in the multi-link element. That is, in MLD communication, a non-AP STA may request partial information for a peer AP via a request element not included in a multi-link element, and may request partial information for another AP that is not the peer AP via the multi-link element.

[0588] Also, the first request element may include first identifier information indicating partial information for the second link. The second request element may include second identifier information indicating partial information for the third link. Elements of the partial information for the second link may be separated according to the first identifier information. Elements of the partial information for the third link may also be separated according to the second identifier information.

[0589] That is, this embodiment proposes a method of setting an indicator for whether or not to include a request element in the profile field of each receiving STA included in the above-mentioned multiple link element, and requesting partial information for a specific AP based on the request element. Then, the AP MLD decodes the full information profile subfield to check whether the request element is included in the profile field of each receiving STA, checks the requested partial information in the request element, and can include the partial information in the probe response frame. Thus, the non-AP MLD can always request partial information, not the full information, for another link, which has the effect of reducing frame overhead.

[0590] The technical features of the present specification described above are applicable to various devices and methods. For example, the technical features of the present specification described above are implemented / supported via the device of FIG. 1 and / or FIG. 11. For example, the technical features of the present specification described above are applied to only a part of FIG. 1 and / or FIG. 11. For example, the technical features of the present specification described above are implemented based on the processing chips 114 and 124 of FIG. 1, based on the processors 111 and 121 and memories 112 and 122 of FIG. 1, or based on the processor 610 and memory 620 of FIG. 11. For example, the device of the present specification transmits a probe request frame to a transmitting MLD via a first link and receives a probe response frame from the transmitting MLD via the first link.

[0591] The technical features of the present specification are implemented based on a CRM (computer readable medium). For example, the CRM proposed by the present specification is at least one computer readable medium including instructions based on which the instructions are executed by at least one processor.

[0592] The CRM may store instructions for performing operations including transmitting a probe request frame to a transmitting MLD via a first link and receiving a probe response frame from the transmitting MLD via the first link. The instructions stored in the CRM herein are executed by at least one processor. The at least one processor associated with the CRM herein may be the processors 111, 121 or processing chips 114, 124 of FIG. 1, or the processor 610 of FIG. 11. Meanwhile, the CRM herein may be the memory 112, 122 of FIG. 1, the memory 620 of FIG. 11, or a separate external memory / storage medium / disk, etc.

[0593] The technical features of the present specification described above can be applied to various applications and business models. For example, the technical features described above can be applied to wireless communication in a device that supports artificial intelligence (AI).

[0594] Artificial intelligence refers to the field that studies artificial intelligence or the methodology for creating it, while machine learning refers to the field that defines various problems to be dealt with in the field of artificial intelligence and studies the methodology for solving them. Machine learning can also be defined as an algorithm that improves its performance for a certain task through continuous experience with that task.

[0595] Artificial neural network (ANN) is a model used in machine learning that is composed of artificial neurons (nodes) that form a network of synaptic connections and has problem-solving capabilities. An artificial neural network is defined by the connection patterns between neurons in different layers, the learning process that updates the model parameters, and the activation function that generates the output values.

[0596] An artificial neural network can include an input layer, an output layer, and optionally one or more hidden layers. Each layer includes one or more neurons, and an artificial neural network can include synapses that connect the neurons. In an artificial neural network, each neuron can output a function value of an activation function in response to input signals, weights, and biases input via synapses.

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

[0598] The goal of training an artificial neural network is to determine the model parameters that minimize a loss function. The loss function is used as an index to determine the optimal model parameters in the training process of an artificial neural network.

[0599] Depending on the learning method, machine learning can be classified as supervised learning, unsupervised learning, and reinforcement learning.

[0600] Supervised learning refers to a method of training an artificial neural network when labels for training data are given, and refers to the correct answer (or result value) that the artificial neural network needs to infer when training data called labels are input to the artificial neural network. Unsupervised learning refers to a method of training an artificial neural network when labels for training data are not given. Reinforcement learning refers to a learning method in which an agent defined in an environment is trained to select an action or sequence of actions that maximizes cumulative reward in each state.

[0601] Among artificial neural networks, machine learning implemented as a deep neural network (DNN) containing multiple hidden layers is also called deep learning, and deep learning is a part of machine learning. In the following, machine learning is used to include deep learning.

[0602] The above-mentioned technical features are also applicable to wireless communication of robots.

[0603] A robot is a machine that performs or automatically performs tasks given to it using its own capabilities. In particular, a robot that can recognize its environment, make its own decisions, and execute its actions is called an intelligent robot.

[0604] Robots can be classified into industrial, medical, domestic, military, etc., depending on the purpose and field of use. Robots have a driving part including an actuator or a motor, and can perform various physical actions such as moving the robot joints. Mobile robots also have a driving part including wheels, brakes, propellers, etc., and can run on the ground or fly in the air via the driving part.

[0605] The above technical features also apply to devices that support augmented reality.

[0606] Augmented reality is a general term for virtual reality (VR), augmented reality (AR), and mixed reality (MR). VR technology provides real-world objects and backgrounds only as CG images, AR technology provides virtual CG images on top of images of real objects, and MR technology is a computer graphics technology that mixes and combines virtual objects into the real world.

[0607] MR technology is similar to AR technology in that it shows virtual objects together with virtual objects, but the difference is that in AR technology, virtual objects are used to complement virtual objects, while in MR technology, virtual objects and virtual objects are used with equal characteristics.

[0608] XR technology is 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.

[0609] The claims described herein may be combined in various ways, for example, the technical features of the method claims herein may be combined and implemented in an apparatus, the technical features of the device claims herein may be combined and implemented in a method, the technical features of the method claims herein and the technical features of the device claims herein may be combined and implemented in an apparatus, and the technical features of the method claims herein and the technical features of the device claims herein may be combined and implemented in a method.

Claims

1. 1. A method in a wireless local area network (WLAN) system, comprising: A first non-AP (non-access point) STA (station) transmits a multilink probe request frame to a first AP; receiving a multilink probe response frame from the first AP by the first non-AP STA; The first AP operating on the first link and the second AP operating on the second link belong to an AP MLD (multi-link device); The first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to a non-AP MLD; The multilink probe request frame carries a Per-STA Profile subfield for the second AP; The Per-STA Profile subfield for the second AP includes a first overall information profile subfield of a first STA Control field; Based on the multilink probe request frame enabling the first non-AP STA to request partial information regarding the second AP, The Per-STA Profile subfield for the second AP further includes a first request element; The value of the first general information profile subfield is set to 0, and The partial information regarding the second AP is requested based on the first request element; Based on the multilink probe request frame enabling the first non-AP STA to request full information regarding the second AP, The value of the first general information profile subfield is set to 1; The Per-STA Profile subfield for the second AP does not include the first request element, and The global information regarding the second AP is requested based on the Per-STA Profile subfield for the second AP.

2. A third AP operating on a third link further belongs to the AP MLD; a third non-AP STA operating on the third link further belongs to the non-AP MLD; The multilink probe request frame further includes a Per-STA Profile subfield for the third AP; The method of claim 1 , wherein the Per-STA Profile subfield for the third AP comprises a second overall information profile subfield of a second STA Control field.

3. Based on the first non-AP STA requesting partial information regarding the third AP, a value of the second overall information profile subfield is set to 0, and the Per-STA Profile subfield for the third AP further includes a second request element; The method of claim 2 , wherein partial information regarding the third AP is requested based on the second request element.

4. Based on the first non-AP STA requesting global information regarding the third AP, a value of the second global information profile subfield is set to 1, and the Per-STA Profile subfield for the third AP does not include a second request element; The method of claim 2 , wherein the global information regarding the third AP is requested based on the Per-STA Profile subfield for the third AP.

5. the multilink probe request frame includes a third request element and a multilink element; Based on the first non-AP STA requesting partial information regarding the first AP, the partial information regarding the first AP is requested based on the third request element; The method of claim 1 , wherein the Per-STA Profile subfield for the second AP and the Per-STA Profile subfield for the third AP are included in the Multilink element.

6. the first request element includes first identifier information indicating the partial information regarding the second AP; the second request element includes second identifier information indicating partial information regarding the third AP; The method of claim 3 , wherein the multilink probe response frame is constructed based on the values ​​of the first and second global information profile subfields and the first and second request elements.

7. A first non-AP (non-access point) STA (station) in a WLAN (wireless local area network) system, Memory, A transceiver; a processor operatively coupled to the memory and the transceiver; The processor Sending a multilink probe request frame to the first AP; receiving a multilink probe response frame from the first AP; The first AP operating on the first link and the second AP operating on the second link belong to an AP MLD (multi-link device); The first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to a non-AP MLD; The multilink probe request frame carries a Per-STA Profile subfield for the second AP; The Per-STA Profile subfield for the second AP includes a first overall information profile subfield of a first STA Control field; Based on the multilink probe request frame enabling the first non-AP STA to request partial information regarding the second AP, The Per-STA Profile subfield for the second AP further includes a first request element; The value of the first general information profile subfield is set to 0, and The partial information regarding the second AP is requested based on the first request element; Based on the multilink probe request frame enabling the first non-AP STA to request full information regarding the second AP, The value of the first general information profile subfield is set to 1; The Per-STA Profile subfield for the second AP does not include the first request element, and The overall information regarding the second AP is requested based on the Per-STA Profile subfield for the second AP. A first non-AP STA.

8. 1. A method in a wireless local area network (WLAN) system, comprising: A first access point (AP) receives a multilink probe request frame from a first non-access point (STA); The first AP sends a multilink probe response frame to the first non-AP STA; The first AP operating on the first link and the second AP operating on the second link belong to an AP MLD (multi-link device); The first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to a non-AP MLD; The multilink probe request frame carries a Per-STA Profile subfield for the second AP; The Per-STA Profile subfield for the second AP includes a first overall information profile subfield of a first STA Control field; Based on the multilink probe request frame enabling the first non-AP STA to request partial information regarding the second AP, The Per-STA Profile subfield for the second AP further includes a first request element; The value of the first general information profile subfield is set to 0, and The partial information regarding the second AP is requested based on the first request element; Based on the multilink probe request frame enabling the first non-AP STA to request full information regarding the second AP, The value of the first general information profile subfield is set to 1; The Per-STA Profile subfield for the second AP does not include the first request element, and The global information regarding the second AP is requested based on the Per-STA Profile subfield for the second AP.

9. A third AP operating on a third link further belongs to the AP MLD; a third non-AP STA operating on the third link further belongs to the non-AP MLD; The multilink probe request frame further includes a Per-STA Profile subfield for the third AP; The method of claim 8 , wherein the Per-STA Profile subfield for the third AP comprises a second overall information profile subfield of a second STA Control field.

10. Based on the first non-AP STA requesting partial information regarding the third AP, a value of the second overall information profile subfield is set to 0, and the Per-STA Profile subfield for the third AP further includes a second request element; The method of claim 9 , wherein the partial information regarding the third AP is requested based on the second request element.

11. Based on the first non-AP STA requesting global information regarding the third AP, a value of the second global information profile subfield is set to 1, and the Per-STA Profile subfield for the third AP does not include a second request element; The method of claim 9 , wherein the global information regarding the third AP is requested based on the Per-STA Profile subfield for the third AP.

12. the multilink probe request frame includes a third request element and a multilink element; Based on the first non-AP STA requesting partial information regarding the first AP, the partial information regarding the first AP is requested based on the third request element; The method of claim 8 , wherein the Per-STA Profile subfield for the second AP and the Per-STA Profile subfield for the third AP are included in the Multilink element.

13. the first request element includes first identifier information indicating the partial information regarding the second AP; the second request element includes second identifier information indicating partial information regarding the third AP; The method of claim 10 , wherein the multilink probe response frame is constructed based on the values ​​of the first and second global information profile subfields and the first and second request elements.

14. A first access point (AP) in a wireless local area network (WLAN) system, Memory, A transceiver; a processor operatively coupled to the memory and the transceiver; The processor Receive a multilink probe request frame from a first non-AP station (STA); sending a multilink probe response frame to the first non-AP STA; The first AP operating on the first link and the second AP operating on the second link belong to an AP MLD (multi-link device); The first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to a non-AP MLD; The multilink probe request frame carries a Per-STA Profile subfield for the second AP; The Per-STA Profile subfield for the second AP includes a first overall information profile subfield of a first STA Control field; Based on the multilink probe request frame enabling the first non-AP STA to request partial information regarding the second AP, The Per-STA Profile subfield for the second AP further includes a first request element; The value of the first general information profile subfield is set to 0, and The partial information regarding the second AP is requested based on the first request element; Based on the multilink probe request frame enabling the first non-AP STA to request full information regarding the second AP, The value of the first general information profile subfield is set to 1; The Per-STA Profile subfield for the second AP does not include the first request element, and The global information regarding the second AP is requested based on the Per-STA Profile subfield for the second AP.