Multilink traffic indication for multilink devices

Abstract

The wireless communication network includes an access point (AP) multilink device (MLD) and a non-AP MLD. The AP MLD generates a traffic indication map (TIM) element indicating pending buffered traffic for a plurality of non-AP MLDs associated with the AP MLD, and selectively generates a multilink traffic indication element including a per-link traffic indication to obtain the buffered traffic for the at least one non-AP MLD based on determining whether all the plurality of non-AP MLDs have a default traffic identifier (TID)-to-link mapping and whether the AP MLD has buffered traffic with a TID that is not mapped to all valid links for the at least one non-AP MLD. The AP MLD transmits a beacon frame including the TIM element and the optional multilink traffic indication element to the plurality of non-AP MLDs.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates generally to wireless communications, and more specifically, but not exclusively, to multilink traffic indications for multilink devices in a wireless communication system. [Background technology]

[0002] Wireless Local Area Network (WLAN) technology has evolved towards higher data rates and has grown over the years since the late 1990s in various markets including home, enterprise and hotspots. WLAN allows devices to access the Internet in the 2, 4 GHz, 5 GHz or 60 GHz frequency bands. WLAN is based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. The family of IEEE 802.11 standards aims to improve the speed, reliability and range of wireless networks.

[0003] WLAN devices are increasingly required to support various delay-sensitive or real-time applications, such as augmented reality (AR), robotics, artificial intelligence (AI), cloud computing, and unmanned vehicles. To implement the extremely low latency and extremely high throughput required by such applications, multi-link operation (MLO) has been proposed for WLANs. A WLAN is formed by WLAN devices within a limited area, such as a home, school, apartment, or office building. Each WLAN device may have one or more stations (STAs), such as access point (AP) STAs and non-access point (non-AP) STAs.

[0004] MLO may allow a non-AP multi-link device (MLD) to set up multiple links with an AP MLD, each of which may independently enable channel access and frame exchange between the non-AP MLD and the AP MLD, which may reduce latency and improve throughput.

[0005] A statement provided in the Background section should not be assumed to be prior art merely because it is provided in the Background section. The Background section may describe aspects or embodiments of the present disclosure. Summary of the Invention [Means for solving the problem]

[0006] An embodiment of the present disclosure provides an access point (AP) multi-link device (MLD) associated with a wireless network. The AP MLD includes at least two APs associated with the AP MLD and a processor coupled to the at least two APs. The processor is configured to generate a traffic indication map (TIM) element indicating pending buffered traffic for a plurality of non-AP MLDs associated with the AP MLD. The processor is configured to selectively generate a multi-link traffic indication element including a per-link traffic indication to obtain buffered traffic for the at least one non-AP MLD based on determining whether all the plurality of non-AP MLDs have a default traffic identifier (TID)-to-link mapping and whether the AP MLD has buffered traffic with a TID mapped to all valid links for the at least one non-AP MLD. The processor is configured to generate a beacon frame including the selectively included multi-link traffic indication element and the TIM element. The processor is configured to transmit a beacon frame to a plurality of non-AP MLDs.

[0007] In some embodiments, the processor is configured to generate a multilink traffic indication element when at least one associated non-AP MLD has successfully negotiated a TID-to-link mapping with the AP MLD and the AP MLD has buffered traffic with a TID that is not mapped to all valid links for the at least one non-AP MLD.

[0008] In some embodiments, the processor is configured to generate a multilink traffic indication element when the AP MLD intends to provide a link recommendation for retrieving buffered traffic to at least one non-AP MLD.

[0009] In some embodiments, the processor is configured to refrain from generating a multilink traffic indication element if the AP MLD is not intended to provide link recommendations for retrieving buffered traffic to any associated non-AP MLDs and if the AP MLD does not have buffered traffic with TIDs that map to only a subset of valid links for any associated non-AP MLDs.

[0010] In some embodiments, the multilink traffic indication element includes a recommendation field indicating at least one non-AP MLD over which the AP MLD provides a per-link traffic indication for retrieving the buffered traffic. The per-link traffic indication includes a link recommendation or a traffic indication.

[0011] In some embodiments, the recommendation field includes a set of bits, each bit starting at an offset number of a traffic indication virtual bitmap in the TIM element and corresponding to a respective one of the associated non-AP MLDs and non-AP stations (STAs), each bit indicating whether the AP MLD provides per-link traffic indications for the corresponding non-AP MLD or non-AP STA.

[0012] In some embodiments, the recommendation field includes a set of bits, each bit starting from an offset number of the traffic indication virtual bitmap in the TIM element and corresponding to a distinct one of the associated non-AP MLDs and non-AP STAs that are indicated as having buffered traffic in the traffic indication virtual bitmap of the TIM element, each bit indicating whether the AP MLD provides per-link traffic indication for the corresponding non-AP MLD or non-AP STA.

[0013] In some embodiments, the multilink traffic indication element optionally includes a recommendation field, and the multilink traffic indication element includes a recommendation present field that indicates whether the recommendation field is present in the multilink traffic indication element.

[0014] In some embodiments, the multilink traffic indication element includes one or more per-link traffic indication fields, each field providing a traffic indication or link recommendation for a respective one of the at least one non-AP MLD.

[0015] In some embodiments, the multilink traffic indication element is included in a group-addressed frame, is not associated with a TIM element, and includes a recommendation field indicating at least one non-AP MLD that provides per-link traffic indication for the AP MLD to retrieve the buffered traffic.

[0016] An embodiment of the present disclosure may provide a non-AP MLD associated with a wireless network. The non-AP MLD includes at least two stations (STAs) associated with the non-AP MLD and a processor coupled to the at least two STAs. The processor is configured to receive a traffic indication map (TIM) element included in a beacon frame from an AP MLD associated with the non-AP MLD. The TIM element indicates pending buffered traffic for the non-AP MLD. The processor is configured to determine whether a multilink traffic indication element is present in the beacon frame. The multilink traffic indication element is selectively included in the beacon frame based on whether all of a plurality of non-AP MLDs associated with the AP MLD have a default traffic identifier (TID)-to-link mapping and whether the AP MLD has buffered traffic with a TID that is mapped to all valid links for the associated non-AP MLD. The processor is configured to determine whether a per-link traffic indication for the non-AP MLD is present in the multilink traffic indication element if the multilink traffic indication element exists, the per-link traffic indication providing a link recommendation or traffic indication for obtaining the buffered traffic for the non-AP MLD. The processor is configured to send a trigger frame to the AP MLD to obtain the buffered traffic via the link indicated in the per-link traffic indication if the multilink traffic indication element for the non-AP MLD exists. The processor is configured to receive the buffered traffic via the link indicated in the per-link traffic indication from the AP MLD.

[0017] In some embodiments, the multilink traffic indication element is present in the beacon frame if at least one associated non-AP MLD has successfully negotiated a TID-to-link mapping with the AP MLD and the AP MLD has buffered traffic with TIDs that are not mapped to all valid links for the associated non-AP MLD.

[0018] In some embodiments, if the AP MLD intends to provide a link recommendation for retrieving buffered traffic to at least one associated non-AP MLD, the multilink traffic indication element is present in the beacon frame.

[0019] In some embodiments, if the AP MLD does not intend to provide link recommendations to any associated non-AP MLDs and if the AP MLD does not wait for buffered traffic with TIDs that map to only a subset of the valid links for any associated non-AP MLDs, then the multilink traffic indication element is not present in the beacon frame.

[0020] In some embodiments, the multilink traffic indication element includes a recommendation field indicating at least one non-AP MLD for which the AP MLD provides per-link traffic indications. The processor is configured to determine whether per-link traffic indications for the non-AP MLDs are present in the multilink traffic indication element based on the recommendation field.

[0021] In some embodiments, the recommendation field includes a set of bits, each bit starting from an offset number of the traffic indication virtual bitmap in the TIM element and corresponding to a distinct one of the associated non-AP MLDs and non-AP stations (STAs), each bit indicating whether the AP MLD provides per-link traffic indications to the corresponding non-AP MLD or non-AP STA.

[0022] In some embodiments, the recommendation field includes a set of bits, each bit starting from an offset number of the traffic indication virtual bitmap in the TIM element and corresponding to a distinct one of the associated non-AP MLDs and non-AP STAs that have indicated that they have traffic buffered in the traffic indication virtual bitmap in the TIM element, each bit indicating whether the AP MLD provides per-link traffic indication to the corresponding non-AP MLD or non-AP STA.

[0023] In some embodiments, the multilink traffic indication element optionally includes a recommended field, and the multilink traffic indication element includes a recommended presence field indicating whether the recommended field is present in the multilink traffic indication element. The processor is further configured to determine whether the multilink traffic indication element includes the recommended field based on the recommended presence field.

[0024] In some embodiments, the multi-traffic indication element includes one or more per-link traffic indication fields, each field providing a link recommendation or traffic indication for a respective one of the at least one non-AP MLD.

[0025] In some embodiments, a multilink traffic indication element is included in a group-addressed frame, is not associated with a TIM element, and includes a recommendation field that indicates at least one non-AP MLD for which the AP MLD provides per-link traffic indication. [Brief description of the drawings]

