Access point multi-link device and method performed thereby

Abstract

The present disclosure provides an access point multi-link device and a method performed thereby. Specifically, a receiving MLD transmits a probe request frame to a transmitting MLD over a first link. The receiving MLD receives a probe response frame from the transmitting MLD over the first link. The transmitting MLD includes a first transmitting STA operating on the first link and a second transmitting STA operating on a second link. The receiving MLD includes a first receiving STA operating on the first link and a second receiving STA operating on 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 full information profile subfield. When the first receiving STA requests partial information about the second link, a value of the first full 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 about the second link is requested based on the first request element.

Description

[0001] This application is a divisional application of the original patent application No. 202180074364.2 (International Application No.: PCT / KR2021 / 017018, Application Date: November 18, 2021, Invention Title: Method and Apparatus for Sending Partial Information of AP in MLD in a Wireless LAN System). Technical Field

[0002] This specification relates to multi-link operation in a wireless LAN system, and more specifically, to a method and apparatus for requesting partial information about an AP in a transmitting MLD. Background Technology

[0003] Wireless local area networks (WLANs) have been improved in various ways. For example, the IEEE 802.11ax standard proposes an improved communication environment using orthogonal frequency division multiple access (OFDMA) and downlink multiple user multiple input multiple output (DLMU MIMO) technologies.

[0004] This specification proposes technical features that can be utilized in new communication standards. For example, a new communication standard could be the currently discussed Extremely High Throughput (EHT) standard. The EHT standard could utilize newly proposed increased bandwidth, enhanced PHY layer Protocol Data Unit (PPDU) structures, enhanced sequencing, Hybrid Automatic Repeat Request (HARQ) schemes, etc. The EHT standard could be referred to as the IEEE 802.11be standard.

[0005] New wireless LAN standards may use an increased number of spatial streams. In this case, to properly utilize the increased number of spatial streams, it may be necessary to improve the signaling technology in the WLAN system. Summary of the Invention

[0006] Technical issues

[0007] This specification describes a method and apparatus for requesting partial information about an AP in a wireless LAN system that is transmitting an MLD.

[0008] Technical solutions

[0009] The examples in this specification illustrate a method for requesting partial information about the AP in the MLD.

[0010] This implementation can be run in network environments that support next-generation WLAN systems (IEEE 802.11be or EHT WLAN systems). Next-generation wireless LAN systems are WLAN systems enhanced relative to 802.11ax systems, thus satisfying backward compatibility with 802.11ax systems.

[0011] In this embodiment, when a non-AP STA requests partial information about an AP other than its peer AP via a probe request frame in MLD communication, a method and apparatus are proposed for the non-AP STA to request partial information about a specific AP based on the request element by including the request element in the multi-link element of the probe request frame. Here, the transmitting MLD can correspond to the AP MLD, and the receiving MLD can correspond to the non-AP MLD. If the non-AP STA is the first receiving STA, then the first transmitting STA connected to the first receiving STA via a first link can be referred to as the peer AP, and the second and third transmitting STAs connected via different links can be referred to as different APs.

[0012] The receiving multi-link device (MLD) sends a probe request frame to the sending MLD via the first link.

[0013] The receiving MLD receives probe response frames from the sending MLD via the first link.

[0014] The transmitting MLD includes a first transmitting station (STA) operating on a first link and a second transmitting STA operating on a second link. The receiving MLD includes a first receiving STA operating on a first link and a second receiving STA operating on a second link.

[0015] The probe request frame includes a profile field for the second receiving STA. The profile field for the second receiving STA includes a first complete information profile subfield.

[0016] When the first receiving STA requests partial information about the second link, the value of the first complete information configuration file subfield is set to 0. The configuration file field of the second receiving STA also includes the first request element. At this time, partial information about the second link is requested based on the first request element.

[0017] Beneficial effects

[0018] According to the implementation described in this specification, by setting an indicator for whether to include a request element in the configuration file field of each receiving STA included in the multi-link element, and by proposing a method for requesting partial information about a specific AP based on the request element, a non-AP MLD can always request partial rather than complete information from other links. This has the effect of reducing frame overhead. Attached Figure Description

[0019] Figure 1 Examples of transmitting and / or receiving devices are shown in this specification.

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

[0021] Figure 3 The diagram illustrates the typical link setup process.

[0022] Figure 4 The illustration shows an example of a PPDU used in IEEE standards.

[0023] Figure 5 An example of operation based on UL-MU is shown.

[0024] Figure 6 An example of a trigger frame is shown.

[0025] Figure 7 An example of the common information field of the trigger frame is shown.

[0026] Figure 8 Examples of subfields included in each user information field are shown.

[0027] Figure 9 The technical features of the UORA scheme are described.

[0028] Figure 10 An example of a PPDU used in this specification is shown.

[0029] Figure 11 Examples of transmitting and / or receiving devices modified in this specification are shown.

[0030] Figure 12 An example of a non-AP MLD structure is shown.

[0031] Figure 13 An example is shown of the process of establishing a connection between an AP MLD and a non-AP MLD via a link.

[0032] Figure 14 Examples of link changes or reconnections are shown.

[0033] Figure 15 Specific examples of link changes or reconnections are shown.

[0034] Figure 16 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0035] Figure 17 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0036] Figure 18 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0037] Figure 19Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0038] Figure 20 This example illustrates the operation of a non-AP MLD used to request information about other APs.

[0039] Figure 21 A specific example of the STA ratio for each link is shown.

[0040] Figure 22 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0041] Figure 23 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0042] Figure 24 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0043] Figure 25 An example of adding a multi-link element in a probe request is shown.

[0044] Figure 26 An example of using the link range field in a multi-link element is shown.

[0045] Figure 27 An example of the newly proposed field for indicating link changes and reconnections is shown.

[0046] Figure 28 An example of requesting IE format is shown.

[0047] Figure 29 An example of an extended request in IE format is shown.

[0048] Figure 30 An example of the PV1 probe response option element format is shown.

[0049] Figure 31 An example of an MLD request element is shown.

[0050] Figure 32 Another example of an MLD request element is shown.

[0051] Figure 33 An example of defining a new element based on an MLD request element is shown.

[0052] Figure 34 Another example of an MLD request element is shown.

[0053] Figure 35Another example of an MLD request element is shown.

[0054] Figure 36 Another example of an MLD request element is shown.

[0055] Figure 37 Another example of an MLD request element is shown.

[0056] Figure 38 An example of a field that requests public information is shown.

[0057] Figure 39 An example of the ML IE format defined in 802.11be is shown.

[0058] Figure 40 Examples of multi-link element format and multi-link control field format are shown.

[0059] Figure 41 An example of the multi-link control field format is shown.

[0060] Figure 42 An example of the ML IE format is shown.

[0061] Figure 43 Another example of the ML IE format is shown.

[0062] Figure 44 Another example of the ML IE format is shown.

[0063] Figure 45 Another example of the ML IE format is shown.

[0064] Figure 46 An example of a probe request frame in ML IE format is shown.

[0065] Figure 47 Another example of a probe request frame in ML IE format is shown.

[0066] Figure 48 Another example of a probe request frame in ML IE format is shown.

[0067] Figure 49 Another example of a probe request frame in ML IE format is shown.

[0068] Figure 50 An example of the multi-link control field format is shown.

[0069] Figure 51 An example is shown where the key update request field is included in the ML IE format.

[0070] Figure 52An example of using an MLD probe request that changes sequence elements when requesting critical update information is shown.

[0071] Figure 53 This shows another example of using an MLD probe request that changes sequence elements when requesting critical update information.

[0072] Figure 54 An example is shown where the key update request field is included in the ML IE format.

[0073] Figure 55 An example is shown in which altered sequence elements are included in the ML IE format.

[0074] Figure 56 An example of MLD changing sequence format is shown.

[0075] Figure 57 This shows another example of MLD changing the sequence format.

[0076] Figure 58 An example of MLD altering sequence elements is shown.

[0077] Figure 59 An example of changing sequence elements in an existing standard is shown.

[0078] Figure 60 Another example is shown where altered sequence elements are included in the ML IE format.

[0079] Figure 61 An example of a probe request frame used to request critical update information is shown.

[0080] Figure 62 Another example of a probe request frame used to request critical update information is shown.

[0081] Figure 63 Another example of a probe request frame used to request critical update information is shown.

[0082] Figure 64 Another example of a probe request frame used to request critical update information is shown.

[0083] Figure 65 This is a flowchart illustrating the process by which the sending MLD provides partial information to the receiving MLD based on a probe response frame according to this embodiment.

[0084] Figure 66 This is a flowchart illustrating the process of receiving MLD request portion information based on a probe request frame according to this embodiment. Detailed Implementation

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

[0086] The forward slash ( / ) or comma used in this specification may mean "and / or". For example, "A / B" may mean "A and / or B". Therefore, "A / B" may mean "A only", "B only", or "both A and B". For example, "A, B, C" may mean "A, B, or C".

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

[0088] Additionally, in this specification, "at least one of A, B, and C" may mean "A only", "B only", "C only" 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" may mean "at least one of A, B, and C".

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

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

[0091] The examples in this specification can be applied to various wireless communication systems. For example, the examples in this specification can be applied to wireless local area network (WLAN) systems. For example, this specification can be applied to the IEEE 802.11a / g / n / ac standard or the IEEE 802.11ax standard. Additionally, this specification can also be applied to the newly proposed EHT standard or the IEEE 802.11be standard. Furthermore, the examples in this specification can also be applied to new WLAN standards enhanced from the EHT standard or the IEEE 802.11be standard. Additionally, the examples in this specification can be applied to mobile communication systems. For example, it can be applied to mobile communication systems based on Long Term Evolution (LTE) standards dependent on the 3rd Generation Partnership Project (3GPP) standards, and mobile communication systems based on LTE evolution. Additionally, the examples in this specification can be applied to communication systems based on the 5G NR standard of the 3GPP standard.

[0092] In the following text, for the purpose of describing the technical features of this specification, technical features that can be applied to this specification will be described.

[0093] Figure 1 Examples of transmitting and / or receiving devices are shown in this specification.

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

[0095] For example, STA 110 and 120 can be used as an AP or a non-AP. That is, STA 110 and 120 of this specification can be used as an AP and / or a non-AP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0131] In the S340, the STA can perform a security setup process. The security setup process in the S340 may include a process of setting a private key via a four-way handshake (e.g., via an Extensible Authentication Protocol (EAPOL) frame over the LAN).

[0132] Figure 4 This diagram illustrates an example of a PPDU used in IEEE standards.

[0133] As shown, various types of PHY Protocol Data Units (PPDUs) are used in the IEEE a / g / n / ac standards. Specifically, LTF and STF include training signals, SIG-A and SIG-B include control information for receiving STAs, and the data field includes user data corresponding to the PSDU (MAC PDU / aggregated MAC PDU).

[0134] Figure 4 It also includes examples of HE PPDUs according to IEEE 802.11ax. According to Figure 4 The HE PPDU is an exemplary PPDU for multiple users. HE-SIG-B may be included only in PPDUs for multiple users, and HE-SIG-B may be omitted in PPDUs for single users.

[0135] like Figure 4 As illustrated, an HE-PPDU for multiple users (MUs) may include a conventional short training field (L-STF), a conventional long training field (L-LTF), a conventional 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 alternatively, a MAC payload), and a packet extension (PE) field. Each field can be transmitted within the indicated time period (i.e., 4 or 8 μs).

[0136] The following describes the Resource Unit (RU) used for the PPDU. An RU may include multiple subcarriers (or tones). An RU can be used to transmit signals to multiple STAs according to OFDMA. Alternatively, an RU can also be defined as transmitting signals to a single STA. An RU can be used for STF, LTF, data fields, etc.

[0137] The RUs described in this specification can be used for both uplink (UL) and downlink (DL) communication. For example, when performing UL-MU communication requested by a trigger frame, a transmitting STA (e.g., an AP) can assign a first RU (e.g., 26 / 52 / 106 / 242-RU, etc.) to a first STA via the trigger frame, and can assign a second RU (e.g., 26 / 52 / 106 / 242-RU, etc.) to a second STA. Thereafter, the first STA can send a first trigger-based PPDU based on the first RU, and the second STA can send a second trigger-based PPDU based on the second RU. The first and second trigger-based PPDUs are sent to the AP in the same (or overlapping) time period.

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

[0139] Figure 5 Operation based on UL-MU is illustrated. As illustrated, a transmitting STA (e.g., AP) can perform channel access through contention (e.g., backoff operation) and can transmit trigger frame 1030. That is, the transmitting STA can transmit a PPDU including trigger frame 1030. Upon receiving the PPDU including the trigger frame, a trigger-based (TB) PPDU is transmitted after a delay corresponding to SIFS.

[0140] TB PPDUs 1041 and 1042 can be transmitted within the same time period and can be transmitted from multiple STAs (e.g., user STAs) having the AID indicated in trigger frame 1030. The ACK frame 1050 for the TB PPDU can be implemented in various forms.

[0141] refer to Figures 6 to 8 This describes the specific characteristics of the trigger frame. Even when using UL-MU communication, orthogonal frequency division multiple access (OFDMA) or MU-MIMO schemes can be used, and both OFDMA and MU-MIMO schemes can be used simultaneously.

[0142] Figure 6 An example of a trigger frame is shown. Figure 6The trigger frame is used to allocate resources for uplink multi-user (MU) transmissions and can be sent, for example, from the access point (AP). The trigger frame can consist of a MAC frame and can be included in a PPDU.

[0143] Figure 6 Each field shown can be partially omitted, and another field can be added. Additionally, the length of each field can be changed to a length different from that shown in the diagram.

[0144] Figure 6 The frame control field 1110 may include information related to the MAC protocol version and additional control information. The duration field 1120 may include time information configured in the NAV or information related to the STA's identifier (e.g., AID).

[0145] Additionally, the RA field 1130 may include address information of the receiving STA for the corresponding trigger frame, and may be optionally omitted. The TA field 1140 may include address information of the STA (e.g., AP) that sent the corresponding trigger frame. The common information field 1150 includes common control information applied to the receiving STA that received the corresponding trigger frame. For example, it may include a field indicating the length of the L-SIG field of the uplink PPDU sent in response to the corresponding trigger frame, or information for controlling the content of the SIG-A field (i.e., the HE-SIG-A field) of the uplink PPDU sent in response to the corresponding trigger frame. Furthermore, as common control information, it may include information related to the length of the CP of the uplink PPDU sent in response to the corresponding trigger frame, or information related to the length of the LTF field.

[0146] Additionally, preferably includes receiving Figure 6 The number of STAs receiving the trigger frame corresponds to the per-user information fields 1160#1 to 1160#N. The per-user information field can also be called the "allocation field".

[0147] in addition, Figure 6 The trigger frame may include a padding field 1170 and a frame check sequence field 1180.

[0148] Figure 6 Each of the user information fields 1160#1 to 1160#N shown may include multiple subfields.

[0149] Figure 7 An example of the common information fields for the trigger frame is shown. Some parts can be omitted. Figure 7 It has subfields, and additional subfields can be added. Additionally, the length of each of the listed subfields can be changed.

[0150] The illustrated length field 1210 has the same value as the length field of the L-SIG field of the uplink PPDU sent in response to the corresponding 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 can be used to indicate the length of the corresponding uplink PPDU.

[0151] Additionally, the concatenation identifier field 1220 indicates whether a concatenation operation has been performed. A concatenation operation means that downlink MU transmission and uplink MU transmission are performed together within the same TXOP. That is, it means that downlink MU transmission is performed, and then, after a preset time (e.g., SIFS), uplink MU transmission is performed. During a concatenation operation, only one transmitting device (e.g., AP) can perform downlink communication, and multiple transmitting devices (e.g., non-APs) can perform uplink communication.

[0152] The CS request field 1230 indicates whether the radio medium state or NAV must be considered when the receiving device, having received the corresponding trigger frame, sends the corresponding uplink PPDU.

[0153] HE-SIG-A information field 1240 may include information controlling the content of the SIG-A field (i.e., the HE-SIG-A field) of the uplink PPDU in response to the corresponding trigger frame.

[0154] The CP and LTF type fields 1250 may include information related to the CP length and LTF length of the uplink PPDU sent in response to the corresponding trigger frame. The trigger type field 1260 may indicate the purpose of using the corresponding trigger frame, such as typical triggering, triggering for beamforming, request for block ACK / NACK, etc.

[0155] It can be assumed that the trigger type field 1260 of the trigger frame in this specification indicates a trigger frame of a basic type used for typical triggering. For example, a trigger frame of a basic type may be referred to as a basic trigger frame.

[0156] Figure 8 Examples of subfields included in each user information field are shown. Figure 8 The user information field 1300 can be understood as the above reference. Figure 6 Any one of the user information fields 1160#1 to 1160#N mentioned. Some can be omitted. Figure 8 The user information field 1300 includes subfields, and additional subfields can be added. Additionally, the length of each of the illustrated subfields can be changed.

[0157] Figure 8The User Identifier field 1310 indicates the identifier of the STA (i.e., the receiving STA) corresponding to each user information. An example of the identifier can be all or part of the Associated Identifier (AID) value of the receiving STA.

[0158] Additionally, an RU allocation field 1320 may be included. That is, when a receiving STA identified by the user identifier field 1310 sends a TB PPDU in response to a trigger frame, the TB PPDU is sent through the RU indicated by the RU allocation field 1320.

[0159] Figure 8 The subfield can include encoding type field 1330. Encoding type field 1330 can indicate the encoding type of the TB PPDU. For example, when BCC encoding is applied to the TB PPDU, encoding type field 1330 can be set to "1", and when LDPC encoding is applied, encoding type field 1330 can be set to "0".

[0160] in addition, Figure 8 The subfields may include the MCS field 1340. The MCS field 1340 may indicate the MCS scheme applied to the TB PPDU. For example, when BCC encoding is applied to the TB PPDU, the encoding type field 1330 may be set to "1", and when LDPC encoding is applied, the encoding type field 1330 may be set to "0".

[0161] The following section will describe a random access (UORA) scheme based on UL OFDMA.

[0162] Figure 9 The technical features of the UORA scheme are described.

