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

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

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 from 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 recently discussed Extreme High Throughput (EHT) standard. The EHT standard can use newly proposed increased bandwidth, improved PHY layer protocol data unit (PPDU) structure, improved sequencing, and Hybrid Automatic Repeat Request (HARQ) technology. 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 WLAN systems to properly utilize 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 from 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 from an AP in a sending MLD.

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

[0008] This embodiment proposes a method and apparatus for requesting partial information from a specific AP based on a request element included in a multiple link element of a probe request frame in MLD communication when the non-AP STA requests partial information from another AP that is not a peer AP via a probe request frame. Here, the transmit MLD corresponds to the AP MLD, and the receive MLD corresponds to the non-AP MLD. If the non-AP STA is a first receive STA, the first receive STA and the first transmit STA connected to the first link can be said to be a peer AP, and the second and third transmit 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] If 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, and the partial information for the second link is requested based on the first request element. [Effects of the Invention]

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

[0015] [Figure 1] 1 illustrates an example of a transmitting device and / or a receiving device of the present specification. [Figure 2] FIG. 1 is a conceptual diagram showing the structure of a wireless LAN (WLAN). [Figure 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. [Figure 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 the 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] 10 shows a variation of the transmitting device and / or receiving device of the present specification. [Figure 12] 1 shows an example of the structure of a non-AP MLD. [Figure 13] An example is shown 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] Illustrates the behavior of AP MLD and non-AP MLD for link change or reconnection. [Figure 17] Illustrates the behavior of AP MLD and non-AP MLD for link change or reconnection. [Figure 18] Illustrates the behavior of AP MLD and non-AP MLD for link change or reconnection. [Figure 19] Illustrates the behavior of AP MLD and non-AP MLD for link change or reconnection. [Figure 20] 10 illustrates 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] Illustrates the behavior of AP MLD and non-AP MLD for link change or reconnection. [Figure 23] Illustrates the behavior of AP MLD and non-AP MLD for link change or reconnection. [Figure 24] Illustrates the behavior of AP MLD and non-AP MLD for link change or reconnection. [Figure 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 a newly proposed field for instructing 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. [Figure 30] An example of the PV 1 Probe Response Option element format is shown below. [Figure 31] An example of an MLD Request element is shown below. [Figure 32] Another example of an MLD Request element is shown below. [Figure 33] An example of defining a new element based on the MLD Request element is shown below. [Figure 34] Another example of an MLD Request element is shown below. [Figure 35] Another example of an MLD Request element is shown below. [Figure 36] Another example of an MLD Request element is shown below. [Figure 37] Another example of an 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. [Figure 40] An example of a multi-link element format and a multi-link control field format is shown below. [Figure 41] An example of a Multi-link Control field format is shown below. [Figure 42] An example of the ML IE format is shown below. [Figure 43] Another example of the ML IE format is shown below. [Figure 44] Another example of the ML IE format is shown below. [Figure 45] Another example of the ML IE format is shown below. [Figure 46] An example of a Probe request frame including an ML IE format is shown below. [Figure 47] Another example of a Probe request frame including an ML IE format is shown below. [Figure 48] Another example of a Probe request frame including an ML IE format is shown below. [Figure 49] Another example of a Probe request frame including an ML IE format is shown below. [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 in which the ML IE format includes a 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 ML IE format includes a Change sequence element is shown below. [Figure 61] An example of a probe request frame for requesting critical update information is shown below. [Figure 62] Another example of a probe request frame for requesting critical update information is shown below. [Figure 63] Another example of a probe request frame for requesting critical update information is shown below. [Figure 64] Another example of a probe request frame for requesting critical update information is shown below. [Figure 65] 10 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] 10 is a flowchart 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 INVENTION

[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] As used herein, "at least one of A and B" can mean "only A," "only B," or "both A and B." Additionally, as used herein, the expressions "at least one of A or B" and "at least one of A and / or B" can be interpreted in the same way as "at least one of A and B."

[0019] Furthermore, 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." Furthermore, "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] Furthermore, 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." Furthermore, "control information" in this specification is not limited to "PDCCH," and "PDDCH" is proposed as an example of "control information." Furthermore, 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 examples of the present specification apply to various wireless communication systems. For example, the following examples of the present specification apply to wireless local area network (WLAN) systems. For example, the present specification applies to the IEEE 802.11a / g / n / ac standards and the IEEE 802.11ax standard. The present specification also applies to the newly proposed EHT standard or the IEEE 802.11be standard. The present specification also applies to new WLAN standards that are enhancements of the EHT standard or the IEEE 802.11be. The present specification also applies to mobile communication systems. For example, the present specification applies to mobile communication systems based on LTE (Long Term Evolution) and its evolutions, which are based on the 3GPP (3rd Generation Partnership Project) standard. The present specification also applies to a 5GNR (5G Radio Frequency) communication system based on the 3GPP standard.

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

[0024] FIG. 1 shows an example of a transmitting device and / or a receiving device of this specification.

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

[0026] For example, the STAs (110, 120) can perform either 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, they can support communication standards related to the 3GPP standard (e.g., LTE, LTE-A, 5GNR standard). In addition, the STAs of this specification can be implemented in various devices such as mobile phones, vehicles, and personal computers. In addition, the STAs of this specification can support communication for various communication services such as voice calls, video calls, data communications, and self-driving and autonomous driving.

[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 illustrated processor, memory, and transceiver may each be implemented as a separate chip, or at least two or more blocks / functions may be implemented on 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 (for example, 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 AP's processor (111) can receive signals via the transceiver (113), process the received signals, generate transmit signals, and perform control for signal transmission. The AP's memory (112) can store signals received via the transceiver (113) (i.e., received signals) and can store signals to be transmitted via the transceiver (i.e., transmit signals).

[0033] For example, the second STA (120) can perform the intended operations 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 perform 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 to be transmitted via the transceiver (i.e., transmitted signals).

[0035] For example, in the following specification, the operation of the device designated as AP is performed in the first STA (110) or the second STA (120). For example, if the first STA (110) is an AP, the operation of the device designated as AP is controlled by a 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). Control information related to the operation of the AP and transmitted / received signals of the AP are stored in a memory (112) of the first STA (110). If the second STA (110) is an AP, the operation of the device designated as AP is controlled by a 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). Control information related to the operation of the AP and transmitted / received signals of the AP are stored in a memory (122) of the second STA (110).

