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] The present disclosure generally relates to wireless communication, and more specifically, for example, to multi-link traffic indication for multi-link devices in a wireless communication system, but is not limited thereto.

Background Art

[0002] Wireless Local Area Network (WLAN) technology has evolved towards improving data rates and has continued to grow in various markets such as homes, enterprises, and hotspots for many years since the late 1990s. WLAN enables 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 standards. The family of IEEE 802.11 standards aims to improve speed and reliability and expand the operating range of wireless networks.

[0003] WLAN devices are increasingly required to support various latency-sensitive applications or real-time applications such as extended reality (AR), robotics, artificial intelligence (AI), cloud computing, and autonomous vehicles. To implement the extremely low latency and extremely high throughput required by such applications, multi-link operation (MLO) has been proposed for WLAN. WLANs are formed within limited areas such as homes, schools, apartments, or office buildings by WLAN devices. Each WLAN device may have one or more stations (STA) such as an access point (AP) STA and a non-access point (non-AP) STA.

[0004] MLO (Multi-Link Object) can enable non-AP (Application Platform) multi-link devices (MLDs) to set up multiple links with AP MLDs. Each of these links may independently enable channel access and frame exchange between the non-AP MLD and the AP MLD, which can reduce latency and improve throughput.

[0005] The descriptions contained in the background section should not be assumed to be prior art simply because they are contained in the background section. The background section may describe aspects or embodiments of the present disclosure. [Overview of the project] [Means for solving the problem]

[0006] One embodiment of the present disclosure provides an access point (AP) multilink 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 at least two APs. The processor is configured to generate traffic indication map (TIM) elements showing 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 that includes a per-link traffic indication for retrieving buffered traffic for at least one non-AP MLD, based on determining whether all of 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 at least one non-AP MLD. The processor is configured to generate a beacon frame that includes the selectively included multi-link traffic indication element and the TIM element. The processor is configured to send beacon frames to multiple non-AP MLDs.

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

[0008] In some embodiments, the processor is configured to generate a multilink traffic indication element if the AP MLD intends to provide a link recommendation for receiving 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 does not intend to provide a link recommendation for obtaining buffered traffic to any associated non-AP MLD, or if the AP MLD does not have buffered traffic with a TID that maps to only a subset of valid links to any associated non-AP MLD.

[0010] In some embodiments, the multilink traffic indication element includes a recommendation field that indicates at least one non-AP MLD that provides a per-link traffic indication for the AP MLD to retrieve buffered traffic. The per-link traffic indication includes a link recommendation or traffic indication.

[0011] In some embodiments, the recommended field includes a set of bits. Each bit begins with the offset number of the traffic indication virtual bitmap within the TIM element and corresponds to one of the respective non-AP MLDs and non-AP stations (STAs). Each bit indicates whether the AP MLD provides per-link traffic indication for the corresponding non-AP MLD or non-AP STA.

[0012] In some embodiments, the recommended field includes a set of bits. Each bit corresponds to one of the associated non-AP MLDs and non-AP STAs, starting with the offset number of the traffic indication virtual bitmap within the TIM element and indicating that it has buffered traffic within the traffic indication virtual bitmap of the TIM element. Each bit indicates 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 indicating whether the recommendation field is present within 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 provides traffic indication or link recommendation for at least one individual non-AP MLD.

[0015] In some embodiments, the multilink traffic indication element is contained within a group-addressed frame and is not associated with a TIM element, and the AP MLD includes a recommended field that indicates at least one non-AP MLD that provides per-link traffic indication for retrieving buffered traffic.

[0016] One 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 at least two STAs. The processor is configured to receive a Traffic Indication Map (TIM) element contained within 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 multiple non-AP MLDs associated with the AP MLD have a default traffic identifier (TID) versus link mapping, and whether the AP MLD has buffered traffic with TIDs mapped to all valid links for the associated non-AP MLD. The processor is configured to determine, if a multilink traffic indication element is present, whether per-link traffic indications for non-AP MLDs exist within the multilink traffic indication element, and the per-link traffic indications provide link recommendations or traffic indications for obtaining buffered traffic for non-AP MLDs. The processor is configured to send a trigger frame to the AP MLD to obtain buffered traffic via the links indicated within the per-link traffic indications, if a multilink traffic indication element is present for non-AP MLDs. The processor is configured to receive buffered traffic from the AP MLD via the links indicated within the per-link traffic indications.

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

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

[0019] In some embodiments, if the AP MLD does not intend to provide link recommendations to any associated non-AP MLD, and the AP MLD does not wait for buffered traffic with TIDs that map to only a subset of valid links to any associated non-AP MLD, 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 that indicates at least one non-AP MLD for which the AP MLD provides per-link traffic indication. The processor is configured to determine, based on the recommendation field, whether per-link traffic indication for the non-AP MLD exists within the multilink traffic indication element.

[0021] In some embodiments, the recommended field includes a set of bits. Each bit starts with the offset number of the traffic indication virtual bitmap within the TIM element and corresponds to one of the individual associated non-AP MLDs and non-AP stations (STAs). Each bit indicates whether the AP MLD provides per-link traffic indication for the corresponding non-AP MLD or non-AP STA.

[0022] In some embodiments, the recommended field includes a set of bits. Each bit begins with the offset number of the traffic indication virtual bitmap within the TIM element and corresponds to one of the associated non-AP MLDs and non-AP STAs that have buffered traffic within the traffic indication virtual bitmap within the TIM element. Each bit indicates whether the AP MLD provides per-link traffic indication for the corresponding non-AP MLD or non-AP STA.

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

[0024] In some embodiments, a multi-traffic indication element includes one or more per-link traffic indication fields. Each field provides a link recommendation or traffic indication for at least one individual non-AP MLD.

[0025] In some embodiments, the multi-link traffic indication element is included within a group address specification frame, not associated with the TIM element, and includes a recommended field indicating at least one non-AP MLD for which the AP MLD provides link-by-link traffic indication.

Brief Description of the Drawings