[0163] Sending a STA (e.g., AP) can be done as follows Figure 9 The diagram illustrates the allocation of six RU resources via a trigger frame. 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 related to AID 0, AID 3, or AID 2045 can, for example, be included in... Figure 8 The user identifier field 1310. Information related to RU1 through RU6 can be included, for example, in... Figure 8 In the RU allocation field 1320, AID=0 can mean a UORA resource used for an associated STA, and AID=2045 can mean a UORA resource used for a non-associated STA. Accordingly, Figure 9 The first to third RU resources can be used as UORA resources for associated STAs. Figure 9 The fourth and fifth RU resources can be used as UORA resources for non-associated STAs, and Figure 9 The sixth RU resource can be used as a typical resource for UL MU.

[0164] exist Figure 9 In the example, STA 1's OFDMA Random Access Backoff (OBO) is reduced to 0, and STA 1 randomly selects the second RU resource (AID 0, RU 2). Additionally, since the OBO counters of STA 2 / 3 are greater than 0, no uplink resources are allocated to STA 2 / 3. Furthermore, regarding... Figure 9 In STA4, since STA4's AID (e.g., AID = 3) is included in the trigger frame, RU 6's resources are allocated without backoff.

[0165] Specifically, due to Figure 9 STA1 is an associated STA, therefore the total number of qualified RA RUs for STA1 is 3 (RU1, RU2, and RU3). Therefore, STA1 decrements the OBO counter by 3, making the OBO counter 0. Additionally, because... Figure 9 STA2 is an associated STA, therefore the total number of qualified RA RUs for STA2 is 3 (RU 1, RU 2, and RU 3). Therefore, STA2 decrements the OBO counter by 3, but the OBO counter remains greater than 0. Additionally, because... Figure 9 STA3 is a non-associated STA, so the total number of qualified RA RUs of STA3 is 2 (RU 4, RU 5). Therefore, STA3 will decrease the OBO counter by 2, but the OBO counter is greater than 0.

[0166] The following section describes the PPDUs sent / received in the STA of this specification.

[0167] Figure 10 An example of a PPDU used in this specification is shown.

[0168] Figure 10 PPDUs can be named using various terms such as EHT PPDU, TX PPDU, RX PPDU, Type 1, or Type N PPDU. For example, in this specification, PPDUs or EHT PPDUs can be named using various terms such as TX PPDU, RX PPDU, Type 1, or Type N PPDU. Furthermore, EHT PPDUs can be used in EHT systems and / or new WLAN systems enhanced relative to EHT systems.

[0169] Figure 10 A PPDU can indicate all or part of the PPDU types used in an EHT system. For example, Figure 10 The example can be used for both single-user (SU) and multi-user (MU) modes. In other words, Figure 10 The PPDU can be used for one or more receiving STAs. When Figure 10 When PPDU is used in trigger-based (TB) mode, Figure 10 The EHT-SIG can be omitted. In other words, a STA that has received a trigger frame for the uplink MU (UL-MU) can send a signal in... Figure 10 The PPDU for EHT-SIG is omitted in the example.

[0170] exist Figure 10 In this context, L-STF to EHT-LTF can be referred to as preamble or physical preamble, and can be generated / sent / received / acquired / decoded at the physical layer.

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

[0172] exist Figure 10 In the PPDU, L-LTE and L-STF can be the same as those in the regular fields.

[0173] Figure 10The L-SIG field can include, for example, 24 bits of bit information. For instance, the 24 bits could include a 4-bit rate field, a 1-bit reserved bit, a 12-bit length field, a 1-bit parity bit, and a 6-bit tail bit. For example, the 12-bit length field could include information related to the length or duration of the PPDU. For example, the 12-bit length field can be determined based on the type of PPDU. For example, when the PPDU is a non-HT, HT, VHT, or EHT PPDU, the value of the length field can be determined to be a multiple of 3. For example, when the PPDU is an HE PPDU, the value of the length field can be determined to be either a multiple of 3 + 1 or a multiple of 3 + 2. In other words, for non-HT, HT, VHT, or EHT PPDUs, the value of the length field can be determined to be a multiple of 3, and for HE PPDUs, the value of the length field can be determined to be either a multiple of 3 + 1 or a multiple of 3 + 2.

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

[0175] The transmitting STA can generate an RL-SIG in the same way as the L-SIG. BPSK modulation can be applied to the RL-SIG. The receiving STA can determine whether the RX PPDU is an HE PPDU or an EHT PPDU based on the presence of the RL-SIG.

[0176] It is possible Figure 10 A generic SIG (U-SIG) is inserted after the RL-SIG. U-SIBs can be named using various terms such as First SIG Field, First SIG, First Type SIG, Control Signal, Control Signal Field, First (Type) Control Signal, etc.

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

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

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

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

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

[0182] For example, the version-independent bits of U-SIG may include a 1-bit UL / DL flag field. The first value of the 1-bit UL / DL flag field relates to UL communication, and the second value of the UL / DL flag field relates to DL communication.

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

[0184] For example, when EHT PPDUs are classified into various types (e.g., EHT PPDUs related to SU mode, EHT PPDUs related to MU mode, EHT PPDUs related to TB mode, EHT PPDUs related to extended range transmission, etc.), information related to the type of EHT PPDU can be included in the version-related bits of U-SIG.

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

[0186] In the following examples, signals represented as (TX / RX / UL / DL) signals, (TX / RX / UL / DL) frames, (TX / RX / UL / DL) packets, (TX / RX / UL / DL) data units, (TX / RX / UL / DL) data, etc., can be based on Figure 10 The signals transmitted / received by the PPDU. Figure 10 PPDUs can be used to send / receive various types of frames. For example, Figure 10 PPDUs can be used in control frames. Examples of control frames can include Request to Send (RTS), Allow to Send (CTS), Power Saving Polling (PS Polling), BlockACKReq, BlockAck, Null Data Packet (NDP) announcement, and trigger frames. For example, Figure 10 PPDUs can be used for management frames. Examples of management frames can include beacon frames, (re)association request frames, (re)association response frames, probe request frames, and probe response frames. For example, Figure 10 PPDUs can be used in data frames. For example, Figure 10 A PPDU can be used to send at least two or more of control frames, management frames, and data frames simultaneously.

[0187] Figure 11 Examples of modified transmitting and / or receiving devices are illustrated in this specification.

[0188] Figure 1 Each device / STA in subgraphs (a) / (b) can be as follows Figure 11 The modifications shown are as indicated. Figure 11 The transceiver 630 can be used with Figure 1 The transceivers 113 and 123 are the same. Figure 11 The transceiver 630 may include a receiver and a transmitter.

[0189] Figure 11 The processor 610 can be with Figure 1 The processors 111 and 121 are the same. Alternatively, Figure 11The processor 610 can be with Figure 1 The processing chips 114 and 124 are the same.

[0190] Figure 11 The memory 620 can be with Figure 1 The memories 112 and 122 are the same. Alternatively, Figure 11 The memory 620 can be with Figure 1 The memories 112 and 122 are different separate external memories.

[0191] Reference Figure 11 The power management module 611 manages the power supplied to the processor 610 and / or transceiver 630. The battery 612 supplies power to the power management module 611. The display 613 outputs the results processed by the processor 610. The keyboard 614 receives input to be used by the processor 610. The keyboard 614 may be displayed on the display 613. The SIM card 615 may be an integrated circuit for securely storing the International Mobile Subscriber Identity (IMSI) and its associated key, which is used to identify and authenticate subscribers on mobile devices such as mobile phones and computers.

[0192] Reference Figure 11 The speaker 640 can output results related to the sound processed by the processor 610. The microphone 641 can receive input related to the sound to be used by the processor 610.

[0193] The technical features of the multi-link (ML) supported by the STA in this specification will be described below.

[0194] The STA (AP and / or non-AP STA) in this specification can support multi-link (ML) communication. ML communication can refer to communication supporting multiple links. Links associated with 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).

[0195] Multiple links for ML communication can be configured in various ways. For example, multiple links for ML communication supported by a single STA can be multiple channels in the 2.4 GHz band, multiple channels in the 5 GHz band, and multiple channels in the 6 GHz band. Alternatively, the multiple links can be a combination of at least one channel in the 2.4 GHz band (or the 5 GHz / 6 GHz band) and at least one channel in the 5 GHz band (or the 2.4 GHz / 6 GHz band). Furthermore, at least one of the multiple links for ML communication supported by a single STA can be a channel with preamble culling applied.

[0196] The STA can perform ML settings to enable ML communication. ML settings can be performed based on management or control frames such as beacons, probe requests / responses, and association requests / responses. For example, information about the ML settings can be included in element fields included in beacons, probe requests / responses, and association requests / responses.

[0197] Once the ML setup is complete, the enabled links for ML communication can be determined. The STA can perform frame switching through at least one of the multiple links determined to be enabled. For example, the enabled link can be used for at least one of management frames, control frames, and data frames.

[0198] When a STA supports multiple links, the transmitting / receiving devices supporting each link can operate like a logical STA. For example, an STA supporting two links can be represented as an ML device (Multi-Link Device; MLD) including a first STA for the first link and a second STA for the second link. Similarly, an AP supporting two links can be represented as an AP MLD including a first AP for the first link and a second AP for the second link. Conversely, a non-AP supporting two links can be represented as a non-AP MLD including a first STA for the first link and a second STA for the second link.

[0199] The following describes more specific features of ML settings.

[0200] MLDs (AP MLDs and / or non-AP MLDs) can send information about the links they can support through ML settings. Link-related information can be configured in various ways. For example, link-related information includes at least one of the following: 1) whether the MLD (or STA) supports simultaneous RX / TX operation; 2) the number / upper limit of uplink / downlink links supported by the MLD (or STA); 3) the location / band / resources of the uplink / downlink links supported by the MLD (or STA); 4) the type of frames available or preferred in at least one uplink / downlink link (management, control, data, etc.); 5) the available or preferred ACK policy information for at least one uplink / downlink link; and 6) at least one available or preferred TID (Traffic Identifier). TIDs are related to the priority of traffic data and are represented by eight types of values ​​according to standard wireless LAN standards. That is, eight TID values ​​can be defined corresponding to the four access categories (AC) (AC_BK (background), AC_BE (best effort), AC_VI (video), AC_VO (voice)) according to the conventional wireless LAN standard.

[0201] For example, all TIDs for uplink / downlink link mappings can be pre-configured. Specifically, if negotiation is not completed through ML settings, all TIDs can be used for ML communication, and if the mapping between uplink / downlink links and TIDs is negotiated through additional ML settings, the negotiated TIDs can be used for ML communication.

[0202] Multiple links that can be used by the sending MLD and receiving MLD associated with ML communication can be configured through ML settings, and this can be referred to as enabling links. Enabling links can be named differently in various ways. For example, it can be named in various ways such as first link, second link, sending link, and receiving link.

[0203] After the ML settings are complete, the MLD can update them. For example, when it's necessary to update information about a link, the MLD can send information about the new link. This information can be sent based on at least one of management frames, control frames, and data frames.

[0204] The device described below can be Figure 1 and / or Figure 11 The device, and the PPDU can be Figure 10 The device can be an AP or a non-AP STA. The device described below can be an AP multi-link device (MLD) or a non-APSTA MLD that supports multiple links.

[0205] In EHT (Extremely High Throughput) (a standard discussed after 802.11ax), a multi-link environment using one or more frequency bands simultaneously is considered. When a device supports multiple links, it can use one or more frequency bands simultaneously or alternately (e.g., 2.4 GHz, 5 GHz, 6 GHz, 60 GHz, etc.).

[0206] In the following description, MLD refers to a multi-link device. An MLD has one or more connected STAs and a MAC service access point (SAP) that communicates with the uplink layer (Logical Link Control, LLC). MLD can refer to a physical device or a logical device. In the following text, device may refer to an MLD.

[0207] In the following description, "transmitting device" and "receiving device" may refer to an MLD. The first link of the receiving / transmitting device may be a terminal (e.g., a STA or AP) included in the receiving / transmitting device and performing signal transmission / reception via the first link. The second link of the receiving / transmitting device may be a terminal (e.g., a STA or AP) that transmits / receives signals via the second link included in the receiving / transmitting device.

[0208] In IEEE 802.11be, two types of multilink operation are supported. For example, simultaneous transmit and receive (STR) and non-STR operations can be considered. STR can be referred to as asynchronous multilink operation, and non-STR as synchronous multilink operation. Multilink can include multiple frequency bands. That is, multilink can refer to links included in several frequency bands, or it can refer to multiple links included in one frequency band.

[0209] EHT (11be) considers multilink technology, where multiple links can include multiple frequency bands. That is, multiple links can simultaneously represent links in several frequency bands or multiple multiple links within a single frequency band. Two main multilink operations are being considered: asynchronous operation of TX / RX simultaneously on multiple links and the impossibly synchronous operation. In the following text, the ability to enable simultaneous reception and transmission on multiple links is referred to as STR (Simultaneous Transmit and Receive), an STA with STR capability is called a STR MLD (Multilink Device), and an STA without STR capability is called a non-STR MLD.

[0210] In the following description, for ease of explanation, it is described that the MLD (or the processor of the MLD) controls at least one STA, but is not limited thereto. As mentioned above, the at least one STA can transmit and receive signals independently of the MLD.

[0211] Depending on the implementation, an AP MLD or a non-AP MLD can have a structure containing multiple links. In other words, a non-AP MLD can support multiple links. A non-AP MLD can include multiple STAs. Multiple STAs can have links for each STA.

[0212] In the EHT standard (802.11be standard), the MLD (Multi-Link Device) architecture, where one AP / non-AP MLD supports multiple links, is considered a key technology. STAs included in a non-AP MLD can transmit information about other STAs in the non-AP MLD together via a single link. Therefore, this reduces frame switching overhead. Additionally, it improves link utilization efficiency for STAs and reduces power consumption.

[0213] Figure 12 An example of a non-AP MLD structure is shown.

[0214] Reference Figure 12 A non-AP MLD can be configured with multiple links. In other words, a non-AP MLD can support multiple links. A non-AP MLD can include multiple STAs. Multiple STAs can have links for each STA. Although Figure 12An example of a non-AP MLD structure is shown, but the structure of an AP MLD can also be... Figure 12 The example of the non-AP MLD structure shown is configured in the same way.

[0215] For example, a non-AP MLD may include STA 1, STA 2, and STA 3. STA 1 may operate on link 1. Link 1 may be included in the 5 GHz band. STA 2 may operate on link 2. Link 2 may be included in the 6 GHz band. STA 3 may operate on link 3. Link 3 may be included in the 6 GHz band. The bands included in links 1 / 2 / 3 are exemplary and may be included in 2.4 GHz, 5 GHz, and 6 GHz.

[0216] Thus, in the case of AP / non-AP MLDs supporting multiple links, each AP in the AP MLD and each STA in the non-AP MLD can connect to each link through the link establishment process. Furthermore, depending on the situation, the connected link can be changed or reconnected to another link via either the AP MLD or the non-AP MLD.

[0217] Furthermore, in the EHT standard, to reduce power consumption, links can be classified as anchored links or non-anchored links. Anchored and non-anchored links can be named differently. For example, an anchored link can be called a primary link, while a non-anchored link can be called a secondary link.

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

[0219] For example, anchored links can be used for both synchronization-related frame switching and non-data frame switching (i.e., beacon and management frames). Conversely, non-anchored links can only be used for data frame switching.

[0220] Non-AP MLDs can monitor only the anchor link during idle periods to receive beacon and management frames. Therefore, in the case of a non-AP MLD, at least one anchor link must be connected to receive beacon and management frames. One or more anchor links must always remain active. In contrast, non-anchor links are used only for data frame switching. Therefore, during idle periods when the channel / link is not in use, the STA corresponding to the non-anchor link (or the STA connected to the non-anchor link) can enter doze mode. This has the effect of reducing power consumption.

[0221] Therefore, the following specification may present a protocol for dynamically recommending or requesting link reconnection by an AP MLD or non-AP MLD as needed, for efficient link connectivity. Additionally, the following specification may also present an anchored link reconnection protocol that takes into account anchored links used for power reduction purposes and the characteristics of common links.

[0222] Examples of link changes and reconnections

[0223] According to the implementation method, each link between the AP MLD and the non-AP MLD can be determined during the association or (re)association process. At this time, the AP MLD and non-AP MLD can perform frame switching through the connected links. See also... Figure 13 This describes a specific implementation of connecting AP MLDs and non-AP MLDs via a link establishment process.

[0224] Figure 13 An example is shown of the process of establishing a connection between an AP MLD and a non-AP MLD via a link.

[0225] Reference Figure 13 An AP MLD can include AP 1, AP 2, and AP 3. A non-AP MLD can include STA 1 and STA 2. AP 1 and STA 1 can be connected via link 1. AP 2 and STA 2 can be connected via link 2.

[0226] For example, AP 1 and STA 1 can be connected via Link 1 using a first link establishment process. AP 2 and STA 2 can be connected via Link 2 using a second link establishment process. In another example, AP MLD and non-AP MLD can be connected via a single link establishment process. In other words, AP MLD and non-AP MLD can be connected via Link 1 and Link 2 in a single link establishment process.

[0227] As mentioned above, each AP and STA can perform frame exchange through the connected link. Additionally, information from other APs or STAs on different links can be sent and received through a single link.

[0228] However, after the link establishment process, either the AP MLD or the non-AP MLD can request a link change or reconnection depending on the situation / environment, for more efficient frame switching (e.g., load balancing or interference avoidance).

[0229] You can refer to this. Figure 14 This describes the implementation methods for link changes or reconnections.

[0230] Figure 14Examples of link changes or reconnections are shown.

[0231] Reference Figure 14 Typically, STA 2 connects to AP 2. Subsequently, AP 2 may experience excessive data load. STA 2 can then reconnect to AP 3, which has a relatively smaller data load. In this scenario, the existence of AP MLD and non-AP MLDs allows for efficient data exchange.

[0232] Figure 15 Specific examples of link changes or reconnections are shown.

[0233] Reference Figure 15 AP 1 of AP MLD can connect to STA 1 (not AP MLD) via link 1. AP 2 of AP MLD can connect to STA 2 (not AP MLD) via link 2. Subsequently, STA 2 can attempt / request a connection to AP 3 via link change or reconnection, and STA 2 can connect to AP 3 via link 2 based on link change or reconnection.