[0036] For example, in the following specification, the operation of a device designated as non-AP (or User-STA) is performed 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 designated 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 AP transmission / reception signals 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 designated 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 referred to as a (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 Figure 1. For example, devices referred to as a (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 Figure 1. For example, in the following example, operations by various STAs to transmit and receive signals (e.g., PPPDUs) may be performed in transceivers (113, 123) in Figure 1. Also, in the following example, operations in which various STAs generate transmission / reception signals or perform data processing or calculations in advance for transmission / reception signals may be executed by the processors (111, 121) in Fig. 1. For example, examples of operations in which various STAs generate transmission / reception signals or perform data processing or calculations in advance for transmission / reception signals may include: 1) operations of determining / acquiring / configuring / calculating / decoding / encoding bit information of subfields (SIG, STF, LTF, Data) included in a PPDU, 2) operations of 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) operations of determining / configuring / acquiring specific sequences (e.g., pilot sequences, STF / LTF sequences, extra sequences applied to SIG) used for the subfields (SIG, STF, LTF, Data) included in a PPDU, 4) power control operations and / or power saving operations applied to the STAs, and 5) operations related to determining / acquiring / configuring / calculating / decoding / encoding an ACK signal.Also, 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 device / STA of Fig. 1(a) described above is modified as shown in Fig. 1(b). The STAs (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, the terms mobile terminal, wireless device, wireless transmit / receive unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, user, user STA, network, base station, Node-B, access point (AP), repeater, router, relay, receiving device, transmitting device, receiving STA, transmitting STA, receiving device, transmitting device, receiving apparatus, and / or transmitting apparatus refer to the STAs (110, 120) shown in FIG. 1(a) / (b) or the processing chips (114, 124) shown in FIG. 1(b). In other words, the technical features of this specification may be performed by the STAs (110, 120) shown in FIG. 1(a) / (b), or may be performed only by the processing chips (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 Figure 1(a) / (b) being transmitted via the transceiver (113, 123) shown in Figure 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 being generated in the processing chip (114, 124) shown in Figure 1(b) and transmitted to the transceiver (113, 123).

[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] Referring to Figure 1(b), software code (115, 125) is contained within memory (112, 122). The software code (115, 125) contains instructions that control the operation of the processor (111, 121). The software code (115, 125) may be contained 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 (Smartphone) manufactured by Qualcomm®. TMEXYNOS series processor, 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 it.

[0044] In this specification, an uplink refers to a link for communication from a non-AP STA to an AP STA, and uplink PPDUs / packets / signals, 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 downlink PPDUs / packets / signals, 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 Electronic Engineers) 802.11 infrastructure BSS (basic service set).

[0047] Referring to the top of Figure 2, a wireless LAN system can include one or more infrastructure BSSs (200, 205) (hereinafter referred to as BSS). A BSS (200, 205) is 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 does not refer to a specific area. A BSS (205) can include one AP (230) and one or more STAs (205-1, 205-2) that can join the BSS.

[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 refer to a network formed by connecting one or more APs via the distribution system (210). APs included in one ESS (240) have the same service set identification (SSID).

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

[0051] In the BSS shown at the top 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 between them. A network that sets up a network between STAs without APs (225, 230) and communicates between them is defined as an ad-hoc network or independent basic service set (IBSS).

[0052] The bottom 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 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 step S310, the STA can perform a network discovery operation. The network discovery operation can include the STA's scanning operation. In other words, the STA needs to find a joinable network in order to access the 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 illustrates an example of a network discovery process that includes an active scanning process. In active scanning, a scanning STA moves between channels, transmits a probe request frame to search for nearby APs, and waits for a response. The 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 last transmitted a beacon frame in the BSS of the channel being scanned. In a BSS, the AP transmits the beacon frame, so the responder is the AP. In an IBSS, the responder is not fixed because STAs within the IBSS return and transmit beacon frames. 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., transmit and receive probe request / response on channel 2).

[0057] Although not shown as an example in FIG. 3, scanning operations may also be performed using a privileged scan method. STAs performing scanning based on privileged scan can wait for beacon frames while moving between channels. Beacon frames are a type of management frame in IEEE 802.11 that notify the existence of wireless networks and are periodically transmitted to allow scanning STAs to find and join wireless networks. In a BSS, the AP periodically transmits beacon frames, while in an IBSS, STAs within the IBSS return and transmit beacon frames. When a scanning STA receives a beacon frame, it stores information about the BSS contained in the beacon frame and records beacon frame information on each channel as it moves to other channels. A STA that receives a beacon frame stores BSS-related information contained in the received beacon frame, moves to the next channel, and performs scanning on the next channel in the same manner.

[0058] An STA that has discovered a network can perform an authentication process through step S320. This authentication process is called the first authentication process to clearly distinguish it from the security setup operation in step S340, which will be described later. 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 for 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, RSN (Robust Security Network), 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 according to step S330. The association process includes the STA transmitting an association request frame to the AP, and the AP transmitting an association response frame to the STA in response. For example, the association request frame can include various capability-related information, 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 regarding 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 other information.

[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] 4 also includes an example of an HE PPDU of the IEEE 802.11ax standard. The HE PPDU shown in FIG. 4 is an example of a PPDU for multiple users, and the HE-SIG-B is included only for multiple users, and the corresponding HE-SIG-B is omitted for 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 (e.g., 4 or 8 μs, etc.).

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

[0068] The RUs described herein are 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 via 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 interval.

[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 within one MU PPDU.

[0070] 5 shows the operation of a UL-MU. As shown, a transmitting STA (e.g., AP) can perform channel access via 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. When 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 in the same time period from multiple STAs (for example, User STAs) whose AIDs are indicated in the Trigger frame 1030. The ACK frame 1050 for the TB PPDU can be implemented in various ways.

[0072] Specific features of the trigger frame will be 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 Figure 6. The trigger frame in Figure 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 field may vary from that shown.

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

[0076] Furthermore, the RA field 1130 contains address information of the STA receiving the trigger frame, but can be omitted if necessary. The TA field 1140 contains address information of the STA (e.g., AP) transmitting the trigger frame, and the common information field 1150 contains common control information applied to the receiving STA receiving the trigger frame. For example, it includes 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. In addition, 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] It is also 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 to 1160#N) can again include multiple subfields.

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

[0081] The indicated length field 1210 has the same value as the length field of the L-SIG field of the uplink PPDU transmitted corresponding to the trigger frame, and the length field of the L-SIG field of the uplink PPDU indicates the length of the uplink 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 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 uplink MU transmission is performed after a previously set time (e.g., SIFS) has passed since downlink MU transmission. 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, or a request for Block Ack / NACK.

[0086] In this specification, the trigger type field 1260 of the trigger frame may be assumed to indicate a Basic type trigger frame for a normal trigger. 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 the 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] The RU Allocation field 1320 is also included. That is, when the 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 the RU indicated by the RU Allocation field 1320.

[0090] 8 may include a coding type field 1330. The coding type field 1330 may indicate the 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 also 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 six RU resources via a trigger frame as shown in Figure 9. Specifically, the AP can allocate the first RU resource (AID 0, RU 1), the second RU resource (AID 0, RU 2), the third RU resource (AID 0, RU 3), the fourth RU resource (AID 2045, RU 4), ​​the fifth RU resource (AID 2045, RU 5), and the sixth RU resource (AID 3, RU 6). Information about AID 0, AID 3, or AID 2045 is included, for example, in the user identification field 1310 in Figure 8. Information about RU 1 to RU 6 is included, for example, in the RU allocation field 1320 in Figure 8. AID=0 indicates a UORA resource for an associated STA, and AID=2045 indicates a UORA resource for an unassociated STA. Accordingly, the first to third RU resources in FIG. 9 are used as UORA resources for associated STAs, the fourth and fifth RU resources in FIG. 9 are used as UORA resources for unassociated STAs, and the sixth RU resource in FIG. 9 is used as a resource for a normal UL MU.

[0095] In the example shown in Figure 9, the OFDMA random access Back Off (OBO) counter of STA1 is decremented to 0, and STA1 randomly selects the second RU resource (AID 0, RU 2). Since the OBO counters of STA2 / 3 are greater than 0, no uplink resources are allocated to STA2 / 3. Also, in Figure 9, STA4 includes its own AID (i.e., AID=3) in the trigger frame, and therefore is allocated resources in 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 still 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 still 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. Furthermore, EHT PPDU is used in EHT systems and / or new wireless LAN systems that are improvements to EHT systems.

[0100] The PPDU in Fig. 10 may represent 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 from which the EHT-SIG is omitted.

[0101] In FIG. 10, L-STF to EHT-LTF can be called preambles or physical preambles, 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 Figure 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 contain, 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 6 Tail bits. For example, the 12-bit Length field may contain information about 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 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 EHT PPDU, the value of the Length field may be determined as a multiple of 3, and for an 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 BCC coding based on a code rate of 1 / 2 to the 24-bit information in the L-SIG field. The transmitting STA then obtains 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 excluding the pilot subcarriers (subcarrier indexes -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 an RL-SIG, which is generated in the same way as the L-SIG. BPSK modulation is applied to the RL-SIG. The receiving STA can determine whether 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 a first SIG field, a first SIG, a first type SIG, a control signal, a control signal field, or a first (type) control signal.

[0108] The U-SIG can contain N bits of information, including information for identifying the type of EHT PPDU. For example, the U-SIG is composed of 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 bits of information. For example, each U-SIG symbol is transmitted and received based on 52 data tones and 4 pilot tones.

[0109] For example, A-bit information (e.g., 52 uncoded bits) is transmitted via the U-SIG (or U-SIG field), with the first symbol of the U-SIG transmitting the first X-bit information (e.g., 26 uncoded bits) of the total A-bit information, and the second symbol of the U-SIG transmitting the remaining Y-bit information (e.g., 26 uncoded bits). For example, the transmitting STA may obtain the 26 uncoded bits included in each U-SIG symbol. The transmitting STA may perform convolutional encoding (i.e., BCC coding) based on a rate of R=½ to generate 52-coded bits and perform interleaving on the 52-coded bits. The transmitting STA may 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 uncoded bits) transmitted by a U-SIG may include a CRC field (e.g., a 4-bit field) and a tail field (e.g., a 6-bit field). The CRC field and tail field are transmitted via the second symbol of the U-SIG. The CRC field is generated based on the 26 bits allocated 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. The tail field is used to terminate the trellis of a 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 can be allocated only to the first symbol of the U-SIG, or the version-independent bits can be allocated to both the first and second symbols of the U-SIG. For example, the version-independent bits and version-dependent bits can be called by various names, such as first control bits and 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 and received PPDU. For example, a first value of the 3-bit PHY version identifier may indicate that the transmitted and received PPDU is an EHT PPDU. In other words, when transmitting an EHT PPDU, the transmitting STA may set the 3-bit PHY version identifier to a first value. In other words, the 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 1-bit UL / DL flag field, where a first value of the 1-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 various 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.), 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 on 1) a bandwidth field containing information about the bandwidth, 2) a field containing information about the MCS technique applied to the EHT-SIG, 3) an indication field containing information related to whether dual subcarrier modulation (DCM) technique is applied to the EHT-SIG, 4) a field containing information about the number of symbols used for the EHT-SIG, 5) a field containing information about whether the EHT-SIG is generated across the entire band, 6) a field containing information about 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 (send / receive / up / down) signals, (send / receive / up / down) frames, (send / receive / up / down) packets, (send / receive / up / down) data units, (send / 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 control frames include a request to send (RTS), clear to send (CTS), Power Save-Poll (PS-Poll), Block ACK Req, Block Ack, Null Data Packet (NDP) announcement, and Trigger frame. For example, the PPDU of FIG. 18 is used for a management frame. Examples of management frames 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 may also be used to simultaneously transmit 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 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 and 121 in Figure 1. Alternatively, the processor 610 in Figure 11 may be the same as the processing chips 114 and 124 in Figure 1.

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

[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 STAs (APs and / or non-AP STAs) in this specification can support multilink (ML) communication. ML communication refers to 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 may be configured 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. Alternatively, 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 5 GHz / 6 GHz band) and at least one channel in the 5 GHz band (or 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 or control frames such as Beacon, Probe Request / Response, and Association Request / Response. For example, information about ML setup is included in the element field included in Beacon, Probe Request / Response, and Association Request / Response.

[0128] Once ML setup is complete, enabled links for ML communication are determined. STAs can perform frame exchange through at least one of the enabled links. For example, an enabled link is used for at least one of management frames, control frames, and data frames.

[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 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] More specific features regarding the ML setup are described below.

[0131] An MLD (AP MLD and / or non-AP MLD) can transmit information about links that the MLD can support through ML setup. The link information can be configured in various ways. For example, the link information 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 / bandwidth / resources of uplink / downlink links supported by the MLD (or STA); 4) information about frame types (e.g., management, control, data) available or preferred for at least one uplink / downlink link; 5) ACK policy information available or preferred for at least one uplink / downlink link; and 6) information about traffic identifiers (TIDs) available or preferred for at least one uplink / downlink link. The TID is related to the priority of traffic data and is represented by eight different values ​​in conventional WLAN standards. That is, eight TID values ​​are defined corresponding to the 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 them 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 TIDs are used for ML communication.