[0026] [Figure 1] FIG. 1 illustrates an example of a wireless network according to an embodiment. [Figure 2a] FIG. 2 illustrates an example of an AP according to an embodiment. [Figure 2b] FIG. 2 illustrates an example of a STA according to an embodiment. [Diagram 3] FIG. 2 illustrates an example of a multi-link communication operation according to an embodiment. [Figure 4] FIG. 1 illustrates an example of a TID-to-link mapping element according to an embodiment. [Figure 5a] FIG. 2 illustrates an example of a multilink traffic indication element according to an embodiment. [Figure 5b] FIG. 1 illustrates an example of a multilink traffic indication element configuration according to an embodiment. [Figure 6a] FIG. 13 illustrates another example of a multilink traffic indication element according to an embodiment. [Figure 6b] FIG. 13 illustrates another example of a multilink traffic indication element configuration according to an embodiment. [Figure 6c] FIG. 13 illustrates another example of a multilink traffic indication element configuration according to an embodiment. [Figure 7a] FIG. 13 illustrates another example of a multilink traffic indication element according to an embodiment. [Figure 7b] FIG. 13 illustrates another example of a configuration of a multilink traffic indication element when a recommendation partial virtual bitmap field is present according to an embodiment. [Figure 7c] FIG. 13 illustrates another example of a configuration of a multilink traffic indication element when a recommendation partial virtual bitmap field is present according to an embodiment. [Figure 8a] FIG. 13 illustrates another example of a multilink traffic indication element according to an embodiment. [Figure 8b] FIG. 13 illustrates another example of a multilink traffic indication element configuration according to an embodiment. [Figure 9] FIG. 13 illustrates another example of a multilink traffic indication element configuration according to an embodiment. [Figure 10] 1 illustrates an example process for indicating buffered traffic using a multilink traffic indication element by AP MLD according to an embodiment. [Figure 11] FIG. 13 illustrates another example of a process for indicating buffered traffic using a multilink traffic indication element by an AP MLD according to an embodiment. [Figure 12] 1 illustrates an example of a process for receiving a multilink traffic indication element by non-AP MLD according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] In one or more implementations, not all of the shown components in each figure may be required, and one or more implementations may include additional components not shown in the figures. Changes in the arrangement or type of components may be made without departing from the scope of the subject disclosure. Additional, different, or fewer components may be utilized within the scope of the subject disclosure.

[0028] The detailed description set forth below in conjunction with the accompanying drawings is intended as a description of various implementations and is not intended to represent the only implementations in which the subject technology may be practiced. Rather, the detailed description includes specific details for the purpose of providing a thorough understanding of the subject matter of the invention. As can be understood by those skilled in the art, the described implementations can be modified in various ways, all without departing from the scope of the present disclosure. Thus, the drawings and descriptions should be regarded as illustrative in nature, and not restrictive. Like reference numerals refer to like elements.

[0029] The following description is directed to a specific implementation for purposes of illustrating the revolutionary aspects of the present disclosure. However, those skilled in the art will readily appreciate that the teachings herein may be applied in a wide variety of ways. Examples of the present disclosure are based on WLAN communication according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, including the IEEE 802.11be standard and any future amendments of the IEEE 802.11 standard. However, the described embodiments may be implemented using any standard including, but not limited to, the IEEE 802.11 standard, the Bluetooth standard, Global System for Mobile communications (GSM), GSM / General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Terrestrial Trunked Radio (TETRA), Wideband CDMA (W-CDMA), Evolution Data Optimized (EV-DO), 1xEV-DO, EV-DO Rev A, EV-DO Rev B, High Speed ​​Packet Access (HSPA), High Speed ​​Downlink Packet Access (HSDPA), High Speed ​​Uplink Packet Access (HSUPA), Evolved High Speed ​​Packet Access (HSPA+), Long Term Evolution (LTE), 5G, 5G, 5G+ ... It may be implemented in any device, system or network capable of transmitting and receiving radio frequency (RF) signals according to NR (New Radio), AMPS, or other known signals used to communicate within wireless, cellular or Internet of Things (IoT) networks, such as systems utilizing 3G, 4G, 5G, 6G or further implementations thereof, technologies.

[0030] 1 illustrates an example of a wireless network 100 according to an embodiment. The embodiment of the wireless network 100 illustrated in FIG. 1 is for illustrative purposes only. Other embodiments of the wireless network 100 may be used without departing from the scope of the present disclosure.

[0031] As shown in FIG. 1, the wireless network 100 includes a plurality of wireless communication devices. Each wireless communication device may include one or more stations (STAs). An STA may be a logical entity that is a single addressable instance of a medium access control (MAC) layer and a physical (PHY) layer interface to a wireless medium. The STAs may be classified into access point (AP) STAs and non-access point (non-AP) STAs. An AP STA may be an entity that provides associated STAs with access to a distribution system service over a wireless medium. A non-AP STA may be a STA that is not included within an AP-STA. For ease of explanation, an AP STA may be referred to as an AP, and a non-AP STA may be referred to as an STA. In the example of FIG. 1, APs 101 and 103 are wireless communication devices that may each include one or more AP STAs. In such an embodiment, APs 101 and 103 may be AP multilink devices (MLDs). Similarly, STAs 111-114 are wireless communication devices that may each include one or more non-AP STAs. In such an embodiment, the STAs 111-114 may be non-AP MLDs.

[0032] The APs 101 and 103 communicate with at least one network 130, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network. The AP 101 provides wireless access to the network 130 for multiple stations (STAs) 111-114 in the coverage area 120 of the AP 101. The APs 101 and 103 may communicate with each other and with the STAs using Wi-Fi or other WLAN communication techniques.

[0033] Depending on the network type, other well-known terms such as "router" or "gateway" may be used instead of "access point" or "AP". For convenience, the term "AP" is used in this disclosure to denote a network infrastructure component that provides wireless access to remote terminals. In WLANs, APs may also be referred to as STAs because they also compete for wireless channels. Also, depending on the network type, other well-known terms such as "mobile station", "subscriber station", "remote terminal", "user equipment", "wireless terminal", or "user device" may be used instead of "station" or "STA". For convenience, the terms "station" and "STA" are used in this disclosure to denote a remote wireless device that wirelessly accesses an AP or competes for wireless channels in a WLAN, regardless of whether the STA is a mobile device (such as a mobile phone or smartphone) or what is typically considered a fixed device (such as a desktop computer, AP, media player, fixed sensor, television, etc.).

[0034] 1, the dotted lines indicate the approximate extents of coverage areas 120 and 125 of APs 101 and 103, which are shown as approximately circular for purposes of illustration and explanation. It should be clearly understood that coverage areas associated with APs, such as coverage areas 120 and 125, may have other shapes, including irregular shapes, depending on the configuration of the APs.

[0035] As described in more detail below, one or more APs may include circuitry and / or programming for management of MU-MIMO and OFDMA channel sounding in a WLAN. FIG. 1 illustrates an example of a wireless network 100, although various modifications may be made to FIG. 1. For example, wireless network 100 may include any number of STAs and any number of APs in any suitable arrangement. AP 101 may also directly communicate with any number of STAs and provide those STAs with wireless broadband access to network 130. Similarly, each AP 101 and 103 may directly communicate with network 130 and provide the STAs with wireless broadband access to network 130. Additionally, AP 101 and / or 103 may provide access to other or additional external networks, such as an external telephone network or other type of data network.

[0036] 2a illustrates an example of an AP 101 according to an embodiment. The embodiment of the AP 101 illustrated in FIG. 2a is for illustrative purposes, and the AP 103 in FIG. 1 may have the same or a similar configuration. However, there are many different configurations of APs, and FIG. 2a does not limit the scope of the present disclosure to a particular implementation of an AP.

[0037] As shown in FIG. 2a, the AP 101 includes multiple antennas 204a-204n, multiple radio frequency (RF) transceivers 209a-209n, a transmit (TX) processing circuit 214, and a receive (RX) processing circuit 219. The AP 101 also includes a controller / processor 224, a memory 229, and a backhaul or network interface 234. The RF transceivers 209a-209n receive incoming RF signals, such as signals transmitted by STAs in the network 100, from the antennas 204a-204n. The RF transceivers 209a-209n downconvert the incoming RF signals to generate intermediate (IF) or baseband signals. The IF or baseband signals are sent to the RX processing circuit 219, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuit 219 sends the processed baseband signals to the controller / processor 224 for further processing.

[0038] The TX processing circuitry 214 receives digital or analog data (such as voice data, web data, email, or interactive video game data) from the controller / processor 224. The TX processing circuitry 214 encodes, multiplexes, and / or digitizes outgoing baseband data to generate processed baseband or IF signals. The RF transceivers 209a-209n receive the processed baseband or IF signals from the TX processing circuitry 214 and upconvert the baseband or IF signals to RF signals that are transmitted via the antennas 204a-204n.

[0039] The controller / processor 224 may include one or more processors or other processing devices that control the overall operation of the AP 101. For example, the controller / processor 224 may control the reception of uplink signals and the transmission of downlink signals by the RF transceivers 209a-209n, the RX processing circuitry 219, and the TX processing circuitry 214 in accordance with well-known principles. The controller / processor 224 may also support additional functionality, such as more advanced wireless communication functions. For example, the controller / processor 224 may support beamforming or directional routing operations in which outgoing signals from multiple antennas 204a-204n are weighted differently to effectively point the outgoing signals in a desired direction. The controller / processor 224 may also support OFDMA operations in which outgoing signals are assigned to different subsets of subcarriers for different recipients (e.g., different STAs 111-114). Any of a wide variety of other functions may be supported within the AP 101 by the controller / processor 224, including a combination of DL MU-MIMO and OFDMA on the same transmission opportunity. In some embodiments, the controller / processor 224 includes at least one microprocessor or microcontroller. The controller / processor 224 may also execute programs and other processes that reside in the memory 229, such as an OS. The controller / processor 224 may move data in and out of the memory 229 as required by the processes being executed.