[0234] According to the implementation, both non-AP MLDs and AP MLDs can request link switching to improve performance. AP MLDs and non-AP MLDs can send / receive / exchange link state information and various other information for each current link. Therefore, AP MLDs and non-AP MLDs can select a more suitable link for transmitting and receiving signals based on the link state and various other information for each current link, and can send the aforementioned information to aid in the selection. For example, the various types of information for each current link may include information about the data traffic load of each link and the channel access capabilities between links. For example, the link state can be set to disabled or enabled.

[0235] In the following description, the process of negotiating with a non-AP MLD / AP MLD to request a change or reconnection to a link other than the one connected to the APMLD / non-AP MLD to improve performance can be referred to as "link switching negotiation". The name "link switching negotiation" can be different and can be changed.

[0236] During link switching negotiation, a non-AP MLD (or AP MLD) requests to change the link connected to a specific STA to another link. The AP MLD (or non-AP MLD) can respond to the request by sending an accept or reject message.

[0237] For example, such as Figure 15 As shown, when a link change is agreed upon through link switching negotiation, the STA can perform a link re-establishment process in which the existing link is changed from AP 2 to AP 3 and the reconnection is completed.

[0238] The link change or reconnection process can be described below by dividing it into cases requested by AP MLD and cases not requested by AP MLD.

[0239] Implementation of AP MLD request link change or reconnection

[0240] Depending on the implementation, the AP MLD can request link changes or reconnections from non-AP MLDs for more efficient data transmission. For example, based on the data traffic of each AP used for load balancing, the AP MLD can request the STA to change or reconnect to a more efficient link.

[0241] For example, the AP MLD can calculate / verify / confirm links suitable for STAs that are not part of the AP MLD based on the data traffic load information of each AP and / or the channel access capability information between each link (e.g., simultaneous TX / RX (STR) capability information, etc.). Subsequently, the AP MLD can request link changes or reconnection to the STA (or non-AP MLD) based on the data traffic load information of each AP and / or the channel access capability information between each link.

[0242] As mentioned above, when a link change is requested, the AP MLD can send what it deems the most appropriate link information to a non-AP MLD via a request message. For example, the request message may include a beacon or management frame.

[0243] Regarding the above implementation method, new elements or fields can be proposed to include information on the link deemed most suitable. These newly proposed elements or fields can be defined as "recommended links." "Recommended links" is an example, and the names of specific elements or fields can be changed.

[0244] Recommended links (elements / fields) The AP MLD recommends the most suitable link elements or fields to STAs that are not connected to the AP MLD based on various information about each link (e.g., data load of each link). For example, the recommended link (element / field) may be indicated by the AP MLD's link ID information or AP BSS information. In other words, the recommended link (element / field) may include AP MLD link ID information or AP BSS information.

[0245] According to one implementation, the recommended link (element / field) may optionally be included in the link switching response and sent. For example, the STA may establish a connection with a link recommended by the AP based on the element / field (i.e., the recommended link). In another example, the STA may make a connection request for a link different from the indicated link based on the element / field (i.e., the recommended link) and additional information possessed by the STA.

[0246] You can refer to this. Figure 16 This describes the detailed signal exchange process between the AP MLD and the non-AP MLD according to the above implementation.

[0247] Figure 16 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0248] Reference Figure 16 When STA 2 is connected to AP 2 via Link 2, a large amount of data traffic may flow to AP 2. In other words, when STA 2 is connected to AP 2 via Link 2, a large amount of data traffic may be generated in AP 2.

[0249] AP MLD (or AP 2) can request a non-AP MLD (or STA 2) to reconnect to AP 3, which has relatively fewer STA connections. Typically, the message requesting reconnection is sent to the STA that wants to reconnect (i.e., STA 2), but depending on the circumstances (e.g., channel state or link state), this message can be sent to any STA (i.e., other STAs). In other words, the STA to which the request message for reconnection (e.g., a link switching request frame) is sent can change based on channel or link conditions.

[0250] For example, when an STA (i.e., STA 2) receives a request message for reconnection, it can send an "accept" response message (e.g., a link switching response frame) if it accepts the request. In another example, when the request is rejected, the STA (i.e., STA 2) can send a "reject" response message.

[0251] Typically, the STA that accepts the reconnection (i.e., STA 2) sends a response message to the existing link (the link that was previously reconnected). It can take advantage of the multi-link feature to send a response message through any link (i.e., another STA).

[0252] If STA 2 accepts the link reconnection request, it can disconnect from the existing AP 2 and request a link reconnection to AP 3 after sending a response message. The reconnection request process can then be performed in the same manner as the link establishment process between existing MLDs. After the link establishment process between AP 3 and STA 2 is complete, STA 2 can perform frame exchange with AP 3 via link 2.

[0253] Conversely, when STA 2 rejects the link reconnection request, STA 2 and AP 2 can use the existing linked link (i.e., link 2) as is.

[0254] According to the implementation method, when the AP requests a link change from the STA, if a suitable link is recommended, the STA may or may not change the link to the recommended link. For example, the recommended link can be used by the AP to recommend a link suitable for the STA.

[0255] For example, as a response to an AP's request message for reconnection, the STA can approve a link change. The STA can approve / confirm a link change made with a recommended link and can request another link change from the AP based on information beyond what is included in the request message.

[0256] Therefore, the AP needs to notify the STA whether it accepts the response message. For this purpose, the AP can send an acknowledgment message (e.g., a link handover acknowledgment frame) to the STA in response to the STA's response message (e.g., a link handover response frame).

[0257] You can refer to this. Figure 17 To describe the specific operations of the AP MLD and non-AP MLD in the above embodiments.

[0258] Figure 17 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0259] Reference Figure 17 AP 2 can request a link change from STA 2, including recommended link information. In other words, AP 2 can send a link handover request frame containing recommended link information to STA 2.

[0260] STA 2 can send whether it accepts the link request via a link switching response frame.

[0261] For example, when a link switch is accepted, STA 2 can send a link switch response frame that includes information about the link to be changed. The link information to be changed may or may not be the same as the recommended link.

[0262] In another example, when STA 2 selects a link other than the one recommended by AP 2 and responds with a link switching response frame, the AP can send a message to the STA regarding whether final approval has been granted. This message can be referred to as a link switching confirmation frame.

[0263] For example, AP 2 can accept a link change for the link specified by STA 2 via a link handover acknowledgment frame. Based on the link handover acknowledgment frame, STA 2 can attempt to change the link to the link it has specified.

[0264] As another example, AP 2 can reject a link change for the link specified by STA 2 via a link switching acknowledgment frame. STA 2 and AP 2 can maintain their connection to the existing link without changing the link itself.

[0265] Even when the AP sends a link switching request frame without including recommended link information, it can still be applied. Figure 17 The implementation shown is as follows. For example, when an AP (e.g., AP 2) sends a link handover request frame to a STA (e.g., STA 2) without recommended link information, the STA can directly specify the changed link based on its own information and then respond to the AP with a link handover response frame. Even in this case, the AP must eventually send a link handover confirmation frame for approval. Therefore, the following implementation can be applied: the AP sends a link handover confirmation frame even when the recommended link information is not included in the link handover request frame.

[0266] Implementation of non-AP MLD request link change or reconnection

[0267] According to the implementation, a non-AP MLD can request a link change or reconnection from the AP MLD for efficient data transmission. For example, in order to use STR capabilities during data transmission, a non-AP MLD can request a connection link change or reconnection from the AP MLD.

[0268] Figure 18 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0269] Reference Figure 18 Both AP MLD and non-AP MLD can perform link handover negotiation. STA 2 (non-AP MLD) can send a link handover request frame to AP 2 (AP MLD). In response to the link handover request frame, AP 2 (AP MLD) can send a link handover response frame to STA 2 (non-AP MLD). Link handover request frames or link handover response frames can be sent and received through the link to be changed, but are not limited to this. Link handover request frames or link handover response frames can be sent and received through the link to be changed, as well as various other links.

[0270] Non-AP MLDs can request link changes or reconnections using various methods. Below, three methods for non-AP MLDs to request link changes or reconnections are presented. Specifically, these three methods can be described, in order, as a request method, a non-request method, and a general method.

[0271] 1) Request Method: A method by which a non-AP MLD requests various information from an AP MLD for link (re)selection and receives such information accordingly. For example, each piece of information may include information about capabilities, operational elements, and BSS parameters.

[0272] According to the implementation method, not only during link reconfiguration, but in various situations, the method of the STA requesting information about other APs in the connected AP MLD can be used. For example, after multiple links are established, the STA can request BSS parameter information of other APs used for link switching and select the best link based on the received information. Alternatively, during the discovery process, the STA can request BSS load information for each AP from the AP MLD and select a link to perform link establishment based on the received information. (However, it is assumed that the number of APs in the AP MLD is greater than the number of STAs in the non-AP MLDs.)

[0273] Therefore, the AP receiving the information request message can send any information, such as capability information, BSS parameter information, key parameters, and / or operational element information, for all APs in the AP MLD. The above example can be applied to all implementations described below.

[0274] 2) Non-request method: A method by which an AP sends various information for link (re)selection without a separate information request from a non-AP MLD. The STA can utilize the received information in various situations. According to implementations, when reconfiguring a link and in various other situations, an AP using an AP MLD can send information about other APs without a separate information request from the STA. Therefore, the AP receiving the information request message can send any information such as capability information, BSS parameter information, key parameters, and / or operational element information for all APs in the AP MLD. The above examples can be applied to all implementations described below.

[0275] 3) General method: Non-AP MLD requests link (re)selection based on information obtained through previous beacon frames, etc., without additional information.

[0276] 1) Method of pleading

[0277] The following text will first describe the implementation of the above-described method of making a request.

[0278] According to the implementation method, a non-AP MLD can request information from the AP MLD for selecting a suitable link before a link change or reconnection. The STA can utilize the data load information of each AP or the capacity information of each link (or information about other links) to select an appropriate link.

[0279] For example, the capability information for each link can be included in beacon frames and sent periodically.

[0280] In another example, the capability information for each link is optional and may not be included in the beacon frames transmitted periodically. Alternatively, to reduce frame overhead, information about only the links connected to the STA or some of the links connected to the STA may be received. Alternatively, if the beacon reception period is long due to the nature of a non-AP MLD (e.g., a low-power device), the non-AP MLD may not be able to receive the capability information for each link for more appropriate link selection.

[0281] In the above scenarios, a non-AP MLD can request the latest capability information and link-specific information (e.g., BSS parameter information or operational element information) for each link from the AP MLD. The capability information and link-specific information for each link can include not only the transmitting / receiving link but also other links. For example, the latest information can be requested / sent using QoS data frame fields (the A control field of the 11ax standard), management frames, probe response / request frames, PS polling frames, or empty frames. Alternatively, a separate new frame can be defined to request / send the latest information.

[0282] According to the implementation, in order to request the capability information and latest information of each link in the AP MLD, the STA can send a request message to the AP requesting the information necessary for link reselection. For example, a probe request frame defined conventionally for the request message can be reused. As another example, a new frame can be defined for the request message.

[0283] According to the implementation method, the STA can specify necessary specific information and request it from the AP via a request message. The specific information that can be specified can change depending on the situation. That is, the STA can request only the information corresponding to a specific link or the information corresponding to a specific capability. For example, the information corresponding to a specific link may include information about the BSS load / parameters of the specific link. In addition, the information corresponding to the capability may include the BSS load information of all links (all links) or the BSS load information of a specific link. In this case, the AP can send only the information specified by the STA via a response message. The specific implementation method of specific information request and response can be described through the implementation method of IOM definition and operation.

[0284] As another example, the STA can request all the capability information that the AP MLD currently possesses (e.g., information about other links) via a request message.

[0285] As in the examples above, implementations for sending all information owned by the AP or for sending only specific information specified by the STA can be defined / configured in various ways. For example, the AP can send all information or specify information to indicate (or send) only specific information based on individual fields or bitmaps.

[0286] Typically, a message requesting information from the AP MLD can be sent by the STA that wants to reconnect, but depending on the situation (channel conditions or link conditions), it can be sent to any STA (i.e., other STAs).

[0287] The AP MLD that receives the request message sends a response message (i.e., an information message) to the non-AP MLD that includes the information requested by the STA (e.g., data load information for each link, STR capability information between links, etc.). For example, when a standard probe request frame is reused as a request message, the AP (or AP MLD) must respond with a probe response frame as the response message.

[0288] Response messages can typically be sent through the AP that has received the request message, but can be sent to any AP (i.e., other APs) using the multi-link feature.

[0289] Alternatively, the AP MLD can send a "recommended link" element to the STA via a response message that includes various information (e.g., the latest information necessary for link reselection).

[0290] This specification details the situation where a STA that is not an AP MLD requests information from another AP.

[0291] When a STA that is not an AP MLD sends an MLD probe request frame to request complete information about other APs from a peer AP, the peer AP responds with an MLD probe response frame that includes complete information about the AP requested by the STA. In this case, the peer AP may respond to the MLD probe response frame with complete information about the requested AP as follows.

[0292] 1-1) A method to mandate the inclusion of complete information about the peer AP in the MLD probe response when the STA requests complete information about another AP.

[0293] This method includes all information about the peer AP even when the STA requests all information about other APs in the same AP MLD besides the peer AP. Currently, 802.11be uses an inheritance model to reduce the overhead of MLD probe responses. Therefore, when the STA requests complete information about other APs, the inheritance model can be applied if the AP always includes complete information about the peer AP. In other words, if the AP MLD includes peer AP information in response to a request for all information about a specific AP, common values ​​within the same MLD are included as common information in the ML IE, and information different for each AP can be included as non-inherited elements in the Per-STA Profile (each STA's profile) for each AP. When the STA requests all information about multiple other APs, for the same information, the overhead of the entire MLD probe response frame can be reduced by utilizing common information to construct that same information only once. However, in this case, if the STA does not request all the information about the peer AP, there is some overhead because it also includes unrequested information about the peer AP. But when requesting information about multiple other APs, the overhead can be reduced more significantly by using the inheritance model, so it can be useful.

[0294] 1-2) When a STA requests complete information about another AP, the method of not mandating including the entire information of the peer AP in the MLD probe response (i.e., sending only the entire information of the other AP that was requested)

[0295] In this method, when a STA requests complete information about other APs from a peer AP, only the complete information about the requested AP is included in the MLD probe response and sent. In this method, when the STA requests information about peer APs together, the overhead can be reduced by applying an inheritance model. If the STA only requests information about other APs within the same AP MLD without including information about peer APs, the inheritance model cannot be applied. Therefore, if peer AP information is not included, the inheritance model is not applied, which may slightly increase the overhead. When the STA requests complete information about a specific AP rather than multiple APs, the overhead may be quite small because unnecessary peer AP information is not included. It is a method that responds only with the information of the AP requested by the STA. Although it may be slightly simpler than the mandatory first method, as the number of other APs within the same AP MLD from which the STA requests complete information increases, the mandatory first method using the inheritance model may be more efficient.

[0296] 1-3) How peer APs can, depending on the situation, send the entire message by configuring the one with the lower overhead.

[0297] The AP constructs and sends MLD probe responses efficiently by comparing the frame overhead in the first case (where the information about the peer AP is forcibly included in the response if the STA did not request it) and the second case (where the information about the peer AP is not forcibly included in the response if the STA did not request it). In other words, the STA configures a less expensive format to respond by comparing the efficiency of the application inheritance model based on the information requested by the STA from the AP. However, in this method, the criteria for determining efficiency by comparing these two cases can be determined based on the AP's implementation.

[0298] The methods used for the various options described above are for situations where the STA requests complete information about other APs, and may not be applicable when the STA requests partial information about other APs because information about a specific IE is being requested. However, when the STA requests complete information about some APs and partial information about some APs in an MLD probe request frame, the three methods mentioned above can be used because the inheritance model can be applied.

[0299] The aforementioned request method can be used for link changes or reconnections in STAs that are not connected to the AP MLD. For example, when a STA that is not connected to the AP MLD wants to reselect a link due to link congestion, it can request BSS load information and BSS parameter information for each link of the AP MLD it is connected to. Upon receiving this request message, the AP can send the link and information indicated by the STA in the response message.

[0300] In the following text, the request and response messages mentioned above may be described as information request messages and information response messages in order to distinguish them from request messages and response messages for link changes.

[0301] Based on the information included in the aforementioned information response message, the STA can reselect an appropriate 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 information about the link to which the STA will reconnect and AP information.

[0302] Upon receiving a request message, the AP MLD can send a "Accept" response message if it accepts the request. If the AP MLD rejects the request, it can send a "Reject" response message.

[0303] If the request is accepted, the AP can perform link (re)establishment based on frame switching of the link via the reselected AP after sending a response message. Conversely, when the request is rejected, the STA can use the existing link as is.

[0304] It can be done Figure 19 Describe examples of specific AP MLD and non-AP MLD operations based on the request method.

[0305] Figure 19 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0306] Reference Figure 19 When a non-AP MLD STA 2 wants to reselect a link, STA 2 can send an information request message to the AP MLD via link 2. Upon receiving this message, the AP MLD can send an information response message containing the necessary information for the non-AP MLD's link reselection. Based on the information included in the information response message, the non-AP MLD STA 2 can send a link change request message (i.e., a link switching request frame) to the AP MLD's AP 2. Afterward, STA 2 can receive a response message for the link change (i.e., a link switching response frame) and perform a link (re)establishment in response to the link change.

[0307] Even when the STA requests necessary information from the AP, the information request implementation methods described in this specification can be used / applied. When the information included in a frame (e.g., a beacon) received by the STA from the AP is insufficient, the STA can request the missing information from the AP. For example, when the AP only sends information about the connected link and not about other links, or sends information about whether the information about other links has been updated, the STA can request the missing information from the AP.

[0308] It can be done Figure 20 Specific examples of the above implementation methods are described.

[0309] Figure 20 This example illustrates the operation of a non-AP MLD used to request information about other APs.

[0310] Reference Figure 20 AP MLD (or AP 1 to AP 3) can send information to STA via beacon frames regarding whether to update information about other APs (i.e., links). Therefore, STA 2 can send an information request message (or information request frame) to AP 2. STA 2 can receive an information response message (or information message) based on the information request message. STA 2 can receive / obtain information about other APs based on the information response message.

[0311] For example, the beacon may not include other AP information from AP MLD (e.g., BSS load information, etc.), or it may only send information about whether AP 2 has updated other AP information (e.g., version / update version).