[0133] Through ML setup, multiple links that can be used by the sending MLD and receiving MLD involved in 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 to the link information is required, 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 Figure 1 and / or Figure 11, and the PPDU may be the PPDU in Figure 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] The standard being discussed since 802.11ax, Extremely High Throughput (EHT), takes into account multi-link environments that use 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 description, MLD means multi-link device. An 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 can mean either a physical device or a logical device. In the following, device means MLD.

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

[0139] IEEE 802.11be can support two main types of multi-link operation. 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 refer to links included in multiple frequency bands, or it can refer to multiple links included in one frequency band.

[0140] EHT (11be) considers multi-link technology, where multi-link can include multi-band. In other words, multi-link can refer to links of multiple bands, or multiple multi-links within a single band at the same time. 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 referred to as STR (simultaneous transmit and receive). STAs with STR capability are referred to as STR MLDs (multi-link devices), and STAs without STR capability are referred to as non-STR MLDs.

[0141] For the sake of convenience, the following description will be made assuming that the MLD (or a processor of the MLD) controls at least one STA, but this is not intended to be limiting. As mentioned above, the at least one STA can also transmit and receive signals independently of the MLD.

[0142] According to one embodiment, an AP MLD or a non-AP MLD is configured with a structure having multiple links. In other words, a non-AP MLD can support multiple links. A 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 a single link. This reduces the overhead of frame exchange. It also increases the link utilization efficiency of STAs and reduces power consumption.

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

[0145] Referring to Figure 12, a non-AP MLD is configured with a structure having multiple links. In other words, a non-AP MLD can support multiple links. A non-AP MLD can include multiple STAs. Each of the multiple STAs can have its own link. Although Figure 12 shows an example of a non-AP MLD structure, the AP MLD structure can also be configured in the same way as the example of the non-AP MLD structure shown in Figure 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 Links 1 / 2 / 3 include are exemplary and include 2.4, 5, and 6 GHz.

[0147] In this way, in the case of AP / non-AP MLD that supports multi-link, each AP in AP MLD and each STA in non-AP MLD are connected to their respective links 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. An anchored link and a non-anchored link can be called various names. 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 specifying each link as an anchored link or a non-anchored link. The AP MLD can support one or more of multiple links as anchored links. A non-AP MLD can be used by selecting one or more of its own anchored links from the anchored link list (the 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), while 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 idle periods. Therefore, non-AP MLD must be connected to at least one anchored link to receive beacons and management frames. These one or more anchored links must always be kept enabled. 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 idle periods when the channel / link is not in use. 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. Also, in the following specification, an anchored link reconnection protocol is proposed that takes into account the characteristics of not only normal links but also anchored links used for the purpose of power reduction.

[0153] Embodiments for Link Change and Reconnection

[0154] According to one embodiment, each link between an AP MLD and a non-AP MLD is determined in an association or (re)association process. At this time, the AP MLD and the non-AP MLD can exchange frames via the connected link. A specific embodiment in which the AP MLD and the non-AP MLD are connected via the link setup process is 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, the AP MLD and the non-AP MLD are connected via one link setup process. In other words, the AP MLD and the 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 about 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 (for example, 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 Figure 14, STA2 is currently connected to AP2. After that, the data load on AP2 may become excessive. STA2 is then reconnected to AP3, which has a relatively light data load. In this case, AP MLD and non-AP MLD can efficiently exchange data.

[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 a link change or reconnection, and STA2 is connected to AP3 via link 2 based on the link change or reconnection.

[0165] According to one 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, and exchange various information about the current link and information about the link state. Therefore, the AP MLD and the non-AP MLD can select a more suitable link for transmitting and receiving signals based on the various information about the current link and the link state, and can transmit the above information to support the selection. For example, the various information about the current link can include information about the data traffic load for each link and the channel access capability between links. For example, the link state can be set as disable or enable.

[0166] In the following description, the process in which an AP MLD / non-AP MLD negotiates with a non-AP MLD / AP MLD to request a change or reconnection to a different link than the connected link in order to improve performance is referred to as "link switching negotiation." The term "link switching negotiation" may be variously referred to and is 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 approval or rejection 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 requests it and the case where non-AP MLD requests it.

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

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

[0172] For example, the AP MLD can calculate / confirm / 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 the 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 it considers 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 containing 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 can 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. In other words, the recommend link (element / field) can include AP MLD Link ID information or AP BSS information.

[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 it possesses.

[0177] A specific signal exchange process of AP MLD and non-AP MLD according to the above embodiment will be described with reference to 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 large amount of data traffic may be concentrated on AP2. In other words, when STA2 is connected to AP2 via link2, a large amount of data traffic may be generated 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 requesting reconnection is sent to the STA that wishes to reconnect (i.e., STA2), but depending on the situation (e.g., channel conditions or link status), 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) for reconnection is sent can be changed based on the channel conditions or link status.

[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 (i.e., STA2) approving the reconnection 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 re-establishment request, after sending a response message, STA2 can disconnect from the existing AP2 and request a link re-establishment from AP3. In this case, the re-establishment 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 via 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 its link, if the AP recommends a suitable link, the STA may or may not change its link to the recommended link. For example, the AP uses the above-mentioned recommend link to recommend a suitable link to the STA.

[0186] For example, the STA can approve a link change in a response message to a request message for requesting reconnection to the AP. The STA can approve / confirm a link change to a recommended link, or can 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 whether or not the response message is accepted. To this end, the AP can send a Confirmation message (e.g., a link switching confirmation frame) to the STA in response to the STA's response message (e.g., a Link Switching Response frame).

[0188] The specific operations of AP MLD and non-AP MLD in the above-described 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, AP2 can request STA2 to change a link by including the recommended link information. In other words, AP2 can send a link switching request frame including the recommended link information to STA2.

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

[0192] For example, if link switching is approved, STA2 can send 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 whether or not the link is finally approved. This message may be called a Link Switching Confirmation frame.

[0194] For example, AP2 can approve a link change to the link determined by STA2 via a 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 reject the link change to the link determined by STA2 via the link switching confirmation frame, and STA2 and AP2 can maintain the connection with the existing link without changing the link.

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

[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 Figure 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 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 link switching response frame can be transmitted and received via various links, not just the link to be changed.

[0201] A non-AP MLD can request a link change or reconnection through various methods. Three methods for a non-AP MLD to request a link change or reconnection are proposed below. Specifically, the three methods are the solicited method, the unsolicited method, and the general method, which will be 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 can include information on capability, operation element, and BSS parameters.

[0203] According to one embodiment, the method in which a STA requests information about other APs in the associated AP MLD can be used in various cases, not just when reconfiguring a link. For example, after multi-link setup, a STA can request BSS parameter information from other APs for link switching and select the best link based on the received information. Alternatively, during the discovery process, a STA can request BSS load information for each AP from the AP MLD and select a link for link setup based on the received information. (However, this assumes that the number of APs in the AP MLD is greater than the number of STAs in non-AP MLD.)

[0204] 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, to all APs in the AP MLD. The above examples all apply 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. STAs can utilize the received information in various situations. According to one embodiment, the method in which an AP transmits information about other APs in the AP MLD without a separate information request from the STA is used in various cases, not just when reconfiguring a link. 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 all apply 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 link change or reconnection. 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 transmitted periodically.

[0211] In another example, link-specific capability information may not be included in the beacon frame transmitted periodically as optional information. Alternatively, to reduce frame overhead, only information on the link to which the STA is connected or some related links may be received. Alternatively, 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 AP MLD's link-specific information (e.g., BSS parameter information or operation element information). The link in the link-specific capability information and link-specific information can include not only the link being transmitted or received but also other links. For example, a field in a QoS data frame (A-Control field in 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 can be defined to request / send the latest information.

[0213] According to one embodiment, to request updated information on per-link capability information and per-link AP MLD information, the STA may transmit a request message to the AP requesting information necessary for link reselection. For example, the previously defined Probe Request frame may be reused for the request message. In another example, a new frame may be defined for the request message.

[0214] According to one 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 vary 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, information corresponding to a specific link may include information regarding the BSS load / parameters of the specific link. Furthermore, information corresponding to a capability may include BSS load information for all links or BSS load information for a specific link. In this case, the AP may transmit only the information specified by the STA through a response message. Specific embodiments of specific information requests and responses will be described through embodiments of IOM definitions and operations.

[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 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 (i.e., 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 AP) using the multi-link characteristics.

[0220] Alternatively, the AP MLD can send a "recommend link" element recommending a suitable link for the STA together with a response message containing 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 from 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 full information about another AP, the peer AP responds with an MLD Probe Response frame containing full information about the AP requested by the STA. In this case, the peer AP can respond with full information about the AP in the MLD Probe Response frame as follows:

[0223] 1-1) When a STA requests full information from other APs, the full information of the peer AP is mandatory in the MLD Probe Response.

[0224] This method also includes the overall information of the peer AP when a STA requests overall information of other APs in the same AP MLD excluding the peer AP. Currently, 802.11be uses an inheritance model to reduce the overhead of MLD probe responses. Therefore, when a STA requests 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 an AP MLD responds to a request for overall information for a specific AP and includes peer AP information, values ​​that are common within the same MLD are included in the Common info in the ML IE, and information that differs for each AP can be included as a non-inheritance element in the Per-STA Profile in the ML IE and different information for each AP. When a STA requests overall information for multiple other APs, the overhead of the overall MLD probe response frame can be reduced by configuring the same 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 information not requested from the peer AP will be included. However, if the STA requests information from multiple other APs, 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 full information about other APs, the MLD Probe Response does not include the full information of the peer AP as a mandatory requirement (i.e., the MLD Probe Response includes only the full information of the requested other AP and sends it).

[0226] In this method, when a STA requests full information about other APs from a peer AP, it sends only full information about the requested AP in the MLD Probe Response. This method can reduce overhead by applying the inheritance model when the STA also requests information about the peer AP. However, if the STA requests only information about other APs in the same AP MLD, excluding information about the peer AP, the inheritance model cannot be applied. Therefore, if information about the peer AP is not included, the inheritance model is not applied, which may result in a slight increase in overhead. However, if the STA requests full information only for a specific AP rather than multiple APs, the overhead may actually be reduced because unnecessary peer AP information is not included. The method of responding by including only information about the AP requested by the STA is somewhat simpler than the first mandatory method, but the first mandatory method using the inheritance model becomes more efficient as the number of other APs in the same AP MLD from which the STA requests full information increases.

[0227] 1-3) How to configure the peer AP to send all information to 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 (a method in which peer AP information is included as a mandatory part in the response if the STA does not request information about the peer AP) and the second case (a method in which peer AP information is not included as a mandatory part in the response if the STA does not request information about the peer AP) depending on the configuration of the MLD Probe Response frame related to the AP's Common info information requested by the STA, and then configures and sends the MLD Probe Response that is more efficient. In other words, the efficiency of applying the Inheritance model is compared depending on the AP information requested by the STA, and a format with less overhead is configured and sent in response. However, the criteria for determining the efficiency of this method when comparing the two cases can be determined by the AP implementation.

[0229] The above-described methods for multiple options are for when a STA requests full information from other APs, and may not be applicable when a STA requests partial information from other APs because they request information for specific IEs. However, if a STA requests full information from some APs and partial information from 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 solicited method described above can be used by non-AP MLD STAs to change or reconnect links. For example, if a non-AP MLD STA wishes 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 include the link and information specified by the STA in a response message and send it.

[0231] Hereinafter, the above-mentioned request message and response message will be referred to 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] Upon receiving the request message, the AP MLD can send an "Accept" response message if it approves the request, or a "Decline" response message 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] A specific example of the operation of AP MLD and non-AP MLD according 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 the non-AP MLD wants to reselect the connected link, STA2 can send an Info request message to the AP MLD via Link 2. Upon receiving this, the AP MLD can send an Info response message including information necessary for the non-AP MLD link reselection. Based on the information included in the above-mentioned Info response message, STA2 of the non-AP MLD can send a request message for link change (i.e., link switching request frame) to AP2 of the AP MLD. Thereafter, STA2 receives the response message for link change (i.e., link switching request frame) and can perform link(re)setup for the link change.

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

[0239] A specific example of the 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 (such as BSS load information) of the AP MLD, or AP2 may transmit only information regarding whether the other AP information has been updated (such as version / update version).

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

[0244] Furthermore, the above-mentioned solicited method can be used by a STA to obtain information about APs held by the AP MLD even before multi-link setup. In the multi-link setup process for non-AP MLD and AP MLD, if the number of APs held by the AP MLD is greater than the number of STAs held by the non-AP MLD, the non-AP MLD STA must decide whether to set up a link with the AP with the AP MLD. In this case, the non-AP MLD STA can request specific link-specific information (e.g., BSS load information of the AP held by the AP MLD) from the AP with the AP MLD to understand the status of each link before multi-link setup. For 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 requesting a specific element (e.g., a Request element, Extended Request element, or PV1 Probe Response Option element) and an indicator indicating specific link information (e.g., a Link ID).

[0245] For example, a STA in a non-AP MLD can send a request message including instructions requesting the 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 for 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 also use the solicited method described above 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 about 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, the STA ratio per Link (element / field) may include information about 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 three links, 10 STAs are connected to Link 1 and 20 STAs are connected to Link 2. The AP MLD can transmit information about the STAs connected to each link via the STA ratio per Link (element / field) as a value or percentage to the non-AP MLD.

[0252] For example, if information about 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, if the information for the STAs connected to each link is expressed as a ratio, Link1 can be expressed / set as 20 (10 / 50)% and Link2 can be expressed 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 example is merely an example, and information for STAs connected to each link can be set in various ways. In addition to the above example, information for STAs connected to each link can be set as a relative value.

[0255] Based on the information on the STAs connected to each link described above, the STA can check / 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 other than the above-mentioned "ratio per Link" (element / field) are included in the information response message. 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 per 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] After receiving the information in the above example, the STA can select an AP to change or reconnect to based on the received information and then send a request message to request reconnection of the link. If the AP MLD that received the request message accepts the request, it can send an "Accept" response message. If the AP MLD rejects the request, it can send a "Decline" response message.