[0040] The controller / processor 224 is also coupled to a backhaul or network interface 234. The backhaul or network interface 234 enables the AP 101 to communicate with other devices or systems over a backhaul connection or network. The interface 234 can support communication over any suitable wired or wireless connection(s). For example, the interface 234 can enable the AP 101 to communicate over a wired or wireless local area network or over a wired or wireless connection to a larger network (such as the Internet). The interface 234 includes any suitable communication supporting communication over a wired or wireless connection, such as an Ethernet or RF transceiver. The memory 229 is coupled to the controller / processor 224. A portion of the memory 229 can include RAM, and another portion of the memory 229 can include flash memory or other ROM.

[0041] As described in more detail below, the AP 101 may include circuitry and / or programming for managing channel sounding procedures in a WLAN. Although FIG. 2a illustrates an example of an AP 101, various modifications may be made to FIG. 2a. For example, the AP 101 may include any number of each of the components shown in FIG. 2a. As a particular example, the AP may include multiple interfaces 234, and the controller / processor 224 may support a routing function for routing data between different network addresses. As another example, although shown to include a single instance of the TX processing circuit 214 and a single instance of the RX processing circuit 219, the AP 101 may include multiple instances of each (such as one per RF transceiver). Alternatively, as in a conventional AP, only one antenna and RF transceiver path may be included. Also, the various components of FIG. 2a may be combined, further subdivided, or omitted, and additional components may be added according to specific needs.

[0042] As shown in FIG. 2a, in some embodiments, the AP 101 may be an AP MLD that includes multiple APs 202a-202n. Each AP 202a-202n is associated with the AP MLD 101 and includes multiple antennas 204a-204n, multiple radio frequency (RF) transceivers 209a-209n, a transmit (TX) processing circuit 214, and a receive (RX) processing circuit 219. Each AP 202a-202n may communicate independently with the controller / processor 224 and other components of the AP MLD 101. Although FIG. 2a shows each AP 202a-202n having separate antennas, each AP 202a-202n may share multiple antennas 204a-204n without requiring separate antennas. Each AP 202a-202n may represent a physical (PHY) layer and an underlying media access control (MAC) layer.

[0043] FIG 2b illustrates an example of a STA 111 according to an embodiment. The embodiment of the STA 111 illustrated in FIG 2b is for illustrative purposes, and the STAs 111-114 in FIG 1 may have the same or similar configurations. However, there are many different configurations of STAs, and FIG 2b does not limit the scope of the present disclosure to any particular implementation of a STA.

[0044] 2b, the STA 111 includes antenna(s) 205, an RF transceiver 210, a TX processing circuit 215, a microphone 220, and an RX processing circuit 225. The STA 111 also includes a speaker 230, a controller / processor 240, an input / output (I / O) interface (IF) 245, a touch screen 250, a display 255, and a memory 260. The memory 260 includes an operating system (OS) 261 and one or more applications 262.

[0045] The RF transceiver 210 receives incoming RF signals transmitted by APs of the network 100 from the antenna(s) 205. The RF transceiver 210 downconverts the incoming RF signals to generate IF or baseband signals. The IF or baseband signals are sent to the RX processing circuitry 225, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuitry 225 sends the processed baseband signals to the speaker 230 (e.g., in the case of voice data) or to the controller / processor 240 for further processing (e.g., in the case of web browsing data).

[0046] The TX processing circuitry 215 receives analog or digital voice data from a microphone (220) or other outgoing baseband data (such as web data, email, or interactive video game data) from the controller / processor 240. The TX processing circuitry 215 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate processed baseband or IF signals. The RF transceiver 210 receives the processed baseband or IF signals outgoing from the TX processing circuitry 215 and upconverts the baseband or IF signals to RF signals that are transmitted via the antenna(s) 205.

[0047] The controller / processor 240 may include one or more processors and execute a basic OS program 261 stored in memory 260 to control the overall operation of the STA 111. In one such operation, the controller / processor 240 controls the reception of downlink signals and the transmission of uplink signals by the RF transceiver 210, the RX processing circuitry 225, and the TX processing circuitry 215 in accordance with well-known principles. The controller / processor 240 may also include processing circuitry configured to provide management of channel sounding procedures for the WLAN. In some embodiments, the controller / processor 240 includes at least one microprocessor or microcontroller.

[0048] The controller / processor 240 may also execute other processes and programs resident in the memory 260, such as operations for managing channel sounding procedures for the WLAN. The controller / processor 240 may move data in and out of the memory 260 as required by the processes being executed. In some embodiments, the controller / processor 240 is configured to execute multiple applications 262, such as an application for channel sounding, including feedback calculation based on received null data packet announcements (NDPAs) and null data packets (NDPs) and sending beamforming feedback in response to trigger frames (TFs). The controller / processor 240 may operate the multiple applications 262 based on an OS program 261 or in response to signals received from the AP. The controller / processor 240 is also coupled to an I / O interface 245, which provides the STA 111 with the ability to connect to other devices, such as laptop computers and handheld computers. The I / O interface 245 is the communication path between these accessories and the main controller / processor 240.

[0049] Controller / processor 240 is also coupled to input 250 (such as a touch screen) and display 255. An operator of STA 111 can use input 250 to input data into STA 111. Display 255 may be a liquid crystal display, a light emitting diode display, or other display capable of rendering text and / or at least limited graphics from a website, etc. Memory 260 is coupled to controller / processor 240. A portion of memory 260 may include random access memory (RAM) and another portion of memory 260 may include flash memory or other read-only memory (ROM).

[0050] FIG. 2b illustrates an example of the STA 111, although various modifications may be made to FIG. 2b. For example, various components of FIG. 2b may be combined, further subdivided, or omitted, and additional components may be added depending on specific needs. In a particular example, the STA 111 may include any number (multiple) antennas 205 for MIMO communication with the AP 101. In another example, the STA 111 may not include voice communication, and the controller / processor 240 may be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Also, while FIG. 2b illustrates the STA 111 configured as a mobile phone or smartphone, the STA may be configured to operate as other types of mobile or fixed devices.

[0051] As shown in FIG. 2b, in some embodiments, the STA 111 may be a non-AP MLD that includes multiple STAs 203a-203n. Each STA 203a-203n is associated with the non-AP MLD 111 and includes antenna(s) 205, an RF transceiver 210, a TX processing circuit 215, and an RX processing circuit 225. Each STA 203a-203n may communicate independently with the controller / processor 240 and other components of the non-AP MLD 111. Although FIG. 2b shows each STA 203a-203n having a separate antenna, each STA 203a-203n may share the antenna 205 without requiring a separate antenna. Each STA 203a-203n may represent a physical (PHY) layer and an underlying media access control (MAC) layer.

[0052] 3 illustrates an example of a multi-link communication operation according to an embodiment. The multi-link communication operation may be available in the IEEE 802.11be standard and any future amendments to the IEEE 802.11 standard. In FIG. 3, the AP MLD 310 may be the wireless communication devices 101 and 103 of FIG. 1, and the non-AP MLD 220 may be one of the wireless communication devices 111-114 of FIG. 1.

[0053] As shown in FIG. 3, an AP MLD 310 may include multiple associated APs, including, for example, AP1, AP2, and AP3. Each associated AP includes a PHY interface to the wireless medium (Link 1, Link 2, or Link 3). The AP MLD 310 includes a single MAC Service Access Point (SAP) 318 through which the associated APs of the AP MLD 310 communicate with higher layers (Layer 3 or network layer). Each associated AP of the AP MLD 310 may have a different MAC address (lower MAC address) than the other associated APs of the AP MLD 310. The AP MLD 310 may have an MLD MAC address (higher MAC address), and the associated APs share a single MAC SAP 318 to Layer 3. Thus, the associated APs share a single IP address, and Layer 3 recognizes the AP MLD 310 by assigning a single IP address.

[0054] The non-AP MLD 320 may include multiple associated STAs, including, for example, STA1, STA2, and STA3. Each associated STA includes a PHY interface to the wireless medium (Link 1, Link 2, or Link 3). The non-AP MLD 320 includes a single MAC SAP 328 through which the associated STAs of the non-AP MLD 320 communicate with higher layers (Layer 3 or network layer). Each associated STA of the non-AP MLD 320 may have a different MAC address (lower MAC address) than the other associated STAs of the non-AP MLD 320. The non-AP MLD 320 may have an MLD MAC address (higher MAC address), and the associated STAs share a single MAC SAP 328 to Layer 3. Thus, the associated STAs share a single IP address, and Layer 3 recognizes the non-AP MLD 320 by assigning it a single IP address.

[0055] The AP MLD 310 and non-AP MLD 320 may set up multiple links between their associated APs and STAs. In this example, AP1 and STA1 may set up link 1 operating in the 2.4 GHz band. Similarly, AP2 and STA2 may set up link 2 operating in the 5 GHz band, and AP3 and STA3 may set up link 3 operating in the 6 GHz band. Each link may enable frame exchange and channel access between the AP MLD 310 and non-AP MLD 320 independently, which may improve data throughput and reduce latency.