[0026] [Figure 1] FIG. is a diagram showing an example of a wireless network according to an embodiment. [Figure 2a] FIG. is a diagram showing an example of an AP according to an embodiment. [Figure 2b] FIG. is a diagram showing an example of a STA according to an embodiment. [Figure 3] FIG. is a diagram showing an example of a multi-link communication operation according to an embodiment. [Figure 4] FIG. is a diagram showing an example of a TID-to-link mapping element according to an embodiment. [Figure 5a] FIG. is a diagram showing an example of a multi-link traffic indication element according to an embodiment. [Figure 5b] FIG. is a diagram showing an example of the configuration of a multi-link traffic indication element according to an embodiment. [Figure 6a] FIG. is a diagram showing another example of a multi-link traffic indication element according to an embodiment. [Figure 6b] FIG. is a diagram showing another example of the configuration of a multi-link traffic indication element according to an embodiment. [Figure 6c] FIG. is a diagram showing another example of the configuration of a multi-link traffic indication element according to an embodiment. [Figure 7a] FIG. is a diagram showing another example of a multi-link traffic indication element according to an embodiment. [Figure 7b] FIG. is a diagram showing another example of the configuration of a multi-link traffic indication element when there is a recommended partial virtual bitmap field according to an embodiment. [Figure 7c] This figure shows another example of the configuration of a multilink traffic indication element when a Recommendation partial virtual bitmap field exists according to the embodiment. [Figure 8a] This figure shows another example of a multilink traffic indication element according to an embodiment. [Figure 8b] This figure shows another example of the configuration of a multilink traffic indication element according to the embodiment. [Figure 9] This figure shows another example of the configuration of a multilink traffic indication element according to the embodiment. [Figure 10] This figure shows an example of a process for indicating buffered traffic using a multilink traffic indication element by AP MLD according to an embodiment. [Figure 11] This figure shows another example of a process for indicating buffered traffic using a multilink traffic indication element by AP MLD according to an embodiment. [Figure 12] This figure shows an example of a process for receiving multilink traffic indication elements by a non-AP MLD according to an embodiment. [Modes for carrying out the invention]

[0027] In one or more implementations, not all of the components shown 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 deviating from the scope of the subject disclosure. Within the scope of the subject disclosure, additional components, different components, or fewer components may be used.

[0028] In relation to the accompanying drawings, the detailed description below is intended to describe various implementations and is not intended to represent only the implementations in which the subject art can be practiced. Rather, the detailed description includes specific details for the purpose of providing a complete understanding of the subject matter of the invention. As will be understood by those skilled in the art, all implementations described can be modified in various ways without departing from the scope of this disclosure. Accordingly, the drawings and description should be considered as illustrative and non-limiting in nature. Similar reference numerals indicate similar elements.

[0029] The following description is directed to a specific implementation for the purpose of illustrating the revolutionary aspects of this disclosure. However, those skilled in the art will readily understand that the teachings herein can be applied to a wide variety of methods. The examples in this disclosure are based on WLAN communication according to the IEEE 802.11 standard, including any future modifications of the IEEE 802.11be and IEEE 802.11 standards. However, the embodiments described include the IEEE 802.11 standard, the Bluetooth® standard, the Global System for Mobile communications (GSM), the General Packet Radio Service (GPRS), the 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), and 5G. It can be implemented in any device, system, or network that can transmit and receive radio frequency (RF) signals by other known signals used for communication within wireless, cellular, or Internet of Things (IoT) networks, such as NR (New Radio), AMPS, or 3G, 4G, 5G, 6G, or further implementations thereof, or systems utilizing these technologies.

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

[0031] As shown in Figure 1, the wireless network 100 includes multiple wireless communication devices. Each wireless communication device may include one or more stations (STAs). An STA can be a logical entity that is a single addressable instance of the medium access control (MAC) layer and physical (PHY) layer interfaces to the wireless medium. STAs can be classified into access point (AP) STAs and non-access point (non-AP) STAs. An AP STA may be an entity that provides access to distribution system services via the wireless medium to the associated STA. A non-AP STA may be an STA that is not included within an AP-STA. For simplicity of explanation, AP STAs may be referred to as APs, and non-AP STAs may be referred to as STAs. In the example in Figure 1, AP101 and 103 are wireless communication devices, each potentially containing one or more AP STAs. In such embodiments, AP101 and 103 may be AP multilink devices (MLDs). Similarly, STA111-114 are wireless communication devices, each potentially containing one or more non-AP STAs. In such embodiments, STA111-114 may be non-AP MLDs.

[0032] AP101 and 103 communicate with at least one network 130, such as the Internet, a proprietary Internet Protocol (IP) network, or another data network. AP101 provides wireless access to network 130 to several stations (STAs) 111-114 within AP101's coverage area 120. AP101 and 103 may communicate with and to 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, in this disclosure, the term "AP" is used to refer to a network infrastructure component that provides wireless access to a remote terminal. In a WLAN, APs also compete for wireless channels, so APs are sometimes also called STAs. 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, in this disclosure, the terms "station" and "STA" are used to refer to a remote wireless device that wirelessly accesses an AP or competes for wireless channels within a WLAN, regardless of whether the STA is a mobile device (such as a cell phone or smartphone) or something that is normally considered a fixed device (such as a desktop computer, AP, media player, fixed sensor, or television).

[0034] In Figure 1, the dotted lines indicate the approximate extents of coverage areas 120 and 125 of APs 101 and 103, which are shown as nearly circular for illustrative and explanatory purposes. 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 AP.

[0035] As will be described in more detail below, one or more APs may include circuitry and / or programming for managing MU-MIMO and OFDMA channel sounding within the WLAN. Figure 1 shows an example of a wireless network 100, but various modifications can be made to Figure 1. For example, wireless network 100 can include any number of STAs and any number of APs in any suitable placement. Also, AP 101 can communicate directly with any number of STAs and provide those STAs with wireless broadband access to network 130. Similarly, each AP 101 and 103 can communicate directly with network 130 and provide STAs with wireless broadband access to network 130. Furthermore, AP 101 and / or 103 can provide access to other or additional external networks, such as an external telephone network or other types of data networks.

[0036] Figure 2a shows an example of AP101 according to an embodiment. The embodiment of AP101 shown in Figure 2a is for illustrative purposes only, and AP103 in Figure 1 may have the same or similar configuration. However, there are many different configurations of AP, and Figure 2a does not limit the scope of this disclosure to any particular implementation of AP.

[0037] As shown in Figure 2a, AP101 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. AP101 also includes a controller / processor 224, memory 229, and a backhaul or network interface 234. RF transceivers 209a-209n receive incoming RF signals from antennas 204a-204n, such as signals transmitted by STAs in network 100. 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 a baseband signal processed by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuit 219 sends the processed baseband signal to the controller / processor 224 for further processing.

[0038] The TX processing circuit 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 circuit 214 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate processed baseband or IF signals. The RF transceivers 209a-209n receive the processed baseband or IF signals emanating from the TX processing circuit 214 and upconvert the baseband or IF signals into RF signals transmitted via antennas 204a-204n.

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