[0266] If the request is accepted, the AP can exchange frames with the reselected AP via the link after sending the response message. Conversely, 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, the Unsolicited method allows the AP MLD to transmit additional information to the non-AP MLD via a Beacon frame or a separate frame (e.g., a QoS data frame field (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) 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 for link switching or may not be up-to-date. Therefore, the AP can send a frame containing AP MLD link capability information to the non-AP MLD. Then, the non-AP STA can obtain the latest information on the capability of each link in the AP MLD. The frame can be sent periodically or aperiodically.

[0270] For example, if the frame is transmitted periodically, the AP may transmit the frame at a fixed time interval to share the latest information of the AP. 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 μs. As another example, a period agreed upon by the AP and STA through capability negotiation is used. For example, the transmission period can be indicated by the values ​​of the 'periodic' field and '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 AP MLD changes, the changed information is transmitted to the connected STA. In this case, the STA can 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 link capability, there is an advantage 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 advantage 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 described 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, AP MLD can transmit essential information required for link reselection to non-AP in a separate frame (e.g., PS-Poll frame or Null frame) without a separate request message from non-AP MLD.

[0276] According to one embodiment, unlike Fig. 22, the AP MLD can transmit information on link capability to the STA via a field in a DL frame (e.g., QoS data frame) that it transmits to the non-AP MLD without a separate request message from the non-AP MLD. The operations of the AP MLD and non-AP MLD according to the above embodiment are 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 other APs (or information about other APs) to STA2 based on a DL frame (i.e., DL1). That is, the DL frame can include information about other APs. For example, information about other APs 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, frame overhead can be reduced. 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, the non-AP MLD can acquire the latest link capability information regardless of the beacon frame period. Based on the received information, the non-AP MLD can select an appropriate link during link switching. Based on the received information, the STA can reselect an appropriate link and request the AP MLD to change or reconnect the link. The request message can include information about the AP and link to which the STA will reconnect. In addition, the AP MLD that receives this message 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 on 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.

[0299] 3)General method

[0300] According to the general method, a non-AP MLD can request a link change or reconnection based on its current information without requesting additional information. The information used at this time can include AP MLD information and non-AP MLD information (e.g., per-link STR capability information, 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 additional information from the AP MLD. The request message can include AP information and link information to which the STA will reconnect. The AP MLD that receives the request message can send an "Accept" response message if it accepts the request, or a "Decline" response message if it rejects it.

[0302] If the request is accepted, the AP can exchange frames 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] A specific example of 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 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 which it wants to reconnect, STA2 can request a link change or reconnection without requesting additional information.

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

[0307] Signaling for indicating link changes and reconnection methods

[0308] To implement 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 proposed method is proposed below.

[0309] First, a new element is proposed to indicate the proposed method. Hereinafter, an embodiment related to signaling for indicating a link change and reconnection method will be described, but the above embodiment also applies 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 reconnection method is performed during or after multi-link setup. Furthermore, new elements proposed below can be used in the signaling process for indicating a link change and 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 about whether to enable the method of obtaining additional information for multiple links. For example, in a process (e.g., a capability negotiation process) in which AP MLD and non-AP MLD exchange messages for operational agreement in a multi-link setup process, the IOM capability value may be present in the message element. The presence of the IOM capability value in the message element means that the IOM capability is supported.

[0313] According to one embodiment, if an AP MLD supports the IOM capability, the AP may internally share information about other APs and have information about other APs. An MLD that does not share information about other APs 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 activates the IOM to operate with the indicated function. Conversely, when the value of the IOM capability element is set to a second value (e.g., 0), the IOM capability element deactivates the IOM.

[0315] According to one 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. For example, among the fields / elements added to the IOM capability element, fields / elements containing information that does not need to be indicated may be omitted.

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

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

[0318] The Method type field / element (hereinafter referred to as the Method field / element) can contain 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 the IOM method to obtain information from the AP, the Non-AP MLD can select and indicate the method to be used from the proposed methods (e.g., the Solicited method, the Unsolicited method, and the General method).

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