[0312] STA 2 may need information about AP 1 (or information related to AP 1). STA 2 can request the necessary information through AP 2. STA 2 can obtain the information about AP 1 through a response message to the request. STA 2 can use the information from AP 1 to reselect an appropriate link for link switching. For example, frames used for link switching can be configured in various ways.

[0313] Additionally, STAs can use the aforementioned request method to obtain information about APs owned by the AP MLD even before multi-link establishment. During multi-link establishment between non-AP MLDs and AP MLDs, if the number of APs in the AP MLD is greater than the number of STAs in the non-AP MLD, the STAs in the non-AP MLD must decide which AP in the AP MLD to establish a link with. In this case, the STAs in the non-AP MLD can request link-specific information (e.g., BSS load information of APs owned by the AP MLD) from the APs in the AP MLD before multi-link establishment to know the status of each link. For example, the STA can use a probe request as a request message. As another example, a new frame can be defined for the request message. STAs can send request messages by including indicators for requesting specific elements (e.g., request element, extended request element, PV1 probe response option element, etc.) and indicators for indicating specific link information (e.g., link ID, etc.).

[0314] For example, a STA that is not part of an AP MLD can send a request message including an indication of the current BSS load information of all APs in the AP MLD to which it is to connect. Upon receiving the request message, the AP can send the necessary information (BSS load information of all APs in the AP MLD to which the AP is connected) to the STA in a response message based on the STA's indication. At this point, the STA, which checks the BSS load information of each AP, can select the link to connect to in order of the BSS with the lowest BSS load (i.e., the AP). The STA can indicate the selected link during multi-link establishment. In other words, information about the selected link can be sent to the AP during multi-link establishment.

[0315] In this way, the STA can use the above-described request method as a way to obtain information for each AP in the AP MLD before establishing multiple links in order to select the link to be connected.

[0316] The following text may introduce new elements / fields that include information for STAs that are not part of the AP MLD to select the appropriate link.

[0317] For example, a "Ratio per Link" (element / field) could be proposed. "STA Ratio per Link" could include information about the ratio of the number of STAs connected to each link. Examples of specific details for "STA Ratio per Link" can be found through... Figure 21 To describe.

[0318] Figure 21 A specific example of the STA ratio for each link is shown.

[0319] Reference Figure 21 The STA ratio (element / field) for each link can include information about the number or ratio of STAs connected to each link in the entire AP MLD.

[0320] For example, if a total of 50 STAs are connected to an AP MLD with 3 links, then 10 STAs can connect to link 1 and 20 STAs can connect to link 2. The AP MLD can send information about the STAs connected to each link, or the percentage (%), to the non-AP MLD via the STA ratio (element / field) for each link.

[0321] For example, when information about the STAs connected to each link is represented as values, link 1 can be represented / set to 10 and link 2 can be represented / set to 20. Therefore, the value of STA ratio 1 for each link can be set to 10. Additionally, the value of STA ratio 2 for each link can be set to 20.

[0322] As another example, when information about the STAs connected to each link is expressed as ratios, link 1 can be represented / set to 20 (10 / 50)% and link 2 can be represented / set to 40 (20 / 50)%. Therefore, the value of STA ratio 1 for each link can be set to 20. Additionally, the value of STA ratio 2 for each link can be set to 40.

[0323] The examples above are illustrative, and information about the STAs connected to each link can be set in various ways. In addition to the examples above, information about the STAs connected to each link can also be set to relative values.

[0324] Based on the information about the STAs connected to each link, the STA can check / obtain the number and ratio of STAs connected to each link, and can use it as information for link selection.

[0325] According to one implementation, in addition to the "ratio per link" (element / field) mentioned above, various other information / elements / fields may be included in the information response message. For example, the following information / elements / fields may be included in the information response message.

[0326] - BSS load information for each AP

[0327] - STR capability information between links

[0328] - TXOP information for each link

[0329] - NAV information for each link

[0330] - Recommended link information (i.e., the "Recommended Link" element)

[0331] - Link-specific STA ratio information (i.e., the "STA ratio for each link" element)

[0332] - etc.

[0333] In addition to the information / elements / fields mentioned above, various other information required for link selection can be included in the information response message and sent.

[0334] Upon receiving information such as the example above, the STA can select the AP to which it wants to change or reconnect based on the received information, and then send a request message to request link reconnection. Upon receiving the request message, the AP MLD can send a "Accept" response message if it accepts the request. If the AP MLD rejects the request, it can send a "Reject" response message.

[0335] If the request is accepted, the AP can perform frame exchange via the link with the reselected AP after sending a response message. Conversely, if rejected, the STA can use the existing link as is.

[0336] 2) Non-pleading method

[0337] Unlike the request method where non-AP MLDs directly request additional information, the non-request method allows AP MLDs to send additional information to non-AP MLDs via beacon frames or individual frames (e.g., fields of QoS data frames (11ax Standard A control fields), management frames, FILS discovery frames, non-request probe response frames, PS polling frames, or empty frames, etc.). As another example, a new frame can be defined as a frame used to send additional information to a non-AP MLD.

[0338] For example, if the beacon period is quite long, the necessary information for link switching in a non-AP MLD may be insufficient or outdated. Therefore, the AP can send a frame to the non-AP MLD that includes the link capability information of the AP MLD. The non-AP STA can then obtain up-to-date information about the capabilities of each link in the AP MLD. Frames can be sent periodically or aperiodically.

[0339] For example, when frames are sent periodically, the AP can send frames at regular time intervals to share the latest information about the AP. In this case, the time interval should be shorter than the beacon period sent by the AP. Alternatively, when using FILS discovery frames as frames, frames can be sent every 20 µs. As another example, a period agreed upon between the AP and STA through capability negotiation can be used. For example, the transmission period can be indicated by the "Periodic" field and "Interval" field / subfield values ​​of the IOM capability element.

[0340] As another example, when frames are sent aperiodically, the AP can send a frame whenever an update event occurs in the AP's information (capabilities, BSS parameters, operational elements). As a specific example, whenever the AP's link capabilities change in the AP MLD, the updated information can be sent to the connected STAs. In this case, the STAs can maintain up-to-date information about the link capabilities.

[0341] Based on the example above, since non-AP STAs do not send request messages to acquire individual link capabilities, there is a relatively lower frame switching overhead compared to the pleading method. Furthermore, since STAs can receive updated information whenever the primary information is updated, there is an effect that STAs can effectively utilize the received information.

[0342] You can refer to this. Figure 22 Examples of specific AP MLD and non-AP MLD operations based on non-request methods are provided.

[0343] Figure 22 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0344] Reference Figure 22 The AP MLD can send the necessary information for link reselection to a non-AP in a separate frame (e.g., a PS polling frame or an empty frame) without a separate request message from the non-AP MLD.

[0345] According to the implementation method, with Figure 22Unlike other methods, the AP MLD sends information about link capabilities to the STA via fields in DL frames (e.g., QoS data frames) sent by the AP MLD to the non-AP MLD, even without a separate request message from a non-AP MLD. See also... Figure 23 To describe the operation of AP MLD and non-AP MLD according to the above implementation.

[0346] Figure 23 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0347] Reference Figure 23 AP 2 can send information about another AP (or information about other APs) to STA 2 based on a DL frame (i.e., DL 1). In other words, the DL frame can include information about other APs. For example, information about other APs can be included in the A control field of the 802.11ax standard. According to the above implementation, frame overhead can be reduced because existing DL frames are used without separate messages. If critical information of other APs changes and real-time information is required, the updated information can be sent through a separate message, such as... Figure 23 The implementation method is the same.

[0348] For example, the key information for an AP may include the following A to Q.

[0349] A. Includes elements of the channel handover announcement.

[0350] B. Includes elements of the extended channel switching announcement.

[0351] C. Modification of EDCA parameter elements

[0352] D. Includes quiet elements

[0353] E. Modification of DSSS parameter set

[0354] F. Modification of CF parameter set elements

[0355] G. Modification of HT operation elements

[0356] H. Widebandwidth channel switching elements include

[0357] I. Includes Channel Switching Packaging Elements

[0358] J. Includes operation mode notification elements

[0359] K. The inclusion of quiet channel elements

[0360] L. Modification of VHT operation elements

[0361] M. HE operation element modification

[0362] N. Insertion of broadcast TWT elements

[0363] O. BSS color change announcement elements include

[0364] Modification of P. MU EDCA parameter set elements

[0365] Q. Modification of parameter set elements for space reuse

[0366] Therefore, regardless of the beacon frame period, the non-AP MLD can obtain the latest link capability information. 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 request a link change or reconnect to the AP MLD by reselecting an appropriate link. The request message can include information about the link to be reconnected and AP information. Furthermore, the AP MLD receiving this message can send an "Accept" response message when accepting the request and a "Reject" response message when rejecting the request.

[0367] If the request is accepted, the AP can perform link (re)establishment by exchanging frames with the reselected AP after sending a response message. Conversely, if rejected, the STA can use the existing link as is.

[0368] 3) General Method

[0369] According to a general approach, a non-AP MLD can request link changes or reconnection based on the information it currently possesses without requesting additional information. The information used in this case may include AP MLD information and non-AP MLD messages included in previously received beacon or management frames (e.g., STR capability information for each link, link status (enabled / disabled) information, etc.).

[0370] Unlike the pleading method, the STA can send a link change or reconnection request message directly to the AP MLD without requesting separate information from the AP MLD. The request message can include AP information and link information to be reconnected. Upon receiving the request message, the AP MLD can send an "Accept" response message if it accepts the request, and a "Reject" response message if it rejects the request.

[0371] If the request is accepted, the AP can perform frame exchange via the link with the reselected AP after sending a response message. Conversely, if rejected, the STA can use the existing link as is.

[0372] You can refer to this. Figure 24Examples of specific AP MLD and non-AP MLD operations based on the general method are described.

[0373] Figure 24 Examples of operations for AP MLDs and non-AP MLDs for link changes or reconnections are shown.

[0374] Reference Figure 24 STA 2 may want to change the link directly for QoS guarantee reasons. If STA 2 has previously received information from AP MLD (e.g., information received via beacon frames or management frames) or has already determined the link it wants to reconnect to, STA 2 may request a link change or reconnection without a separate information request.

[0375] STA 2 can send STA information (e.g., STA ID, etc.) and information about the link to be changed (e.g., link ID or AP BSS information, etc.) in a link switching request frame. Upon receiving this, when the change is accepted, AP MLD can send a link switching response frame "acknowledgment" to STA 3 via existing link 2. Afterwards, STA 2 (not AP MLD) can reconnect to AP 3 after the link (re)establishment process is performed.

[0376] Signaling used to indicate link changes and reconnection methods

[0377] To implement the methods described above, a mutual agreement process may be required between the AP MLD and the non-AP MLD. For this purpose, the signaling method for enabling the proposed methods is described in the following specification.

[0378] First, new elements for indicating the methods described above can be proposed. The following describes an implementation of signaling for indicating link change and reconnection methods, but the above implementation can also be applied to implementations of signaling for indicating anchor link change and reconnection methods.

[0379] Signaling procedures for indicating link changes and reconnection methods can be executed during or after multi-link establishment. Additionally, the new elements presented below can be used in signaling procedures for indicating link changes and reconnection methods. For example, these elements can be included in a standard (re)association frame or a new frame.

[0380] IOM (Information Acquisition Methods) capability element

[0381] IOM capability elements can include information about whether a method for obtaining additional information about multiple links is enabled. For example, during a multiple link establishment process (e.g., a capability negotiation process), when the AP MLD and non-AP MLD exchange messages regarding operational agreements, the IOM capability value can exist in an element of the message. The presence of an IOM capability value in an element of the message can indicate that IOM capabilities are supported.

[0382] According to the implementation method, when an AP MLD supports IOM capability, the AP can internally share information from other APs and possess that information. An MLD that does not share information from other APs cannot support IOM capability.

[0383] According to the implementation, when the value of the IOM capability element is set to a first value (e.g., 1), the IOM capability element can mean that the IOM is activated and operates 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 can mean that the IOM is disabled.

[0384] According to one implementation, an IOM capability element may include various fields / elements to indicate various operations. For example, an IOM capability element may include the various fields / elements described below. However, the fields / elements added to the IOM capability element may be set differently depending on whether the AP MLD requests a link change or not. Additionally, at least some of the fields / elements added to the IOM capability element may be omitted. For example, fields / elements containing information that does not need to be indicated may be omitted from the fields / elements added to the IOM capability element.

[0385] The following sections describe examples of various fields / elements defined / configured to obtain additional information about multiple links. These fields / elements can be configured independently, or two or more fields / elements can be combined and transmitted over various frames. For example, the fields / elements described below can be included in other elements to perform defined operations. As another example, the fields / elements described below can be added to other elements and used as individual elements or as independent fields.

[0386] Method type (or method) field / element

[0387] The method type field / element (hereinafter, method field / element) can include information about the operation method of the IOM. In other words, the method field / element can indicate the operation method of the IOM. For example, when a 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 methods mentioned above (e.g., request method, non-request method, general method).

[0388] For example, a requested method can be indicated / used based on the first value of the method field / element (e.g., 0). A non-requested method can be indicated / used based on the second value of the method field / element (e.g., 1). A generic method can be indicated / used based on the third value of the method field / element (e.g., 2). Both a requested method and a non-requested method can be indicated / used based on the fourth value of the method field / element (e.g., 3).

[0389] As another example, a 1-bit method field / element can be used. In this case, based on the value of the method field / element being the first value (e.g., 0), a request method can be indicated / used. Based on the value of the method field / element being the second value (e.g., 1), a non-request method can be indicated / used.

[0390] As another example, two digits can be used as a method field / element. In this case, it can indicate whether each method is used once or repeatedly.

[0391] Link range field / element

[0392] When requesting information from an AP MLD, a non-AP MLD can indicate the range of links requested via the Link Range field / element. The Link Range field / element can include information about whether the STA wants to request information about all links within the AP MLD or about some links within the AP MLD.

[0393] For example, when the value of the link range field / element is the first value (e.g., 0), the link range field / element may mean a request for information about all links within the AP MLD. When the value of the link range field / element is the second value (e.g., 1), the link range field or element may mean a request for information about some links within the AP MLD.

[0394] In this case, if the value of the link range field / element is the first value (e.g., 0), then since it is a request for all links in the AP MLD, separate link indication (e.g., "Link Condition" field) information is not needed. Conversely, when the value of the link range field / element is the second value (e.g., 1), because the information is a request for some links within the AP MLD, link indication information is needed. For example, this field can be included and used in a multi-link element defined in 802.11be. Figure 25 The currently defined multilink element is shown in the figure.

[0395] Figure 25 An example of adding a multi-link element in a probe request is shown.

[0396] like Figure 25 As shown, when a non-AP MLD sends a request message to request AP MLD information, a "range" field can be added and used in the multi-link element. Figure 26 An example is shown in the figure.

[0397] Figure 26 An example of using the link range field in a multi-link element is shown.

[0398] like Figure 26 As shown, the link range can be used in conjunction with the MLD MAC address field to indicate whether information on all links within the MLD is requested or information on some links is requested. In this case, if the field value is 0, it means that information on all links is requested, so no additional link indicator information is needed, and therefore the "Per-STA Profile(x)" sub-element can be omitted.

[0399] Additionally, this field can be used by being added to another element that is not included in a multi-link element defined by 802.11be. Figure 27 An example is shown in the figure.

[0400] Figure 27 An example of the newly proposed field for indicating link changes and reconnections is shown.

[0401] like Figure 27 As shown, several fields presented in this specification can be used together to instruct the STA to, as... Figure 27 The integrated form shown illustrates the scope and conditions of the information requested from the AP MLD. Alternatively, when requesting information from the AP MLD, the STA may include each field presented independently in the request message, and may omit them if necessary.

[0402] Information range fields / elements

[0403] When a non-AP MLD requests information, the information range field can be used to indicate the range of information.

[0404] For example, when the information scope field has a first value (e.g., 0), it can indicate that only a portion of the information possessed by the AP is provided. When the information scope field has a second value (e.g., 1), it can indicate that all the information possessed by the AP is provided.

[0405] According to one implementation, an information scope field can be defined to indicate a request for all or part of the information (elements) possessed by the AP, but the STA can request more detailed information through additional subfields. For example, a subfield indicating the scope of information to be provided (e.g., all or part of the information) can be included in the information scope field. For example, a subfield indicating the scope of information to be provided can be defined / set as a full / partial subfield.

[0406] According to the implementation method, a new subfield can be proposed to indicate whether all information is received or only the modified information among all information is received. In other words, the proposed subfield can indicate whether all information is received or only the modified information among all information is received.

[0407] For example, a subfield indicating whether to receive all information or only the changed information from all information can be defined / set to update only the subfield.

[0408] If the STA wants to receive only the changed information, the update-only subfield value can be set to 1. In other words, if the STA wants to receive only the changed information, it can set the update-only subfield value to 1. For example, when the update-only subfield value is set to 1, according to the request method, when the STA requests information, the AP (or AP MLD) can only send the changed information (i.e., the updated information) from the requested information. As another example, when the update-only subfield value is set to 1, according to the non-request method, the AP can only notify information that has changed within the information range set by the STA.

[0409] Based on the example above, in order to receive only the changed information, the "Update Only" subfield within the information scope field has been proposed, but it is not limited to this. To receive only the changed information, separate fields or elements can be defined / configured.

[0410] According to the above implementation, the range of information that the STA can request can be set to either the updated information or all information. In this case, the STA, which does not require a large amount of frame overhead, can request to receive only the changed information. Therefore, there is an effect of reducing overhead.

[0411] Link condition fields / elements

[0412] The link condition field can be used to indicate the specific link being requested. In other words, the link condition field can include information about the specific link being requested. The link condition field can be used when a STA wants to receive only specific link information from an AP.

[0413] The link condition field can be displayed as a link identifier (e.g., link ID, BSS ID). In other words, the link condition field can include information about the link identifier (e.g., link ID, BSS ID). In other words, the link identifier can be used to specify the link used to obtain information.