[0040] The controller / processor 224 is also coupled to a backhaul or network interface 234. The backhaul or network interface 234 allows the AP101 to communicate with other devices and systems via a backhaul connection or network. Interface 234 can support communication via any suitable (multiple) wired or wireless connections. For example, interface 234 can allow the AP101 to communicate via a wired or wireless local area network, or via a wired or wireless connection to a larger network (such as the Internet). Interface 234 includes any suitable communication that supports communication via a wired or wireless connection, such as Ethernet or RF transceivers. Memory 229 is coupled to the controller / processor 224. Part of memory 229 may include RAM, and another part of memory 229 may include flash memory or other ROM.

[0041] As will be described in more detail below, AP101 may include circuitry and / or programming for managing channel sounding procedures within the WLAN. Figure 2a shows an example of AP101, but various modifications can be made to Figure 2a. For example, AP101 can include any number of each component shown in Figure 2a. In a particular example, the AP may include multiple interfaces 234, and the controller / processor 224 may support routing functionality for routing data between different network addresses. In another example, it is shown to include a single instance of the TX processing circuit 214 and a single instance of the RX processing circuit 219, but AP101 may include multiple instances of each (such as one per RF transceiver). Alternatively, it may include only one antenna and RF transceiver path, like a conventional AP. Also, the various components in Figure 2a can be combined, further subdivided, or omitted, and additional components can be added depending on specific needs.

[0042] As shown in Figure 2a, in some embodiments, AP101 may be an AP MLD containing multiple APs 202a-202n. Each AP 202a-202n is associated with AP MLD101 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 can communicate independently with the controller / processor 224 and other components of AP MLD101. Although Figure 2a shows that each AP 202a-202n has separate multiple antennas, each AP 202a-202n can share multiple antennas 204a-204n without requiring separate multiple antennas. Each AP 202a-202n may represent the physical (PHY) layer and the underlying media access control (MAC) layer.

[0043] Figure 2b shows an example of STA111 according to an embodiment. The embodiment of STA111 shown in Figure 2b is for illustrative purposes only, and STA111-114 in Figure 1 may have the same or similar configurations. However, there are many different configurations of STA, and Figure 2b does not limit the scope of this disclosure to any particular implementation of STA.

[0044] As shown in Figure 2b, the STA111 includes (multiple) antennas 205, an RF transceiver 210, a TX processing circuit 215, a microphone 220, and an RX processing circuit 225. The STA111 also includes a speaker 230, a controller / processor 240, an input / output (I / O) interface (IF) 245, a touchscreen 250, a display 255, and 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 network 100 from (multiple) antennas 205. The RF transceiver 210 downconverts the incoming RF signals to generate IF or baseband signals. The IF or baseband signals are sent to an RX processing circuit 225, which generates a baseband signal that has been processed by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuit 225 transmits the processed baseband signal to a speaker 230 (for example, in the case of voice data) or to a controller / processor 240 for further processing (for example, in the case of web browsing data).

[0046] The TX processing circuit 215 receives analog or digital voice data from the 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 circuit 215 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The RF transceiver 210 receives the processed baseband or IF signal emanating from the TX processing circuit 215 and upconverts the baseband or IF signal to an RF signal transmitted via the (multiple) antennas 205.

[0047] The controller / processor 240 includes one or more processors and can execute a basic OS program 261 stored in memory 260 to control the overall operation of the STA111. 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, RX processing circuit 225, and TX processing circuit 215, according to well-known principles. The controller / processor 240 may also include processing circuits configured to provide management of the WLAN channel sounding procedure. In some embodiments, the controller / processor 240 includes at least one microprocessor or microcontroller.

[0048] The controller / processor 240 can also run other processes and programs residing in memory 260, such as operations for managing WLAN channel sounding procedures. The controller / processor 240 can move data in and out of memory 260 as required by the running processes. In some embodiments, the controller / processor 240 is configured to run multiple applications 262, such as applications for channel sounding, which include feedback calculations 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 can operate multiple applications 262 based on the OS program 261 or in response to signals received from APs. The controller / processor 240 is also coupled to an I / O interface 245 that provides the STA111 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] The controller / processor 240 is also coupled to an input 250 (such as a touchscreen) and a display 255. An operator of the STA111 can input data to the STA111 using the input 250. The 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 the controller / processor 240. Part of memory 260 may include random access memory (RAM), and another part of memory 260 may include flash memory or other read-only memory (ROM).

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

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

[0052] Figure 3 shows an example of multilink communication operation according to an embodiment. Multilink communication operation may be available in any future modifications of the IEEE 802.11be and IEEE 802.11 standards. In Figure 3, AP MLD310 may be wireless communication devices 101 and 103 in Figure 1, and non-AP MLD220 may be one of the wireless communication devices 111 to 114 in Figure 1.

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

[0054] A non-AP MLD320 may include multiple associated STAs, such as STA1, STA2, and STA3. Each associated STA includes a PHY interface to the radio medium (Link 1, Link 2, or Link 3). The non-AP MLD320 includes a single MAC SAP328, through which the associated STAs of the non-AP MLD320 communicate with the higher layer (Layer 3 or Network Layer). Each associated STA of the non-AP MLD320 may have a different MAC address (lower MAC address) than other associated STAs of the non-AP MLD320. The non-AP MLD320 may have an MLD MAC address (higher MAC address), and the associated STAs share a single MAC SAP328 to Layer 3. Therefore, the associated STAs share a single IP address, and Layer 3 recognizes the non-AP MLD320 by assigning a single IP address.

[0055] AP MLD310 and non-AP MLD320 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.4GHz band. Similarly, AP2 and STA2 may set up Link 2 operating in the 5GHz band, and AP3 and STA3 may set up Link 3 operating in the 6GHz band. Each link may independently enable frame exchange and channel access between AP MLD310 and non-AP MLD320, which can improve data throughput and reduce latency.

[0056] To prioritize transmissions of different types of traffic identified by traffic identifiers (TIDs) over the setup links, a non-AP MLD320 may negotiate a TID-to-link mapping with an AP MLD310. The TID-to-link mapping allows the AP MLD310 and non-AP MLD320 to determine how frames belonging to a TID are individually assigned to transmissions on each setup link in the uplink and downlink directions. A link is called a valid link for the non-AP MLD320 if at least one TID associated with the non-AP MLD320 is mapped to a setup link in either the uplink or downlink direction. By default, all TIDs are mapped to all setups between the AP MLD310 and non-AP MLD320; this mapping is called the default TID-to-link mapping. During association, a non-AP MLD320 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 frame or re-association 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. An AP MLD310 can also use a broadcast procedure to indicate a switch to a non-default mapping for all associated non-AP MLDs. In default mapping mode, all TIDs are mapped to all setup links for downlinks and uplinks, and all setup links are enabled. A non-AP MLD320 operates in default mapping mode if TID-to-link mapping negotiation does not occur or fails.