[0056] In order to prioritize the transmission of different types of traffic, identified by traffic identifiers (TIDs), over the setup link, the non-AP MLD 320 may negotiate a TID-to-link mapping with the AP MLD 310. The TID-to-link mapping allows the AP MLD 310 and the non-AP MLD 320 to determine how frames belonging to a TID are assigned for transmission on each setup link in the uplink and downlink directions, respectively. If at least one TID associated with the non-AP MLD 320 is mapped to a setup link in either the uplink or downlink direction, the link is called a valid link for the non-AP MLD 320. By default, all TIDs are mapped to all setups between the AP MLD 310 and the non-AP MLD 320, and this mapping is called the default TID-to-link mapping. During association, the non-AP MLD 320 can negotiate a non-default mapping of TIDs to setup links using a negotiation procedure by including a TID-to-link mapping element in the association request or reassociation request frame. A non-default mapping is either when all TIDs are mapped to the same subset of setup links or when all TIDs are not mapped to the same subset of setup links. The AP MLD 310 can also use a broadcast procedure to indicate a switch to a non-default mapping for all associated non-AP MLDs. In the default mapping mode, all TIDs are mapped to all setup links for downlink and uplink, and all setup links are enabled. The non-AP MLD 320 operates in the default mapping mode if the TID-to-link mapping negotiation does not occur or fails.

[0057] 4 illustrates an example of a TID-to-Link Mapping element 400 according to an embodiment. This example of FIG. 4 may be applicable to the IEEE 802.11be standard and any future amendments to the IEEE 802.11 standard. The TID-to-Link Mapping element 400 may indicate the links over which frames belonging to each TID may be exchanged.

[0058] As shown in FIG. 4, the TID-to-Link Mapping element 400 may include an Element ID field, a Length field, an Element ID Extension field, a TID-to-Link Mapping Control field, a Mapping Switch Time field, an Expected Duration field, and optional Link Mapping of TID n fields.

[0059] The element ID field and the element ID extension field may include information to identify the TID-to-link mapping element 400. The length field may indicate the length of the TID-to-link mapping element 400.

[0060] The TID-to-Link Mapping control field may include a Direction subfield, a Default Link Mapping subfield, a Mapping Switch Time Present subfield, an Expected Duration Present subfield, a Link Mapping Size subfield, a Reserved subfield, and an optional Link Mapping Presence Indicator subfield. The Direction subfield may indicate whether the TID-to-Link mapping element 400 is for a downlink frame, an uplink frame, or both. For example, the Direction subfield may be set to 0 for a downlink frame, 1 for an uplink frame, and 2 for a frame transmitted on both the uplink and downlink. The Default Link Mapping subfield may indicate whether the TID-to-Link mapping element 400 represents a default TID-to-link mapping. For example, the subfield may be set to 1 for a default mapping and 0 for a non-default mapping. The Mapping Switch Time Present subfield may indicate whether a mapping switch time field is present in the TID-to-link mapping element 400. The Expected Duration Present subfield may indicate whether an Expected Duration field is present in the TID-to-link mapping element 400. The Link Mapping Size subfield may indicate the length of the link mapping for the TID n field. The Link Mapping Present Indicator subfield may indicate whether a link mapping for the TID n field is present in the TID-to-link mapping element 400.

[0061] The TID-to-link mapping element 400 is sent by an AP associated with an AP MLD in a beacon or probe response frame, and the mapping switch time field is present if the indicated TID-to-link mapping has not yet been established.

[0062] The expected duration field may indicate the duration that the proposed TID-to-link mapping is expected to be valid, if the mapping switch time field is present, and the remaining duration that the proposed TID-to-link mapping is expected to be valid, if the mapping switch time field is not present.

[0063] The link mapping field of TID n (e.g., where n=0,1,...,7) may indicate the links over which frames belonging to TID n are allowed to be transmitted. The link mapping field of TID n may carry a bitmap of the links to which TID n is mapped. The link mapping field of TID n may be absent if the default link mapping subfield of the TID-to-link mapping control field indicates a default TID-to-link mapping. For example, if the direction subfield is set to 0 and the link mapping field of TID 0 is configured to 10000....0, this configuration indicates that downlink data corresponding to TID 0 is transmitted on link 1.

[0064] The TID-to-link mapping element 400 may be included in various management frames, such as a beacon frame, an association request / response frame, a reassociation request / response frame, or a probe response frame.

[0065] To allow non-AP MLDs to conserve power, there may be several power management solutions. For example, STAs in a non-AP MLD may be in a doze state for extended periods during which frames are expected not to be transmitted or received. During this time, the corresponding AP in the AP MLD may buffer buffer-able units (BUs) (buffered BUs or buffered traffic) addressed to the STAs in the non-AP MLD. To indicate to all associated non-AP MLDs about the presence of pending BUs via broadcast or multicast signaling, each AP associated with the AP MLD periodically includes a traffic information map (TIM) element in the beacon frames it transmits, and each AP associated with the AP MLD may optionally transmit a separate periodic broadcast TIM frame. In multilink operation, APs in the AP MLD may include a multilink traffic indication element in the beacon frames to indicate the links on which the buffered BUs (or buffered traffic) may be obtained. A BU may be a medium access control (MAC) service data unit (MSDU), an aggregate MAC service data unit (MSDU) [quality of service (QoS) station (STA) only], or a bufferable MAC management protocol data unit (MMPDU). A BU may be buffered to operate a power saving mode. In this disclosure, the terms "buffered traffic" and "buffered BU" may be used interchangeably and have the same meaning.

[0066] 5a illustrates an example of a multilink traffic indication element according to an embodiment, which may be applicable to the IEEE 802.11be standard and any future amendments to the IEEE 802.11 standard.

[0067] As shown in FIG. 5, the multilink traffic indication element 500 may include an element ID field, a length field, an element ID extension field, a multilink traffic indication control field, and a per-link traffic indication list field.

[0068] The element ID field and the element ID extension field may contain information to identify the multilink traffic indication element 500. The length field may indicate the length of the multilink traffic indication element 500.

[0069] The Multilink Traffic Indication Control field may include a Bitmap Size subfield, an Association Identifier (AID) Offset subfield, and a Reserved subfield. The Bitmap Size subfield may indicate the size of the Traffic Indication Bitmap subfield for each link in the Traffic Indication List per Link field. The AID Offset subfield may indicate the number k bits of the Traffic Indication Virtual Bitmap in the TIM. The Traffic Indication Virtual Bitmap indicates the presence of pending traffic for a particular STA or non-AP MLD in the AP MLD.

[0070] The per-link traffic indication list field may include multiple per-link traffic indication bitmap subfields and a padding subfield. The per-link traffic indication bitmap subfield may indicate per-link traffic indications for non-AP MLDs that have negotiated TID-to-link mapping with the AP MLD, where not all TIDs are mapped to all valid links. In an embodiment, the per-link traffic indication bitmap subfield may indicate link recommendations for obtaining buffered traffic for non-AP MLDs that have negotiated TID-to-link mapping with the AP MLD, where all TIDs are mapped to all valid links. In an embodiment, the per-link traffic indication bitmap subfield may indicate link recommendations for obtaining buffered traffic for non-AP MLDs in a default mapping mode. The padding subfield may include padding bits to make the per-link traffic indication list field a multiple of 8 bits.

[0071] FIG. 5b illustrates an example of a multilink traffic indication element configuration according to an embodiment.

[0072] In Fig. 5b, the Traffic Indication Virtual Bitmap and Partial Virtual Bitmap subfields in the TIM element shown at the top and middle indicate how to indicate the AIDs of associated non-AP MLDs and STAs. An AP associated with an AP MLD may use the Partial Virtual Bitmap in the TIM element to indicate pending buffered traffic for STAs associated with the AP MLD and non-AP MLDs. The Partial Virtual Bitmap in the TIM element may include a portion of the Traffic Indication Virtual Bitmap shown at the top. An AP associated with an AP MLD should include a Multilink Traffic Indication element 500, shown partially at the bottom of Fig. 5b, in its beacon frame.

[0073] As described, the multilink traffic indication element 500 may include per-link traffic indication bitmap subfields corresponding to the AIDs of the STAs or non-AP MLDs starting from bit number k of the traffic indication virtual bitmap indicated in the AID offset subfield in the multilink traffic indication element 500. The order of the per-link traffic indication bitmap subfields may follow the order of the bits set to 1 in the partial virtual bitmap subfield in the TIM element. If the non-AP MLD has a non-default TID-to-link mapping with an AP MLD, then bit position i of the per-link traffic indication bitmap subfield for link ID i may be set to 1 if the AP MLD has a buffered BU or medium access control (MAC) management protocol data unit (MMPDU) with a TID that is mapped to that link for that non-AP MLD, otherwise the bit should be set to 0. When the non-AP MLD is in the default mapping mode, if the AP MLD has buffered BUs or MMPDUs and the non-AP MLD may use link i to retrieve the buffered BUs or MMPDUs, then bit position i of the Per-Link Traffic Indication Bitmap subfield for link ID i may be set to 1. Thus, the AP MLD may provide link recommendations to the non-AP MLD to use one or more available links to retrieve the buffered traffic (BUs or MMPDUs).