[0320] As another example, 1 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 which case, the use of each method can be specified as either single or multiple.

[0322] Link range field / element

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

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

[0325] In this case, if the value of the link range field / element is the first value (e.g., 0), it is a request for all links within 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 the second value (e.g., 1), it is a request for information on some links within the AP MLD, so link indicator information is required. For example, this field can be included in and used as the multi-link element defined in 802.11be. The currently defined multi-link element is shown in Figure 25.

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

[0327] As shown in Figure 25, when a non-AP MLD sends a request message to request information from an AP MLD, a 'Range' field can be added to the Multi-link element and used, as shown in Figure 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 this field is 0, it indicates a request for information on all links, so additional link indicator information is not required and the 'Per-STA Profile(x)' sub-element can be omitted.

[0330] This field is not included in the multi-link element defined in 802.11be, but is added to a separate element for use, as shown in Figure 27.

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

[0332] As shown in Figure 27, multiple fields proposed in this specification can be used together to indicate the range and conditions of information that a STA requests from AP MLD in an integrated form as shown in Figure 27. Alternatively, when a STA requests information from AP MLD, it can include each proposed field independently in the request message, and can also omit it if unnecessary.

[0333] Info range field / element

[0334] The Info range field can be used to indicate the range of information when 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. 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 (Info range) field can be defined to indicate a request for all or part of the information (elements) held by the AP, and 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 may be defined / set as an all / partial subfield.

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

[0338] For example, a subfield for indicating whether all information is provided or whether only changed information among all the information is provided can be defined / set as an 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 the STA requests information, the AP (or AP MLD) can transmit only changed information (i.e., updated information) among 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-described embodiment, the range of information that a STA can request can be set to updated information or all information. In this case, a STA that does not want a large frame overhead can request to receive only changed information. Therefore, 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 contain information about the specific link to be requested. The link condition field can be used when the STA wants only specific link information to be provided by the AP.

[0344] The link condition field can be represented 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 identify the link for which information is to be acquired.

[0345] For example, if a STA connected to Link1 wishes to request only information on Link2 and Link3 from the AP, the STA can request information on Link2 and Link3 from the AP by indicating Link2 and Link3 in the link condition field. For example, if the value of the above-mentioned Info range field is 1, all information corresponding to Link2 and Link3 is transmitted. As another example, if the value of the above-mentioned Info range field is 0, some information specified by the STA for Link2 and Link3 is transmitted. According to one embodiment, the part of information specified 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 can determine that there is no link condition. Therefore, the AP can 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 Info Condition field can be used only if the Info Range field is set to 0. As another example, the Info 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 within the bit can be set in various ways.

[0351] According to one embodiment, the information condition field can be used together with the link condition field described above. According to one embodiment, the information condition field can transmit request information of various conditions to the STA (or AP) based on various field / element combinations.

[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 shown in Figures 28 and 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 a STA specifies a list of information for which it wishes to receive a response in the Requested Element IDs field, the AP transmits the corresponding information in a Probe Response frame or an Information Response frame. Therefore, this element can be reused in this specification as an indicator for requesting specific information, and can also be used together with a link identifier (e.g., Link Identifier) ​​to request information on a desired link. 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 in various combinations with Link Identifier information to indicate specific information of a specific AP. If a new frame is defined in the present invention to request information that is not an existing frame, the Request element and Extended Request element in FIGS. 28 and 29 can be reused.

[0356] In addition, existing standards provide a PV1 Probe Response Option element to request specific information, and this 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 shown below. However, in the case of 802.11be, since multi-link information needs to be provided in consideration of MLD, the STA can request specific information for specific links in various combinations using a Link Identifier along with the bitmap indicator shown below. However, in this case, since there may be newly defined optional information (e.g., STR Capability) along with multi-link in 802.11be, if this PV1 Probe Response Option element is reused, a new or additional bitmap must be defined for information that is newly defined or needs to be acquired in 802.11be.

[0357] Figure 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 periodicity field whether it will receive messages containing the information periodically or aperiodically.

[0360] For example, if the STA wants 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 containing the information at a periodic interval set by the STA.

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

[0363] Transmission interval field / element

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

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

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

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

[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 examples of the operation of AP MLD and non-AP MLD when the IOM capability is activated. For example, a non-AP MLD can request additional information for multiple links by sending the above-mentioned field / element to an AP MLD. A non-AP MLD can send an IOM capability element including the above-mentioned field / element to an AP MLD. The inclusion of the above-mentioned field / element in the IOM capability element is exemplary and is sent as an independent field / element.

[0370] For example, during 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 multi-link setup, the non-AP MLD operates using the Solicited method, and when requesting information, it can request information for multiple links (e.g., information about other APs) including all information included in the beacon. Therefore, the AP MLD can provide / send information about a link in a response message only when it receives a request message from a STA. When the AP MLD receives a request message, it can send a response message to the STA including information about all links in the AP MLD. The information about all links in the AP MLD can include all information included in the beacon.

[0371] As another example, the 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 the AP MLD and agree on this with the AP MLD. In this case, after multi-link setup, the non-AP MLD can operate in the UnSolicited method. Therefore, the AP can send Link 2 BSS load information to the STA via a separate message without a separate request message.

[0372] As another example, the 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 the AP MLD and agree on this with the AP MLD. In this case, the non-AP MLD can operate in the Solicited method after multi-link setup. Therefore, when a STA requests information, the 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 a response message to the STA.

[0373] This specification proposes several options for a new element for a STA to request some information (i.e., target information) from 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 (ie, 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 a STA transmits a Probe request frame including the above-mentioned MLD Request element, the AP that receives the request message will respond with a Probe Response that includes all the information of the AP specified in the element. If the STA wants to request partial information but not all the information of the specified AP, it can transmit a Probe request frame including a Request element or Extended Request element defined in an existing standard along with the MLD Request element, and the AP that receives this will respond with a Probe Response that includes only the information specified in the Request element or Extended Request element.

[0378] Furthermore, we also propose a 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 (ie, links) to be 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). This field contains only the element ID information if the Element ID is 0-254, but if it is a value of 255 or higher, it must be recognized as an Extended Element ID and must also contain Requested element ID extensions information. 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 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 defining a new element based on the MLD Request element.

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

[0385] 33, the AP recognizes the information requested by the STA as all or part of the information depending on whether the "Requested element IDs / Requested element ID extensions" field in the element is omitted. Element ID value information defined in the standard 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 from 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 require different information for different links in some cases, and several options for this purpose are proposed herein.

[0390] First, we 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 and / or 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 replies by including it in a Response frame.

[0394] In this case, if 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 can be omitted as necessary.

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

[0396] Second, when an STA requests information, a format is proposed as shown in FIG. 36, which distinguishes between common information that is requested in the same way 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 indicated later, and the information arranged after the number of Elements along 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, if 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 can 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 along 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 the same information as shown in FIG. 38 as a separate Request element or an Extended Request element along with the MLD Request element.

[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 information requested differently for each link is specified via the MLD Request element. The MLD Request element format is defined in multiple ways. 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 in a response message. Furthermore, if the 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] 802.11be defines the ML IE (Multi-Link Information Element) as shown in Figure 39 to define information for each link. Subsequently, elements or fields are added depending on the proposed functions. The Per-STA Profile(x) sub-element can contain multiple pieces of information for the link. The sub-element contains the link ID and the information range contained in the sub-element via the Per-STA Control field, and then lists the information (elements) corresponding 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. The 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 (e.g., a Probe request frame), a STA can utilize it to request partial information from other APs, and various options are proposed for this purpose.

[0409] This specification defines the following constraints for using the ML IE for MLD probing. When a STA uses the 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) can be omitted and transmitted to reduce overhead. (However, when the ML IE is used in an association request / response frame used for association, Element information must be included.) If the information requested by the STA is complete information for a link, the STA indicates a complete information bit via the per-STA control field and then omits the element information list before transmitting. Otherwise, the STA indicates a partial information bit via the per-STA control field and then adds information for the requested element ID. However, several options for when a STA requests partial information for a specific element rather than the entire information are defined in detail below.

[0410] As mentioned above, the ML IE defined in 802.11be changes its information 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 to request a probe, an element containing multiple pieces of information in the Per-STA Profile(X) is omitted, but otherwise, the element information must be included. Therefore, a control field is proposed to indicate this.

[0411] The multi-link element and multi-link control field format currently defined in the 802.11be standard are 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] In this case, 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 per-STA element list information requested by the current ML IE. If the value is 1, it means that element information is included after the Per-STA Control field in the Per-STA Profile(x) field, and if the 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 explained above, the ML IE defined in 802.11be changes its information 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. This field is included in the ML IE of a request / response frame and indicates the frame type currently being transmitted by the STA. Depending on this, the contents and arrangement of further configured elements (elements configured as 0 or variable) may differ.

[0416] 'Frame type': An indicator of the frame type currently being transmitted by the STA. The value of this field indicates the type of frame currently containing the ML IE. For example, it can be indicated as 0: Association request, 1: Association response, 3: Probe request, 4: Probe Response, etc. This can be indicated as an integer value or as a bitmap. In addition, if MLD Probing configured in 802.11be is divided, further values ​​such as 5: MLD Probe request frame and 6: MLD Probe Response frame can be added. In this way, this is an indicator 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 within the 'Frame type' field, and when the value is 1, it indicates the indicated frame type.