[0057] Figure 4 shows an example of a TID-to-Link Mapping element 400 according to an embodiment. This example in Figure 4 may be applicable to any future modifications of the IEEE 802.11be and IEEE 802.11 standards. The TID-to-Link Mapping element 400 may indicate links to which frames belonging to each TID can be exchanged.

[0058] As shown in Figure 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 TID n fields.

[0059] The element ID field and element ID extension field may contain information for identifying 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 downlink frames, uplink frames, or both. For example, the Direction subfield may be set to 0 for downlink frames, 1 for uplink frames, and 2 for frames transmitted on both 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, its subfield may be set to 1 for a default mapping and 0 for a non-default mapping. The Mapping Switch Time Presence subfield may indicate whether the Mapping Switch Time field exists in the TID vs. Link Mapping element 400. The Expected Duration Presence subfield may indicate whether the Expected Duration field exists in the TID vs. 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 Presence Indicator subfield may indicate whether the link mapping for the TID n field exists in the TID vs. Link Mapping element 400.

[0061] If the TID-to-link mapping element 400 is transmitted by an AP associated with the AP MLD in a beacon or probe response frame and the indicated TID-to-link mapping has not yet been established, then a mapping switching time field exists.

[0062] The expected duration field may indicate the expected duration for which the proposed TID-to-link mapping is valid, if the mapping switch time field is present, and the remaining duration for which 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 for TID n (for example, where n=0,1,...,7) may indicate the link to which frames belonging to TID n are permitted to be transmitted. The link mapping field for TID n may carry a bitmap of the link to which TID n is mapped. If the default link mapping subfield of the TID-to-link mapping control field represents the default TID-to-link mapping, the link mapping field for TID n may not exist. For example, if the direction subfield is set to 0 and the link mapping field for TID 0 is configured as 10000....0, this configuration indicates that the 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 beacon frames, association request / response frames, re-association request / response frames, or probe response frames.

[0065] Several power management solutions are possible to enable non-AP MLDs to conserve power. For example, the STA of a non-AP MLD may be in a dozed state for extended periods when it is expected that no frames will be transmitted or received. During this time, the corresponding AP of the AP MLD may buffer bufferable units (BUs) (buffered BUs or buffered traffic) addressed to the STA of the non-AP MLD. To inform all associated non-AP MLDs of the presence of pending BUs via broadcast or multicast signaling, each AP associated with the AP MLD may periodically include a traffic information map (TIM) element in the beacon frames it transmits, and each AP associated with the AP MLD may optionally transmit separate periodic broadcast TIM frames. In multilink operation, the AP of the AP MLD may include a multilink traffic indication element in the beacon frame to indicate the link from which the buffered BUs (or buffered traffic) may be received. A BU may be a medium access control (MAC) service data unit (MSDU), an aggregated 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 in a power-saving mode. In this disclosure, the terms “buffered traffic” and “buffered BU” are used interchangeably and may have the same meaning.

[0066] Figure 5a shows an example of a multilink traffic indication element according to an embodiment. This example may be applicable to any future modifications of the IEEE 802.11be and IEEE 802.11 standards.

[0067] As shown in Figure 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 element ID extension field may contain information for identifying 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 per-link traffic indication list field. The AID offset subfield may indicate the number k bit 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 contain multiple per-link traffic indication bitmap subfields and padding subfields. The per-link traffic indication bitmap subfield may show per-link traffic indications for a non-AP MLD that has negotiated a TID-to-link mapping with the AP MLD, where not all TIDs are mapped to all valid links. In embodiments, the per-link traffic indication bitmap subfield may show link recommendations for obtaining buffered traffic for a non-AP MLD that has negotiated a TID-to-link mapping with the AP MLD, where all TIDs are mapped to all valid links. In embodiments, the per-link traffic indication bitmap subfield may show link recommendations for obtaining buffered traffic for a non-AP MLD in default mapping mode. The padding subfield may contain padding bits to make the per-link traffic indication list field a multiple of 8 bits.

[0071] Figure 5b shows an example of the configuration of a multilink traffic indication element according to an embodiment.

[0072] Figure 5b illustrates how the traffic indication virtual bitmap and partial virtual bitmap subfields within the TIM element, shown in the top and middle sections, indicate the AID of the associated non-AP MLD and STA. An AP associated with an AP MLD may use the partial virtual bitmap of the TIM element to indicate pending buffered traffic for the STA and non-AP MLD associated with the AP MLD. The partial virtual bitmap within 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 in its beacon frame, partially shown at the bottom of Figure 5b.

[0073] As described, the multilink traffic indication element 500 may include a per-link traffic indication bitmap subfield corresponding to the AID of the STA or non-AP MLD, starting with bit number k of the traffic indication virtual bitmap indicated by the AID offset subfield within 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 subfields within the TIM element. If the non-AP MLD has a non-default TID-to-link mapping with the AP MLD, 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 mapped to that link for the non-AP MLD; otherwise, the bit should be set to 0. If a non-AP MLD is in default mapping mode, and the AP MLD has a buffered BU or MMPDU, and the non-AP MLD can use link i to obtain the buffered BU or MMPDU, then bit position i in the per-link traffic indication bitmap subfield for link ID i may be set to 1. Thus, the AP MLD may provide a link recommendation to the non-AP MLD to use one or more valid links to obtain the buffered traffic (BU or MMPDU).

[0074] In the example in Figure 5b, the first, third, fourth, and sixth AIDs in the partial virtual bitmap subfield within the TIM start with bit number k of the traffic indication virtual bitmap indicated by the AID offset subfield and are set to 1. The per-link traffic indication bitmap subsubfields correspond in ascending order to the first, third, fourth, and sixth AIDs in the partial virtual bitmap subfields. The first per-link traffic indication bitmap subfield may indicate, with AID k, that an AP MLD has pending buffered traffic on link 0. Thus, a non-AP MLD with AID k can use link 0 to retrieve the pending buffered traffic. The remaining per-link traffic indication bitmap subfields indicate the recommended link in a similar manner.

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