[0074] In the example of FIG. 5b, the first, third, fourth, and sixth AIDs in the partial virtual bitmap subfield in the TIM are set to 1, starting from bit number k of the traffic indication virtual bitmap indicated in the AID offset subfield. The per-link traffic indication bitmap subfields correspond to the first, third, fourth, and sixth AIDs in the partial virtual bitmap subfield in ascending order. The first per-link traffic indication bitmap subfield may indicate, with AID k, that the AP MLD has pending buffered traffic on link 0. Thus, the non-AP MLD with AID k can obtain the pending buffered traffic using link 0. The remaining per-link traffic indication bitmap subfields indicate the preferred links in a similar manner.

[0075] In some implementations, the AP MLD may not provide link recommendations for many non-AP MLDs. For example, this may occur for AIDs with default TID-to-link mappings or AIDs with non-default mappings, but with pending BUs mapped to all valid links. The same may be true for individually addressed management frames that are mapped to all setup links. In such cases, transmission of the multilink traffic indication element 500 may be avoided.

[0076] In an embodiment, the AP MLD may not provide the multilink traffic indication element 500 in the beacon frame if all associated non-AP MLDs with buffered BUs have at least one link with all TIDs mapped to the link. Also, the AP MLD may not provide the multilink traffic indication element in the beacon frame if all associated non-AP MLDs with buffered BUs have default TID-to-link mapping or all TIDs are mapped to the same subset of links. Thus, an AP associated with an AP MLD may include the multilink traffic indication element 500 in the beacon frame if at least one associated non-AP MLD has successfully negotiated a TID-to-link mapping and the AP MLD has buffered BUs with unmapped TIDs to all valid links for the non-AP MLD. Thus, the non-AP MLD may selectively include the multilink traffic indication element 500, thereby helping to address the beacon bloat problem.

[0077] In some implementations, there may be a mechanism for an AP MLD to indicate to a non-AP MLD in default mapping mode that the AP MLD has no link recommendation for the non-AP MLD. In some implementations, there may also be a mechanism for an AP MLD to indicate to a non-AP MLD in non-default mapping mode whether pending BUs may be fetched or retrieved from any setup link.

[0078] In an embodiment, if the non-AP MLD has negotiated a non-default TID-to-link mapping, but the AP MLD's pending buffered traffic is mapped to all valid links, the AP MLD may take any one of the following actions: i) set to 0 all bits in the per-link traffic indication bitmap subfield corresponding to the non-AP MLD's AID in the multilink traffic indication element, indicating that all buffered traffic may be fetched from any valid link; or ii) set to 1 a bit corresponding to link i of the non-AP MLD's AID in the per-link traffic indication bitmap subfield of the multilink traffic indication element, indicating that the buffered traffic may be fetched from link i. If at least one pending traffic in the AP MLD for the non-AP MLD is not mapped to all valid links, the AP MLD may not set to 0 all bits in the per-link traffic indication bitmap subfield corresponding to the non-AP MLD's AID in the multilink traffic indication element. If a non-AP MLD STA in non-default TID-to-link mapping mode receives a TIM element with the bit corresponding to its AID set to 1, and all bits in the per-link traffic indication bitmap subfield corresponding to that AID in the multilink traffic indication element may be set to 0, then any non-AP MLD STA operating on the valid link may send a PS (power save)-poll frame or a U-APSD (unscheduled automatic power save delivery) trigger frame (if the STA is using U-APSD and all access categories are delivery enabled) to obtain all buffered BUs from the AP MLD.

[0079] In one embodiment, the AP MLD may set all bits in the per-link traffic indication bitmap subfield corresponding to the AID of the non-AP MLD to indicate to the non-AP MLD that "most" of the pending BUs may be fetched from any of the available links. In one embodiment, the AP MLD may indicate that the AP MLD has no preferred link for the non-AP MLD to use to fetch buffered BUs, for example, using an "all zeros" indication to the non-AP MLD in the default TID-to-link mapping mode.

[0080] In some implementations, the bits unnecessarily reserved to indicate the recommended link may be wasteful and undesirable. This may make the size of the multilink traffic indication element 500 very large, reducing efficiency and making it difficult to fit those bits within a beacon frame. Thus, there is a need for a mechanism for an AP MLD to efficiently indicate a recommended link for fetching buffered traffic for only those non-AP MLDs for which it has link recommendations.

[0081] Figure 6a illustrates another example of a multilink traffic indication element 600 according to an embodiment. Figures 6b and 6c illustrate another example of a multilink traffic indication element configuration according to an embodiment. This example may be applicable to the IEEE 802.11be standard and any future amendments to the IEEE 802.11 standard.

[0082] 6a, the multilink traffic indication element 600 may include an element ID field, a length field, an element ID extension field, a multilink traffic indication control field, and a recommended partial virtual bitmap field, and a traffic indication list per link field. The multilink traffic indication control field may include a bitmap size subfield, an AID offset subfield, and a reserved subfield.

[0083] In some aspects, the various fields or subfields in the multilink traffic indication element 600 may be the same as or similar to the corresponding fields or subfields in the multilink traffic indication element 500 of FIG. 5a, with examples of differences described below. For example, the multilink traffic indication element 600 may include an additional field called a recommended partial virtual bitmap field.

[0084] 6a and 6b, the AID offset subfield in the multilink traffic indication element 600 may indicate bit number k of the traffic indication virtual bitmap. The recommended partial virtual bitmap field may have bits for all AIDs in the partial virtual bitmap subfield of the TIM element starting with AID k indicated in the AID offset subfield. A bit for a particular AID may be set to 1 only if the AP MLD has a pending BU for the AID and the AP MLD has a recommended link to obtain the pending BU. Otherwise, the bit for the AID may be set to 0. A bit may always be set to 0 for non-AP MLD or non-MLD STAs with a single valid link.

[0085] The length of the Recommended Partial Virtual Bitmap field, excluding zero padding, may be the same as the length of the Partial Virtual Bitmap subfield in the TIM element, as shown in Figure 6b. In one embodiment, zero padding may be used to make the length of the field a multiple of 8 bits. In one embodiment, the multilink traffic indication element 600 may additionally have a Recommended Partial Virtual Bitmap Length field to indicate the length, in octets, of the Recommended Partial Virtual Bitmap field.

[0086] The per-link traffic indication list field in the multilink traffic indication element 600 may include multiple per-link traffic indication bitmap subfields and padding subfields in a manner similar to that shown in Figures 5a and 5b. The per-link traffic indication bitmap subfield may start with bit number k of the traffic indication virtual bitmap as shown in Figure 6b, correspond to the non-AP MLD and AID of the STA, and be set to 1. The per-link traffic indication list field may include l per-link traffic indication bitmap subfields, where l is the number of bits in the recommended partial virtual bitmap field of the multilink traffic indication element 600, start with AID k, correspond to the non-AP MLD and AID of the STA, and be set to 1.

[0087] In the example of Figure 6b, there are four bits set to 1 corresponding to four AIDs (i.e., AID k, AID k+2, AID k+3, and AID k+5) in the partial virtual bitmap subfield in the TIM element. However, only two bits corresponding to two AIDs (i.e., AID k and AID k+5) are set to 1 in the recommended partial virtual bitmap because the AP MLD does not have link recommendations for AID k+2 and AID k+3, which are set to 1 in the partial virtual bitmap. As a result, the per-link traffic indication list field contains only two per-link traffic indication bitmap subfields corresponding to AID k and AID k+5, which are set to 1 in the recommended partial virtual bitmap. The first per-link traffic indication bitmap subfield indicates link 0 as the preferred link for non-AP MLD with AID k, and the second per-link traffic indication bitmap subfield indicates link 1 as the preferred link for non-AP MLD with AID k+5 by setting the bit corresponding to the preferred link to 1 and the other bits to 0.

[0088] In an embodiment, the recommended partial virtual bitmap field may be carried in an information element or frame other than the multilink traffic indication element 600. For example, it may be carried in a TIM element or an EHT action frame.

[0089] Figure 6c illustrates another example of a multilink traffic indication element configuration according to an embodiment, which uses the multilink traffic indication element 600 described with reference to Figures 6a and 6b, with example differences described below.

[0090] The length of the Recommended Partial Virtual Bitmap field may be equal to the number of bits (excluding zero padding) l that are set to 1 and correspond to the AIDs of non-AP MLDs or STAs, starting from bit number k of the Partial Virtual Bitmap subfield of the TIM element. The order of bits in the Recommended Partial Virtual Bitmap field may follow the order of the AID bits of non-AP MLDs or STAs that are set to 1 in the Partial Virtual Bitmap of the TIM element. In FIG. 6c, if AID k+3 is the third bit set to 1 in the Partial Virtual Bitmap of the TIM element (counting from AID k), then the third bit of the Recommended Partial Virtual Bitmap filed in the multilink traffic indication element 600 corresponds to AID k+3. The length of the Recommended Partial Virtual Bitmap field may be inferred from the number of bits that are set to 1 in the Partial Virtual Bitmap of the TIM element, starting from AID k. In an embodiment, zero padding may be used to make the length of this field a multiple of 8 bits. In an embodiment, the multilink traffic indication element 600 may additionally have a Recommended Partial Virtual Bitmap field to indicate the length of the Recommended Partial Virtual Bitmap field in octets. In FIG. 6c, the length of the Recommended Partial Virtual Bitmap field is 4 bits excluding zero padding, but the Partial Virtual Bitmap subfield of the TIM element is 6 bits because, starting from AID k, only 4 bits corresponding to 4 out of 6 AIDs (i.e., AID k, AID k+2, AID k+3, AID k+5) are set to 1. As a result, the length of the Recommended Partial Virtual Bitmap field may be reduced by 2 bits compared to the embodiment of FIG. 6b.