[0414] For example, if a STA connected to link 1 wants to request information about links 2 and 3 from the AP only, the STA can request this information by specifying links 2 and 3 in the link condition field. For instance, when the value of the aforementioned information range field is 1, all information corresponding to links 2 and 3 can be sent. In another example, when the value of the aforementioned information range field is 0, only the portion of information specified by the STA can be sent on links 2 and 3. According to the implementation, the portion of information specified by the STA can be determined through the following information condition field.

[0415] According to the implementation method, when the link condition field has no value or the value is 0, the AP can determine that there is no link condition. Therefore, the AP can provide / send information about all links to the STA.

[0416] Information condition fields / elements

[0417] The information condition field can be used to indicate the specific type of information requested. In other words, the information condition field can be used when the STA wants to receive only specific information from the AP.

[0418] For example, an information condition field can be used only when the information range field is set to 0. In another example, an STA can use an information condition field to indicate specific information even when there is no information range field.

[0419] For example, within the information conditions field, information that the STA can specify (e.g., BSS load, STR capability, etc.) can be displayed as a bitmap. For example, the type of information provided by the AP and the order or indication method within the bits can be set in various ways.

[0420] According to the implementation method, the information condition field can be used in conjunction with the link condition field described above. According to the implementation method, the information condition field can send various conditional request information to the STA (or AP) based on combinations of various fields / elements.

[0421] At this point, elements from existing standards can be reused to request specific information from the STA. For example, a request for IE or an extension of the STA could be used. The element information for this is as follows: Figure 28 and Figure 29 As shown in the image.

[0422] Figure 28 An example of requesting IE format is shown.

[0423] Figure 29 An example of an extended request in IE format is shown.

[0424] Figure 28 and Figure 29 The element can be used to request specific information in a probe request frame or information request frame. When the STA indicates a list of information expected to be responded to as the ID of the requested element, the AP sends the corresponding information by including it in the probe response frame or information response frame. Therefore, in this specification, the element can be reused as an indicator for requesting specific information, and can also be used together with a link identifier (e.g., link identifier) ​​to request desired information for a desired link. For example, if in Figure 28 and Figure 29 If the request element mentioned above indicates the element ID used for BSS load information and the information about AP 2 is indicated as a link identifier, then only BSS load information for AP 2 can be requested. This element ID information can be used, together with the link ID information, to indicate specific information for a specific AP in various combinations. If a new frame for information requests is defined in this disclosure instead of an existing frame, it can be reused. Figure 28 and Figure 29 The request element and its extended form.

[0425] Additionally, existing standards provide PV1 probe response option elements to request specific information, and these elements can be reused as a method to indicate specific information. This is the method used by the STA to request optional information as a probe request for desired information. For frequently used information, each piece of information is indicated by a probe response option bitmap, as shown below. However, in the case of 802.11be, since MLD must be taken into account to provide multi-link information, the STA can use link identifiers along with bitmap indicators in various combinations to request specific information for a specific link, as shown below. However, in this case, since there may be newly defined optional information (e.g., STR capabilities) in 802.11be along with multi-link information, if the PV1 probe response option element is reused, a new or additional bitmap must be defined for the information that needs to be newly defined or additionally obtained in 802.11be.

[0426] Figure 30 An example of the PV1 probe response option element format is shown.

[0427] Send periodic fields / elements

[0428] If a STA wants to receive information in a non-requested manner, it can indicate whether to receive the message containing the information periodically or non-periodically by sending a periodicity field.

[0429] For example, when a STA wants to receive information non-periodically, the AP can notify the STA of updated information whenever other APs update their information.

[0430] In another example, when the STA instructs to receive information periodically, the STA can receive messages including that information at set periodic intervals.

[0431] According to the implementation method, the transmission periodicity field can be set to 1 bit. When the value of the transmission periodicity field is set to 1, the STA can receive / obtain information through a periodic method of periodically receiving messages. When the value of the transmission periodicity field is set to 0, the STA can receive / obtain information through a non-periodic method of receiving messages.

[0432] Sending interval field / element

[0433] According to the implementation method, when a STA wants to periodically receive information from other APs, the STA can directly set the period. The STA can send information about the period used to receive information from other APs based on the transmission interval field. However, this period can be set to be shorter than the beacon transmission period. For example, when using FILS discovery frames, this period must be set to 20 µs.

[0434] As mentioned above, it can be defined as a separate field within an element indicating the sending period, or it can be defined as a subfield within a sending periodic field.

[0435] According to the implementation method, the fields / elements defined / configured to obtain additional information about the multi-link are not limited to the fields / elements mentioned above, and various fields / elements can be further set.

[0436] Therefore, an MLD (AP MLD or non-AP MLD) can use at least one of the aforementioned elements / fields during the multi-link establishment process to indicate the IOM capabilities negotiated between the AP MLD and the non-AP MLD. Furthermore, after the multi-link establishment is complete, the MLDs can update the agreed-upon content between them through separate message exchanges.

[0437] According to the implementation method, when the IOM capability is activated, the AP MLD and non-AP MLD can operate based on the implementation method for link changes and reconnection.

[0438] The following describes examples of the operation of the AP MLD and non-AP MLD when IOM capability is activated. For example, the non-AP MLD can request additional information for multi-links by sending the aforementioned fields / elements to the AP MLD. The non-AP MLD can send an IOM capability element to the AP MLD that includes the fields / elements mentioned above. Including the aforementioned fields / elements in the IOM capability element is exemplary and can be sent as standalone fields / elements.

[0439] For example, during multi-link establishment, a non-AP MLD can send an IOM capability element to the AP MLD, including "Method Field = 0" and "Information Range Field = 1," and agree upon this with the AP MLD. In this case, after multi-link establishment, the non-AP MLD operates using a request method, and when requesting information, it can request multi-link information (e.g., information about other APs) that includes all information contained in the beacon. Therefore, the AP MLD only receives request messages from the STA. Link information can be provided / sent as a response message. Upon receiving the request message, the AP MLD can send a response message to the STA including information about all links within the AP MLD. Information about all links in the AP MLD can include all information included in the beacon.

[0440] In another example, a non-AP MLD can send IOM capability elements including "Method field=1", "Information range field=0", "Link range=link id 2", and "Information condition field=(value of BSS load displayed via bitmap)", and can agree on this with the AP MLD. In this case, after the multi-link is established, the non-AP MLD can operate in a non-request manner. Therefore, the AP can send the BSS load information for link 2 to the STA via a separate message without a separate request message.

[0441] In another example, a non-AP MLD can send IOM capability elements including "Method field=0", "Information range field=0", "Update only field or subfield=1", and "Information condition field=(value of BSS load displayed via bitmap)", and can agree on this with the AP MLD. In this case, after the multi-link is established, the non-AP MLD can operate using a request method. Therefore, when the STA requests information, the AP MLD (or AP) can include only the updated (changed) information from the BSS load information of all APs connected to the AP MLD in the response message and send it to the STA.

[0442] In this specification, several options for new elements are presented so that the STA can request partial information (i.e., target information) from other APs of the connected AP MLD.

[0443] Figure 31 An example of an MLD request element is shown.

[0444] Reference Figure 31 "Number of Link IDs" is a field used to indicate the number of APs (i.e., links) requested when a STA requests information about a specific AP.

[0445] The "Link ID" field contains indicator information about the AP requested by the STA.

[0446] For example, when a STA sends a probe request frame including the above MLD request elements, the AP receiving the request message responds with a probe response including all information of the AP indicated in the corresponding element. If the STA wants to request some but not all information of the indicated AP, it sends the probe request frame along with the MLD request element and the request element or extended request element defined in the existing standard. Upon receipt, the AP responds with a probe response including only the information indicated by the request element or extended request element.

[0447] In addition, it was also proposed Figure 32 New elements in.

[0448] Figure 32 Another example of an MLD request element is shown.

[0449] Reference Figure 32 "Number of Link IDs" is a field used to indicate the number of APs (i.e., links) requested when a STA requests information about a specific AP.

[0450] The "Link ID" field contains indicator information about the AP requested by the STA.

[0451] "Request Element ID / Request Element ID Extension" is a field that includes the element ID information of the requested information when the STA requests specific information (i.e., an element). When the element ID corresponds to 0 to 254, this field only includes the element ID information, and when the value is 255 or greater, it is identified as the extended element ID, and the requested element ID extension information must be included together. In this case, the information corresponding to "Request Element ID / Request Element ID Extension" can be defined in the form of a field, but can be as follows: Figure 33 The element shown is defined as a new element and is included as a child element within the MLD request element. It can be as follows: Figure 33The diagram illustrates the definition of a new element for this purpose. This element has the advantage of reducing overhead because it can be indicated as a single element without distinction between existing request elements or extended request elements.

[0452] Figure 33 An example of defining a new element based on an MLD request element is shown.

[0453] For example, when a STA sends a probe request frame that includes the above MLD request elements, the AP receiving the request message responds by including information about the AP indicated in the corresponding element in the probe response.

[0454] Reference Figure 33 Depending on whether the "Request Element ID / Request Element ID Extension" field is omitted in the corresponding element, the AP identifies the information requested by the STA as all or part of the information. The element ID value information defined in the 802.11 standard is as follows. Furthermore, the definitions of "Request Element ID" and "Element ID Extension" mentioned in this specification are the same as those in existing standards.

[0455] For example, when a STA requests information about an AP or other APs, it sends a probe request frame including the MLD request element mentioned above. Upon receiving this, the AP responds with a probe response frame containing only the information requested by the AP via the "Link ID" field and the information requested via the "Request Element ID / Request Element ID Extension" field.

[0456] If the STA sends the request by omitting the "Request Element ID / Request Element ID Extension" field, the AP will respond with a probe response frame that includes all information requested by the AP via the "Link ID" field upon receipt.

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

[0458] However, the STA can request different information for each link as needed. This specification presents several options for this purpose.

[0459] First, such as Figure 34 As shown, a format for requesting different information for each link is also proposed.

[0460] Figure 34 Another example of an MLD request element is shown.

[0461] like Figure 34As shown, STA is a method of including and indicating existing request elements and / or extended request element information for each link within the MLE request element so as to request different information for each link. At this point, a new field or element, "Number of Elements," is defined to indicate the length of the requested elements. This information refers to the number of elements requested relative to link ID (x).

[0462] Upon receiving the request, the AP examines the information requested for each link differently based on the MLD request element and responds by including it in the response frame.

[0463] In this case, Figure 35 The diagram illustrates an implementation when using fields proposed in this disclosure instead of existing request elements or / and extended request elements. Each field or element may be omitted as needed.

[0464] Figure 35 Another example of an MLD request element is shown.

[0465] Second, when the STA requests information, such as Figure 36 As shown, a format is proposed to distinguish between common information requested the same for all links and link-specific information requested differently for each link.

[0466] Figure 36 Another example of an MLD request element is shown.

[0467] like Figure 36 As shown, when a request element or / and extended request elements are included before the Link ID Number field, it indicates an element of common information for a link-to-link common request, which will be indicated later. The information listed after the element number, together with the Link ID(x) following the Link ID Number field, indicates element information for each link request. Each field or element can be omitted as needed.

[0468] In this case, Figure 37 The diagram illustrates an implementation when using fields proposed in this disclosure instead of existing request elements or / and extended request elements. Each field or element may be omitted as needed.

[0469] Figure 37 Another example of an MLD request element is shown.

[0470] like Figure 37As shown, when a request element or / and extended request elements are included before the Link ID Number field, it indicates an element of common information for a link-to-link common request, which will be indicated later. The information listed after the element number, together with the Link ID(x) following the Link ID Number field, indicates element information for each link request. Each field or element can be omitted as needed.

[0471] Fourth, when STA requests information, the common information requested in the same way for all links is used together with the MLD request element to indicate a single request element or an extended request element, such as... Figure 38 As shown in the image.

[0472] Figure 38 An example of a field that requests public information is shown.

[0473] When a STA requests information about multiple links in an AP MLD via a request frame, a method is proposed to indicate the commonly requested information using existing request elements or / and extended request elements. When information is requested differently for each link, a method is proposed to indicate it using MLD request elements. The AP receiving the request message identifies the information included in the request or / and extended request elements as commonly requested information for the links indicated in the MLD request elements, and sends the corresponding element information for all links indicated by the MLD request elements in the response message. Alternatively, when a STA requests different information for each link, the AP includes the information indicated for each link in the MLD request elements in the response message and sends it.

[0474] This specification also describes a method in which the STA uses the Multilink (ML) IE defined in the 802.11be standard to request partial information from other APs connected to the AP MLD.

[0475] Figure 39 An example of the ML IE format defined in 802.11be is shown.

[0476] In 802.11be, such as Figure 39The diagram illustrates the definition of an ML multi-link information element (IE) to define information for each link. Depending on the proposed functionality, elements or fields can be added later. The Per-STA Profile(x) sub-element can include various information about the link. The corresponding sub-element includes the scope and content of the information included in the corresponding sub-element and the corresponding link ID through the Per-STA Control field, and then lists the information (elements) corresponding to the information requested by the STA. If non-inherited information exists, it can be included using non-inherited elements. The complete profile in the Per-STA Control sub-element is a field that distinguishes whether the included information is complete or partial information about the link.

[0477] Therefore, by including the ML IE in a request frame (e.g., a probe request frame), the STA can use it to request partial information from other APs and propose various options for this purpose.

[0478] In this specification, the following limitations are defined for using ML IEs for MLD probing. If a STA uses an ML IE for MLD probing in a probe request frame, the element information (e.g., element x, ..., element n) provided by the Per-STA Profile(x) can be omitted and sent to reduce overhead. (However, when using an ML IE in an association request / response frame for association, the element information must be included.) If the information requested by the STA is complete link information, the complete information bits are indicated via the Per-STA control field, and the subsequent list of element information is omitted and sent. Otherwise, partial information bits are indicated via the Per-STA Control field, and information about the requested element ID is appended. However, the following details various options related to the case where the STA requests partial rather than complete information for a specific element.

[0479] As described above, in the ML IE defined by 802.11be, the included information can vary depending on whether the corresponding element is included in the associated frame or the probe frame, or whether the corresponding frame is a request or a response. For example, if the STA uses the ML IE when making a probe request, the element containing various information from the Per-STA Profile(x) can be omitted, but otherwise, the element information must be included. Therefore, this specification provides control fields to indicate this.

[0480] The format of the multilink element and multilink control field defined in the current 802.11be standard is as follows: Figure 40As shown in the image.

[0481] Figure 40 Examples of multi-link element format and multi-link control field format are shown.

[0482] At this point, a field 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 present per STA". The field name can be redefined as needed. This field indicates the presence or absence of element list information for each STA requested by the current ML IE. If the value is 1, it means that element information following the Per-STA Control field in the Per-STA Profile(x) field is included, while if it is 0, it means that element information following the Per-STA Control field in the Per-STA Profile(x) field is omitted. This implementation is used in... Figure 41 As shown in the image.

[0483] Figure 41 An example of the multi-link control field format is shown.

[0484] Furthermore, as mentioned above, in the ML IE defined by 802.11be, the included information can change depending on whether the corresponding element is included in an associated frame or a probe frame, or whether the corresponding frame is a request or a response. Therefore, a field is proposed that can indicate this. The corresponding field is included in the ML IE of the request / response frame and indicates the type of frame currently being sent by the STA. Therefore, the content or order of other elements (elements consisting of 0 or variables) can be changed.

[0485] "Frame Type": An indicator that specifies the type of frame currently being sent by the STA. The value of the corresponding field indicates the type of frame currently including the ML IE. For example, it can be indicated by classifications such as 0: Association Request, 1: Association Response, 3: Probe Request, 4: Probe Response, etc. This can be represented as an integer value or a bitmap. Additionally, if distinguishing between MLD probes configured in 802.11be, additional classifications can be added such as 5: MLD Probe Request Frame, 6: MLD Probe Response Frame, etc. In this way, it is an indicator that the elemental composition of the MLIE changes according to the frame type. Each frame type can be listed as a subfield in the "Frame Type" field, and in the case of 1, the indicated frame type can be configured.

[0486] At this point, the sent frames can be categorized into multiple subfields within "Frame Type" based on their various functions. Therefore, in this specification, "Request Type" is defined as a subfield within "Frame Type" that categorizes frames according to their purpose. The corresponding "Request Type" subfield can be further categorized within the message types classified as "Frame Type," based on the purpose of the currently sent frame. For example, if "Frame Type" sends 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), but whether the information is complete or partial, when partial information is requested, and what specific information is requested (e.g., critical update information, a subset of links not set for link reset, etc.) are considered as requests under "Request Type." If "Frame Type" is set to (re)association request frame for link switching to a specific AP, the "Frame Category" field is set to (re)association request frame (for reference, MLD probe request frames are currently used in 802.11be). Since all frames except those of the same basic type are categorized, the (re)association request frame will be categorized as the basic type. However, the frame type classification can change in the future, depending on the purpose of the requested frame (e.g., TID-link mapping, link switching between MLDs, link switching within the same MLD), which can be indicated in the "Request Type" subfield. Upon receipt, non-AP STAs or APs can determine the purpose of the frame sent by the STA in more detail by sending the subfield value along with the type of the currently received frame, and by including the appropriate information in the response frame.

[0487] The following are various formatting options and operations for ML IE regarding the situation where STA requests partial rather than complete information about a specific element.

[0488] First, it is a method of sending request elements and / or extended request elements that indicate the information that the STA wants to request from the corresponding AP in the Per-STA Profile(x) in the existing ML IE.

[0489] The AP receiving the request message indicating the corresponding information can learn the partial information of the link that the STA wants to request through MLIE information and send it by including that information in a response frame (e.g., a probe response frame). The STA uses the Per-STA Control field in the Per-STA Profile(x) of the MLIE to indicate in the request frame the link ID it wants to request and whether the currently requested information is complete or partial. Additionally, it is a method for displaying the specific information to be requested via a request element or / and extended request elements. Figure 42As shown in the format, the STA can request specific desired information for each link. If the request element or / and extended request elements are omitted, it means that all information for the corresponding AP (i.e., complete information) is requested. However, as suggested above, the element information listed after the Per-STAControl field can be omitted if necessary.

[0490] Figure 42 An example of the ML IE format is shown.

[0491] Second, it is a method of sending the request element ID / request element ID extended field, which indicates the information the STA wants to request from the corresponding AP, within the existing Per-STA Profile(x) in the ML IE. Figure 43 The corresponding fields are defined in the specification and are presented in this specification.