[0076] In the embodiment, an AP MLD may not provide a multilink traffic indication element 500 in its beacon frame if all associated non-AP MLDs have buffered BUs and at least one link where all TIDs are mapped to links. Alternatively, an AP MLD may not provide a multilink traffic indication element in its beacon frame if all associated non-AP MLDs have buffered BUs and either have default TID-to-link mappings or all TIDs are mapped to the same subset of links. Therefore, an AP associated with an AP MLD may include a multilink traffic indication element 500 in its beacon frame if at least one associated non-AP MLD successfully negotiates TID-to-link mappings and the AP MLD has buffered BUs with TIDs that are not mapped to any valid links for the non-AP MLD. Thus, non-AP MLDs 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 the AP MLD to indicate to a non-AP MLD in default mapping mode that the AP MLD does not have a link recommendation for the non-AP MLD. In some implementations, there may also be a mechanism for the AP MLD to indicate to a non-AP MLD in non-default mapping mode whether a pending BU can be fetched or acquired from any setup link.

[0078] In the embodiment, if a non-AP MLD negotiates 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 one of the following actions: i) set all bits in the per-link traffic indication bitmap subfield corresponding to the non-AP MLD's AID in the multilink traffic indication element to 0, indicating that all buffered traffic can be fetched from any valid link; or ii) set the 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 to 1, indicating that buffered traffic can 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 all bits in the per-link traffic indication bitmap subfield corresponding to the non-AP MLD's AID in the multilink traffic indication element to 0. If an STA of a non-AP MLD in non-default TID vs. link mapping mode receives a TIM element with the bit corresponding to its AID set to 1, and if all bits in the per-link traffic indication bitmap subfield corresponding to that AID within the multilink traffic indication element can be set to 0, then any STA of a non-AP MLD operating on a valid link may send a PS (Power Save) - Pole frame or a U-APSD (Unscheduled Automated Power Save Delivery) trigger frame (if the STA is using U-APSD and all access categories are enabled for delivery) 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 non-AP MLD's AID, indicating to the non-AP MLD that "most" of the pending BUs can be fetched from any of the valid links. In one embodiment, the AP MLD may, for example, use an "all zeros" indication for the non-AP MLD in the default TID vs. link mapping mode, to indicate that the non-AP MLD has no preferred link to use for fetching the buffered BUs.

[0080] In some implementations, bits unnecessarily reserved to indicate the recommended link can be wasteful and undesirable. This can lead to the multilink traffic indication element 500 becoming excessively large, reducing efficiency and making it difficult to fit those bits within the beacon frame. Therefore, there is a need for a mechanism to efficiently indicate the recommended link for AP MLDs to fetch buffered traffic only to non-AP MLDs that have link recommendations.

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

[0082] As shown in Figure 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, a 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 reserved subfield.

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

[0084] Referring to Figures 6a and 6b, the AID offset subfield within 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 TIM element's partial virtual bitmap subfield, starting with AID k indicated in the AID offset subfield. The 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 acquire the pending BU. Otherwise, the bit for the AID may be set to 0. The bit may always be set to 0 for non-AP MLDs 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 within the TIM element, as shown in Figure 6b. In one embodiment, zero padding may be used to make the field length a multiple of 8 bits. In one embodiment, the multilink traffic indication element 600 may have an additional recommended partial virtual bitmap length field to indicate the length of the recommended partial virtual bitmap field in octets.

[0086] The per-link traffic indication list field within 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 begin with bit number k of the traffic indication virtual bitmap, as shown in Figure 6b, corresponding to the AIDs of non-AP MLDs and STAs, and may 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, starting with AID k, corresponding to the AIDs of non-AP MLDs and STAs, and may be set to 1.

[0087] In the example in Figure 6b, there are four bits set to 1 corresponding to the four AIDs (i.e., AID k, AID k+2, AID k+3, and AID k+5) in the partial virtual bitmap subfield within 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 recommendation 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 the two per-link traffic indication bitmap subfields corresponding to AID k and AID k+5, which are set to 1 in the recommendation partial virtual bitmap. The first per-link traffic indication bitmap subfield indicates link 0 as the recommended link for non-AP MLDs with AID k, and the second per-link traffic indication bitmap subfield indicates link 1 as the recommended link for non-AP MLDs with AID k+5 by setting the bit corresponding to the recommended link to 1 and the other bits to 0.

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

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

[0090] The length of the recommended partial virtual bitmap field may be equal to the number of bits (excluding zero padding) that start with bit number k of the partial virtual bitmap subfield of the TIM element, are set to 1, and correspond to the AID of a non-AP MLD or STA. The order of the bits in the recommended partial virtual bitmap field may follow the order of the AID bits of a non-AP MLD or STA that are set to 1 in the partial virtual bitmap of the TIM element. In Figure 6c, if AID k+3 is the third bit (counting from AID k) that is set to 1 in the partial virtual bitmap of the TIM element, 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 can be inferred from the number of bits that start with AID k and are set to 1 in the partial virtual bitmap of the TIM element. In embodiments, zero padding may be used to make the length of this field a multiple of 8 bits. In the embodiment, the multilink traffic indication element 600 may have an additional recommended partial virtual bitmap field to indicate the length of the recommended partial virtual bitmap field in octets. In Figure 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, since only 4 bits corresponding to 4 of the 6 AIDs (i.e., AID k, AID k+2, AID k+3, AID k+5) are set to 1, counting from AID k. As a result, the length of the recommended partial virtual bitmap field can be reduced by 2 bits compared to the embodiment in Figure 6b.

[0091] The per-link traffic indication list field within the multilink traffic indication element 600 may contain 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 subfields begin with bit number k of the traffic indication virtual bitmap, set to 1, and correspond to the AIDs of STA and non-AP MLDs, as shown in Figure 6c. The per-link traffic indication list field contains 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 STA and non-AP MLDs.

[0092] In the example in Figure 6c, there are four bits set to 1 corresponding to the four AIDs (i.e., AID k, AID k+2, AID k+3, and AID k+5) in the partial virtual bitmap subfield within the TIM element. However, since 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, only two bits corresponding to the two AIDs (i.e., AID k and AID k+5) are set to 1 in the recommendations partial virtual bitmap. As a result, the per-link traffic indication list field contains only the two per-link traffic indication bitmap subfields corresponding to AID k and AID k+5, which are set to 1 in the recommendations partial virtual bitmap. The first per-link traffic indication bitmap subfield indicates link 0 as the recommended link for non-AP MLDs with AID k, and the second per-link traffic indication bitmap subfield indicates link 1 as the recommended link for non-AP MLDs with AID k+5 by setting the bit corresponding to the recommended link to 1 and the other bits to 0.

[0093] Figure 7a shows another example of a multilink traffic indication element 7000 according to an embodiment. This example may be usable in any future modifications of the IEEE 802.11be and IEEE 802.11 standards.