[0091] The per-link traffic indication list field in the multilink traffic indication element 600 may include multiple per-link traffic indication bitmap subfields and padding subfields in a manner similar to that shown in Figure 6b. The per-link traffic indication bitmap subfield starts at bit number k of the traffic indication virtual bitmap, which is set to 1 and corresponds to the AIDs of the STAs and non-AP MLDs, as shown in Figure 6c. The per-link traffic indication list field includes l per-link traffic indication bitmap subfields, where l is the number of bits in the recommended partial virtual bitmap field of the multilink traffic indication element 600 that are set to 1 and correspond to the AIDs of the STAs and non-AP MLDs.

[0092] In the example of Figure 6c, there are four bits set to 1 corresponding to four AIDs (i.e., AID k, AID k+2, AID k+3, and AID k+5) in the partial virtual bitmap subfield in the TIM element. However, because the AP MLD does not have a link recommendation for AID k+2 and AID k+3 that are set to 1 in the partial virtual bitmap, only two bits corresponding to two AIDs (i.e., AID k and AID k+5) are set to 1 in the recommended partial virtual bitmap. As a result, the per-link traffic indication list field includes only two per-link traffic indication bitmap subfields corresponding to AID k and AID k+5 that are set to 1 in the recommended partial virtual bitmap. The first per-link traffic indication bitmap subfield indicates link 0 as the preferred link for non-AP MLD with AID k, and the second per-link traffic indication bitmap subfield indicates link 1 as the preferred link for non-AP MLD with AID k+5 by setting the bit corresponding to the preferred link to 1 and the other bits to 0.

[0093] 7a illustrates another example of a multilink traffic indication element 7000 according to an embodiment, which may be usable in the IEEE 802.11be standard and any future amendments to the IEEE 802.11 standard.

[0094] 7a, the multilink traffic indication element 700 may include an element ID field, a length field, an element ID extension field, a multilink traffic indication control field, an optional recommended partial virtual bitmap field, and a per-link traffic indication list field. The multilink traffic indication control field may include a bitmap size subfield, an AID offset subfield, and a recommended bitmap present subfield.

[0095] In some aspects, various fields or subfields in the multilink traffic indication element 700 may be the same as or similar to corresponding fields or subfields in the multilink traffic indication element 600 of FIG. 6a, with example differences described below. For example, the multilink traffic indication element 700 may include an additional subfield in the multilink traffic indication control field, called a recommended bitmap present subfield. The recommended bitmap present subfield indicates whether the optional recommended partial virtual bitmap field is present. The recommended bitmap present subfield is set to 1 if the recommended partial virtual bitmap field is present. Otherwise, the recommended bitmap present subfield is set to 0.

[0096] 7b illustrates another example of a configuration of a multilink traffic indication element when a recommended partial virtual bitmap field is present according to an embodiment. In FIG. 7b, the recommended bitmap present subfield (B15) in the multilink traffic indication control field is set to 1 to indicate the presence of the optional recommended partial virtual bitmap field. The order of the recommended link indications and AIDs in the per-link traffic indication list field is the same as or similar to FIG. 6c. The per-link traffic indication list field may include l per-link traffic indication bitmap subfields, where l is the number of bits set to 1 in the recommended partial virtual bitmap field of the multilink traffic indication element 700 and corresponding to the STA and non-AP MLD AIDs.

[0097] Figure 7c illustrates another example of the configuration of the multilink traffic indication element when the recommended partial virtual bitmap field is not present according to an embodiment. In Figure 7c, the recommended bitmap present subfield (B15) in the multilink traffic indication control field is set to 0, indicating that the optional recommended partial virtual bitmap field is not present. The order of the indications and AIDs of the recommended links in the per-link traffic indication list field is the same or similar to that in Figure 5b. The per-link traffic indication list field includes l per-link traffic indication bitmap subfields, where l is the number of bits corresponding to the AIDs of the STAs and non-AP MLDs starting from AID k in the partial virtual bitmap subfield of the TIM element included in the beacon frame with the multilink traffic indication element, set to 1.

[0098] The AP MLD may determine whether to include the recommended partial virtual bitmap field based on, for example, the number of AIDs for which the AP MLD has link recommendations for fetching pending traffic and the number of AIDs with pending traffic.

[0099] If the recommended partial virtual bitmap field is present, when a non-AP MLD receives a TIM element with partial virtual bitmap set to 1 for that AID and a multilink traffic indication element 700 with recommended partial virtual bitmap set to 0 for that AID, the non-AP MLD may not decode the remaining part of the multilink traffic indication element. In an embodiment, the non-AP MLD may use any valid link to fetch pending BUs in the AP MLD. In one embodiment, the non-AP MLD may use any of the valid links with all TIDs mapped to the non-AP MLD to fetch pending BUs in the AP MLD.

[0100] In an embodiment, if the recommended partial virtual bitmap field is present and a non-AP MLD receives a multilink traffic indication element 700 with the recommended partial virtual bitmap set to 1 for its AID, or if the recommended partial virtual bitmap field is not present, the non-AP MLD may parse the per-link traffic indication list field to determine a list of recommended links for the non-AP MLD.

[0101] In one embodiment, the recommended partial virtual bitmap field may be carried in an information element or frame other than the multilink traffic indication element 700. For example, it may be carried in a TIM element or an EHT action frame.

[0102] 8a illustrates another example of a multilink traffic indication element 800 according to an embodiment, which may be usable in the IEEE 802.11be standard and any future amendments to the 802.11 standard.

[0103] 8a, the multilink traffic indication element 800 may include an Element ID field, a Length field, an Element ID Extension field, a Multilink Traffic Indication Control field, an optional Incremental AID List field, and a Traffic Indication List Per Link field. The Multilink Traffic Indication Control field may include a Bitmap Size subfield, an AID Offset subfield, and a Traffic List Format subfield.

[0104] In some aspects, various fields or subfields within the multilink traffic indication element 800 may be the same as or similar to corresponding fields or subfields within the multilink traffic indication element 700 of FIG. 7a, with example differences described below. For example, the multilink traffic indication element 800 may include an optional Incremental AID List field in place of the optional Recommended Partial Virtual Bitmap field in the multilink traffic indication element 700 of FIG. 7a. Additionally, the multilink traffic indication element 800 may include a Traffic List Format subfield within the multilink traffic indication control field in place of a Recommended Bitmap Present subfield. The Traffic List Format subfield may indicate whether an Incremental AID List field is present. The Traffic List Format subfield may be set to 1 if the Incremental AID List field is present. Otherwise, the Traffic List Format subfield may be set to 0.

[0105] If the Traffic List Format subfield is set to 0, the Increment AID List field may not be present and the Per Link Traffic Indication List field may include l Per Link Traffic Indication Bitmap subfields, where l is the number of bits set to 1 in the Partial Virtual Bitmap subfield of the TIM element and corresponding to the STA and non-AP MLD AIDs. The order of the preferred link indications and AIDs in the Per Link Traffic Indication List field may be the same as or similar to Figure 5b.

[0106] If the Traffic List Format subfield is set to 1, the Increment AID List field may be present and may indicate a list of AIDs for which the AP MLD provides link recommendations for fetching pending BUs. In this embodiment, instead of indicating the actual AID values, only the increment value for k is indicated. The size of each increment AID value in bits is

number

[0107] FIG. 8b illustrates another example of a multilink traffic indication element configuration according to an embodiment.

[0108] In Figure 8b, the Incremental AID List Format field has a list of AIDs including AID k and AID k+5 in the Partial Virtual Bitmap subfield. Even though the corresponding bits in the Partial Virtual Bitmap subfield are set to 1, there are no link recommendations for AID k+2 and AID k+3 in the Per Link Traffic Indication List field because there are no corresponding increment values ​​for AID k+2 and AID k+3. Thus, the Per Link Traffic Indication List field contains two Per Link Traffic Indication Bitmap subfields because the Incremental AID List field has two bits corresponding to AID k and AID k+5.

[0109] In one embodiment, for any AID x, the incremental AID value may hold a count of the number of bits set to 1 between the bit for AID k and the bit corresponding to AID x, and the size of each incremental AID value in bits is:

number

[0110] In an embodiment, the length of each of the incremental AID values ​​within the Increment AID List Format subfield may be indicated in a separate and optional Increment AID Length field or subfield of the multilink traffic indication element.

[0111] If a non-AP MLD receives a multilink traffic indication element 800 with a partial virtual bitmap for that AID set to 1 and the increment AID list field does not contain its corresponding increment value (with respect to k), the non-AP MLD may not decode the remainder of the multilink traffic indication element 800. In this case, the non-AP MLD may use any of its valid links to fetch pending BUs at the AP MLD. In one embodiment, the non-AP MLD may use any of its valid links with all TIDs that map to valid links to fetch pending buffered BUs at the AP MLD.

[0112] In an embodiment, if a non-AP MLD receives a multilink traffic indication element 800 in which the Increment AID List field includes its corresponding increment value (with respect to k) and the Traffic List Format subfield is set to 0, the non-AP MLD may parse the Per-Link Traffic Indication List field to determine link recommendations for the non-AP MLD.