[0492] Figure 43 Another example of the ML IE format is shown.

[0493] Upon receiving the information, the AP can determine the partial information of the link the STA wants to request through the ML IE information and send it by including that information in a response frame (e.g., a probe response frame). The STA uses the Per-STA Control field in the Per-STAProfile(x) within the ML IE to indicate in the request frame the link ID it wants to request and whether the currently requested information is complete or partial. Additionally, it is a method of displaying the specific information to be requested via the request element ID and / or request element ID extension. Omitting the request element ID / request element ID extension field means requesting all information from the corresponding AP (i.e., all element information). An example of the corresponding format is shown below. However, as suggested above, the element information listed after the Per-STA Control field can be omitted if necessary.

[0494] Figure 43 The format has the advantage of reducing the overhead of default fields (e.g., element ID, length) by sending the element indication information defined in the 802.11 standard as a single message instead of dividing it into request elements or / and extended request elements.

[0495] Third, it is a format in which the STA distinguishes between common information that the STA wants to request from all APs and link-specific information by sending request elements and / or extended request elements to indicate the information the STA wants to request from each AP. Figure 44 This format is defined in [the document / reference].

[0496] Figure 44 Another example of the ML IE format is shown.

[0497] When a STA requests information from each AP via a request frame (e.g., a probe request frame), it can make the same request for some information and can request other information for each AP. A format for indicating this is defined, and implementation methods are proposed. Figure 44 As shown, the indicator used to indicate the same information requested by the STA from the AP requesting the information via the request frame is used together with the ML IE in the request frame as a request element for the request or / and extended request. The indicator used to indicate other information requested by each AP uses the request or / or extended request element in the Per-STA Profile(x). However, as suggested above, the element information listed after the Per-STA Control field may be omitted if necessary.

[0498] For example, if the STA displays information corresponding to the TIM element (e.g., element 5=11) as a request element in the probe request frame, indicates the Per-STA Control of the Per-STA Profile(x) in the ML IE as link ID=1, full profile=0 (conversely, if the value is 1, it means all element information is requested), displays information corresponding to the BSS payload element in the request element (e.g., element ID=11), indicates the Per-STA Control of the Per-STA Profile(y) (the profile(y) of each STA) as link ID=2, full profile=0, and indicates and sends information corresponding to the non-inherited element in the extended request element (e.g., element ID=255, element ID extended=56), then the AP responds with a probe response frame that includes the following information.

[0499] - TIM element information for Link 1 and Link 2

[0500] - BSS load element information for Link 1

[0501] - Non-inherited element information of link 2

[0502] STA can request different information for each link by classifying the requested information into common or link-specific categories based on the element hierarchy within the frame.

[0503] In this way, in 802.11be, the inheritance model can be applied to ML probe request frames. As described above, when a STA sends a request including (extended) request elements in an ML probe request, because the inheritance model applies not only to peer APs but also to APs requesting via ML IE (i.e., probe request variant multi-link element), this portion of the information request is accepted by the peer AP as a common information request to all APs. Therefore, when... Figure 44 When an AP receives a probe request frame from the STA that includes an (extended) request element outside the ML IE, it can respond by interpreting it as a common information request to the requested AP (i.e., the AP indicating the information request for other APs in the ML IE) and peer APs, and acknowledging the requested information indicated by the (extended) request element in the ML probe response, including the information corresponding to each AP in the ML IE (i.e., the basic variant multilink element) in the Per-STA Profile.

[0504] Fourth, this is to instruct the STA to send request elements or / and extended request elements within the multi-link element to indicate the information it wants to request for each AP, thereby distinguishing the common information that the STA wants to request for all APs from link-specific information in the request format. Figure 45 This format is defined in [the document / reference].

[0505] Figure 45 Another example of the ML IE format is shown.

[0506] When a STA requests information for each AP via a request frame (e.g., a probe request frame), it can make the same request for some information and request additional information for each AP for another part of the information. A format for indicating this is defined, and implementation methods are proposed. If the request and / or extended request elements are included in the request frame (e.g., a probe request) along with a multi-link element, this means that the STA is requesting partial information about the link it is connected to (i.e., the associated AP). If the STA requests information about APs in the connected AP MLD other than their own link, the indication information for this is included in the ML multi-link element (IE). Therefore, if the request and / or extended request elements are included before the Per-STA Profile(x) element within the ML IE as described above, the corresponding element can indicate information commonly requested by other APs in the AP MLD that the STA is requesting (APs in the AP MLD that the STA is connected to but whose links do not correspond to their own). Information commonly requested by other APs is indicated through request or / and extended request elements in the ML IE, while information requested differently for each other AP is displayed after the Per-STA Control field in the Per-STA Profile(x). This can be indicated by adding request or / and extended request elements. In this case, if the Per-STA Profile(x) in the ML IE includes indicators for the AP corresponding to its own link but not for other APs, the STA can also obtain information about the AP corresponding to its own link through the ML IE. In this case, the request or / and extended request elements included in the ML IE can be omitted to request only partial information about the AP corresponding to its own link.

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

[0508] Fifth, the STA can request complete or partial information about peer APs (i.e., the sending link) and other APs (e.g., other links) through MLD probe requests. Several related situations and implementations are as follows.

[0509] 1) When requesting complete information about a peer AP and also requesting complete information about other APs.

[0510] EHT non-AP STAs can send a message requesting all information about peer APs and other APs using a probe request frame.

[0511] Figure 46 An example of a probe request frame in ML IE format is shown.

[0512] Reference Figure 46 When requesting complete information about peer APs, instead of including the (extended) request element in the core (frame body) of the probe request frame, the "Complete Profile" subfield in the "Control for Each STA" field of the Per-STA Profile in the multi-link element (i.e., the probe request variant multi-link element) is set to 1 to indicate a request for all information about other APs.

[0513] 2) When requesting complete information about a peer AP and also requesting complete or partial information about other APs.

[0514] 2) When requesting complete information about a peer AP and also requesting complete or partial information about other APs.

[0515] EHT non-AP STAs can send a message in a probe request frame requesting all information about the peer AP and requesting all or part of the information about other APs indicated by ML IE.

[0516] Figure 47 Another example of a probe request frame in ML IE format is shown.

[0517] Reference Figure 47 When requesting complete information about a peer AP, or when requesting partial information about another AP without including the (extended) request element in the core of the probe request frame, the STA includes the (extended) request element in the Per-STA Profile (per STA profile) of the multi-link element (i.e., the probe request variant multi-link element), and sets the "Complete Profile" subfield in the "Control for Per STA" field to 0 to indicate a partial information request for the AP. In this case, if the STA wants to request complete information about another AP, it can set the "Complete Profile" subfield in the "Control for Per STA" field to 1 without the (extended) request element in the Per-STA Profile. In this way, a complete or partial information request for each AP can be made using a single probe request frame for the other AP.

[0518] 3) When requesting partial information from a peer AP and requesting complete or partial information from other APs.

[0519] An EHT non-AP STA requests partial information from a peer AP in a probe request frame and can request all or part of the information from other APs indicated by the multi-link element.

[0520] Figure 48 Another example of a probe request frame in ML IE format is shown.

[0521] Reference Figure 48 When requesting partial information about peer APs, the (extended) request element is included in the core of the probe request frame, and when requesting complete information about other APs, the STA sets the "Complete Profile" subfield in the "Control for Each STA" field to 1, without the (extended) request element in the Per-STAProfile (Profile for Each STA) of the multi-link element (i.e., the probe request variant multi-link element), and the STA requests complete information about other APs.

[0522] At this point, if a STA wants to request partial information from another AP, it includes the (extended) request element in the Per-STA Profile (the profile for each STA) and sets the "Complete Profile" subfield in the "Control per STA" field to 0. If the inheritance model is applied to the MLD probe request, the (extended) request element in the Per-STA Profile(x) can be omitted if the requested partial information is the same for both the peer AP and the AP(x) indicated in the Per-STA Profile(x) (i.e., the link). That is, the (extended) request element is only included in the Per-STA Profile(x) if it corresponds to a non-inherited element of the (extended) request element included in the core of the probe request frame; otherwise, it can be omitted.

[0523] exist Figure 49 The diagram illustrates an implementation of applying the inheritance model to MLD probe requests.

[0524] Figure 49 Another example of a probe request frame in ML IE format is shown.

[0525] Reference Figure 49 When an EHT non-AP STA requests partial information from a peer AP via an MLD probe request, the (extended) request element is included in the core of the probe request frame. In this case, if some APs among the APs indicated by the multi-link element (i.e., Per-STA Profile(x)) request partial information different from that of the peer AP, other information can be requested by including the (extended) request element corresponding to the inherited element in the Per-STAProfile(x). At this time, the full profile value of the Per-STAControl field is set to 0.

[0526] Alternatively, when requesting the same partial information as the peer AP to some of the APs indicated by the multi-link element (i.e., Per-STA Profile(y)), the STA omits (extended) request elements in the profile(y) of each STA. In this case, the full profile value of the Per-STA Control field is set to 0. In this way, when the inheritance model is applied to MLD probe requests, if an EHT non-AP STA requests elements (a) and (b) from the peer AP and elements (a) and (c) from the AP(x) indicated by the Per-STA Profile(x), then because there is information requested in the same way from both the peer AP and AP(x) (e.g., element (a)) and also includes other information (e.g., element (c)), the Per-STA Profile(x) must include (extended) request elements indicating the request for information about elements (a) and (c) in order for the AP to distinguish them. (When applying the inheritance model, if there are (extended) request elements in the Per-STA Profile(x), even if there is requested partial information overlapping with the peer AP, the AP will recognize it as a non-inherited element. Therefore, unless the requested partial information is the same as that requested by the peer AP, the (extended) request elements included in the Per-STA Profile(x) must indicate all element information requested by the requesting AP (e.g., AP(x) indicated by the Per-STA Profile(x)), regardless of the partial information requested by the peer AP). However, if the EHT non-AP STA requests elements (a) and (b) from the peer AP, and the EHT non-AP STA requests the same elements (a) and (b) from the AP(x) indicated by the Per-STA Profile(x), then since the information requested by the peer AP and AP(x) is the same, the STA applies the inheritance model and sets the "Complete Profile" subfield in the Per-STA Profile(x) to 0. The (extended) request elements indicating the request for information about elements (a) and (b) can be omitted.)

[0527] In this scenario, when the full profile value of the Per-STA Control field is set to 1, the inheritance model is not applied to the requested peer AP's information, but rather to the full information request for AP(y). That is, in order to apply the inheritance model to the multi-link element of a partial information request for a peer AP, the full profile value of the Per-STA Control field must be set to 0.

[0528] STA can request different information for each link by dividing the requested information into common or link-specific information based on the arrangement of elements in the frame.

[0529] 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 distinguished from common information. As mentioned above, the STA can represent the common information of the corresponding link based on the arrangement of the request element and / or extended request elements. Depending on whether common information is requested, the request element and / or extended request elements may exist before the Per-STA Profile(x) in the ML IE in the request frame. Therefore, as Figure 50 The diagram shows the control fields used to represent them.

[0530] Figure 50 An example of the multi-link control field format is shown.

[0531] Figure 50 The field can be defined as the "Public Information Exists" field, and the corresponding name can be defined later as another name. If this field is indicated as 1, it means that when the STA requests information about other APs from the AP MLD, the request element and / or extended request element for the same information request is included before and sent in the Per-STA Profile(x) element. The request element and / or extended request element included in the Per-STA Profile(x) element indicates the link-specific information requested differently for each AP. If this field is indicated as 0, it means that there is no information that the STA requests in the same way for other APs, and it means that there is no separate request element and / or extended request element before the Per-STA Profile(x) element.

[0532] The following is an example used for this.

[0533] The STA can make partial requests for critical update information from APs in the AP MLD. For this purpose, this specification presents two options. In this case, the AP can correspond to all APs (reporting APs and reported APs) that the STA can obtain through the beacon. Reported APs refer to other APs that the STA can obtain through the beacon's RNR element, as well as other APs in the same AP MLD as the reporting AP, other APs corresponding to the TxBSSID group, and other APs corresponding to non-TxBSSID groups, etc. In other words, the STA can request critical update information from all other APs whose CSN (Change Sequence Number) information can be obtained through the beacon (for reference, the 802.11be convention includes the Change Sequence Field information of other APs in the RNR element of the beacon frame).

[0534] First, a new method for defining a "critical update request" field to request critical update information from other APs.

[0535] - “Critical Update Request” field: This field requests only system information that is defined as a critical update for an AP. Used in conjunction with the link indicator, it is used when requesting system information that is defined as a critical update for a specific link.

[0536] When a STA requests information about other APs regarding AP MLD, if the corresponding field value is set to 1 and sent along with the link indicator information in the request frame (e.g., a probe request frame), the AP responds by including critical update information about the indicated link in a response frame upon receipt. Here, critical update information (a) inclusion of extended channel handover announcements, (b) modification of EDCA parameters, and (c) modification of S1G operation elements refer to various system information defined as critical updates in the existing 802.11 standard system information update process. However, in the case of 802.11be, new information can be defined in addition to the previously defined system information for critical updates, and the critical update information mentioned in this specification refers to information including newly defined critical update information in 802.11be. If the corresponding field value is set to 0 and sent, the AP responds with a response frame as in previous operations. The proposed field can be included in any element within the request frame, and can also be included in and used in the aforementioned MLD request element or ML IE. Implementations for this purpose are described in... Figure 51 As shown in the image.

[0537] Figure 51 An example is shown where the key update request field is included in the ML IE format.

[0538] Reference Figure 51When a STA requests information about a specific link via an MLD probe request, it can request the information corresponding to that specific link through a Per-STA Profile(x). In this case, if the newly defined "Critical Update Request" field is included in the Per-STA Control within the Per-STA Profile(x) and set to 1 for transmission, the AP responds to the link indicated by the Per-STA Profile(x) using a response frame that includes current system information defined as a critical update. Furthermore, when a non-AP STA in a non-AP MLD sends a "Critical Update Request" field value set to 1 via an MLD probe request to request critical update information, depending on the STA's implementation, the Change Sequence Number (CSN) information for each non-AP STA in the non-AP MLD (e.g., Change Sequence Element, Change Sequence Field, etc.) can be sent together or omitted. In this scenario, if an MLD probe request is used to request critical update information from the AP (i.e., the "Critical Update Request" field = 1), and if a change sequence element is used when including CSN information, a separate additional indicator is unnecessary (because the AP can check the presence of the change sequence element by examining its element ID). However, if the change sequence field is used as CSN information, a (sub)field indicating the presence or absence of the change sequence field (e.g., the "CSN Exists" subfield) needs to be defined separately. Therefore, in this specification, an additional indicator for displaying the presence or absence of CSN information in the Per-STA Profile of the ML IE is proposed as follows.

[0539] - "Existence CSN" (sub) field: Indicates the existence of a modified sequence field. When this value is set to 1, it indicates that a modified sequence field exists, and when this value is 0, it indicates that a modified sequence field does not exist.

[0540] -> When the STA requests critical update information from other APs, this field can be used in conjunction with the "Critical Update Request" field (for example, the "CSN Existence" (sub) field can be used in conjunction with the "Critical Update Request" (sub) field in the Per-STAControl field of the Per-STA Profile element in ML IE).

[0541] This field can also be used when an AP (including both reporting and reported APs) announces its CSN information via beacon / probe responses. When using a change sequence element to announce the corresponding CSN information, this field is not required; however, when using a change sequence field, a "Presence CSN" (sub) field indicating the presence of the field is required. In this case, the corresponding (sub) field can be included in various ways depending on where the CSN information for each AP is included. It can be included in the beacon / probe response frame (e.g., when the reporting AP's CSN information is in the beacon / probe response frame), in the common information section of the ML IE (e.g., when the reported AP's CSN information is in the common information section of the ML IE), or in the Per-STA Profile (e.g., when the reported AP's CSN information is in the link information section of the ML IE).

[0542] At this time, 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.), then when a non-AP STA requests critical update information for STA(x) by setting the value of the "Critical Update Request" field in the Per-STA Profile(x) of the multi-link element (e.g., probe request variant multi-link element), the receiving AP can respond to the MLD probe response as follows, depending on whether CSN information is included.

[0543] 1) When a non-AP STA sends an MLD probe request that includes its CSN information (i.e., the most recently received CSN information can be included in the form of a changed sequence element or a changed sequence field) and the "Critical Update Request" field in the Per-STA Profile(x) is 1, A. The AP compares 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) to 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.

[0544] B. However, even in this case, if the received AP MLD does not implement the function of tracking the update information of each CSN of the AP, since it does not know what information has been updated for each CSN version, it can respond by including all current critical update information of AP(x) connected to non-AP STA(x) (i.e., elements classified as critical update events in 802.11be) in the MLD probe response.

[0545] C. In this specification, to reduce the overhead of MLD probe responses, when requesting critical update information, it is proposed to respond with all current critical updates of AP(x) instead of all information of AP(x). Depending on the AP implementation, even if an MLD probe request is received from a non-AP STA with the "Critical Update Request" field in the Per-STA Profile(x) set to 1, the complete profile (i.e., complete information) of AP(x) can still be responded to.

[0546] 2) Case where a non-AP STA sends an MLD probe request by omitting its CSN information (i.e., the most recently received CSN information) and the "Critical Update Request" field in the Per-STA Profile(x) is equal to 1.

[0547] A. Since the AP cannot know the CSN information of the non-AP STA(x), all current critical update information of the AP(x) connected to the non-AP STA(x) (i.e., elements classified as critical update events in 802.11be) can be included in the MLD probe response.

[0548] B. In this specification, to reduce the overhead of MLD probe responses, when requesting critical update information, it is proposed to respond with all current critical update information of AP(x) instead of all information of AP(x). Depending on the AP implementation, even when receiving an MLD probe request from a non-AP STA where the "Critical Update Request" field in the Per-STA Profile(x) is set to 1, it can still respond with the complete profile of AP(x) (i.e., complete information).

[0549] Figure 52 An example of using an MLD probe request with altered sequence elements when requesting critical update information is shown.

[0550] Figure 53 Another example is shown where an MLD probe request with altered sequence elements is used when requesting critical update information.