[0094] As shown in Figure 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 presence subfield.

[0095] In some respects, various fields or subfields within the multilink traffic indication element 700 may be the same as or similar to the corresponding fields or subfields within the multilink traffic indication element 600 in Figure 6a, and examples of differences are described below. For example, the multilink traffic indication element 700 may include an additional subfield within the multilink traffic indication control field called the Recommended Bitmap Existence subfield. The Recommended Bitmap Existence subfield indicates whether an optional Recommended Partial Virtual Bitmap field exists. The Recommended Bitmap Existence subfield is set to 1 if the Recommended Partial Virtual Bitmap field exists. Otherwise, the Recommended Bitmap Existence subfield is set to 0.

[0096] Figure 7b shows another example of the configuration of a multilink traffic indication element when a recommended partial virtual bitmap field exists according to the embodiment. In Figure 7b, the recommended bitmap presence subfield (B15) in the multilink traffic indication control field is set to 1, indicating the presence of an 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 that in Figure 6c. The per-link traffic indication list field may contain 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 700 that are set to 1 and correspond to the AIDs of the STA and non-AP MLDs.

[0097] Figure 7c shows another example of the configuration of a multilink traffic indication element when the recommended partial virtual bitmap field according to the embodiment is not present. In Figure 7c, the recommended bitmap presence 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 recommended link indications and AIDs in the per-link traffic indication list field is the same as or similar to that in Figure 5b. The per-link traffic indication list field contains l per-link traffic indication bitmap subfields, where l is the number of bits corresponding to the AIDs of STA and non-AP MLDs, starting with AID k in the partial virtual bitmap subfield of the TIM element contained in the beacon frame with the multilink traffic indication element, and set to 1.

[0098] AP MLD may determine whether to include a recommendation partial virtual bitmap field based, for example, on the number of AIDs that have link recommendations for fetching pending traffic and the number of AIDs that have pending traffic.

[0099] If a preferred partial virtual bitmap field exists, and a non-AP MLD receives a TIM element with its AID whose partial virtual bitmap is set to 1 and a multilink traffic indication element 700 with its AID whose preferred partial virtual bitmap is set to 0, the non-AP MLD may not decode the rest of the multilink traffic indication element. In embodiments, the non-AP MLD may use any valid link to fetch a pending BU in the AP MLD. In one embodiment, the non-AP MLD may use any valid link with all TIDs mapped to the non-AP MLD to fetch a pending BU in the AP MLD.

[0100] In the embodiment, if a recommended partial virtual bitmap field exists 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 does not exist, the non-AP MLD may parse a link-by-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 different from the multilink traffic indication element 700. For example, it may be carried in a TIM element or an EHT action frame.

[0102] Figure 8a shows another example of a multilink traffic indication element 800 according to an embodiment. This example may be usable in any future modifications of the IEEE 802.11be and 802.11 standards.

[0103] As shown in Figure 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 per-link traffic indication list 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 respects, various fields or subfields within the multilink traffic indication element 800 may be the same as or similar to the corresponding fields or subfields within the multilink traffic indication element 700 in Figure 7a, and examples of differences are described below. For example, the multilink traffic indication element 800 may include an optional incremental AID list field instead of the optional recommended partial virtual bitmap field in the multilink traffic indication element 700 in Figure 7a. Furthermore, the multilink traffic indication element 800 may include a traffic list format subfield within the multilink traffic indication control field instead of the recommended bitmap presence subfield. The traffic list format subfield may indicate whether the incremental AID list field exists. The traffic list format subfield may be set to 1 if the incremental AID list field exists. Otherwise, the traffic list format subfield may be set to 0.

[0105] If the traffic list format subfield is set to 0, the incremental AID list field may not exist, and the per-link traffic indication list field may contain l per-link traffic indication bitmap subfields, where l is the number of bits in the partial virtual bitmap subfield of the TIM element that are set to 1 and correspond to the AIDs of STA and non-AP MLDs. The recommended order of indications and AIDs for links in the per-link traffic indication list field may be the same as or similar to that in Figure 5b.

[0106] If the traffic list format subfield is set to 1, the incremental AID list field may exist, and the incremental AID list field may contain a list of AIDs that provide link recommendations for the AP MLD to fetch pending BUs. In this embodiment, only the incremental value with respect to k is shown instead of the actual AID value. The size of each bit of the incremental AID value is:

number

[0107] Figure 8b shows another example of the configuration of a multilink traffic indication element according to the 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 if the corresponding bits in the partial virtual bitmap subfield are set to 1, there are no corresponding incremental values ​​for AID k+2 and AID k+3, so there are no link recommendations for AID k+2 and AID k+3 in the per-link traffic indication list field. Therefore, since the incremental AID list field has two bits corresponding to AID k and AID k+5, the per-link traffic indication list field contains two per-link traffic indication bitmap subfields.

[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 of bits is,

number

[0110] In the embodiment, the length of each of these incremental AID values ​​in the incremental AID list format subfield may be indicated in a separate and optional incremental AID length field or subfield of the multilink traffic indication element.

[0111] If a non-AP MLD receives a multilink traffic indication element 800 in which a TIM element has a partial virtual bitmap for its AID set to 1 and an incremental AID list field does not contain its corresponding incremental value (with respect to k), the non-AP MLD may not decode the rest of the multilink traffic indication element 800. In this case, the non-AP MLD may use any of its valid links to fetch the pending BU in the AP MLD. In one embodiment, the non-AP MLD may use any of its valid links that have all TIDs mapped to valid links to fetch the buffered BU pending in the AP MLD.

[0112] In the embodiment, if the non-AP MLD receives a multilink traffic indication element 800 in which the incremental AID list field contains its corresponding incremental 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 a link recommendation for the non-AP MLD.

[0113] In one embodiment, the incremental AID list field may be carried in an information element or frame different from the multilink traffic indication element 800. For example, they may be carried in a TIM element or an EHT action frame.

[0114] Figure 9 shows another example of the configuration of a multilink traffic indication element according to the embodiment.

[0115] Multilink traffic indication elements can also be transmitted in individually addressed or group addressed frames 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 in Figure 6, except for the AID offset subfield indicating the number n as shown in Figure 9. The recommendation partial virtual bitmap field may have bits for all AIDs, starting with AID f(n), where f(n) can be several functions of n, e.g., 2n, 8n, or 16n. The bits for a particular AID in the recommendation partial virtual bitmap field may be set to 1 only if the AP MLD intends to provide a link recommendation for a non-AP MLD with that AID to fetch buffered pending traffic. Otherwise, the bits for the AID may be set to 0. In embodiments, zero padding may be used to make the length of this field a multiple of 8 bits.

[0117] In the embodiment, the long-term multilink traffic indication element may have an additional 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 by 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 by the TIM element. Therefore, 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] A newly received long-range multilink traffic indication element may replace the indication by a previous long-range multilink traffic indication element for a non-AP MLD. If a link recommendation for a non-AP MLD is included in the new long-range multilink traffic indication element and the bits for all links are set to 1, this may indicate that the previous long-range multilink traffic indication element is being discarded or deactivated for the non-AP MLD. In embodiments, an AP MLD may not provide a multilink traffic indication element in the beacon frame along with the TIM element if the link recommendation in the long-range multilink traffic indication element is sufficient and effective to obtain buffered traffic for all associated non-AP MLDs that have buffered BUs.