[0113] In one embodiment, the Increment AID List fields may be carried in an information element or frame other than the Multilink Traffic Indication element 800. For example, they may be carried in a TIM element or an EHT Action frame.

[0114] FIG. 9 illustrates another example of a multilink traffic indication element configuration according to an embodiment.

[0115] A multilink traffic indication element may also be transmitted in an individually addressed or group addressed frame without an associated TIM element, in this example, the multilink traffic indication element may be referred to as a "long-term" multilink traffic indication element.

[0116] The long-term multilink traffic indication element may be the same as or similar to the multilink traffic indication element 600 of FIG. 6, except for the AID offset subfield, which indicates the number n, as shown in FIG. 9. The recommended partial virtual bitmap field may have bits for all AIDs starting with AID f(n), where f(n) may be some function of n, e.g., 2n, 8n, or 16n. A bit for a particular AID in the recommended partial virtual bitmap field may be set to 1 only if the AP MLD intends to provide a link recommendation for fetching pending traffic buffered to a non-AP MLD with that AID. Otherwise, the bit for the AID may be set to 0. In an embodiment, zero padding may be used to make the length of this field a multiple of 8 bits.

[0117] In an embodiment, the long term multilink traffic indication element may additionally have a Recommended Partial Virtual Bitmap Length field to indicate the length of the Recommended Partial Virtual Bitmap field in octets.

[0118] A non-AP MLD receiving a long-term multilink traffic indication element may use the recommended link set for fetching pending buffered traffic indicated in all subsequent TIM elements unless the TIM element is accompanied by an associated multilink traffic indication element that recommends an alternate link set for fetching the buffered traffic indicated in the TIM element. Thus, a long-term multilink traffic indication element without an associated TIM element may indicate a "long-term" link recommendation to a non-AP MLD.

[0119] The newly received long-term multilink traffic indication element may replace the previous long-term multilink traffic indication element indication for the non-AP MLD. If the link recommendations for the non-AP MLD are included in the new long-term multilink traffic indication element and the bits for all links are set to 1, this may indicate that the previous long-term multilink traffic indication element is discarded or deactivated for the non-AP MLD. In an embodiment, the AP MLD may not provide a multilink traffic indication element in a beacon frame together with a TIM element if the link recommendations in the long-term multilink traffic indication element are sufficient and valid to retrieve the buffered traffic for all associated non-AP MLDs with buffered BUs.

[0120] FIG. 10 illustrates an example process 1000 for indicating buffered traffic using a multilink traffic indication element by AP MLD according to an embodiment.

[0121] In operation 1001, the AP MLD determines whether the AP MLD has pending buffered traffic for a non-AP MLD with AID x. If the AP MLD has pending buffered traffic for a non-AP MLD with AID x, the process 1000 proceeds to operation 1003. In an embodiment, the process 1000 operates if a non-AP MLD associated with the AP MLD has negotiated a non-default TID-to-link mapping, but the AP MLD's pending buffered traffic is mapped to all valid links.

[0122] In operation 1003, the AP MLD sets the bit corresponding to AID x in the partial virtual bitmap subfield of the TIM element to 1. The process 1000 then proceeds to operation 1005.

[0123] In operation 1005, the AP MLD determines whether all buffered traffic can be fetched from any valid link by the non-AP MLD with AID x. If all buffered traffic can be fetched from any valid link by the non-AP MLD with AID x, the process 1000 proceeds to operation 1007, otherwise, the process 1000 proceeds to operation 1009.

[0124] In operation 1007, the AP MLD sets all bits corresponding to the non-AP MLD's AID x in the per-link traffic indication bitmap subfield of the multilink traffic indication element to 0. This indicates that all buffered traffic may be fetched from any valid link of the non-AP MLD with AID x.

[0125] In operation 1009, the AP MLD does not set all bits corresponding to the non-AP MLD's AID x in the per-link traffic indication bitmap subfield of the multilink traffic indication element to 0. The AP MLD may set the bit corresponding to the non-AP MLD's link i with AID x in the per-link traffic indication bitmap subfield of the multilink traffic indication element to 1 to indicate that pending buffered traffic may be fetched from link i.

[0126] FIG. 11 illustrates another example of a process 1100 for indicating buffered traffic using a multilink traffic indication element with AP MLD according to an embodiment.

[0127] In operation 1101, the AP MLD determines whether the AP MLD has pending buffered traffic for a non-AP MLD with AID x. The process 1100 proceeds to operation 1103 if the AP MLD has pending buffered traffic for a non-AP MLD with AID x.

[0128] At operation 1103, the AP MLD sets the bit corresponding to AID x in the partial virtual bitmap subfield of the TIM element to 1. The process 1100 then proceeds to operation 1105.

[0129] In operation 1105, the AP MLD determines whether the multilink traffic indication element includes an optional field. In an embodiment, the optional field may be a Recommended Partial Virtual Bitmap field, a Recommended Partial Virtual Bitmap Length field, a Recommended Bitmap Present subfield, an Increment AID List field, or a Traffic List Format subfield, which are described with reference to Figures 6a-9. The process 1100 proceeds to operation 1107 if the AP MLD includes the optional field in the multilink traffic indication element. Otherwise, the process proceeds to operation 1113.

[0130] In operation 1107, the AP MLD determines whether it has a link recommendation for a non-AP MLD with AID x. If the AP MLD has a link recommendation for a non-AP MLD with AID x, the process 1100 proceeds to operation 1109. Otherwise, the process 1100 proceeds to operation 1111.

[0131] In operation 1109, the AP MLD includes optional fields in the multilink traffic indication element. For example, the optional fields may include a recommended partial virtual bitmap field, a recommended partial virtual bitmap length field, a recommended bitmap present subfield, an increment AID list field, or a traffic list format subfield. Additionally, the AP MLD includes the AID x of the non-AP MLD in a per-link traffic indication list field of the multilink traffic indication element.

[0132] In operation 1111, the AP MLD includes optional fields in the multilink traffic indication element. For example, the optional fields may include a recommended partial virtual bitmap field, a recommended partial virtual bitmap length field, a recommended bitmap present subfield, an increment AID list field, or a traffic list format subfield. However, the AP MLD does not include the AID x of the non-AP MLD in the per-link traffic indication list field in the multilink traffic indication element.

[0133] In operation 1113, the AP MLD includes the AID x of the non-AP MLD in a per-link traffic indication list field in a multilink traffic indication element.

[0134] FIG. 12 illustrates an example process 1200 for receiving a multilink traffic indication element via non-AP MLD according to an embodiment.

[0135] At operation 1201, the non-AP MLD detects that the non-AP MLD receives a TIM element in a beacon frame indicating pending buffered traffic for the non-AP MLD's AID. If the non-AP MLD receives a TIM element in a beacon frame, the process 1200 proceeds to operation 1203. Otherwise, the process proceeds to operation 1211 and returns to a doze state.

[0136] In operation 1203, the non-AP MLD determines whether a multilink traffic indication element is present in the beacon frame. If a multilink traffic indication element is present in the beacon frame, the process 1200 proceeds to operation 1205. Otherwise, the process 1200 proceeds to operation 1209.

[0137] In operation 1205, the non-AP MLD determines whether there is a per-link traffic indication for the AID of the non-AP MLD. The per-link traffic indication may be present in a per-link traffic indication bitmap subfield in a per-link traffic indication list field of the multilink traffic indication element. In one embodiment, the multilink traffic indication element may include optional fields, for example, the optional fields may include a recommended partial virtual bitmap field, a recommended partial virtual bitmap length field, a recommended bitmap present subfield, an increment AID list field, or a traffic list format subfield. The recommended partial virtual bitmap field and the increment AID list field indicate the presence of a recommended link to the non-AP MLD. Thus, the non-AP MLD may determine whether there is a per-link traffic indication for the AID of the non-AP MLD in the per-link traffic indication bitmap subfield based on the increment AID list field and the recommended partial virtual bitmap field. The process 1200 proceeds to operation 1207 if there is a per-link traffic indication for the AID of the non-AP MLD. Otherwise, proceed to action 1209.

[0138] In operation 1207, the non-AP MLD fetches pending traffic in the AP MLD using the links indicated in the per-link traffic indication list field of the multilink traffic indication element. The non-AP MLD STAs operating on the links indicated in the per-link traffic indication list field can send PS poll frames or U-APSD trigger frames to obtain buffered traffic from the AP MLD.

[0139] In operation 1209, the non-AP MLD fetches the pending buffered traffic in the AP MLD by sending a PS poll frame or a U-APSD trigger frame to obtain the buffered traffic from the AP MLD using the previously determined linked list.

[0140] Reference to an element in the singular is intended to mean one or more, unless specifically stated otherwise, and not to mean one and only one. For example, "a" module may refer to one or more modules. An element preceded by "a," "an," "the," or "said" does not exclude the presence of additional identical elements, unless further constraints are present.

[0141] Headings and subheadings, if any, are used for convenience only and do not limit the invention. The word exemplary is used in the sense of serving as an example or illustration. To the extent that the terms "include," "have," and the like are used, such terms are intended to be inclusive in the same manner as the term "comprise" is interpreted when used as a transitional term in the claims. Relative terms, such as first and second, may be used to distinguish one entity or action from another, but do not necessarily require or imply an actual relationship or order between such entities or actions.