[0551] For example, when a non-AP STA requests critical update information for a specific STA(x), such as Figure 53 As shown, a critical update request can be set to 1, and sequence number change information (e.g., changing sequence elements or changing sequence fields) can be sent along with it. In this case, non-STAs may omit and send the sequence number change information as appropriate. However, in this scenario, the information included in the MLD probe response from the AP, as defined above, may be limited.

[0552] Figure 54An example is shown where the key update request field is included in the ML IE format.

[0553] Reference Figure 54 When the critical update request field is located in the ML IE as described above, critical update information for all links indicated by Per-STAProfile(x) can be requested. If the critical update request field is included in the location of public information within the ML IE, and the field value is indicated as 1 and sent, the AP responds upon receipt with a response frame including the critical update information for the requested link in the corresponding request frame. Alternatively, the critical update request field can be indicated in a subfield within the multi-link control field of the ML IE. The shape (field, subfield, sub-element, etc.) or location within the ML IE of a field defined in this way can be defined in various ways according to standard definitions.

[0554] Second, a method using a changed sequence element for requesting critical update information from other APs. In 802.11ah, if a changed sequence element is included in and sent in a probe request frame, the AP only sends the changed critical update information for the corresponding link in the compressed probe response frame. 802.11be can also utilize this.

[0555] When a STA makes a probe request by including a change sequence element along with a link indicator for other APs in the probe request frame, the AP receiving the request only includes the key update information of the changed link for the indicated link in its probe response and sends it. The change sequence element can be included in any element or sub-element of the request frame, and can also be included in and used within the aforementioned MLD request element or ML IE. Implementations for this are described in... Figure 55 As shown in the image.

[0556] Figure 55 An example is shown in which altered sequence elements are included in the ML IE format.

[0557] For example, when Figure 55When the change sequence element is included in the MLIE for transmission as shown, for the link indicated by the MLIE, the AP compares its currently held change sequence field value with the change sequence field value in the change sequence element sent by the STA. If a change exists, the AP responds by including the changed critical update information in the probe response. In this case, the change sequence element sent by the STA must include change sequence information for all links requesting information from the MLIE. Therefore, when using existing change sequence elements, additionally requested link indicator information may be required. Furthermore, in this specification, when the change sequence element is included in the MLIE for transmission as described above, the option of including all information related to the critical updates currently held by the AP for transmission is also considered. If the AP compares the value of the change sequence field sent by the STA with the field currently held by the AP and finds a difference, the AP sends all information related to the currently held critical updates to the STA. This method may increase the overhead of the information sent by the AP, but it can be implemented more simply because it is not necessary to store change information for every critical update version for every AP.

[0558] In addition, new elements considering MLD are proposed in this specification.

[0559] "MLD altered sequence elements": can contain elements that change sequence information from multiple links.

[0560] An example used here Figure 56 and Figure 57 As shown in the image.

[0561] Figure 56 An example of MLD changing sequence format is shown.

[0562] Figure 57 This shows another example of MLD changing the sequence format.

[0563] like Figure 56 As shown, the MLD changed sequence values ​​are repeatedly listed for each link, or as... Figure 57 As shown, after indicating the number of links as "number of link IDs", the link ID information and change sequence information can be indicated separately.

[0564] The implementation of MLD in changing sequence elements is as follows: Figure 58 As shown in the image.

[0565] Figure 58 An example of MLD altering sequence elements is shown.

[0566] like Figure 58As shown, when the MLD change sequence element is included in the ML IE in the probe request frame and sent, the AP can compare the change sequence value received for each link with its own change sequence value, and can respond by including the changed key update information of the link corresponding to the updated change sequence value in the response frame. In this case, if the STA does not request other information for each link, the Per-STA Profile(x) sub-element can be omitted and sent.

[0567] At this point, when using existing modified sequence elements, it can be done as follows: Figure 59 It is used as shown in the diagram.

[0568] Figure 59 An example of changing sequence elements in an existing standard is shown.

[0569] Key update information for each link update can be requested by using existing changed sequence elements in the ML IE as is. Implementations for this are described in... Figure 59 As shown in the image.

[0570] Figure 60 Another example is shown where altered sequence elements are included in the ML IE format.

[0571] Reference Figure 60 When the STA includes a change sequence element in the Per-STA Profile(x) within the ML IE of the probe request, this signifies a request for critical update information regarding the changes to the link indicated by the Per-STA Profile(x). Therefore, after examining the change sequence element included in the request frame, the AP compares the received change sequence value with its own change sequence value, and when an update exists (i.e., when there is changed information that the STA needs to update), the AP can send a response frame including the changed critical update information or a response frame including all critical update-related information.

[0572] Third, the sequence field is modified to be used in conjunction with the "Critical Update Request" field defined above to request critical update information from other APs. The "Critical Update Request" field, as an indicator for the STA to request information from other APs, is defined as follows.

[0573] - “Critical Update Request” field: This field requests only system information that is defined as a critical update for an AP. It can be used in conjunction with a link indicator when requesting system information that is defined as a critical update for a specific link.

[0574] However, when a STA requests critical update information for a specific link with the 1-bit indicator mentioned above, if the AP receiving the request does not know the version of the critical update information currently possessed by the STA (i.e., the change sequence field value of the STA's critical update information), the AP must send a response message including all critical update information for the requested link. Alternatively, the change sequence element can be included in the corresponding response frame along with the critical update information and sent. This is a fairly simple method, but since it may be redundant transmission of information already possessed by the STA, a different format is proposed to reduce overhead. An example for this is shown below.

[0575] Figure 61 An example of a probe request frame used to request critical update information is shown.

[0576] Reference Figure 61 The STA can send a request frame by including a critical update request field, which serves as an indicator for requesting critical update information, and a change sequence field (or change sequence element) that includes version information of the critical update currently possessed by the STA. In this case, the change sequence field signifies an indicator of the change sequence value for each link. In 802.11be, the STA can periodically receive change sequence values ​​from the AP of the connected AP MLD via beacon or probe responses, and since the STA is defined to store these values, the STA change sequence value information for each link is known. Therefore, the change sequence field defined in this specification signifies information about the version (i.e., change sequence value) of the critical update information of the AP of the connected AP MLD previously obtained by the STA via beacon or probe responses.

[0577] At this point, when the value of the "Critical Update Request" field is 1, it means that the STA is requesting critical update information; otherwise, the value is indicated as 0. If the value of the "Critical Update Request" field is 1, it signifies a request for critical update information, and therefore it is sent including the change sequence field (or change sequence element). However, if the value is 0, this field is omitted before sending. In other words, when the value of the "Critical Update Request" field is 1, the STA attaches the change sequence field (or change sequence element), and the receiving AP compares the received information with its current information. Only the changed information (i.e., only the modified information to be updated by the STA) can be sent in the response message. When the value of the "Critical Update Request" field is 0, the change sequence field (or change sequence element) is omitted to reduce overhead. Additionally, in this specification, when the change sequence field is included in the ML IE for transmission as described above, the option to include all information related to the critical updates currently possessed by the AP is also considered. If the AP compares the value of the changed sequence field sent by the STA with the fields currently held by the AP and finds a difference, the AP sends all information related to the currently held critical update to the STA. This method may increase the overhead for the information sent by the AP, but it can be implemented more simply because it does not require storing change information for every critical update version for every AP.

[0578] As mentioned above, the presence or absence of a change sequence field (or change sequence element) can be categorized and defined based on the value of the "Critical Update Request" field. However, depending on the option, the "Critical Update Request" field value and the change sequence field (or change sequence element) can be defined and used independently. In this case, it is possible that the request message sent by the STA does not include the change sequence field (or change sequence element) along with the "Critical Update Request" field having a value of 1. In this case, consider that the receiving AP wants to receive all critical update information, not only the updated critical update information, and respond by including all critical update information in the response message. In this specification, the following method is proposed as follows: the STA sends the 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 sends only the changed information in the response frame. At this time, the corresponding segment provides the change sequence field as an example to convey the change sequence information of the link, but the STA can request a change sequence element instead of the change sequence field. However, since the use of the change sequence element has already been mentioned in the above segment, the implementation in which the change sequence element is used together with the "Critical Update Request" field is omitted.

[0579] For example, when a STA sends a probe request frame that includes an ML IE for MLD probing, the information for requesting critical updates can be included in the Per-STA Profile(x) sub-element that requests information for each STA, such as... Figure 61 As shown in the diagram. In this case, the critical update request field and change sequence field in the Per-STA Control field, which contains critical update information for the current STA, can be located in the Per-STA Profile(x). Alternatively, the critical update request field can be located in the Per-STA Profile(x) along with the change sequence field, instead of in the Per-STA Control field. This implementation method is used in... Figure 62 As shown in the image.

[0580] Figure 62 Another example of a probe request frame used to request critical update information is shown.

[0581] Upon receiving such Figure 62 Following the request frame shown, the AP sees the ML IE information in the request frame and sends 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 exists in the Per-STA Profile(x) element in the MLIE and has a value of 1, it is recognized that the STA has requested critical update information. In addition, by comparing the STA's change sequence information with the current change sequence information of the link (X) requested by the STA through the change sequence field information received at this time, if there is updated content (i.e., if there is changed information that the STA needs to update), a compressed probe response frame containing only the update information is sent, or if there is an update entry, all information related to the critical update can be responded to with a probe response frame.

[0582] The information mentioned above is included in the public information level in ML IE rather than the link-specific level, which allows critical update information to be requested for all links at once rather than for a specific link.

[0583] The implementation method used here is Figure 63 As shown in the image.

[0584] Figure 63 Another example of a probe request frame used to request critical update information is shown.

[0585] like Figure 63As shown, an STA request can be sent in a link-specific information location (e.g., a common information location, not a Per-STA Profile(x)) within the ML IE frame, including the critical update request field (i.e., setting its value to 1) and the change sequence field. Upon receipt, the AP identifies the STA as making a request for all its links, not just a specific link, and compares the change sequence field information sent by the STA with the current change sequence information used for all its links. That is, if there is changed information that the STA needs to update, it sends a compressed probe response frame containing only the update information for all links, or if an update entry exists, it can respond with a probe response frame containing all information related to the critical update.

[0586] Figure 64 Another example of a probe request frame used to request critical update information is shown.

[0587] At this point, the STA can indicate a request for critical update information regarding changes to the link by placing the critical update request field within the multi-link control field, such as... Figure 64 As shown in the image.

[0588] Regarding the above method for a STA to request critical update change information from a specific AP, this specification further proposes the AP response procedure. In the current 802.11ax standard, when a 6GHz AP receives a probe request and sends a probe response frame, if the AP does not indicate the actual SSID of the SSID element in its beacon frame, the transmission rule is defined by setting the broadcast address in the Address 1 field. Referring to this, in the 802.11be standard, when an MLD probe request frame requesting complete information about an AP operating in the 2.4 GHz or 5 GHz band is received, and when the AP responds to the MLD probe response frame, if the AP does not indicate the actual SSID of the SSID element in its beacon frame, the method of setting the Address 1 field to the broadcast address is discussed.

[0589] In contrast, this specification proposes a method for setting the Address 1 field to a broadcast address, even when a STA requests update-related information about a critical update of a specific AP via an MLD probe request frame (e.g., when the STA sends an MLD probe request frame including information about a changed sequence field), if the AP does not indicate the actual SSID of the SSID element of its beacon frame when responding to the MLD probe response frame. Critical update information is important change information for the AP and is information that all STAs must know before data transmission / reception. Therefore, to prevent storms caused by MLD probes, this specification proposes a method for responding with a broadcast message when a STA requests partial information about a critical update of a specific AP, unless otherwise instructed.

[0590] Additionally, as mentioned above, depending on the implementation of the AP MLD, the AP MLD can implement a method to store which information (i.e., IE) has been updated for each CSN (changing sequence number whenever a critical update occurs) for each AP. Depending on the memory size, this may not be implemented. If such a method is supported, the AP needs to remember which IE information has been updated whenever the AP's CSN changes. For example, if the AP generates a critical update event for element X at CSN n=1 and updates elements Y and Z at CSN=n+1, the AP determines what happened at CSN=n and CSN=n+1. This information should be able to be retained to see if it has changed. If the AP can track which IE has changed for each CSN in this way, it can be useful in terms of overhead when the STA sends its currently stored CSN information in a request frame, since only the information that has changed compared to the AP's current CSN value, rather than all information, can be included in the response frame and sent. However, such tracking may not be easy, and since the AP requires additional memory, this capability may or may not be supported depending on the AP's implementation specification. Therefore, this disclosure proposes the following capability for instructing the AP to track updated information for each CSN.

[0591] - "Critical Update Tracking Support" field: This field indicates whether the current STA or AP supports the function of storing which information (e.g., EI (Element ID) information) has been updated for each CSN value. A value of 1 means the STA or AP supports the ability to store which information has been updated for each CSN value, and a value of 0 means the STA or AP does not support the corresponding function. For example, this field can be included in an extended capability element or an EHT capability element.

[0592] A STA can use this feature to request critical update information for a specific AP (or STA) by checking whether the corresponding AP (or STA) supports it during the relevant process. This feature can be supported at the MLD level or the STA level for each STA.

[0593] In this way, when defining the "Critical Update Tracking Support" field, which indicates whether the MLD supports critical update tracking, the detailed operations of the STA can be defined as follows.

[0594] For example, if the AP MLD supports critical update tracking support (e.g., the "critical update tracking support" field = 1), the non-AP MLD can know this during the multi-link establishment process.

[0595] When the AP MLD supports critical update tracking, a non-AP MLD STA can include the CSN (Change Sequence Number) information in the probe request frame when requesting only partial information related to the critical update. Upon receiving this, the AP can compare its current CSN with the CSN information received from the STA and send a probe response frame containing only the updated information. However, even in this case, if the STA wants all information related to the AP's critical update, not just the changed information, it can send the probe request frame without including the CSN information when requesting partial information related to the critical update, thus obtaining the desired information (the entire information related to the AP's critical update).

[0596] If the AP MLD does not support critical update tracking (e.g., the "Critical Update Tracking Support" field = 0), then when a non-AP MLD STA requests information only related to critical updates, the CSN information may not be included in the probe request frame and may be sent. Upon receiving this, the AP may send a probe response frame including all elements related to critical updates corresponding to the current AP's CSN (or, if no separate instruction is given, the complete information of the requested AP (i.e., the complete profile)). However, even in this case, when the STA requests partial information related to critical updates, the CSN information may be included in the probe request frame and sent. However, since the receiving AP cannot track update information for every CSN, all elements related to critical updates corresponding to the current AP's CSN (or, unless otherwise indicated, the complete information of the requested AP (i.e., the complete profile)) may be included in the probe response frame and sent.

[0597] Thus, if a non-AP MLD can determine whether the APMLD supports tracking update information for each CSN by defining a "Critical Update Tracking Support" field in the MLD, the non-AP MLD will request a probe request for partial information related to critical updates. This can be useful because it allows you to decide whether to include CSN information in the frame.

[0598] According to the implementation method, both AP MLD and non-AP MLD can activate the IOM method proposed during or after multi-link establishment using the signaling methods described in this specification. Furthermore, both AP MLD and non-AP MLD can limit the scope and type of requested information using various field values ​​in the IOM capability element.

[0599] According to the implementation method, IOM operations can be performed after precise operation negotiation between MLDs using the aforementioned IOM signaling method. However, IOM operations can also be performed via MLD implementation without a separate signaling procedure. This may mean that it operates by implementing either AP MLD or non-AP MLD without negotiation between AP MLD and non-AP MLD.

[0600] Based on the above implementation, both AP MLD and non-AP MLD can operate, but the following constraints may occur when MLD performs IOM operations without separate signaling exchange.

[0601] 1) Constraints on request methods: If information sharing is not supported between APs in the AP MLD, then when a STA requests information about another link, it cannot respond.

[0602] 2) Constraints on non-request methods: APs can provide separate messages by identifying STAs that require additional link information (e.g., beacon periods). Therefore, STAs cannot predict in advance whether they will receive the message.

[0603] When MLD implements IOM without a separate signaling method, it simplifies the operation process, but the limitations mentioned above may occur.

[0604] According to the implementation, a method for requesting multi-link information can be set based on the agreement between the AP MLD and the non-AP MLD executed using the aforementioned IOM capability elements. In contrast, in the case of a pleading method, the STA may want to temporarily obtain information by indicating specific information in addition to the agreed-upon content. In this case, when the STA dynamically sends a request message, the request may include the indicated content (e.g., IOM capability information).

[0605] For example, during or after multi-link establishment, the AP MLD (Multi-Link Deployment Provider) makes agreements with non-AP MLDs, and the STA (Single-Link Provider) can receive information from the AP based on the agreed-upon content. However, the STA may want to temporarily request information from a specific AP or specific parameter information of the AP. In this case, when requesting information, the STA can send an "IOM (Internal Message) Capability" element in a request frame (e.g., a probe request frame, a (re)association frame, or a new frame), which includes instructions for the information it wants to request. Based on the request frame, the AP can send / provide a response message to the STA including the information requested by the STA. According to the implementation, when the fields in the IOM Capability element are omitted, the AP can provide information to the STA based on previously agreed-upon content.

[0606] Therefore, the MLD (AP MLD or non-AP MLD) can use the aforementioned elements to perform negotiation between the AP MLD and the non-AP MLD during or after the multi-link establishment process. Based on the negotiation, the non-AP MLD can agree on the information to be provided (or received) and receive it. Alternatively, the STA can temporarily receive the requested information by sending a request message that includes instructions regarding the desired information. However, if specific instructions are omitted in the request message, both the non-AP MLD and the AP MLD can operate based on the instructions of the basic agreement.

[0607] According to the implementation method, if the agreed content needs to be changed after the multi-link establishment is completed, the non-AP MLD and AP MLD can update the agreed content between the MLDs through separate message exchanges.

[0608] The following describes the process of critical updates to BSS parameters.

[0609] If the AP of the AP MLD does not belong to multiple BSSIDs or the AP corresponds to a transmitted BSSID in multiple BSSID sets, then the AP will include the BSS parameter change count (BPCC) subfield of each of all APs belonging to the same AP MLD in the beacon and probe response frame and send the beacon and probe response frame.

[0610] The value of the BPCC subfield for each AP is initialized to 0 and should be incremented (modulo 256) whenever there is a critical update to the AP's operating parameters.