[0120] Figure 10 shows an example of process 1000 to illustrate 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 to a non-AP MLD with AID x. Process 1000 proceeds to operation 1003 if the AP MLD has pending buffered traffic to a non-AP MLD with AID x. In an embodiment, this process 1000 operates if the non-AP MLD associated with the AP MLD has negotiated a non-default TID-to-link mapping, but the pending buffered traffic in the AP MLD is mapped to all active links.

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

[0123] In operation 1005, the AP MLD determines whether all buffered traffic can be fetched from any valid link by a non-AP MLD with AID x. If all buffered traffic can be fetched from any valid link by a non-AP MLD with AID x, process 1000 proceeds to operation 1007; otherwise, it 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 can be fetched from any valid link of the non-AP MLD having 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 link i of the non-AP MLD 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 can be fetched from link i.

[0126] Figure 11 shows another example of process 1100 for illustrating buffered traffic using a multilink traffic indication element by AP MLD according to an embodiment.

[0127] In operation 1101, the AP MLD determines whether it 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, process 1100 proceeds to operation 1103.

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

[0129] In operation 1105, the AP MLD determines whether the multilink traffic indication element includes optional fields. In embodiments, the optional fields may be a recommended partial virtual bitmap field, a recommended partial virtual bitmap length field, a recommended bitmap presence subfield, an incremental AID list field, or a traffic list format subfield, as described with reference to Figures 6a-9. If the AP MLD includes optional fields in the multilink traffic indication element, process 1100 proceeds to operation 1107; otherwise, it 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. Process 1100 proceeds to operation 1109 if the AP MLD has a link recommendation for a non-AP MLD with AID x; otherwise, it proceeds to operation 1111.

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

[0132] In operation 1111, AP MLDs include optional fields in the multilink traffic indication element. For example, optional fields may include a preferred partial virtual bitmap field, a preferred partial virtual bitmap length field, a preferred bitmap presence subfield, an incremental AID list field, or a traffic list format subfield. However, AP MLDs do not include the non-AP MLD AID x in the per-link traffic indication list field within the multilink traffic indication element.

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

[0134] Figure 12 shows an example of process 1200 for receiving multilink traffic indication elements by a non-AP MLD according to an embodiment.

[0135] In operation 1201, the non-AP MLD detects that it has received 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 the beacon frame, process 1200 proceeds to operation 1203. Otherwise, it proceeds to operation 1211 and returns to the Dose state.

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

[0137] In operation 1205, the non-AP MLD determines whether there is a per-link traffic indication for the non-AP MLD's AID. The per-link traffic indication may reside in the per-link traffic indication bitmap subfield within the 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, a recommended partial virtual bitmap field, a recommended partial virtual bitmap length field, a recommended bitmap presence subfield, an incremental AID list field, or a traffic list format subfield. The recommended partial virtual bitmap field and the incremental AID list field indicate the presence of recommended links to the non-AP MLD. Thus, the non-AP MLD can determine, based on the incremental AID list field and the recommended partial virtual bitmap field, whether there is a per-link traffic indication for the non-AP MLD's AID in the per-link traffic indication bitmap subfield. If a per-link traffic indication for the non-AP MLD's AID exists, process 1200 proceeds to operation 1207. Otherwise, proceed to operation 1209.

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

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

[0140] References to singular elements are intended to mean one or more, not just one or a single element, unless otherwise specified. For example, the module "a" can refer to one or more modules. Elements beginning with "a," "an," "the," or "said" do not preclude the existence of additional identical elements unless further constraints are imposed.

[0141] Where headings and subheadings exist, they are used for convenience only and do not limit the invention. The word "exemplary" is used in the sense that it serves as an example or explanation. Wherever terms such as "include" and "have" are used, such terms are intended to be comprehensive in the same way that the term "comprise" is interpreted when used as a transitional term in a claim. Relational 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 embodiments,” “configuration,” “the configuration,” “another configuration,” “some configurations,” “one or more configurations,” “the subject technology,” “the disclosure,” “the present closure,” and “other variations thereof,” and similar phrases, are for convenience only and do not imply that disclosures related to such phrases are essential to the subject technology or that such disclosures apply to all configurations of the subject technology. Disclosures relating to such (multiple) phrases may apply to all or one or more of the components. Disclosures relating to such (multiple) phrases may provide one or more examples. Phrases such as "an aspect" or "some aspects" may indicate one or more aspects, and vice versa, and this also applies to the phrases above.

[0143] The phrase “at least one” preceding a series of items, along with the terms “and” or “or” used to separate any items, modifies the list as a whole, rather than each individual member of the list. The phrase “at least one” does not require a selection of at least one item; rather, it allows the meaning to include at least one of any one of the items, and / or at least one of any combination of items, and / or at least one of each of the items. For example, the phrases “at least one of A, B, and C” or “at least one of A, B, or C” indicate 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] The specific order or hierarchy of steps, actions, or processes described is to be understood as an example of an exemplary approach. Unless otherwise explicitly stated, the specific order or hierarchy of steps, actions, or processes may be executed in different orders. Some steps, actions, or processes may be executed concurrently or as part of one or more other steps, actions, or processes. The attached method claims present, in some cases, elements of various steps, actions, or processes in a sample order and are not intended to be limited to the specific order or hierarchy presented. These may be executed in series, linearly, in parallel, or in different orders. The instructions, actions, and systems described may typically be integrated into a single software / hardware product or packaged into multiple software / hardware products.

[0145] This disclosure is provided to enable those skilled in the art to practice the various aspects described herein. In some examples, well-known structures and components are shown in block diagram form so as not to obscure the concepts of the subject art. The disclosure provides various examples of the subject art, and the subject art 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 also be applicable to other aspects.