[0142] Phrases such as "an aspect," "the aspect," "another aspect," "some aspects," "one or more aspects," "an implementation," "the implementation," "some implementations," "one or more implementations," "an embodiment," "the embodiment," "one embodiment," "some embodiments," "one or more implementations," "configuration," "the configuration," "another configuration," "some configurations," "one or more configurations," "the subject technology," "the discosure," "the present closure," "other variations thereof," and similar phrases are used for convenience and do not imply that disclosure associated with such phrase(s) is essential to the subject technology or that such disclosure applies to all configurations of the subject technology. Disclosure relating to such phrase(s) may apply to all configurations or to one or more configurations. Disclosure relating to such phrase(s) may provide one or more examples. Phrases such as "an aspect" or "some aspects" may refer to one or more aspects, and vice versa, as applicable to the above phrases as well.

[0143] The phrase "at least one" preceding a list of items, together with the terms "and" or "or" separating any items, modifies the list as a whole, not each member of the list. The phrase "at least one" does not require the selection of at least one item; rather, the phrase allows for a meaning including at least one of any one of the items, and / or at least one of any combination of the items, and / or at least one of each of the items. By way of example, each of the phrases "at least one of A, B, and C," or "at least one of A, B, or C" refers to A only, B only, C only; any combination of A, B, and C; and / or at least one of each of A, B, and C.

[0144] It is understood that the particular order or hierarchy of steps, operations, or processes set forth is illustrative of an example approach. It is understood that the particular order or hierarchy of steps, operations, or processes may be performed in different orders unless expressly stated otherwise. Some steps, operations, or processes may be performed simultaneously or as part of one or more other steps, operations, or processes. The accompanying method claims present various steps, operations, or process elements in a sample order in some cases, and are not meant to be limited to the particular order or hierarchy presented. These may be performed serially, linearly, in parallel, or in different orders. It should be understood that the instructions, operations, and systems described may generally be integrated into a single software / hardware product or packaged into multiple software / hardware products.

[0145] The present disclosure is provided to enable those skilled in the art to practice the various aspects described herein. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology. The disclosure provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the principles described herein may be applied to other aspects.

[0146] All structural and functional equivalents to the elements of various aspects described throughout this disclosure that are known or later become known to those of ordinary skill in the art are intended to be expressly incorporated herein by reference and encompassed by the claims. Moreover, nothing disclosed herein is intended to be disclosed to the public, regardless of whether such disclosure is expressly recited in the claims. No element of a claim shall be construed under the provisions of 35 USC §112, sixth paragraph, unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, unless the element is recited using the phrase "step for."

[0147] The title, background, brief description of the drawings, abstract, and drawings are incorporated into this disclosure and are provided as illustrative examples of the disclosure, not as limiting descriptions. They are submitted with the understanding that they will not be used to limit the scope or meaning of the claims. Moreover, in the detailed description, it can be understood that various features are grouped together in various implementations for the purpose of the description providing illustrative examples and streamlining the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed structure or operation. The following claims are incorporated into the detailed description on their own as if each claim were separately claimed subject matter.

[0148] The claims are not intended to be limited to the aspects described herein but are to be accorded the full scope consistent with the language of the claims, including all legal equivalents. Nonetheless, no claim is intended, and should not be construed, to cover subject matter that does not comply with the requirements of applicable patent law.

Claims

1. An access point (AP) multi-link device (MLD) associated with a wireless communication, At least two APs associated with the AP MLD; a processor coupled to the at least two APs; Including, The processor is configured to generate a traffic indication map (TIM) element indicating pending buffered traffic for a plurality of non-AP MLDs associated with the AP MLD, selectively generate a multi-link traffic indication element including per-link traffic indications to obtain buffered traffic for the at least one non-AP MLD based on a determination of whether all the plurality of non-AP MLDs have a default traffic identifier (TID)-to-link mapping and whether the AP MLD has buffered traffic with TIDs mapped to all valid links for at least one non-AP MLD, generate a beacon frame including the selectively included multi-link traffic indication element and the TIM element, and transmit the beacon frame to the plurality of non-AP MLDs. AP MLD.

2. The processor is configured to generate the multilink traffic indication element when at least one associated non-AP MLD successfully negotiates a TID-to-link mapping with the AP MLD and the AP MLD has buffered traffic with a TID that is not mapped to all valid links for the at least one non-AP MLD. The AP MLD of claim 1.

3. The processor is configured to generate the multilink traffic indication element when the AP MLD intends to provide a link recommendation for obtaining buffered traffic to the at least one non-AP MLD. The AP MLD according to claim 1 or claim 2.

4. The processor is configured to refrain from generating the multilink traffic indication element when the AP MLD does not intend to provide link recommendations for obtaining buffered traffic to any of the associated non-AP MLDs and when the AP MLD does not have buffered traffic with TIDs that are mapped to only a subset of valid links for any of the associated non-AP MLDs. The AP MLD according to any one of claims 1 to 3.

5. The multi-link traffic indication element includes a recommendation field indicating to the at least one non-AP MLD that the AP MLD should provide the per-link traffic indication for obtaining buffered traffic; The traffic indication for each link includes a link recommendation or a traffic indication. The AP MLD according to any one of claims 1 to 4.

6. A non-access point (AP) multi-link device (MLD) associated with a wireless communication, comprising: At least two stations (STAs) associated with the non-AP MLD; a processor coupled to the at least two STAs; Including, The processor receives a traffic indication map (TIM) element included in a beacon frame from an AP MLD associated with an AP MLD, the TIM element indicating pending buffered traffic for the non-AP MLD; determines whether a multi-link traffic indication element is present in the beacon frame, the multi-link traffic indication element being selectively included in the beacon frame based on whether all of the non-AP MLDs associated with the AP MLD have a default traffic identifier (TID)-to-link mapping and whether the AP MLD has buffered traffic with TIDs mapped to all valid links for the associated non-AP MLD; if the multi-link traffic indication element is present, determines whether a per-link traffic indication for the non-AP MLD is present in the multi-link traffic indication element, the per-link traffic indication for the non-AP MLD providing a link recommendation or traffic indication for obtaining the buffered traffic for the non-AP MLD; and if the per-link traffic indication for the non-AP MLD is present, determines whether a per-link traffic indication for the non-AP MLD is present in the multi-link traffic indication element, the multi-link traffic indication element being selectively included in the beacon frame based on whether all of the non-AP MLDs associated with the AP MLD have a default traffic identifier (TID)-to-link mapping and whether the AP MLD has buffered traffic with TIDs mapped to all valid links for the associated non-AP MLD. sending a trigger frame to the AP MLD to obtain buffered traffic through the link indicated in the per-link traffic indication; and receiving the buffered traffic through the link indicated in the per-link traffic indication from the AP MLD; Non-AP MLD.

7. The multilink traffic indication element is present in the beacon frame if at least one of the associated non-AP MLDs has successfully negotiated a TID-to-link mapping with the AP MLD and the AP MLD has buffered traffic with a TID that is not mapped to any valid link for the associated non-AP MLD. The non-AP MLD of claim 6.

8. The multilink traffic indication element is present in the beacon frame if the AP MLD intends to provide link recommendations for retrieving buffered traffic to at least one associated non-AP MLD. The non-AP MLD according to claim 6 or claim 7.

9. The multilink traffic indication element is not present in the beacon frame if the AP MLD does not intend to provide link recommendations to any of the associated non-AP MLDs and if the AP MLD does not have buffered traffic with TIDs that map to a subset of valid links to any of the associated non-AP MLDs. The non-AP MLD according to any one of claims 6 to 8.

10. The multi-link traffic indication element includes a recommendation field indicating at least one non-AP MLD to which the AP MLD provides the per-link traffic indication; The processor is configured to determine whether the per-link traffic indication for the non-AP MLD is present in the multi-link traffic indication element based on the recommendation field. The non-AP MLD according to any one of claims 6 to 9.

11. The recommendation field includes a set of bits, each bit starting from an offset number of a traffic indication virtual bitmap within the TIM element and corresponding to a respective one of an associated non-AP MLD and non-AP station (STA); Each bit indicates whether the AP MLD provides the per-link traffic indication to a corresponding non-AP MLD or non-AP STA. The non-AP MLD according to any one of claims 6 to 10.

12. The recommendation field includes a set of bits, each bit starting from an offset number of a traffic indication virtual bitmap in the TIM element and corresponding to a respective one of an associated non-AP MLD and non-AP STA that is indicated as having buffered traffic in the traffic indication virtual bitmap in the TIM element; Each bit indicates whether the AP MLD provides the per-link traffic indication to a corresponding non-AP MLD or non-AP STA. The non-AP MLD according to any one of claims 6 to 11.

13. the multilink traffic indication element optionally includes the recommendation field, and includes a recommendation present field indicating whether the recommendation field is present in the multilink traffic indication element; The processor is further configured to determine, based on the recommended presence field, whether the multilink traffic indication element includes the recommended field. The non-AP MLD according to any one of claims 6 to 12.

14. the multi-link traffic indication element includes one or more per-link traffic indication fields, each field providing a traffic indication or link recommendation for a respective one of the at least one non-AP MLD; A non-AP MLD according to any one of claims 6 to 13.

15. The multilink traffic indication element is included in a group addressing frame, is not associated with the TIM element, and includes a recommendation field indicating at least one non-AP MLD for which the AP MLD provides the per-link traffic indication. The non-AP MLD according to any one of claims 6 to 14.

Images