[0611] The BPCC subfield of each of the other APs in the AP MLD must be sent in the MLD parameter subfield of the Target Beacon Transmission Time (TBTT) information field corresponding to the Reduced Neighbor Report (RNR) element of the AP.

[0612] The BPCC subfield of the AP must be transmitted in the common information field of the basic multilink element.

[0613] The AP provides the key update flag subfield of the capability information field for beacon and probe response frames, and the value sent in the BPCC subfield of the MLD parameter field of any AP's RNR element in the same APMLD (or the update indicator of the value sent in the BPCC subfield of the common information field of the basic multilink element) is sent.

[0614] If the value sent from the BPCC subfield of the MLD parameter field of the RNR element of the AP in the same AP MLD (or the value sent from the BPC subfield of the common information field of the basic multilink element) changes, 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 in which the AP operates.

[0615] In other cases, AP sets the critical update flag subfield of the capability information field to 1.

[0616] Non-AP MLDs should maintain a record of the most recently received BPCC subfield value for each AP in an AP MLD with a multi-link configuration.

[0617] In the following text, reference will be made to Figures 1 to 64 The above implementation method will be described below.

[0618] Figure 65 This is a flowchart illustrating the process by which the sending MLD provides partial information to the receiving MLD based on a probe response frame according to this embodiment.

[0619] Figure 65 Examples can be implemented in network environments that support next-generation WLAN systems (IEEE 802.11be or EHT WLAN systems). Next-generation wireless LAN systems are WLAN systems enhanced relative to 802.11ax systems, thus satisfying backward compatibility with 802.11ax systems.

[0620] In this embodiment, when a non-AP STA requests partial information about an AP other than its peer AP via a probe request frame in MLD communication, a method and apparatus are proposed for the non-AP STA to request partial information about a specific AP based on the request element by including the request element in the multi-link element of the probe request frame. Here, the transmitting MLD can correspond to the AP MLD, and the receiving MLD can correspond to the non-AP MLD. If the non-AP STA is the first receiving STA, then the first transmitting STA connected to the first receiving STA via a first link can be referred to as the peer AP, and the second and third transmitting STAs connected via different links can be referred to as different APs.

[0621] In step S6510, the transmitting multilink device (MLD) receives a probe request frame from the receiving MLD via the first link.

[0622] In step S6520, the sending MLD sends a probe response frame to the receiving MLD via the first link.

[0623] The transmitting MLD includes a first transmitting station (STA) operating on a first link and a second transmitting STA operating on a second link. The receiving MLD includes a first receiving STA operating on a first link and a second receiving STA operating on a second link.

[0624] The probe request frame includes a profile field for the second receiving STA. The profile field for the second receiving STA includes a first complete information profile subfield.

[0625] When the first receiving STA requests partial information about the second link, the value of the first complete information configuration file subfield is set to 0. The configuration file field of the second receiving STA also includes the first request element. At this time, partial information about the second link is requested based on the first request element.

[0626] When the first receiving STA requests complete information about the second link, the value of the first complete information configuration file subfield can be set to 1. The configuration file field of the second receiving STA may not include the first request element. In this case, complete information about the second link can be requested based on the configuration file field of the second receiving STA.

[0627] That is, the probe response frame can be configured based on the values ​​of the first complete information configuration file subfield and / or the first request element. When the value of the first complete information configuration file subfield is 0, the receiving MLD can request partial information about the second link based on the first request element in the probe request frame, and the sending MLD can send partial information about the second link in the probe response frame. When the value of the first complete information configuration file subfield is 1, the receiving MLD can request complete information about the second link using only the configuration file field of the second receiving STA, and the sending MLD can send complete information about the second link in the probe response frame.

[0628] Additionally, the receiving MLD can request partial information about multiple APs in the sending MLD.

[0629] The transmitting MLD may also include a third transmitting STA operating on a third link. The receiving MLD may also include a third receiving STA operating on a third link.

[0630] The probe request frame may also include a profile field for the third receiving STA. The profile field for the third receiving STA may include a second complete information profile subfield.

[0631] When the first receiving STA requests partial information about the third link, the value of the second complete information configuration file subfield can be set to 0, and the configuration file field of the third receiving STA can also include a second request element. In this case, partial information about the third link can be requested based on the second request element.

[0632] When the first receiving STA requests complete information about the third link, the value of the second complete information configuration file subfield can be set to 1, and the configuration file field of the third receiving STA may not include the second request element. In this case, complete information about the third link can be requested based on the configuration file field of the third receiving STA.

[0633] Similarly, the probe response frame can be configured based on the values ​​of the second complete information configuration file subfield and / or the second request element. When the value of the second complete information configuration file subfield is 0, the receiving MLD can request partial information about the third link from the probe request frame based on the second request element, and the sending MLD can send partial information about the third link in the probe response frame. When the value of the second complete information configuration file subfield is 1, the receiving MLD can request complete information about the third link using only the configuration file field of the third receiving STA, and the sending MLD can send complete information about the third link in the probe response frame.

[0634] If both the first request element and the second request element are included in the probe request frame, the probe response frame can be configured based on the values ​​of the first and second complete information configuration file subfields and the first and second request elements.

[0635] Additionally, the probe request frame may include a third request element and a multilink element. When the first receiving STA requests partial information about the first link, it can request this information based on the third request element. The profile fields of the second and third receiving STAs can be included in the multilink element. That is, in MLD communication, a non-AP STA can request partial information about the peer AP through a request element not included in the multilink element, and can request partial information about APs other than the peer AP through the multilink element.

[0636] Additionally, the first request element may include first identifier information indicating partial information about the second link. The second request element may include second identifier information indicating partial information about the third link. Elements containing partial information about the second link can be distinguished by the first identifier information. Elements containing partial information about the third link can also be distinguished by the second identifier information.

[0637] That is, this implementation proposes the following method: setting an indicator for whether to include a request element in the profile field of each receiving STA included in the aforementioned multi-link element, and requesting partial information about a specific AP based on the request element. Therefore, the AP MLD can decode the complete information profile subfield, check whether the request element is included in the profile field of each receiving STA, check the partial information requested in the request element, and include the corresponding partial information in the probe response frame. As a result, the non-AP MLD can always request partial information from other links instead of complete information, which has the effect of reducing frame overhead.

[0638] Figure 66 This is a flowchart illustrating the process of receiving MLD request portion information based on a probe request frame according to this embodiment.

[0639] Figure 66 Examples can be implemented in network environments that support next-generation WLAN systems (IEEE 802.11be or EHT WLAN systems). Next-generation wireless LAN systems are WLAN systems enhanced relative to 802.11ax systems, thus satisfying backward compatibility with 802.11ax systems.

[0640] In this embodiment, when a non-AP STA requests partial information about an AP other than its peer AP via a probe request frame in MLD communication, a method and apparatus are proposed for the non-AP STA to request partial information about a specific AP based on the request element by including the request element in the multi-link element of the probe request frame. Here, the transmitting MLD can correspond to the AP MLD, and the receiving MLD can correspond to the non-AP MLD. If the non-AP STA is the first receiving STA, then the first transmitting STA connected to the first receiving STA via a first link can be referred to as the peer AP, and the second and third transmitting STAs connected via different links can be referred to as different APs.

[0641] In step S6610, the receiving multi-link device (MLD) sends a probe request frame to the sending MLD through the first link.

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

[0643] The transmitting MLD includes a first transmitting station (STA) operating on a first link and a second transmitting STA operating on a second link. The receiving MLD includes a first receiving STA operating on a first link and a second receiving STA operating on a second link.

[0644] The probe request frame includes a profile field for the second receiving STA. The profile field for the second receiving STA includes a first complete information profile subfield.

[0645] When the first receiving STA requests partial information about the second link, the value of the first complete information configuration file subfield is set to 0. The configuration file field of the second receiving STA also includes the first request element. At this time, partial information about the second link is requested based on the first request element.

[0646] When the first receiving STA requests complete information about the second link, the value of the first complete information configuration file subfield can be set to 1. The configuration file field of the second receiving STA may not include the first request element. In this case, complete information about the second link can be requested based on the configuration file field of the second receiving STA.

[0647] That is, the probe response frame can be configured based on the values ​​of the first complete information configuration file subfield and / or the first request element. When the value of the first complete information configuration file subfield is 0, the receiving MLD can request partial information about the second link based on the first request element in the probe request frame, and the sending MLD can send partial information about the second link in the probe response frame. When the value of the first complete information configuration file subfield is 1, the receiving MLD can request complete information about the second link using only the configuration file field of the second receiving STA, and the sending MLD can send complete information about the second link in the probe response frame.

[0648] Additionally, the receiving MLD can request partial information about multiple APs in the sending MLD.

[0649] The transmitting MLD may also include a third transmitting STA operating on a third link. The receiving MLD may also include a third receiving STA operating on a third link.

[0650] The probe request frame may also include a profile field for the third receiving STA. The profile field for the third receiving STA may include a second complete information profile subfield.

[0651] When the first receiving STA requests partial information about the third link, the value of the second complete information configuration file subfield can be set to 0, and the configuration file field of the third receiving STA can also include a second request element. In this case, partial information about the third link can be requested based on the second request element.

[0652] When the first receiving STA requests complete information about the third link, the value of the second complete information configuration file subfield can be set to 1, and the configuration file field of the third receiving STA may not include the second request element. In this case, complete information about the third link can be requested based on the configuration file field of the third receiving STA.

[0653] Similarly, the probe response frame can be configured based on the values ​​of the second complete information configuration file subfield and / or the second request element. When the value of the second complete information configuration file subfield is 0, the receiving MLD can request partial information about the third link from the probe request frame based on the second request element, and the sending MLD can send partial information about the third link in the probe response frame. When the value of the second complete information configuration file subfield is 1, the receiving MLD can request complete information about the third link using only the configuration file field of the third receiving STA, and the sending MLD can send complete information about the third link in the probe response frame.

[0654] If both the first request element and the second request element are included in the probe request frame, the probe response frame can be configured based on the values ​​of the first and second complete information configuration file subfields and the first and second request elements.

[0655] Additionally, the probe request frame may include a third request element and a multilink element. When the first receiving STA requests partial information about the first link, it can request this information based on the third request element. The profile fields of the second and third receiving STAs can be included in the multilink element. That is, in MLD communication, a non-AP STA can request partial information about the peer AP through a request element not included in the multilink element, and can request partial information about APs other than the peer AP through the multilink element.

[0656] Additionally, the first request element may include first identifier information indicating partial information about the second link. The second request element may include second identifier information indicating partial information about the third link. Elements containing partial information about the second link can be distinguished by the first identifier information. Elements containing partial information about the third link can also be distinguished by the second identifier information.

[0657] That is, this implementation proposes the following method: setting an indicator for whether to include a request element in the profile field of each receiving STA included in the aforementioned multi-link element, and requesting partial information about a specific AP based on the request element. Therefore, the AP MLD can decode the complete information profile subfield, check whether the request element is included in the profile field of each receiving STA, check the partial information requested in the request element, and include the corresponding partial information in the probe response frame. As a result, the non-AP MLD can always request partial information from other links instead of complete information, which has the effect of reducing frame overhead.

[0658] The technical features of this disclosure can be applied to various apparatuses and methods. For example, they can be used... Figure 1 and / or Figure 11 The apparatus executes / supports the technical features of this disclosure. For example, the technical features of this disclosure may be applied only to... Figure 1 and / or Figure 11 Part of it. For example, the technical features of this disclosure may be based on Figure 1 The processing chips 114 and 124 are used to implement this, or it can be implemented based on processors 111 and 121 and memory 112 and 122, or based on... Figure 11 The processor 610 and memory 620 are used for implementation. For example, the apparatus according to this disclosure sends a probe request frame to a transmitting multilink device (MLD) via a first link; and receives a probe response frame from the transmitting MLD via the first link.

[0659] The technical features of this disclosure can be implemented based on a computer-readable medium (CRM). For example, the CRM according to this disclosure is at least one computer-readable medium including instructions designed to be executed by at least one processor.

[0660] The CRM can store instructions for performing operations including: sending a probe request frame to a transmitting multilink device (MLD) via a first link; and receiving a probe response frame from the transmitting MLD via the first link. At least one processor can execute the instructions stored in the CRM according to this disclosure. The at least one processor associated with the CRM of this disclosure may be... Figure 1 Processors 111, 121, Figure 1 Processing chips 114, 124, or Figure 11 The processor 610. Furthermore, the CRM disclosed herein can be... Figure 1 Memory 112, 122, Figure 11 The memory 620, or a separate external memory / storage medium / disk.

[0661] The aforementioned technical features in this specification are applicable to various applications or business models. For example, the aforementioned technical features can be applied to wireless communication in devices that support artificial intelligence (AI).

[0662] Artificial intelligence (AI) refers to the field of research concerning artificial intelligence or the methods used to create it, while machine learning refers to the field of research concerning methods for defining and solving various problems within the field of AI. Machine learning is also defined as an algorithm that improves operational performance through stable operational experience.

[0663] Artificial neural networks (ANNs) are models used in machine learning, and can refer to models that solve problems in general, including artificial neurons (nodes) that form a network by combining synapses. An artificial neural network can be defined by the connection patterns between neurons in different layers, the learning process that updates model parameters, and the activation function that generates the output value.

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

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

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

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

[0668] Supervised learning refers to the method of training an artificial neural network using labels provided for the training data. When the training data is input into the artificial neural network, the labels indicate the correct answer (or result value) that the network should infer. Unsupervised learning refers to the method of training an artificial neural network without providing labels for the training data. Reinforcement learning can be a training method used to train an agent defined in an environment to select actions or sequences of actions to maximize the cumulative reward in each state.

[0669] Machine learning implemented using deep neural networks (DNNs) with multiple hidden layers is called deep learning, and deep learning is a part of machine learning. In the following text, machine learning is interpreted as including deep learning.

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

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

[0672] Depending on their application or field, robots can be categorized into industrial, medical, household, and military robots, among others. Robots can include actuators or drives that include motors to perform various physical operations, such as moving robot joints. Additionally, mobile robots can include wheels, brakes, propellers, etc., in their drives to move on the ground or fly in the air.

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

[0674] Extended reality is collectively referred to as virtual reality (VR), augmented reality (AR), and mixed reality (MR). VR technology is a computer graphics technology that provides real-world objects and backgrounds only in CG images; AR technology is a computer graphics technology that provides virtual CG images on top of real object images; and MR technology is a computer graphics technology that provides virtual objects that are mixed and combined with the real world.

[0675] MR technology is similar to AR technology in that it can display real and virtual objects together. However, in AR technology, virtual objects are used as a supplement to real objects, while in MR technology, virtual and real objects are used as equals.

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

[0677] The claims disclosed in this specification can be combined in various ways. For example, the technical features in the method claims of this specification can be combined to implement as an apparatus, and the technical features in the apparatus claims of this specification can be combined to implement by a method. Furthermore, the technical features in the method claims and apparatus claims of this specification can be combined to implement as an apparatus, and the technical features in the method claims and apparatus claims of this specification can be combined to implement by a method.

Claims

1. A method performed by an Access Point Multilink Device (AP MLD) in a Wireless Local Area Network (WLAN) system, the method comprising the following steps: The access point (AP) attached to the AP MLD receives a multi-link probe request frame from a non-AP station (STA) attached to a non-AP MLD; as well as The AP sends a multi-link probe response frame to the non-AP STA. In response to the multi-link probe request frame, the multi-link probe response frame includes complete or partial information of the first requested AP. The multi-link probe request frame includes a per-STA profile sub-element for the first requested AP. Specifically, the per-STA configuration file sub-element for the first requested AP includes a first complete configuration file request sub-field of the first STA control field, and Specifically, when the first complete configuration file request subfield of the first STA control field is set to 0, the partial information for the first requested AP is requested.

2. The method according to claim 1, wherein, The first requested AP is further attached to the AP MLD. Specifically, based on the partial information requested for the first requested AP, the per-STA configuration file sub-element for the first requested AP further includes a first request element. Specifically, the first complete configuration file request subfield based on the first STA control field is set to 1, the complete information for the first requested AP is requested, and the per STA configuration file sub-element for the first requested AP does not include the first request element.

3. The method according to claim 2, wherein, The multi-link probe request frame also includes a per-STA profile sub-element for the second requested AP. Wherein, the second requested AP is further attached to the AP MLD, The non-AP STA and the AP operate on the first link. The first requested AP operates on the second link. The second requested AP operates on the third link. Specifically, the per-STA profile sub-element for the second requested AP includes a second complete profile request sub-field of the second STA control field.

4. The method according to claim 3, wherein, The second complete profile request subfield based on the second STA control field is set to 0, partial information for the second requested AP is requested, and the per STA profile sub-element for the second requested AP also includes a second request element.

5. The method according to claim 4, wherein, The second complete profile request subfield based on the second STA control field is set to 1, complete information for the second requested AP is requested, and the per STA profile sub-element for the second requested AP does not include the second request element.

6. The method according to claim 3, wherein, The multi-link probe request frame includes a third request element and a multi-link element. Specifically, based on the non-AP STA request for partial information about the AP, the third request element is used to request the partial information about the AP. The per-STA profile sub-element for the first requested AP and the per-STA profile sub-element for the second requested AP are included in the multi-link element.

7. The method according to claim 4, wherein, The first request element includes first identifier information indicating the portion of information for the first requested AP. The second request element includes second identifier information indicating the portion of information for the second requested AP. The multi-link probe response frame is configured based on the values ​​of the first complete configuration file request subfield and the second complete configuration file request subfield, as well as the first request element and the second request element.

8. An access point multi-link device (AP MLD) in a wireless local area network (WLAN) system, the AP MLD comprising: Memory; transceiver; as well as A processor, operatively coupled to the memory and the transceiver, The processor is configured as follows: The access point (AP) attached to the AP MLD receives a multi-link probe request frame from a non-AP station (STA) attached to a non-AP MLD; and The AP sends a multi-link probe response frame to the non-AP STA. In response to the multi-link probe request frame, the multi-link probe response frame includes complete or partial information of the first requested AP. The multi-link probe request frame includes a per-STA profile sub-element for the first requested AP. Specifically, the per-STA configuration file sub-element for the first requested AP includes a first complete configuration file request sub-field of the first STA control field, and Specifically, when the first complete configuration file request subfield of the first STA control field is set to 0, the partial information for the first requested AP is requested.

Images