[0146] All elements of the various aspects described throughout this disclosure that are known to those skilled in the art or that will become known thereafter are structurally and functionally equivalent to them are expressly incorporated by reference and intended to be included in the claims. Furthermore, nothing disclosed herein is intended to be made public, whether such disclosure is expressly included in the claims or not. No element of a claim shall be construed under the provisions of 35 U.S.C. § 112, paragraph 6, unless that element is expressly described using the phrase “means for” or, in the case of a method claim, the element is described using the phrase “step for”.

[0147] The title, background, brief description of the drawings, abstract, and drawings are incorporated into this disclosure and provided as exemplary examples of this disclosure, and not as limiting descriptions. They are submitted with the understanding that they are not to be used to limit the scope or meaning of the claims. Furthermore, in the detailed description, it can be understood that for the purpose of providing exemplary examples and simplifying this disclosure, various features are grouped together in various implementations. This method of disclosure should not be interpreted as reflecting an intention that the claimed subject matter requires more features than expressly stated in each claim. Rather, as reflected in the following claims, the subject matter of the invention lies in fewer features than all features of a single disclosed configuration or operation. The following claims are incorporated independently into the detailed description, each claim being a separately claimed subject matter.

[0148] The claims are not intended to be limited to the aspects described herein, but are given the full scope consistent with the literal language of the claims and encompass all legal equivalents. Nevertheless, no claim is intended, nor should it be construed, to encompass subject matter that does not meet the requirements of applicable patent law.

Claims

1. An access point (AP) multilink device (MLD) associated with wireless communication, At least two APs associated with the aforementioned AP MLD, A processor coupled to at least two APs, A memory that stores instructions executed by the aforementioned processor, Includes, The processor executes the instruction, A traffic indication map (TIM) element is generated that shows pending buffered traffic for multiple non-AP MLDs associated with the aforementioned AP MLD. A beacon frame containing the aforementioned TIM element is generated, A multilink traffic indication element is selectively generated, which includes a per-link traffic indication for obtaining buffered traffic to at least one of the multiple non-AP MLDs. It is configured to transmit the beacon frame to any of the associated non-AP MLDs, The multilink traffic indication element is not intended to provide a link recommendation for the AP MLD to retrieve buffered traffic to any of the associated non-AP MLDs, and the AP MLD does not have buffered traffic with a traffic identifier (TID) that maps to only a subset of valid links to any of the associated non-AP MLDs, and is not present in the beacon frame. AP MLD.

2. The multilink traffic indication element is not present in the beacon frame because the AP MLD is configured to refrain from generating the multilink traffic indication element under predetermined conditions. The AP MLD according to claim 1.

3. The processor is configured such that, by executing the instruction, at least one of the associated non-AP MLDs successfully negotiates a TID-to-link mapping with the AP MLD, and the AP MLD has buffered traffic with TIDs that are not mapped to any valid links to the at least one non-AP MLD, the AP MLD generates the multilink traffic indication element. AP MLD according to claim 1 or 2.

4. 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 by executing the instruction. AP MLD according to claim 1 or 2.

5. The multilink traffic indication element includes a recommendation field indicating the at least one non-AP MLD that provides the per-link traffic indication for obtaining buffered traffic, and the per-link traffic indication includes a link recommendation or traffic indication. The AP MLD according to claim 4.

6. The aforementioned recommended field includes a set of bits, each bit starting from the offset number of the traffic indication virtual bitmap within the TIM element and corresponding to one of the associated non-AP MLDs and non-AP stations (STAs). Each of the aforementioned bits indicates whether the AP MLD provides the per-link traffic indication for the corresponding non-AP MLD or non-AP STA. The AP MLD according to claim 5.

7. The aforementioned recommended field includes a set of bits, each bit starting from the offset number of the traffic indication virtual bitmap within the TIM element and corresponding to one of the associated multiple non-AP MLDs and non-AP STAs, which are indicated to have buffered traffic in the traffic indication virtual bitmap within the TIM element. Each of the aforementioned bits indicates whether the AP MLD provides the per-link traffic indication to the corresponding non-AP MLD or non-AP STA. The AP MLD according to claim 5.

8. The multilink traffic indication element optionally includes the recommendation field, and includes a recommendation presence field indicating whether the recommendation field is present within the multilink traffic indication element. The AP MLD according to claim 5.

9. An access point (AP) multilink device (MLD) associated with wireless communication, At least two APs associated with the aforementioned AP MLD, A processor coupled to at least two APs, A memory that stores instructions executed by the aforementioned processor, Includes, The processor executes the instruction, A traffic indication map (TIM) element is generated that shows pending buffered traffic for multiple non-AP MLDs associated with the aforementioned AP MLD. A beacon frame containing the aforementioned TIM element is generated, A multilink traffic indication element is selectively generated, which includes a per-link traffic indication for obtaining buffered traffic to at least one of the multiple non-AP MLDs. It is configured to transmit the beacon frame to any of the associated non-AP MLDs, The multilink traffic indication element is not present in the beacon frame if the AP MLD has pending buffered traffic and all of the associated non-AP MLDs have a default TID-to-link mapping, and if the AP MLD does not intend to provide a link recommendation for any of the associated non-AP MLDs to retrieve the buffered traffic. AP MLD.

10. The multilink traffic indication element is not present in the beacon frame because the AP MLD is configured to refrain from generating the multilink traffic indication element under predetermined conditions. The AP MLD according to claim 9.

11. The processor is configured such that, by executing the instruction, at least one of the associated non-AP MLDs successfully negotiates a TID-to-link mapping with the AP MLD, and the AP MLD has buffered traffic with TIDs that are not mapped to any valid links to the at least one non-AP MLD, the AP MLD generates the multilink traffic indication element. AP MLD according to claim 9 or 10.

12. 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 by executing the instruction. AP MLD according to claim 9 or 10.

13. The multilink traffic indication element includes a recommendation field indicating the at least one non-AP MLD that provides the per-link traffic indication for obtaining buffered traffic, and the per-link traffic indication includes a link recommendation or traffic indication. The AP MLD according to claim 12.

14. The aforementioned recommended field includes a set of bits, each bit starting from the offset number of the traffic indication virtual bitmap within the TIM element and corresponding to one of the associated non-AP MLDs and non-AP stations (STAs). Each of the aforementioned bits indicates whether the AP MLD provides the per-link traffic indication for the corresponding non-AP MLD or non-AP STA. AP MLD according to claim 13.

15. The multilink traffic indication element optionally includes the recommendation field, and includes a recommendation presence field indicating whether the recommendation field is present within the multilink traffic indication element. AP MLD according to claim 13.

Images