[0417] In this case, the frame to be transmitted can be further classified into multiple subfields within the "Frame type" depending on the multiple functions of the frame. Therefore, this specification defines a "request type," which is a subfield within the "Frame type" that further classifies the purpose of the frame. The "request type" subfield further classifies the message type classified by the "Frame type," and is classified according to the purpose of the currently transmitted frame. For example, if the "Frame type" transmits an MLD Probe request frame to request all or part of information about a specific AP, the "Frame type" field is set to MLD Probe request frame (field = 5). The "request type" can further classify whether the requested information is all or part, and if partial information is requested, whether the information requests specific information (e.g., information related to a critical update, information on link subsets that are 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 a (re)Association request frame (for reference, currently in 802.11be, all frames except for 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), but the 'request type' subfield can be specified 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 understand the purpose of the frame sent by the STA in more detail through the value of the subfield transmitted along with the type of the currently received frame, and can then include appropriate information in the Response frame and send it.

[0418] When an 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] First, a Request element or / and Extended Request element for indicating the information that the STA wishes to request from the AP is included in the Per-STA Profile(x) in the existing ML IE and transmitted.

[0420] The AP that receives the request message specifying the relevant information determines the partial link information 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 Figure 42. If the Request element or / and Extended Request element is omitted, it means that all information (i.e., complete information) of the AP is requested. However, as suggested 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 in the Per-STA Profile(x) in the existing ML IE and transmit it to indicate the information that the STA is requesting from the AP. This field is defined in Figure 43 as a proposed field in this specification.

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

[0424] Upon receiving this information, the AP determines the partial link information 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 it wishes to request 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 it wishes to request through the Requested element IDs / Requested element ID extensions field. Omitting the Requested element IDs / Requested element ID extensions field means that all information of the AP (i.e., all element 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 (element ID, length, etc.).

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

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

[0428] When a STA requests information from each AP through a request frame (e.g., Probe request frame), it can request the same information for some information, or it can request different information for each AP for other information. A format for indicating this is defined and an embodiment is proposed. As shown in Figure 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 along 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 listed after the Per-STA Control field can be omitted if necessary.

[0429] For example, if a STA sends a Probe request frame by indicating information corresponding to the TIM element (e.g., Element5=11) in the Request element, specifying Link ID=1 and Complete Profile=0 in the Per-STA Control of Per-STA Profile(x) in the ML IE (conversely, a value of 1 indicates a request for all elements information), indicating information corresponding to the BSS load element (e.g., Element ID=11) in the Request element, specifying Link ID=2 and Complete Profile=0 in the Per-STA Control of Per-STA Profile(y), and indicating information corresponding to the non-inheritance element (e.g., Element ID=255, Element IDextension=56) in the Extended Request element, 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 Link 1

[0432] -Non-inheritance element information for Link2

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

[0434] In this way, 802.11be allows the inheritance model to be applied to ML Probe request frames. As described above, when a STA transmits an ML Probe request including an (Extended) Request element, the inheritance model is applied to not only the peer AP but also the AP requested via the ML IE (i.e., Probe request variant Multi-Link element), and the peer AP accepts it as a 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 a STA as shown in FIG. 44, it is analyzed as a request for common information for the peer AP and requested APs (i.e., APs indicated for the Other AP information request in the ML IE), and the requested information indicated in the (Extended) Request element in the ML Probe Response can be confirmed, and the information corresponding to each AP in the ML IE (i.e., basic variant Multi-Link element) can be included in the Per-STA Profile to respond.

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

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

[0437] When a STA requests information about each AP through a request frame (e.g., a Probe request frame), it can request the same information for some of the information, or it can 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., a Probe request), this means that the STA requests partial information from the link to which it is connected (i.e., its associated AP). If the STA requests information about an AP in the AP MLD to which it is connected that is not its own link, the corresponding indication information 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 the commonly requested information for Other APs in the AP MLD requested by the STA (APs in the AP MLD to which the STA is connected that are not its own link) through this element. Commonly requested information from other APs is indicated via a Request or / and Extended Request element in the ML IE, and different requested information for each other AP can be indicated by considering a 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 other than another AP in the Per-STA Profile(x), the STA can also obtain information about 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 can be omitted to request partial information about the AP corresponding to its own link.

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

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

[0440] 1) When requesting overall information from a peer AP and then requesting overall information from other APs

[0441] An EHT non-AP STA can send 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 Figure 46, when requesting full 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., the Probe request variant Multi-Link element) is set to 1 to indicate a request for full 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 other APs designated via the ML IE.

[0447] FIG. 47 shows another example of a probe request frame including an 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 other APs, 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 other APs. In this case, if full information is to be requested from other APs, 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 can be made for each other AP 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 Figure 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 Other APs, 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 the Multi-Link element (i.e., Probe request variant Multi-Link element) to indicate a request for complete information from Other APs.

[0453] In this case, if partial information is to be requested from other APs, an (Extended) Request element is included in the Per-STA Profile and the "Complete Profile" subfield in the "Per-STA Control" field is set to 0. In this case, if an inheritance model is applied to the MLD Probe request, the (Extended) Request element in Per-STA Profile(x) can be omitted if the partial information requested from the Peer AP and AP(x) (i.e., Link) indicated in Per-STA Profile(x) is the same. In other words, the (Extended) Request element is included in 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 otherwise.

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

[0455] FIG. 49 shows another example of a probe request frame including an 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. At this time, when requesting partial information different from the peer AP for some APs (i.e., Per-STA Profile(x)) among the APs indicated in the Multi-Link element, it can request different information by including an (Extended) Request element corresponding to a non-inheritance element in Per-STA Profile(x). At this time, the value of Complete Profile in the Per-STA Control field is set to 0.

[0457] Alternatively, when requesting the same partial information as the Peer AP from some of the APs (i.e., Per-STA Profile(y)) among the APs specified in the Multi-Link element, the (Extended) Request element is omitted from Per-STA Profile(y). In this case, the value of 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 from the Peer AP and AP(x) is the same (e.g., Element(a)), but since it also contains other information (e.g., Element(c)), the AP must include an (Extended) Request element in 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), it will recognize this as a non-inheritance element even if there is partial information requested that overlaps with that of the Peer AP. Therefore, unless the AP 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 from 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 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 that indicates 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 requested information of the Peer AP, but rather that the complete information is requested from AP(y). In other words, in order to apply the inheritance model to the Multi-Link element for the partial information requested 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 requested information as common or link specific according to the arrangement of elements within 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 common information for the corresponding link by arranging a Request element or / and an Extended Request element. This means that a Request element or / and an Extended Request element may exist before the per-STA Profile(x) in the ML IE in the request frame depending on whether common information is requested. Therefore, a control field to indicate this is proposed as shown in Figure 50.

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

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

[0463] The embodiment for this is as follows.

[0464] An STA can also make a partial request for critical update information only to APs in the AP MLD. Two options are proposed for this. In this case, AP refers to all APs (reporting AP and reported AP) that the STA can acquire through beacons. Reported AP refers to other APs that the STA can acquire through the RNR element of a beacon, and includes 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 whose CSN (Change Sequence Number) information it can acquire through beacons. (For reference, 802.11be agreed to include the Change Sequence field information of other APs 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 together with the link indicator to request system information defined as a critical update of a specific link.

[0467] When a STA requests AP MLD information for other APs, it sends a Request frame (e.g., Probe request frame) with the link indicator information and the corresponding field set to 1. The AP then responds by including critical update information for the specified link in a Response frame. Critical update information refers to multiple system information items defined as critical updates in the system information update procedure of the existing 802.11 standard: (a) Inclusion of an Extended Channel Switch Announcement, (b) Modification of the EDCA parameters, and (c) Modification of the S1G Operation element. Note that 802.11be allows additional information to be defined for critical updates in addition to the system information already defined. The critical update information referred to in this specification refers to information including the newly defined critical update information in 802.11be. If the corresponding field is set to 0, the AP responds with a Response frame using the existing operation. The proposed field can be included in an element within the Request frame and is used by including it in the MLD Request element or ML IE mentioned above. An embodiment of 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] 51, when a STA requests information for a specific link using the ML IE in a Probe request, it can request information corresponding to the specific link via Per-STA Profile(x). In this case, if the newly defined 'Critical update request' field is included in the Per-STA Control in Per-STA Profile(x) and set to 1, the AP responds with a Response frame including current system information defined as a Critical update for the link indicated in Per-STA Profile(x). In this case, when a non-AP STA in non-AP MLD sets the value of the 'Critical update request' field to 1 to request Critical update information via an MLD Probe request, it can also include and transmit Change Sequence Number (CSN) information (e.g., Change sequence element, Change Sequence field, etc.) for each non-AP STA in the non-AP MLD, or it can 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 the AP (i.e., 'Critical update request' field = 1), if a Change sequence element is used to include CSN information, no additional indicator is required (because the AP can check the element ID of the Change sequence element to confirm 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 adding 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: This field indicates the presence of a Change Sequence field. If the value is set to 1, it indicates that the Change Sequence field is present, and if 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 an AP advertises the CSN information of an AP (including the reporting AP and the reported AP) via a Beacon / Probe Response. If a Change sequence element is used to advertise the CSN information, this field is not required. However, if a Change Sequence field is used, a 'CSN Presence' (sub)field indicating the presence of the field is required. In this case, this (sub)field is included depending on the location of the CSN information of each AP. 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), etc. (i.e., AP(x), (y), etc.) and requests critical update information for STA(x) 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, 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 in Per-STA Profile(x) with the "Critical update request" field set to 1 and its own CSN information (i.e., the most recently received CSN information included in the Change sequence element or Change Sequence field).

[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 to track update information for each AP CSN, it is not possible to know which information has been updated for each CSN version. Therefore, it is possible to 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.

[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 is received from a non-AP STA with the 'Critical update request' field set to 1 in Per-STA Profile(x), it may 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, when requesting critical update information in order to reduce the overhead of MLD probe responses, 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 from a non-AP STA with the 'Critical update request' field set to 1 in Per-STA Profile(x) 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 that uses a Change sequence element when requesting Critical update information.

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

[0483] For example, when 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 in some cases. However, in this case, the information included in the MLD Probe Response sent by the AP 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 Figure 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 by the Per-STA Profile(x). If the Critical update request field is included in the position including common information in the ML IE and the field value is set to 1 when 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 Change sequence element is included in a Probe request frame and sent, the AP sends a Compressed Probe Response frame containing only the changed critical update information for the link. 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 this transmits a Probe Response including only the changed Critical update information for the indicated link. 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 a Change sequence element is included in the ML IE format.

[0489] For example, when transmitting a Change sequence element in the ML IE 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. If there are any changes, 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 must include Change Sequence information for all links for which information is requested in the ML IE. Therefore, when using an existing Change sequence element, additional requested link indicator information may be required. Furthermore, this specification considers an option for transmitting all information related to the Critical update currently held by the AP when transmitting a Change sequence element in the ML IE as described above. If the AP compares the Change Sequence field value transmitted by the STA with the field currently held by the AP and finds differences, it transmits all information related to the Critical update currently held by the AP to the STA. Although this method increases the overhead of the information transmitted by the AP, it is easier to implement because it does not require storing change information for each Critical update version for each AP.

[0490] Furthermore, this specification also 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] The corresponding embodiment is shown in FIGS.

[0493] Figure 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 Figure 56, the MLD Change Sequence value can be displayed by repeating the Change Sequence value for each link, or as shown in Figure 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 shown in FIG.

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

[0498] When the MLD Change sequence element is included in the ML IE in the Probe request frame and transmitted as shown in Figure 58, the AP compares the Change Sequence value received for each link with its own Change Sequence value, and can 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 require 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 Figure 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, as 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 the ML IE of a Probe request, it means a request for changed Critical update information for 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 using a 1-bit indicator as described above, if the AP that receives this does not know the version of the 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 send a response message containing all critical update information for the requested link. The response frame can also include a Change sequence element along with the critical update information and send it. While this is a somewhat simple method, there is a possibility that information already held by the STA may be transmitted in duplicate, so a format to reduce this overhead is proposed. An embodiment of this method is as follows.

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

[0508] 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 element) indicating version information of the critical update currently held by the STA. In this case, the Change Sequence fields refer to an indicator indicating a link-specific Change Sequence value. In 802.11be, the STA can periodically receive a Change Sequence value for the AP of the connected AP MLD via a beacon or a probe response, and since the STA is defined to store this value, the STA recognizes the link-specific Change Sequence value information it currently receives. Therefore, the Change Sequence fields defined in this specification refer 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 via a beacon or a probe response.

[0509] In this case, if the value of the "Critical update request" field is 1, it means that the STA requests critical update information; otherwise, it indicates a value of 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 in the transmission. 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 receiving this can add and transmit only the information that has changed compared to its current information (i.e., only the changed information that the STA needs to update) in a response message; and if the value of the "Critical update request" field is 0, the Change Sequence fields (or Change sequence element) are omitted in the transmission to reduce overhead. Furthermore, in this specification, when the Change Sequence fields are included in the ML IE and transmitted as described above, an option is also considered in which all information related to the critical update currently held by the AP is included in the transmission. 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 may 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 separately depending on the value of the 'Critical update request' field. However, the value of the 'Critical update request' field and the Change Sequence field (or Change sequence element) may also be defined and used independently according to options. In this case, if the request message sent by the STA does not include the Change Sequence fields field (or Change sequence element) along with the 'Critical update request' field with a value of 1, the AP that receives this may assume that the STA wishes 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 the changed information in the Response frame. In this case, this section provides the Change Sequence fields field as an example to transmit the Change Sequence information of the link, but the STA may also request a Change sequence element other than the Change Sequence fields field. However, since the use of the Change sequence element has already been mentioned in the above section, an embodiment using the Change sequence element together with the "Critical update request" field is omitted in this section.

[0511] For example, when an 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 the Per-STA Control field, and a Change Sequence fields field having the Critical update information of the current STA can be located in Per-STA Profile(x). At this time, the Critical update request field can also be located together with the Change Sequence fields in Per-STA Profile(x) rather than 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] Upon receiving a Request frame such as that shown in Figure 62, the AP reports the ML IE information in the Request Frame and transmits a response message including the Critical update information for the specific link requested by the STA. At this time, if the Critical update request field is present 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 with the current Change Sequence information for the link (X) requested by the STA via the Change Sequence fields information received at the same time. 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 information level, not the link specific level, in the ML IE, and critical update information can be requested 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 Figure 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, 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 of its links, not a specific link, and compares the Change Sequence field information sent by the STA with the current Change Sequence information for all of its links. If there are any updated items (i.e., if there are any 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 any 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] In this case, the STA may place a Critical update request field in the Multi-link Control field as shown in FIG. 64 to request Critical update information for the changed link.

[0520] In addition to the method in which a STA requests critical update change information from a specific AP, this specification proposes an additional response behavior for the AP. The current 802.11ax standard already defines a rule that when a 6 GHz AP receives a probe request and transmits a probe response frame, if the AP does not specify the actual SSID in the SSID element of its own beacon frame, it sets the Address 1 field to the broadcast address. Based on this, the 802.11be standard discusses a method in which, when an AP receives an MLD probe request frame requesting complete information from an AP operating in the 2.4 GHz band or 5 GHz band and responds with an MLD probe response frame, if the AP does not specify the actual SSID in the SSID element of its own beacon frame, it sets the Address 1 field to the broadcast address.

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

[0522] Also, as described above, depending on the implementation of AP MLD, AP MLD may implement a method for storing which information (i.e., IEs) has been updated for each AP's CSN (Change Sequence Number, each time a critical update occurs), but may not be implemented depending on memory size. If this method is supported, the AP needs to remember which IE information has been updated each time its CSN changes. For example, if a critical update event occurs for Element X when the AP has CSN n=1 and updates for Elements Y and Z occur at CSN n=1, the AP needs to maintain information on which information has been changed at CSN n=1 and CSN n+1. If the AP could track which IEs have been changed for each CSN in this way, when a STA sends a Request frame containing its currently stored CSN information, it can compare it with the AP's current CSN value, rather than the entire information, and send only the changed information in the Response frame, which is convenient in terms of overhead. However, this tracking may not be simple and requires additional memory from the AP, so this capability may or may not be supported depending on the AP's implementation specifications. Therefore, the present invention proposes a capability to indicate the AP's ability to track update information for each 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, an STA can check whether the AP (or STA) supports this feature and use it to request critical update information from a specific AP (or STA). This feature 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 this in the multi-link setup process.

[0527] If AP MLD supports critical update tracking, a non-AP MLD STA can include CSN (Change Sequence Number) information in the Probe request frame when requesting only partial information related to a critical update. The AP that receives this can compare the current AP CSN with the CSN information received from the STA and send a Probe Response frame that includes 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 include CSN information in the Probe request frame and send it. The AP that receives this can send a Probe Response frame that includes element information related to all critical updates corresponding to the CSN of the current AP (or, if there is no other instruction, all information about the requested AP (i.e., Complete Profile)). However, even in this case, when the STA requests partial information related to a critical update, it can also send it by including CSN information in the Probe request frame. However, since the AP that receives this cannot track update information by CSN, it can send a Probe Response frame that includes element information related to all critical updates corresponding to the CSN of the current AP (or, if there is no other instruction, all information about the requested AP (i.e., Complete Profile)).

[0529] In this way, by defining the "Critical update Tracking Support" field in the MLD, if the non-AP MLD knows whether the AP MLD supports tracking of update information by CSN, it can conveniently decide whether 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 via the signaling method proposed herein during or after the multi-link setup process. AP MLD and non-AP MLD can also limit the range and type of information they request via the values ​​of various fields in the IOM capability element.

[0531] According to one embodiment, IOM operation can be performed after precise operation negotiation between MLDs through the above-mentioned IOM signaling method, but IOM operation can also be performed in MLD implementation without a separate signaling process, which means that IOM operation can be performed by AP MLD implementation or 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 if MLD performs IOM operation without a separate signaling exchange, the following restrictions may occur.

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

[0534] 2) Restrictions on the Unsolicited Method: The AP can determine which STAs require additional link information and provide them with a separate message (e.g., 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 will be simplified, but there is a problem that the above-mentioned restrictions may occur.

[0536] According to one embodiment, a method for requesting information about multiple links can be configured based on the agreement between AP MLD and non-AP MLD performed using the IOM capability element described above. In contrast, in the case of the Solicited method, a STA may request specific information that is not part of the agreed-upon content and temporarily acquire that information. In this case, when a STA dynamically sends a request message, it can include the requested content (e.g., IOM capability information) in the request.

[0537] For example, AP MLD and non-AP MLD may agree upon each other during or after multi-link setup, and the STA may provide information from the AP based on the agreed content. However, there may be cases where the STA temporarily requests information about a specific AP or specific parameter information of the AP. In this case, when requesting information, the STA may transmit an "IOM capability" element in a request frame (e.g., a probe request frame, a (re)association frame, or a new frame) including instructions for the information it wishes to obtain. Based on the request frame, the AP may transmit / provide a response message to the STA including the information it wishes to obtain. 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 previously 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-mentioned 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 containing 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 one embodiment, if there is a need to change the agreement after the completion of multi-link setup, the non-AP MLD and AP MLD can update the agreement between the MLDs through 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 the next DTIM beacon frame for the link on which the AP operates.

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

[0548] The non-AP MLD MUST 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 flowchart showing a procedure in which a transmitting MLD according to this embodiment provides partial information on an AP to a receiving MLD based on a probe response frame.

[0551] The example of Figure 65 is executed in a network environment that supports a next-generation wireless LAN system (IEEE 802.11be or EHT wireless LAN system). 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] This embodiment proposes a method and apparatus for requesting partial information from a specific AP based on a request element included in a multiple link element of a probe request frame in MLD communication when a non-AP STA requests partial information from another AP that is not a peer AP via a probe request frame. Here, the transmit MLD corresponds to the AP MLD, and the receive MLD corresponds to the non-AP MLD. If the non-AP STA is a first receive STA, the first receive STA and the first transmit STA connected to the first link can be said to be a peer AP, and the second and third transmit STAs connected to other links can be said to be other APs.

[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] If 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, and 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 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. If 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. If the value of the first overall information profile subfield is 1, the receiving MLD can request full information for the second link using only the profile field of the second receiving STA, and the transmitting MLD can include 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 sending MLD.

[0561] The transmitting MLD may further include a third transmitting STA operating in a third link, and 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, and 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 which 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 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. If 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. If the value of the second overall information profile subfield is 1, the receiving MLD can request full information for the third link using only the profile field of the third receiving STA, and the transmitting MLD can include the full 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] The probe request frame may also 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 can request partial information for a peer AP via a request element not included in the multi-link element, and can request partial information for another AP other than 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 based on the first identifier information. Elements of the partial information for the third link may also be separated based on the second identifier information.

[0569] That is, this embodiment proposes a method of setting an indicator for whether a request element is included 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, and checks the requested partial information in the request element, and can include the requested partial information in the probe response frame. This allows the non-AP MLD to always request partial information, not full information, for another link, thereby reducing frame overhead.

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

[0571] The example of Figure 66 is executed in a network environment that supports a next-generation wireless LAN system (IEEE 802.11be or EHT wireless LAN system). 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] This embodiment proposes a method and apparatus for requesting partial information from a specific AP based on a request element included in a multiple link element of a probe request frame in MLD communication when the non-AP STA requests partial information from another AP that is not a peer AP via a probe request frame. Here, the transmit MLD corresponds to the AP MLD, and the receive MLD corresponds to the non-AP MLD. If the non-AP STA is a first receive STA, the first receive STA and the first transmit STA connected to the first link can be said to be a peer AP, and the second and third transmit STAs connected to another link can be said to be another AP.

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

[0574] In step S6620, the receiving MLD receives a probe response frame from the sending 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] If 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, and 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 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. If 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. If the value of the first overall information profile subfield is 1, the receiving MLD can request full information for the second link using only the profile field of the second receiving STA, and the transmitting MLD can include 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 sending MLD.

[0581] The transmitting MLD may further include a third transmitting STA operating in a third link, and 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, and 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 which 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 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. If 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. If the value of the second overall information profile subfield is 1, the receiving MLD can request full information for the third link using only the profile field of the third receiving STA, and the transmitting MLD can include the full 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] The probe request frame may also 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 can request partial information for a peer AP via a request element not included in the multi-link element, and can request partial information for another AP other than 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 based on the first identifier information. Elements of the partial information for the third link may also be separated based on the second identifier information.

[0589] That is, this embodiment proposes a method of setting an indicator for whether a request element is included 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, and checks the requested partial information in the request element, and can include the requested partial information in the probe response frame. This allows the non-AP MLD to always request partial information, not full information, for another link, thereby 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 performed / 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, the processors 111 and 121 and memories 112 and 122 of FIG. 1, or 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 computer-readable medium (CRM). For example, the CRM proposed by the present specification is at least one computer-readable medium including instructions to be 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 is processor 111, 121 or processing chip 114, 124 of FIG. 1, or processor 610 of FIG. 11. Meanwhile, the CRM herein may be memory 112, 122 of FIG. 1, memory 620 of FIG. 11, or a separate external memory / storage medium / disk.

[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 devices that support artificial intelligence (AI).

[0594] Artificial intelligence refers to the field that studies artificial intelligence or the methodologies 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 methodologies 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] An 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, a learning process that updates the model parameters, and an activation function that generates output values.

[0596] An artificial neural network can include an input layer, an output layer, and optionally one or more hidden layers. Each layer contains one or more neurons, and an artificial neural network can include synapses connecting 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 received via synapses.

[0597] Model parameters are parameters determined through learning, such as synaptic connection weights and neuron biases, while hyperparameters are parameters that must be set before learning in machine learning algorithms, such as 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 the loss function, which is used as an index to determine the optimal model parameters in the training process of the 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 is a method of training an artificial neural network when labels for training data are given, and refers to the correct answer (or resulting value) that the artificial neural network needs to infer when training data called labels are input to the artificial neural network. Unsupervised learning is a method of training an artificial neural network when labels for training data are not given. Reinforcement learning is a learning method that trains an agent defined in an environment to select actions or action sequences that maximize cumulative rewards in each state.

[0601] Among artificial neural networks, machine learning implemented as a deep neural network (DNN) with multiple hidden layers is also called deep learning, and deep learning is a part of machine learning. In what follows, machine learning will be 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 automatically processes or operates a given task using its own capabilities. In particular, a robot that has the ability to recognize its environment, make its own decisions, and execute its actions is called an intelligent robot.

[0604] Robots can be classified according to their intended use and field, such as industrial, medical, domestic, and military. Robots have drive units including actuators or motors, allowing them to perform various physical actions such as moving robot joints. Mobile robots also have drive units including wheels, brakes, and propellers, allowing them to move on the ground or fly in the air.

[0605] The technical features described above 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 displays virtual objects together, but the difference is that in AR technology, virtual objects are used to complement each other, while in MR technology, 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 may be combined with 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 may be combined with 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: An AP MLD (access point multi-link device) receives a multi-link probe request frame from a non-AP MLD; The AP MLD sends a multilink probe response frame to the non-AP MLD; a first AP operating on a first link and a second AP operating on a second link belong to the AP MLD; a first non-AP STA operating on the first link and a second non-AP STA operating on the second link belong to the non-AP MLD; The multilink probe request frame enables the first non-AP STA to request partial information regarding the second AP based on the multilink probe request frame carrying a Per-STA Profile subfield for the second AP; The Per-STA Profile subfield for the second AP includes a first request element and a first overall information profile subfield of a first STA Control field; The value of the first general information profile subfield is set to 0; The method, wherein the partial information regarding the second AP is requested based on the first request element.

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

3. 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 includes a second overall information profile subfield of a second STA Control field.

4. Based on the first non-AP STA requesting partial information regarding the third AP, the 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 3 , wherein the partial information regarding the third AP is requested based on the second request element.

5. Based on the first non-AP STA requesting global information regarding the third AP, the 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 3 , wherein the global information regarding the third AP is requested based on the Per-STA Profile subfield for the third AP.

6. the multilink probe request frame includes a third request element and a multilink element; the partial information regarding the first AP is requested based on the third request element based on the first non-AP STA requesting the partial information regarding the first AP; 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.

7. the first request element includes first identifier information indicating the partial information related to the second AP; the second request element includes second identifier information indicating partial information regarding the third AP; The method of claim 4 , 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.

8. An AP MLD (access point multi-link device) in a WLAN (wireless local area network) system, Memory and A transmitter / receiver, a processor operatively coupled to the memory and the transceiver; The processor Receive a MultiLink Probe Request frame from a non-AP MLD; and transmitting a MultiLink Probe Response frame to the non-AP MLD; a first AP operating on a first link and a second AP operating on a second link belong to the AP MLD; a first non-AP STA operating on the first link and a second non-AP STA operating on the second link belong to the non-AP MLD; The multilink probe request frame enables the first non-AP STA to request partial information regarding the second AP based on the multilink probe request frame carrying a Per-STA Profile subfield for the second AP; The Per-STA Profile subfield for the second AP includes a first request element and a first overall information profile subfield of a first STA Control field; The value of the first general information profile subfield is set to 0; The partial information regarding the second AP is requested based on the first request element, AP MLD.

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

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

11. 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 9 , wherein the Per-STA Profile subfield for the third AP includes a second overall information profile subfield of a second STA Control field.

12. Based on the first non-AP STA requesting partial information regarding the third AP, the 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 11 , wherein the partial information regarding the third AP is requested based on the second request element.

13. Based on the first non-AP STA requesting global information regarding the third AP, the 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 11 , wherein the global information regarding the third AP is requested based on the Per-STA Profile subfield for the third AP.

14. the multilink probe request frame includes a third request element and a multilink element; the partial information regarding the first AP is requested based on the third request element based on the first non-AP STA requesting the partial information regarding the first AP; The method of claim 9 , 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.

15. the first request element includes first identifier information indicating the partial information related to the second AP; The method of claim 12 , wherein the second request element includes second identifier information indicating partial information regarding the third AP.

Images