Multi-link traffic indication for buffered traffic

Abstract

A wireless communication network includes an access point (AP) multilink device (MLD) and a non-AP MLD. The AP of the AP MLD indicates to the STA of the non-AP MLD participating in the active frame exchange whether there is a buffer traffic to be processed for the non-AP MLD on another link, whether the AP MLD intends to recommend that the non-AP MLD uses another link to obtain the buffer traffic, and / or whether there is a critical update to the BSS on another link.

Description

Technical Field

[0001] The present disclosure relates generally to wireless communication systems, and more particularly to multi-link traffic indication for multi-link devices in wireless communication systems, for example but not limited to. Background Art

[0002] Since the late 1990s, wireless local area network (WLAN) technology has evolved toward increased data rates and continues its growth in various markets such as home, enterprise, and hotspots. WLAN allows devices to access the Internet in the 2.4GHz, 5GHz, 6GHz, or 60GHz frequency bands. WLAN is based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards. The IEEE 802.11 family of standards is designed to increase speed and reliability and extend the operating 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 driverless vehicles. In order to achieve the extremely low latency and extremely high throughput required for such applications, multi-link operation (MLO) has been proposed for WLAN. A WLAN is formed by WLAN devices in a limited area such as a home, school, apartment, or office building. Each WLAN device may have one or more stations (STAs), such as an access point (AP) STA and a non-access point (non-AP) STA.

[0004] MLO can enable a non-AP multi-link device (MLD) to establish multiple links with an AP MLD. Each of the multiple links can independently implement channel access and frame exchange between the non-AP MLD and the AP MLD, which can reduce latency and increase throughput.

[0005] The descriptions set forth in the Background section should not be assumed to qualify as prior art merely because they are set forth in the Background section.The Background section may describe aspects or embodiments of the present disclosure. Summary of the invention

[0006] One embodiment of the present disclosure provides an access point (AP) multi-link device (MLD) associated with a wireless network. The AP MLD includes a first AP and one or more second APs attached to the AP MLD and a processor coupled to the first AP and the one or more second APs. The processor is configured to perform individually addressed frame exchange between a first station (STA) attached to a non-AP MLD and a first AP attached to the AP MLD via a first link. The first STA and one or more second STAs are attached to the non-AP MLD. The processor is configured to send a downlink frame to the first STA attached to the non-AP MLD via the first link, the downlink frame including an indication of the presence of buffered services to the non-AP MLD on one or more second links, or a link recommendation for retrieving buffered services for one or more second links. Each of the one or more second links is established between a second AP attached to the AP MLD and a corresponding second STA attached to the non-AP MLD. The processor is configured to receive a frame for requesting transmission of buffered services via the second link from a second STA attached to the non-AP MLD via the second link. The processor is configured to send buffered services to the second STA attached to the non-AP MLD via the second link in response to the frame.

[0007] In some embodiments, a traffic identifier (TID) of the buffered traffic is not mapped to the first link, and the TID of the buffered traffic is mapped to one or more second links.

[0008] In some embodiments, when transmitting the downlink frame, one or more second STAs attached to the non-AP MLD are in a doze state.

[0009] In some embodiments, an indication of the presence of buffered traffic or a link recommendation for one or more second links is included in a control field of a downlink frame.

[0010] In some embodiments, the control field includes a bitmap for identifying one or more second STAs, and a field for identifying the purpose of the bitmap.

[0011] In some embodiments, an indication of the presence of buffered traffic or a link recommendation for one or more second links is included in a buffer status report within a control field of a downlink frame.

[0012] In some embodiments, the processor is further configured to receive, via the first link, from a first STA affiliated with the non-AP MLD, a request to send a downlink frame including a buffer status report.

[0013] In some embodiments, the downlink frame further includes information about updates of a basic service set (BSS) to which the AP MLD belongs. The information about updates indicates that the non-AP MLD is required to check for updates on at least one link between the AP MLD and the non-AP MLD.

[0014] In some embodiments, the downlink frame further includes information indicating that there is no buffered traffic to the non-APMLD on the one or more second links or information indicating that it is recommended that the one or more second STAs do not transition to the awake state.

[0015] In some embodiments, when the AP MLD receives an indication of support for receiving an indication of the presence of buffered traffic or a link recommendation from the non-AP MLD, the indication of the presence of buffered traffic or a link recommendation for one or more second links is included in a downlink frame.

[0016] One embodiment of the present disclosure may provide a non-access point (AP) multi-link device (MLD) associated with a wireless network. The non-AP MLD includes a first STA and one or more second STAs attached to the non-AP MLD and a processor coupled to the first STA and the one or more second STAs. The processor is configured to perform individually addressed frame exchange between a first AP attached to the AP MLD and a first STA attached to the non-AP MLD via a first link. The first AP and one or more second APs are attached to the AP MLD. The processor is configured to receive a downlink frame from a first AP attached to the AP MLD via the first link, the downlink frame including an indication of the presence of buffered services to the non-AP MLD on one or more second links, or a link recommendation for retrieving buffered services for one or more second links. Each of the one or more second links is established between a second AP attached to the AP MLD and a corresponding second STA attached to the non-AP MLD. The processor is configured to send a frame requesting transmission of buffered services via the second link to a second AP attached to the AP MLD via the second link. The processor is configured to receive buffered services from a second AP attached to the AP MLD via the second link.

[0017] In some embodiments, a traffic identifier (TID) of the buffered traffic is not mapped to the first link, and the TID of the buffered traffic is mapped to one or more second links.

[0018] In some embodiments, when sending downlink frames, one or more second STAs attached to the non-AP MLD are in a doze state, and the processor is further configured to coordinate the second STAs to wake up and transition from the doze state to an awake state or an active state in response to receiving the downlink frame.

[0019] In some embodiments, an indication of the presence of buffered traffic or a link recommendation for one or more second links is included in a control field of a downlink frame.

[0020] In some embodiments, the control field includes a bitmap for identifying one or more second STAs, and a field for identifying the purpose of the bitmap.

[0021] In some embodiments, an indication of the presence of buffered traffic or a link recommendation for one or more second links is included in a buffer status report within a control field of a downlink frame.

[0022] In some embodiments, the processor is further configured to send, via the first link, a request to send a downlink frame including a buffer status report to a first AP affiliated with the AP MLD.

[0023] In some embodiments, the downlink frame further includes information about updates of a basic service set (BSS) to which the AP MLD belongs. The information about updates indicates that the non-AP MLD is required to check for updates at least on a link between the AP MLD and the non-AP MLD.

[0024] In some embodiments, the downlink frame further includes information indicating that there is no buffered traffic to the non-APMLD on the one or more second links or information indicating that the recommended one or more second links do not transition to the awake state.

[0025] In some embodiments, when the non-AP MLD sends an indication of supporting reception of an indication of the presence of buffered traffic or a link recommendation, the indication of the presence of buffered traffic or the link recommendation for one or more second links is included in a downlink frame. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 An example of a wireless network according to an embodiment is shown.

[0027] Figure 2a An example of an AP according to an embodiment is shown.

[0028] Figure 2b An example of a STA according to an embodiment is shown.

[0029] Figure 3 An example of a multi-link communication operation according to an embodiment is shown.

[0030] Figure 4 An example of a TID-to-link mapping element according to an embodiment is shown.

[0031] Figure 5a An example of a multi-link traffic indication element according to an embodiment is shown.

[0032] Figure 5b An example of construction of a multi-link traffic indication element according to an embodiment is shown.

[0033] Figures 6a to 6e Other examples of multi-link operations according to embodiments are shown.

[0034] Figure 7a An example of a new information element for indicating pending buffered traffic for non-AP MLD according to an embodiment is shown.

[0035] Figure 7b Another example of a new information element for indicating pending buffered traffic for non-AP MLD according to an embodiment is shown.

[0036] Figure 8 Another example of the A control subfield for indicating pending buffered traffic for non-AP MLD according to an embodiment is shown.

[0037] Figure 9a and 9b An example of a multilink device capabilities and operations subfield 900 of a basic multilink element is shown according to an embodiment.

[0038] Fig.10 An example of an MLTI control subfield according to an embodiment is shown.

[0039] Fig.11a An example of a Link Indication A Control subfield according to an embodiment is shown.

[0040] Fig.11b An example of a subtype subfield and a control information subfield in a link indication A control subfield according to an embodiment is shown.

[0041] Fig.12 Another example of the MLTI Control subfield according to an embodiment is shown.

[0042] Figures 13a to 13c Other examples of the MLTI control subfield according to embodiments are shown.

[0043] Fig.14 Another example of the MLTI Control subfield according to an embodiment is shown.

[0044] Fig.15 An example of a process for indicating buffered traffic in a separately addressed frame by an AP MLD according to an embodiment is shown.

[0045] Fig.16 An example of a process for receiving an indication of buffered traffic in an individually addressed frame by a non-AP MLD according to an embodiment is shown.

[0046] In one or more embodiments, all of the components depicted in each figure may not be required, and one or more embodiments may include additional components not shown in the figures. The arrangement and type of components may be varied without departing from the scope of the present disclosure. Additional components, different components, or fewer components may be utilized within the scope of the present disclosure. DETAILED DESCRIPTION

[0047] The detailed description set forth below in conjunction with the drawings is intended to be a description of various embodiments, and is not intended to represent the only embodiment in which the subject technology can be practiced. On the contrary, the detailed description includes specific details for providing a thorough understanding of the subject of the present invention. As will be appreciated by those skilled in the art, the described embodiments may be modified in various ways, all without departing from the scope of the present disclosure. Therefore, the drawings and descriptions are considered to be illustrative and non-restrictive in nature. The same reference numerals represent the same elements.

[0048] For the purpose of describing the innovative aspects of the present invention, the following description is directed to certain embodiments. However, one of ordinary skill in the art will readily recognize that the teachings herein can be applied in a variety of different ways. The examples in this disclosure are based on WLAN communications according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, including the IEEE 802.11be standard and any future revisions of the IEEE 802.11 standard. However, the described embodiments may be implemented in any device, system, or network capable of sending and receiving radio frequency (RF) signals in accordance with 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 NR (New Radio), AMPS, or other known signals for communicating within a wireless, cellular or Internet of Things (IoT) network (such as a system utilizing 3G, 4G, 5G, 6G or further implementations thereof) technology.

[0049] Figure 1 An example of a wireless network 100 according to an embodiment is shown. Figure 1The embodiment of the wireless network 100 shown in FIG. 1 is for illustration purposes only. Other embodiments of the wireless network 100 may be used without departing from the scope of the present disclosure.

[0050] like Figure 1 As shown, the wireless network 100 may include multiple wireless communication devices. Each wireless communication device may include one or more stations (STAs). A STA may be a logical entity that is a single addressable instance of a media access control (MAC) layer and a physical (PHY) layer interface to a wireless medium. A STA may be classified into an access point (AP) STA and a non-access point (non-AP) STA. An AP STA may be an entity that provides access to distribution system services to associated STAs via a wireless medium. A non-AP STA may be a STA that is not included in an AP-STA. To simplify the description, an AP STA may be referred to as an AP, and a non-AP STA may be referred to as a STA. In Figure 1 In the example of , APs 101 and 103 are wireless communication devices, each of which may include one or more AP STAs. In such an embodiment, APs 101 and 103 may be AP multi-link devices (MLDs). Similarly, STAs 111-114 are wireless communication devices, each of which may include one or more non-AP STAs. In such an embodiment, STAs 111-114 may be non-AP MLDs.

[0051] 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. AP 101 provides wireless access to network 130 for multiple stations 111-114 in a coverage area 120 of AP 101. APs 101 and 103 may communicate with each other and with STAs using Wi-Fi or other WLAN communication technologies.

[0052] Depending on the network type, other well-known terms may be used instead of "access point" or "AP", such as "router" or "gateway". For convenience, the term "AP" is used in this disclosure to refer to a network infrastructure component that provides wireless access to a remote terminal. In a WLAN, assuming that the AP also competes for a wireless channel, the AP may also be referred to as a STA. In addition, depending on the network type, other well-known terms may be used instead of "station" or "STA", such as "mobile station", "subscriber station", "remote terminal", "user equipment", "wireless terminal" or "user device". For convenience, the terms "station" and "STA" are used in this disclosure to refer to remote wireless equipment that wirelessly accesses an AP or competes for a wireless channel in a WLAN, whether the STA is a mobile device (such as a mobile phone or smart phone) or is generally considered to be a fixed device (such as a desktop computer, AP, media player, fixed sensor, television, etc.).

[0053] exist Figure 1 , the dashed lines show the approximate extents of the 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 the 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.

[0054] As described in more detail below, one or more of the APs may include circuitry and / or programming for managing MU-MIMO and OFDMA channel sounding in a WLAN. Figure 1 One example of a wireless network 100 is shown, but may be Figure 1 Various changes may be made. For example, the wireless network 100 may include any number of APs and any number of STAs in any suitable arrangement. In addition, the AP 101 may communicate directly with any number of STAs and provide these STAs with wireless broadband access to the network 130. Similarly, each of the APs 101 and 103 may communicate directly with the network 130 and provide the STAs with direct wireless broadband access to the network 130. In addition, the APs 101 and / or 103 may provide access to other or additional external networks (such as an external telephone network or other types of data networks).

[0055] Figure 2a An example of an AP 101 according to an embodiment is shown. Figure 2a The embodiment of AP 101 shown in FIG. 1 is for illustrative purposes, and Figure 1 The APs 103 may have the same or similar configurations. However, APs have a wide range of configurations, and Figure 2a The scope of the present disclosure is not limited to any particular implementation of the AP.

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

[0057] The TX processing circuit 214 receives analog or digital data (such as voice data, network 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 a processed baseband or IF signal. The RF transceivers 209a-209n receive the outgoing processed baseband or IF signals from the TX processing circuit 214 and up-convert the baseband or IF signals to RF signals that are transmitted via the antennas 204a-204n.

[0058] 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 through the RF transceivers 209a-209n, the RX processing circuit 219, and the TX processing circuit 214 according to well-known principles. The controller / processor 224 may also support additional functions, 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 guide the outgoing signals in the desired direction. The controller / processor 224 may also support OFDMA operations, in which outgoing signals are assigned to different subcarrier subsets of different recipients (e.g., different STAs 111-114). The controller / processor 224 may support any of a variety of other functions in the AP 101, including a combination of DL MU-MIMO and OFDMA in the same transmit opportunity. In some embodiments, the controller / processor 224 may include at least one microprocessor or microcontroller. The controller / processor 224 is also capable of executing programs and other processes, such as an OS, residing in the memory 229. The controller / processor 224 may move data into or out of the memory 229 as required by the execution process.

[0059] The controller / processor 224 is also coupled to a backhaul or network interface 234. The backhaul or network interface 234 allows the AP 101 to communicate with other devices or systems over a backhaul connection or over a network. The interface 234 can support communication over any suitable wired or wireless connection. For example, the interface 234 can allow 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 can include any suitable structure that supports communication over a wired or wireless connection (such as Ethernet or an RF transceiver). The memory 229 is coupled to the controller / processor 224. A portion of the memory 229 may include RAM, and another portion of the memory 229 may include flash memory or other ROM.

[0060] As described in more detail below, AP 101 may include circuitry and / or programming for managing the channel sounding process in a WLAN. Figure 2a An example of AP 101 is shown, but the Figure 2a For example, AP101 may include any number of Figure 2aAs a specific example, the AP may include multiple interfaces 234, and the controller / processor 224 may support routing functions to route data between different network addresses. As another example, although shown as including 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 transceiver per RF). Alternatively, only one antenna and RF transceiver path may be included, such as in a traditional AP. In addition, Figure 2a The various components in may be combined, further subdivided, or omitted, and additional components may be added according to specific needs.

[0061] like Figure 2a As shown, in some embodiments, the AP 101 may be an AP MLD including a plurality of APs 202a-202n. Each AP 202a-202n is attached to the AP MLD 101 and includes a plurality of antennas 204a-204n, a plurality of radio frequency (RF) transceivers 209a-209n, a transmit (TX) processing circuit 214, and a receive (RX) processing circuit 219. Each AP 202a-202n may independently communicate with the controller / processor 224 and other components of the AP MLD 101. Figure 2a Each AP 202a-202n is shown with a separate multiple antennas, but each AP 202a-202n may share multiple antennas 204a-204n rather than requiring separate multiple antennas. Each AP 202a-202n may represent a physical (PHY) layer and a lower media access control (MAC) layer.

[0062] Figure 2b An example of STA 111 according to an embodiment is shown. Figure 2b The embodiment of STA 111 shown in FIG. 1 is for illustration purposes, and Figure 1 STAs 111-114 may have the same or similar configurations. However, STAs have a variety of configurations, and Figure 2b The scope of the present disclosure is not limited to any particular implementation of a STA.

[0063] like Figure 2b As shown, STA 111 may include antenna 205, RF transceiver 210, TX processing circuit 215, microphone 220, and RX processing circuit 225. STA 111 may also include speaker 230, controller / processor 240, input / output (I / O) interface (IF) 245, touch screen 250, display 255, and memory 260. Memory 260 may include operating system (OS) 261 and one or more applications 262.

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

[0065] The TX processing circuit 215 receives analog or digital voice data from the microphone 220, or receives other outgoing baseband data (such as network 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 outgoing processed baseband or IF signal from the TX processing circuit 215 and up-converts the baseband or IF signal to an RF signal that is transmitted via the antenna 205.

[0066] The controller / processor 240 may include one or more processors and execute a basic OS program 261 stored in the 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 through the RF transceiver 210, the RX processing circuit 225, and the TX processing circuit 215 according to well-known principles. The controller / processor 240 may also include a processing circuit configured to provide management of the channel sounding process in the WLAN. In some embodiments, the controller / processor 240 may include at least one microprocessor or microcontroller.

[0067] The controller / processor 240 is also capable of executing other processes and programs resident in the memory 260, such as operations for managing the channel sounding process in the WLAN. The controller / processor 240 can move data into or out of the memory 260 as needed for the execution process. In some embodiments, the controller / processor 240 is configured to execute multiple applications 262, such as applications for channel sounding, including feedback calculations based on received null data packet announcements (NDPA) and null data packets (NDP), and sending beamforming feedback reports 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 the AP. The controller / processor 240 is also coupled to the I / O interface 245, which provides the STA 111 with the ability to connect to other devices such as laptops and handheld computers. The I / O interface 245 is a communication path between these accessories and the main controller / processor 240.

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

[0069] although Figure 2b An example of STA 111 is shown, but the Figure 2b Make various changes. For example, Figure 2b The various components in the 240 may be combined, further subdivided, or omitted, and additional components may be added as required. In a specific example, the STA 111 may include any number of antennas 205 for MIMO communication with the AP 101. In another example, the STA 111 may not include voice communications, or 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). In addition, although Figure 2b STA 111 is shown configured as a mobile phone or smart phone, but the STA may be configured to operate as other types of mobile or stationary devices.

[0070] like Figure 2bAs shown, in some embodiments, STA 111 may be a non-AP MLD including a plurality of STAs 203a-203n. Each STA 203a-203n is attached to the non-AP MLD 111 and includes an antenna 205, an RF transceiver 210, a TX processing circuit 215, and an RX processing circuit 225. Each STA 203a-203n may independently communicate with the controller / processor 240 and other components of the non-AP MLD 111. Figure 2b Each STA 203a-203n is shown with a separate antenna, but each STA 203a-203n may share antenna 205 rather than requiring a separate antenna. Each STA 203a-203n may represent a physical (PHY) layer and a lower medium access control (MAC) layer.

[0071] Figure 3 An example of a multi-link communication operation according to an embodiment is shown. The multi-link communication operation can be used in the IEEE 802.11be standard and any future revisions of the IEEE 802.11 standard. Figure 3 In the example, the AP MLD 310 can be Figure 1 The wireless communication devices 101 and 103 in the embodiment, and the non-AP MLD 220 may be Figure 1 One of the wireless communication devices 111-114 in.

[0072] like Figure 3 As shown, AP MLD 310 may include multiple subordinate APs, including, for example, AP 1, AP 2, and AP 3. Each subordinate AP may include a PHY interface to a wireless medium (Link 1, Link 2, or Link 3). AP MLD 310 may include a single MAC Service Access Point (SAP) 318 through which the subordinate APs of AP MLD 310 communicate with a higher layer (Layer 3 or Network Layer). Each subordinate AP of AP MLD 310 may have a different MAC address (lower MAC address) than any other subordinate AP of AP MLD 310. AP MLD 310 may have an MLD MAC address (higher MAC address), and the subordinate APs share a single MAC SAP 318 to Layer 3. Therefore, the subordinate APs share a single IP address, and Layer 3 identifies AP MLD 310 by assigning a single IP address.

[0073] The non-AP MLD 320 may include a plurality of subordinate STAs, for example, including STA 1, STA 2, and STA 3. Each subordinate STA may include a PHY interface to a wireless medium (Link 1, Link 2, or Link 3). The non-AP MLD 320 may include a single MAC SAP 328 through which the subordinate STAs of the non-AP MLD 320 communicate with a higher layer (Layer 3 or network layer). Each subordinate STA of the non-AP MLD 320 may have a different MAC address (lower MAC address) from any other subordinate STA of the non-AP MLD 320. The non-AP MLD 320 may have an MLD MAC address (higher MAC address), and the subordinate STAs share a single MAC SAP 328 to Layer 3. Therefore, the subordinate STAs share a single IP address, and Layer 3 identifies the non-AP MLD 320 by assigning a single IP address.

[0074] The AP MLD 310 and the non-AP MLD 320 may establish multiple links between their subordinate APs and STAs. In this example, AP 1 and STA 1 may establish Link 1 operating in the 2.4 GHz band. Similarly, AP 2 and STA 2 may establish Link 2 operating in the 5 GHz band, and AP 3 and STA 3 may establish Link 3 operating in the 6 GHz band. Each link may independently enable channel access and frame exchange between the AP MLD 310 and the non-AP MLD 320, which may increase data throughput and reduce latency.

[0075] In order to preferentially transmit different types of traffic identified by traffic identifiers (TIDs) across established links, 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 allocated for transmission on each established link in the uplink and downlink directions, respectively. When at least one TID associated with the non-AP MLD 320 is mapped to an established link in the uplink or downlink direction, the link is referred to as an enabled link of the non-AP MLD 320. By default, all TIDs are mapped to all established links between the AP MLD 310 and the non-AP MLD 320, and the mapping is referred to as a default TID-to-link mapping. During association, the non-AP MLD 320 may negotiate a non-default mapping of TIDs to established links using a negotiation process by including a TID-to-link mapping element in an association request frame or a reassociation request frame. The non-default mapping may be the case where all TIDs are mapped to the same subset of established links, or the case where not all TIDs are mapped to the same subset of established links. The AP MLD 310 may 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 established links for downlinks and uplinks, and all established links are enabled. When TID-to-link mapping negotiation does not occur or is unsuccessful, the non-AP MLD 320 operates in the default mapping mode.

[0076] Figure 4 An example of a TID-to-link mapping element 400 is shown according to an embodiment. Figure 4 This example may be applicable to the IEEE 802.11be standard and any future revisions of the IEEE 802.11 standard. The TID-to-link mapping element 400 may indicate the links on which frames belonging to each TID may be exchanged.

[0077] like Figure 4 As shown, 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 an optional link mapping field for TID n.

[0078] The element ID field and the element ID extension field may include 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.

[0079] The TID to link mapping control field may include a direction subfield, a default link mapping subfield, a mapping switch time existence subfield, an expected duration existence subfield, a link mapping size subfield, a reserved subfield, and an optional link mapping existence 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, for a downlink frame, the direction subfield may be set to 0, for an uplink frame, the direction subfield may be set to 1, and for a frame sent on a downlink and an uplink, the direction subfield may be set to 2. The default link mapping subfield may indicate whether the TID to link mapping element 400 represents a default TID to link mapping. For example, for a default mapping, the subfield may be set to 1, and for a non-default mapping, the subfield may be set to 0. The mapping switch time existence subfield may indicate whether the mapping switch time field exists in the TID to link mapping element 400. The expected duration existence subfield may indicate whether the expected duration field exists in the TID to link mapping element 400. The link mapping size subfield may indicate the length of the link mapping field for TID n. The link map presence indicator subfield may indicate whether a link map field for TID n exists in the TID to link map element 400 .

[0080] The Mapping Switch Time field is present when the TID-to-Link Mapping element 400 is sent in a beacon or probe response frame by an AP attached to an AP MLD and the indicated TID-to-link mapping has not yet been established.

[0081] The expected duration field may indicate the duration for which the proposed TID-to-link mapping is expected to be valid when the mapping switch time field is present, and the remaining duration for which the proposed TID-to-link mapping is expected to be valid when the mapping switch time field is not present.

[0082] The Link Mapping field for TID n (e.g., where n=0, 1, ..., 7) may indicate links on which frames belonging to TID n are allowed to be sent. The Link Mapping field for TID n may carry a bitmap of links to which TID n is mapped. The Link Mapping field for TID n may not be present when the Default Link Mapping subfield of the TID to Link Mapping Control field indicates a default TID to link mapping. For example, when the Direction subfield is set to 0, the Default Link Mapping subfield is set to 0, and the Link Mapping field for TID 0 is configured as 10000 ... 0, the configuration indicates that downlink data corresponding to TID 0 is sent on Link 1.

[0083] 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.

[0084] In order to allow non-AP MLDs to save power, several power management solutions may exist. For example, a STA of a non-AP MLD may be in a doze state for an extended period of time during which it is not expected to be able to send or receive frames. During this time, the corresponding AP of the AP MLD may buffer bufferable units (BUs) addressed to the STA of the non-AP MLD (buffered BUs or buffered traffic). In order to indicate the presence of pending BUs to all associated non-AP MLDs via broadcast or multicast signaling, each AP attached to the AP MLD periodically includes a traffic information map (TIM) element in the beacon frames it sends, and each AP attached to the AP MLD may optionally send a separate periodic broadcast TIM frame. In multi-link operation, the AP of the APMLD may include a multi-link traffic indication element in the beacon frame to indicate the link on which the buffered BUs (or buffered traffic) may be retrieved.

[0085] Figure 5a An example of a multi-link traffic indication element according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0086] like Figure 5a As shown, the multi-link service indication element 500 may include an element ID field, a length field, an element ID extension field, a multi-link service indication control field, and a per-link service indication list field.

[0087] The element ID field and the element ID extension field may include information for identifying the multi-link traffic indication element 500. The length field may indicate the length of the multi-link traffic indication element 500.

[0088] The multi-link 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 each per-link traffic indication bitmap subfield 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 that there is pending traffic for a specific STA or non-AP MLD at the AP MLD.

[0089] The per-link service indication list field may include multiple per-link service indication bitmap subfields and a padding subfield. The per-link service indication bitmap subfield may indicate a per-link service indication 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 enabled links. In an embodiment, the per-link service indication bitmap subfield may indicate a link recommendation for retrieving buffered services for a non-AP MLD that has negotiated a TID-to-link mapping with the AP MLD, and all TIDs are mapped to all enabled links. In an embodiment, the per-link service indication bitmap subfield indicates a link recommendation for retrieving buffered services for a non-AP MLD in a default mapping mode. The padding subfield may include padding bits so that the per-link service indication list field is a multiple of 8 bits.

[0090] Figure 5b An example of construction of a multi-link traffic indication element according to an embodiment is shown.

[0091] exist Figure 5b , the traffic indication virtual bitmap and partial virtual bitmap subfields in the TIM element shown in the top and middle parts show how to indicate the AIDs of the associated non-AP MLDs and STAs. The AP attached to the AP MLD can use the partial virtual bitmap of the TIM element to indicate the pending buffered traffic of the non-AP MLDs and STAs associated with the AP MLD. The partial virtual bitmap subfield in the TIM element may include a portion of the traffic indication virtual bitmap shown in the top part. The AP attached to the AP MLD may include a multi-link traffic indication element 500 in the beacon frame it sends, and the multi-link traffic indication element 500 is included in the Figure 5b The bottom portion is shown.

[0092] As explained, the multi-link traffic indication element 500 may include a per-link traffic indication bitmap subfield corresponding to the AID of the non-AP MLD or STA, starting from bit number k of the traffic indication virtual bitmap indicated in the AID offset subfield in the multi-link 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 the AP MLD, then if the AP MLD has a buffered BU or medium access control (MAC) management protocol data unit (MMPDU), the bit position i of the per-link traffic indication bitmap subfield for link ID i may be set to 1, where the TID is mapped to the link for the non-AP MLD, otherwise the bit should be set to 0. If the non-AP MLD is in the default mapping mode, if the AP MLD has buffered BUs or MMPDUs and the non-AP MLD should use link i to retrieve the buffered BUs or MMPDUs, then bit position i of the Per-Link Traffic Indication Bitmap subfield of link ID i may be set to 1. Thus, the APMLD may provide link recommendations to the non-AP MLD to use one or more enabled links to retrieve the buffered traffic.

[0093] exist Figure 5b In the example of , the first, third, fourth, and sixth AIDs in the partial virtual bitmap subfield in the TIM are set to 1, starting from the bit number k of the service indication virtual bitmap indicated in the AID offset subfield. The per-link service 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 service indication bitmap subfield can indicate in AID k that the AP MLD has buffered services to be processed in link 0. Therefore, the non-AP MLD with AID k can use link 0 to retrieve the buffered services to be processed. The remaining per-link service indication bitmap subfields indicate the recommended links in a similar manner.

[0094] In some embodiments, the AP of the AP MLD cannot indicate to the STA of the non-AP MLD that there is buffered traffic addressed to the non-AP MLD for a TID that is not mapped to the current link, wherein the AP of the AP MLD and the STA of the non-AP MLD are involved in an active frame exchange. Such an indication can reduce the latency of retrieving buffered traffic and checking for critical updates in the multi-link setup. This indication may be useful in the following implementations to be explained below.

[0095] Figure 6a An example of multi-link operation according to an embodiment is shown. Figure 6a, the AP MLD 610 may include two subordinate APs (e.g., AP 1 and AP 2), and the non-AP MLD 620 may include two subordinate STAs (e.g., STA 1 and STA 2). AP1 and STA 1 establish link 1, and AP 2 and STA 2 establish link 2. Each link may independently implement channel access and frame exchange between the AP MLD 610 and the non-AP MLD 620. In this example, it is assumed that the non-AP MLD 620 is in both the non-default TID to link mapping mode and the power saving mode on link 1 and link 2.

[0096] When operating in the power saving mode, STA 1 may wake up to receive a beacon frame (630) sent by AP 1, and may determine that AP MLD 610 has buffered traffic or bufferable units (BUs) for non-AP MLD 620. The BU may be a media access control (MAC) service data unit (MSDU), an aggregated MAC service data unit (MSDU) [quality of service (QoS) station only], or a bufferable MAC management protocol data unit (MMPDU). The BU may be buffered to operate the power saving mode. In the present disclosure, the terms 'buffered traffic' and 'buffered BUs' may be used interchangeably and have the same meaning.

[0097] When STA 1 determines that AP MLD 610 has a buffered BU, STA 1 may indicate to AP 1 that STA 1 has transitioned from the doze state to the awake state, and initiate a frame exchange with AP 1 to retrieve the buffered BU by sending a power save poll (PS-Poll) frame or a U-APSD (unscheduled automatic power save delivery) trigger frame via link 1. In response to the PS-Poll frame or the U-APSD trigger frame, if the buffered BU is available and is not discarded for implementation-related reasons, AP 1 may deliver the buffered BU mapped to STA 1. Otherwise, AP 1 may send a QoS null frame. Upon receiving the QoS null frame, STA 1 may transition to the doze state. When AP 1 participates in a frame exchange with STA 1 in the power save mode, AP 1 may use the More Data subfield (set to 1) of the control field of the downlink frame to indicate to STA 1 that more individually addressed BUs are buffered for the non-AP MLD 620. After AP 1 sends all buffered BUs mapped to STA 1, AP 1 may send a downlink frame with the More Data subfield set to 0 to STA 1. STA 1 may then return to the doze state for the remaining listening interval. Figure 6aAs shown, after the beacon frame (630) transmission and before the frame exchange, AP 1 may have a new BU that is not mapped to STA 1's TID. The current IEEE 802.11 standard does not provide a mechanism to indicate to STA 1 of the non-AP MLD 620 that such a new BU is present in a separately addressed frame. Therefore, via the exchange of separately addressed frames with AP 1, STA 1 may not be aware of the status of the buffered BUs on another link or any critical updates on other links. These indications may be carried only in the beacon frame or TIM frame. Accordingly, the new BU is delivered only after the non-AP 620 decodes the next TIM element and the multi-link traffic indication element, which may result in high latency in recovering the newly arrived BU.

[0098] Figure 6b Another example of multi-link operation according to an embodiment is shown. Figure 6a , assuming that the non-AP MLD 620 is in both the non-default TID-to-link mapping mode and the power saving mode on Link 1 and Link 2. When delay-sensitive traffic is mapped to both Link 1 and Link 2, the AP MLD 610 may indicate both Link 1 and Link 2 as recommended links in the per-link traffic indication bitmap subfield of the multi-link traffic information element for faster channel access and delivery. Figure 6b As shown, STA 1 may wake up to receive a beacon frame sent by AP 1 and determine that AP MLD 610 has a buffered BU for non-AP MLD 620. STA 1 may then indicate to AP 1 that STA 1 has transitioned from the doze state to the wake state and initiate a frame exchange with AP 1 to retrieve the buffered BU by sending a PS-Poll frame or a U-APSD trigger frame A via link 1. After AP 1 sends all buffered BUs, AP 1 may send a More Data subfield set to 0 to STA 1. However, even after STA 1 receives the More Data subfield set to 0, STA 1 may not know whether STA 2 operating on link 2 needs to send a PS-Poll frame or a U-APSD trigger frame to retrieve the buffered BU via link 2. Therefore, without an indication of whether there are buffered BUs for other links, STA 2 of non-AP MLD 620 may unnecessarily remain awake and send another PS-Poll frame or U-APSD trigger frame via another link (i.e., link 2), as shown in FIG. Figure 6b shown.

[0099] Figure 6c Another example of multi-link operation according to an embodiment is shown. Figure 6a , assuming that the non-AP MLD 620 is in both non-default TID-to-link mapping mode and power saving mode on Link 1 and Link 2. Figure 6c, STA 1 attached to the non-AP MLD 620 may wake up for some reason (e.g., P2P communication) and then send a PS-Poll frame to AP 1 of the AP MLD 610 to obtain the buffered BU without decoding the TIM element or the multi-link traffic indication element. In this example, STA 1 may obtain the BU mapped to STA 1 only via link 1 and may not know the BU mapped to link 2. Therefore, STA 2 of the non-AP MLD 620 may have to wait to receive the multi-link traffic indication element recommending link 2 to obtain the buffered BU.

[0100] Figure 6d Another example of multi-link operation according to an embodiment is shown. Figure 6a , assuming that the non-AP MLD 620 is in both non-default TID-to-link mapping mode and power saving mode on Link 1 and Link 2. Figure 6d , it is also assumed that TID 1:2 is mapped to link 1, and all TIDs are mapped to link 2. In addition, it is assumed that STA 1 has a target wake-up time (TWT) negotiation on link 1. As a result, STA 1 of the non-AP MLD 620 may wake up periodically in the TWT service period (SP) and retrieve the BU mapped to STA 1. However, STA 1 may not be aware of the buffered BU mapped to link 2. Therefore, STA 2 of the non-AP MLD 620 may have to wait to receive a multi-link traffic indication element indicating that there is a buffered BU for STA 2.

[0101] Figure 6e Another example of multi-link operation according to an embodiment is shown. Figure 6a , assuming that the non-AP MLD 620 is in both non-default TID-to-link mapping mode and power saving mode on Link 1 and Link 2. Figure 6e , STA 1 may wake up to receive a TIM element indicating the presence of a buffered BU in a beacon frame, and initiate a frame exchange by sending a PS-Poll frame to retrieve the buffered BU. However, in the case where the load on Link 1 is much greater than the load on Link 2 or the pending buffered BU for the non-AP MLD 620 is significantly high, the AP MLD 610 may need to recommend the non-AP MLD 620 to transition STA 2 from the doze state to the awake state and retrieve at least a portion of the pending buffered BU. However, the current IEEE 802.11 standard does not provide such an indication from the AP MLD 610 to the non-AP MLD 620 during the frame exchange sequence on Link 1 initiated by the PS-Poll frame.

[0102] In many examples, including Figure 6a-6eFor those examples explained in , it would be beneficial if the AP MLD could indicate within a frame exchange sequence initiated by a STA affiliated with a non-AP MLD whether the AP MLD has buffered traffic recommended by other STAs affiliated with the non-AP MLD to be retrieved via another link.

[0103] The present disclosure details embodiments in which an AP of an AP MLD indicates to a STA of a non-AP MLD in an active frame exchange in a link: i) whether there is buffered traffic for processing by the non-AP MLD on another link, ii) whether the AP MLD intends to recommend that the non-AP MLD use another link to obtain buffered traffic, and / or iii) whether there is a critical update to the basic service set (BSS) of the non-AP MLD on another link.

[0104] In an embodiment, an additional bit may be added to the frame control field of a downlink PPDU (physical layer (PHY) protocol data unit). For example, the additional bit may be referred to as a "check TIM" bit. The AP of an AP MLD may utilize the check TIM bit in the frame control field of the downlink PPDU to indicate to a STA of a non-AP MLD operating on a link in power saving mode that the AP MLD has buffered BUs to be processed for the non-AP MLD and that the TIDs of these buffered BUs are not mapped to the current link. Upon receiving a downlink PPDU with the check TIM bit set to 1, any STA of the non-AP MLD may attempt to receive a TIM element and / or a multi-link traffic indication element to check and retrieve the buffered BUs to be processed. In an embodiment, the AP MLD may also use an indication of an additional bit (e.g., the check TIM bit) to notify the non-AP MLD that the next beacon frame on any enabled link needs to be decoded to check for any critical updates on one or more enabled links.

[0105] In an embodiment, an additional bit (e.g., check TIM bit) may be added to the QoS null frame. The AP of the AP MLD may send a QoS null frame with a check TIM bit as a response to a PS-Poll frame or a UAPSD trigger frame. This transmission is intended to indicate to a STA of a non-AP MLD operating on a link in power save mode that the AP MLD has a buffered BU to be processed for the non-AP MLD and that the TID of the buffered BU is not mapped to the current link. Upon receiving a QoS null frame with the check TIM bit set to 1, any STA of the non-AP MLD may attempt to receive a TIM element and / or a multi-link traffic indication element to check and retrieve the buffered BU to be processed. In an embodiment, the AP MLD may also use an indication of an additional bit (e.g., check TIM bit) to notify the non-AP MLD that the next beacon frame on any enabled link needs to be decoded to check for any critical updates on one or more enabled links. In various embodiments, new information elements may be defined as follows.

[0106] Figure 7a An example of a new information element 700 for indicating pending buffered traffic for non-AP MLD according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0107] exist Figure 7a , the new information element 700 may include an element ID field, a length field, an element ID extension field, and a link ID bitmap field. The element ID field and the element ID extension field may include information for identifying the new information element 700. The length field may indicate the length of the new information element 700. The link ID bitmap field may indicate the status of buffered traffic for all enabled links between the AP MLD and the associated non-AP MLDs. In this example, the element ID field, the length field, and the element ID extension field each have a length of 1 octet, while the link ID bitmap field has a length of 2 octets.

[0108] The Link ID Bitmap field can be used with Figure 5a and Figure 5bThe bitmap is included in a manner similar to the per-link service indication field of the multi-link service indication element in the multi-link service indication element. This enables the non-AP MLD to interpret the new information element and determine on which links the non-AP MLD needs to retrieve buffered services from the AP MLD. In an embodiment, the order of the link IDs corresponding to the link ID bitmap field may be similar to the order of indications in the per-link service indication field of the multi-link service indication element. In an embodiment, the link ID bitmap field may be 1 or 2 octets, depending on whether the number of per-link service indication bits associated with each AID included in the multi-link service indication element is less than or equal to 8 bits or greater than 8 bits. If the number of bits is not a multiple of 8 bits, zero padding bits may be used. STAs of non-AP MLDs operating on links for which the corresponding bits in the link ID bitmap field are set to 1 can transition from a doze state to an awake state. They can send a PS-Poll frame or a U-ASPD trigger frame to the corresponding AP of the AP MLD to retrieve buffered services. The new information element 700 may be included by the AP of the AP MLD in a downlink frame to the associated non-AP MLD's STA. In an embodiment, the new information element may be such as Figure 5a The multi-link traffic indication element may indicate the status of buffered traffic for all enabled links between the AP MLD and associated non-AP MLDs.

[0109] Figure 7b Another example of a new information element 710 for indicating pending buffered traffic for non-AP MLD according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0110] In some aspects, the fields in the new information element 710 may be Figure 7a The corresponding fields in the new information element 700 shown in FIG. 7 are the same or similar, with examples of differences described below. For example, the new information element 710 may include an additional field, a basic service set (BSS) parameter change count (BPCC) field (also referred to as a check beacon field), such as Figure 7b As shown. The BPCC field may indicate that an associated non-AP MLD or STA is required to check for critical updates on a link for multi-link establishment or activation. In this example, the BPCC field may have a length of 1 octet. Upon receiving a new information element, the associated non-AP MLD STA may attempt to decode the next beacon frame to check for critical updates, or may send a multi-link probe request frame to obtain updated BSS parameters.

[0111] Figure 8Another example of an A control subfield 800 for indicating pending buffered traffic for a non-AP MLD according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0112] This example may be a new type of A (aggregation) control subfield in the HE (high efficiency) variant HT (higher throughput) control field, which may be referred to as a "multi-link traffic indication (MLTI) variant A control subfield" or simply referred to as an "MLTI control subfield" for brevity. In various embodiments, this control subfield may also be referred to as a "link recommendation" control field, a "traffic indication" control field, a "wake-up request" control field, a "wake-up request" control field, a "link activation request" control field, a "link extension request" control field, a "link utilization request" control field, a "link usage request" control field, a "buffered TID" control field, etc. In addition, the MLTI control subfield may be included in a QoS data frame, a QoS null frame, and a separately addressed management frame sent by the AP MLD to the non-AP MLD. The MLTI control subfield may indicate that the AP MLD has pending buffered traffic for other STAs of the non-AP MLD, or recommend another link on which other STAs of the non-AP MLD may retrieve buffered traffic.

[0113] exist Figure 8 , the MLTI control subfield may include a control ID subfield, a recommended link bitmap subfield, a reserved subfield, and a padding bit. The control ID subfield may include information for identifying the MLTI control subfield 800. The control ID subfield may have a length of 4 bits. The recommended link bitmap subfield may indicate the link ID of the STA recommended for waking up and retrieving buffered services. The recommended link bitmap subfield may have a length of 16 bits. In some implementations, the recommended link bitmap subfield may also be referred to as a "link recommendation bitmap subfield" or a "service indication link ID bitmap subfield", etc.

[0114] In an embodiment, when i) the AP MLD has buffered traffic having a TID mapped to link i of the non-AP MLD associated with the AP MLD, and ii) link i is not the same as the link on which the receiving STA of the non-AP MLD is currently operating, the bit in position i of the Recommended Link Bitmap subfield may be set to 1. Otherwise, the bit may be set to 1.

[0115] In an embodiment, when a STA of a non-AP MLD operating on link i is recommended to retrieve individually addressed traffic (i.e., BU) from an APMLD associated with the non-AP MLD, the bit in position i of the recommended link bitmap subfield may be set to 1. On the other hand, when a STA of a non-AP MLD operating on link i is not recommended to retrieve individually addressed BU from an AP MLD associated with the non-AP MLD, the bit in position i of the recommended link bitmap subfield may be set to 0. In other words, when i) the APMLD has buffered traffic with a TID mapped to link i of the non-AP MLD associated with the AP MLD, and link i is a recommended link for retrieving buffered traffic, and ii) link i is not the same link on which a receiving STA of the non-AP MLD is currently operating, the AP of the AP MLD may set the bit in position i of the recommended link bitmap subfield to 1. Otherwise, the bit may be set to 1.

[0116] In an embodiment, the link indication in the recommended link bitmap subfield may be consistent with the link indication in the multi-link service indication element, as shown in FIG. Figure 5a and 5b As explained, except for changes due to the arrival of new traffic or the delivery of certain BUs. In some embodiments, the link recommendation for the non-AP MLD provided in the MLTI Control subfield may replace any traffic indication and link recommendation provided in the Multi-Link Traffic Indication element and TIM element previously sent by the AP MLD.

[0117] In an embodiment, the AP of the AP MLD may send a downlink frame including an MLTI Control subfield to a STA of a non-AP MLD associated with the APMLD, wherein all bits in the Recommended Link Bitmap subfield of the MLTI Control subfield are set to 0, indicating to the non-AP MLD that there are no remaining individually addressed BUs to the non-AP MLD. In an embodiment, the AP MLD may include the MLTI Control subfield only in a QoS Null frame or a QoS Data frame, wherein the More Data bit is set to 0.

[0118] When a STA of a non-AP MLD supports the MLTI Control subfield and receives a QoS frame or a QoS Null frame containing the MLTI Control subfield from an AP of an AP MLD, other STAs of the non-AP MLD operating on the link indicated by the Recommended Link Bitmap subfield can issue a PS-Poll frame or a U-APSD Trigger frame to retrieve the buffered BU from the AP MLD.

[0119] In the IEEE 802.11be standard and any future revisions of the IEEE 802.11 standard, support for transmission and reception of the MLTI control subfield may be optional or mandatory.

[0120] Figure 9a and Figure 9b An example of a multi-link device (MLD) capability and operation subfield 900 of a basic multi-link element according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0121] exist Figure 9a In the MLD capability and operation subfield 900, a maximum number of simultaneous links subfield, an SRS (Single Response Scheduling) support subfield, a supported TID to link mapping negotiation subfield, a frequency separation indication subfield for STR (Simultaneous Transmit and Receive) / AP MLD type, an AAR (AP Assistance Request) support subfield, an MLTI support subfield, and a reserved subfield.

[0122] The Maximum Number of Simultaneous Links subfield may indicate the maximum number of STAs affiliated with the MLD that support simultaneous transmission or reception of frames on the corresponding link. The SRS Support subfield may indicate support for reception of frames carrying the SRS Control subfield. The Supported TID to Link Mapping Negotiation subfield may indicate TID to link mapping negotiation. The Frequency Separation Indication for STR / AP MLD Type subfield may i) indicate the minimum frequency gap between any two links recommended by the non-AP MLD for STR operation, and ii) indicate the type of AP MLD. The AAR Support subfield may indicate that the AP MLD supports reception of frames with the AAR control subfield. The MLTI Support subfield may indicate that the non-AP MLD supports reception of frames with the MLTI control subfield. As Figure 9b As shown, this subfield may be reserved for AP MLD. For non-AP MLD, if the non-AP MLD supports receiving frames with the MLTI control subfield, this subfield may be set to 1, otherwise this subfield may be set to 0.

[0123] In an embodiment, an AP MLD capable of providing multi-link traffic indication via the MLTI Control subfield may set dot11MLTIOptionImplemented to true. An AP attached to an AP MLD with dot11MLTIOptionImplemented set to true may also indicate this capability by setting the MLTI Support subfield to 1. Otherwise, the AP may set the MLTI Support subfield to 0.

[0124] In an embodiment, a non-AP MLD that supports receiving multi-link traffic indication via the MLTI Control subfield may set dot11MLTIOptionImplemented to true. A STA attached to a non-AP MLD with dot11MLTIOptionImplemented equal to true may also indicate this capability by setting the MLTI Support subfield to 1. Otherwise, the STA may set the MLTI Support subfield to 0.

[0125] In an embodiment, an AP may not send a frame containing an MLTI Control subfield whose bit is set to 1 to identify its own link. An AP with dot11MLTIOptionImplemented set to false may not send a frame containing an MLTI Control subfield to an associated STA. A non-AP STA with dot11MLTIOptionImplemented set to false may ignore the MLTI Control subfield sent in a frame from an associated AP.

[0126] Fig.10 Another example of an MLTI control subfield 1000 according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0127] exist Fig.10 In the MLTI control subfield 1000, the control ID subfield, the recommended link bitmap subfield, the MLTI / AAR subfield, the reserved subfield and the padding bit can be included. Figure 8 The MLTI control subfield 800 in FIG. 8 is the same or similar, except that the MLTI / AAR subfield has a length of one bit.

[0128] This example may be a generalization of the AAR control subfield defined in the IEEE 802.11be standard. Therefore, the MLTI control subfield 1000 may reuse the same control ID subfield as the AAR control subfield defined in the IEEE 802.11be standard. Therefore, the AAR control subfield may also be referred to as the MLTI control subfield.

[0129] In an embodiment, the MLTI Control subfield 1000 may have an MLTI control function when sent by an AP MLD. When sent by a non-AP MLD with EMLSR (Enhanced Multi-Link Single Radio), NSTR (Non-Simultaneous Transmit and Receive), or EMLMR (Enhanced Multi-Link Multi-Radio) constraints and dot11AAROptionImplemented is set to true, the MLTI Control subfield 1000 may be interpreted as having an AAR control function. Otherwise, the MLTI Control subfield 1000 may be reserved for other purposes.

[0130] The MLTI / AAR subfield may indicate whether the MLTI control subfield 1000 has an MLTI control function or an AAR control function. For example, the MLTI / AAR subfield may be set to 1 to indicate an MLTI control function. Otherwise, it may be set to 0 to indicate an AAR control function.

[0131] In an embodiment, when both the AP MLD and the non-AP MLD have dot11MLTIOptionImplemented set to true and the MLTI / AAR subfield is set to 1, the MLTI Control subfield 1000 may be sent by the AP of the AP MLD to the non-AP MLD.

[0132] In an embodiment, the MLTI / AAR subfield may be generalized as a "subtype" field of 2, 3, or 4 bits in length. In addition to the AAR control subfield and the MLTI control subfield, it may be used for future extensions of other types of A control fields that may also utilize the recommended link bitmap. For example, one subtype may be used to indicate a buffered TID bitmap to be discussed later, while another subtype may indicate a recommended link bitmap.

[0133] There may be a common A control subfield that may be sent by a first MLD to a second MLD for cross link indication, which may be referred to as a link indication A control subfield.

[0134] Fig.11a An example of a link indication A control subfield 1100 according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0135] exist Fig.11a, the Link Indication (LI) A control subfield 1100 may include a control ID subfield, a subtype subfield, a reserved subfield, a link ID bitmap subfield, and a padding bit. The subtype subfield, the reserved subfield, and the link ID bitmap subfield may together form a control information subfield. The control information subfield may indicate the link ID set of the STA attached to the sending or receiving MLD, and the purpose of the link ID indication as described below. The control information subfield may be used by the MLD to which the sending STA is attached.

[0136] The Subtype subfield may indicate the purpose of the Link ID Map subfield. Fig.11b In the example of , when the subtype subfield is set to 0, the LIA control subfield 1100 has an AAR function, and the control information subfield indicates the link ID of the STA that is requesting assistance from the corresponding AP for media synchronization recovery. When the subtype subfield is set to 1, the LIA control subfield 1100 has an MLTI control or WR (wake-up request) function, and the control information subfield indicates the link ID of the STA attached to the receiving non-AP MLD, and the STA of the receiving non-AP MLD is sent an AP MLD request to transition to the awake state. Subtype values ​​2-7 are reserved for other purposes.

[0137] The Link ID Bitmap subfield may indicate the set of link IDs attached to STAs that transmit or receive non-AP MIDs. A value of 1 in bit position i may indicate that link ID i is an indicated link, and a value of 0 indicates that link ID i is not an indicated link.

[0138] In an embodiment, when the AP MLD supports the transmission of the LIA control subfield 1100 with the WR subtype or the non-AP MLD supports the reception of the LIA control subfield 1100 with the WR subtype, Figure 9a The MLTI support subfield (or WR support subfield) in the MLD capability and operation subfield in the WR is set to 1. Otherwise, the MLTI support subfield is set to 0.

[0139] An AP supporting AP MLD of WR may set the bit in position i of the Link ID Bitmap subfield to 1. It may indicate that the AP MLD has a buffered BU with a TID mapped to link i for non-AP MLD. The buffered BU is recommended to be retrieved by the STA of the non-AP MLD operating on link i. Otherwise, this bit is set to 0.

[0140] When a STA of a non-AP MLD supporting WR receives a frame with the LIA Control subfield 1100 of subtype WR from an AP, i) a STA operating on a link indicated as 1 in the Link ID Bitmap subfield may issue a PS-Poll frame or a U-APSD trigger frame (when the STA uses U-APSD and all access categories (ACs) have delivery enabled) to retrieve buffered BUs from the AP MLD, and ii) a STA operating on a link indicated as 0 in the Link ID Bitmap subfield may not need to issue a PS-Poll frame or a U-APSD trigger frame even if the link is recommended in a multi-link traffic indication element previously sent from the APMLD. In some implementations, the LIA Control subfield 1100 of subtype WR may not be sent by a non-AP MLD.

[0141] In an embodiment, a STA operating on a link indicated as 1 in the Link ID Bitmap subfield may also transition to active mode by setting the PM bit to 0 in a U-APSD Trigger frame or a QoS Null frame sent to the AP MLD. In an embodiment, if a link indicated as 1 in the Link ID Bitmap subfield is disabled (excluding the case where the link is disabled by the advertised TID to link mapping), the non-AP MLD may renegotiate a new TID to link mapping that maps all TIDs to the links indicated as 1 in the Link ID Bitmap subfield.

[0142] Fig.12 Another example of an MLTI control subfield 1200 according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0143] exist Fig.12 In the MLTI control subfield 1200, the control ID subfield, the recommended link bitmap subfield, the BSS parameter change count subfield, and the padding bit can be included. In addition to the BSS parameter change count (BPCC) subfield having a length of 8 bits, the various fields in the MLTI control subfield 1200 can be used with Figure 8 The MLTI control subfield 800 in is the same or similar.

[0144] The BPCC subfield may indicate the BSS parameter change count of the sending AP of the AP MLD. The non-AP MLD may determine whether it needs to receive the next beacon frame on the current link based on the BPCC subfield. In an embodiment, the non-AP MLD may detect that the value of the BPCC subfield in the MLTI control subfield 1200 is different from the BPCC value of the link received in the previous beacon frame, and the non-AP MLD may attempt to receive the next beacon frame on the link.

[0145] Fig.13a Another example of an MLTI control subfield 1300 according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0146] exist Fig.13a In the MLTI control subfield 1300, the control ID subfield, the buffered TID bitmap subfield, the reserved and padding bits can be included. Except for the buffered TID bitmap subfield instead of the recommended link bitmap subfield, the various fields in the MLTI control subfield 1300 can be the same as Figure 8 The MLTI Control subfield 800 in FIG. 8 is the same or similar. The Buffered TID Bitmap subfield may indicate the buffer status indication of all TIDs corresponding to the non-AP MLD. Fig.13a In the Buffered TID Bitmap subfield, the length of 16 bits is 16 bits, where the i-th bit corresponds to TID i-1. When the i-th bit is set to 1, it indicates that the AP MLD has a buffered BU corresponding to TID i-1 at the AP MLD. Otherwise, the bit is set to 0. In some embodiments, the Buffered TID Bitmap may have only 8 bits and indicate the traffic of the first 8 TIDs among the 16 TIDs.

[0147] When a STA of a non-AP MLD supporting MLTI indication receives a QoS data frame or a QoS null frame with the MLTI control subfield 300 from an AP of an AP MLD, the non-AP MLD may use the information in the buffered TID bitmap subfield and the TID to link mapping to determine which STAs are to wake up and send a PS-Poll frame or a U-APSD trigger frame (when the STA uses U-APSD and all ACs have delivery enabled) to retrieve the buffered BUs from the AP MLD. For example, the non-AP MLD may ensure that for each TID indicated as 1 in the buffered TID bitmap subfield, at least one STA having the TID mapped to the STA transitions to the awake state and sends a PS-Poll frame or a U-APSD trigger frame.

[0148] In an embodiment, the AP MLD may skip or exclude all BUs scheduled for delivery in the current frame exchange sequence or TXOP during the calculation of the Buffered TID Bitmap subfield. In an embodiment, the construction of the Buffered TID Bitmap subfield may be determined based on the current knowledge of the buffer status of all TIDs at the transmitting STA when constructing the MLTI Control subfield 1300.

[0149] Fig.13bAnother example of the MLTI control subfield 1310 according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0150] exist Fig.13b In the MLTI control subfield 1310, the control ID subfield, the buffered TID bitmap subfield, the check beacon subfield, and the padding bit can be included. In addition to checking the beacon subfield instead of the reserved subfield, the various fields in the MLTI control subfield 1310 can be the same as Fig.13a The MLTI control subfield 1300 in the STA may be the same or similar. The Check Beacon subfield may be a BSS parameter change count field. The Check Beacon subfield has a length of 8 bits and provides information indicating whether the receiving STA needs to receive the next beacon frame or send a multi-link probe request frame to retrieve an update of the BSS parameters.

[0151] Fig.13c Another example of the MLTI control subfield 1320 according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revision of the IEEE 802.11 standard.

[0152] exist Fig.13c In the MLTI control subfield 1320, the control ID subfield, the buffered TID bitmap subfield, the priority TID subfield, and the padding bit can be included. Except for the priority TID subfield instead of the reserved subfield, the various fields in the MLTI control subfield 1320 can be the same as Fig.13a The MLTI control subfield 1300 in FIG. 1 is the same as or similar to the MLTI control subfield 1300 in FIG. 1 has a length of 4 bits and indicates a TID having the largest amount of buffered traffic or a TID that must be retrieved with priority (eg, delay-sensitive traffic).

[0153] In an embodiment, the receiving non-AP MLD may additionally consider the Priority TID subfield when determining which STAs to wake up and send a PS-Poll frame or a U-APSD trigger frame to the AP MLD. In some implementations, the Priority TID subfield may not indicate a TID whose corresponding bit in the Buffered TID Bitmap subfield is set to 0. In some implementations, the Priority TID subfield may indicate a TID whose corresponding bit in the Buffered TID Bitmap subfield is set to 0, indicating that none of the TIDs indicated in the Buffered TID Bitmap subfield are prioritized.

[0154] exist Fig.13cIn the embodiment, the padding has a length of 6 bits. However, in an embodiment, the padding may have a length of 5 bits, and the non-padding bit (1 bit) may indicate the presence of the priority TID subfield. When the priority TID subfield is not present, this means that no TID is prioritized.

[0155] Fig.14 Another example of an MLTI control subfield 1400 according to an embodiment is shown. This example may be applicable to the IEEE 802.11be standard and any future revisions of the IEEE 802.11 standard.

[0156] exist Fig.14 In the MLTI control subfield 1400, the control ID subfield, the buffered TID bitmap subfield, the recommended link ID subfield, and the padding bit can be included. Except for the recommended link ID subfield instead of the reserved subfield, the various fields in the MLTI control subfield 1400 can be the same as Fig.13a The MLTI control subfield 1300 in is the same or similar.

[0157] In this example, the MLTI control subfield 1400 may include both a buffered TID bitmap subfield and a recommended link ID subfield. When the i-th bit of the buffered TID bitmap subfield is set to 1, it may indicate that the receiving non-AP MLD has at least one buffered BU belonging to the corresponding TID (e.g., TID i-1). Otherwise, the bit is set to 0. In an embodiment, the calculation of the buffered TID bitmap subfield may skip or exclude BUs that are scheduled to be delivered in the current TXOP or on the current link in which the TXOP is active.

[0158] The recommended link ID subfield may indicate the link ID for which the AP recommends the non-AP MLD to retrieve at least a portion of the buffered BU. In an embodiment, the AP may always include the recommended link ID subfield. For example, when the AP does not recommend any link to obtain the buffered BU, the AP may set the link ID of the current link to the recommended link ID subfield. In an embodiment, the MLTI control subfield 1400 may include an additional 1-bit subfield, which may be referred to as the recommended link ID presence subfield, indicating the presence of the recommended link ID subfield. As a result, the padding bits in the MLTI control subfield 1400 may be reduced from 6 bits to 5 bits.

[0159] In an embodiment, a STA receiving a non-AP MLD operating on a link indicated in the recommended link ID subfield may transition to an awake state or an active state and send a PS-Poll frame or a U-APSD trigger frame to retrieve buffered BUs. In an embodiment, a STA receiving a non-AP MLD operating on a link indicated in the recommended link ID subfield may retrieve buffered BUs corresponding to all TIDs by sending a PS-Poll frame or a U-APSD trigger frame, while other STAs may only retrieve buffered BUs corresponding to the TID mapped to the link. Accordingly, the non-AP MLD may determine to transition all subordinate STAs to an awake state or an active state and jointly retrieve buffered BUs, or transition STAs operating on the recommended link and retrieve all buffered BUs via the recommended link.

[0160] In one embodiment, a buffer status report (BSR) may be used to indicate that the AP MLD has pending buffered BUs for other STAs of the non-AP MLD, or to recommend another link on which other STAs of the non-AP MLD may retrieve buffered traffic. The BSR may be allowed to be sent by the AP of the AP MLD to the associated STAs of the non-AP MLD in the QoS Control subfield or the BSR A Control subfield of the downlink frame. When the buffered BUs begin to increase, the AP of the non-AP MLD may include the BSR in the QoS Control subfield or the BSR A Control subfield in the downlink frame that is sent to the associated STAs of the non-AP MLD in the awake state. The information in the BSR may correspond to the BUs addressed to the non-AP MLD. The non-AP MLD may determine whether it needs to transition other STAs attached to the non-AP MLD to the awake state or active mode.

[0161] In an embodiment, there may be a newly defined EHT action frame, which may be referred to as a buffer status report request (BSRR) frame. A non-AP MLD STA may send a BSRR frame to an associated non-AP MLD AP to request that a BSR be sent from the AP. In response to receiving the BSRR frame or at a later time, the AP may send a BSR to the non-AP MLD STA.

[0162] A bit in the MLD Capability and Operation subfield in the Basic Multilink Element sent from the AP MLD may indicate whether the APMLD supports transmission of BSRs to associated non-AP MLDs.

[0163] Fig.15 An example of a process 1500 for indicating buffered traffic in a separately addressed frame by an AP MLD is shown in accordance with an embodiment.

[0164] In operation 1501 , the AP of the AP MLD may initiate frame exchange with the STA of the non-AP MLD associated with the AP MLD in response to receiving a PS-Poll frame or a U-APSD trigger frame from the STA of the non-AP MLD.

[0165] In operation 1503, the AP of the AP MLD may determine whether a condition for sending an indication of pending buffered traffic or a link recommendation for the non-AP MLD via a separately addressed frame is met. For example, the AP of the AP MLD may determine i) whether there is pending buffered traffic for the non-AP MLD on another link, or ii) whether the AP MLD intends to recommend the non-AP MLD to use another link to retrieve the buffered traffic. Then, process 1500 proceeds to operation 1505.

[0166] In operation 1505 , the AP of the AP MLD may determine whether a condition for sending a BSS parameter change count is met. For example, the AP of the AP MLD may determine whether a critical update to the BSS of the AP MLD exists on another link. Then, the process 1500 proceeds to operation 1507 .

[0167] In operation 1507 , the AP of the AP MLD may include an indication of buffered traffic to be processed, a link recommendation, and / or a BSS parameter change count in a downlink frame based on the determinations in operations 1503 and 1505 . The process then proceeds to operation 1509 .

[0168] In operation 1509, the AP of the AP MLD may transmit a downlink frame including an indication of buffered traffic to be processed, a link recommendation, and / or a BSS parameter change count to the non-AP MLD.

[0169] In operation 1511, the AP MLD may receive a PS-Poll frame or a U-APSD trigger frame from another STA that is not the AP MLD. The PS-poll frame or the U-APSD trigger frame may be received via another link that corresponds to a link indicated by an indication of buffered traffic included in a downlink frame or recommended by a link recommendation. Then, the process proceeds to operation 1513.

[0170] In operation 1513, the AP MLD may send a buffered BU in response to a PS-Poll frame or a U-APSD trigger frame. The buffered BU may be sent via another link in operation 1511. Therefore, another AP of the AP MLD (rather than the AP in operation 1509) may send the buffered BU to another STA other than the AP MLD.

[0171] In operation 1515, the AP of the AP MLD may transmit a downlink frame with the More Data bit set to 0, and end the frame exchange when all buffered BUs are transmitted and exhausted.

[0172] Fig.16 An example of a process 1600 for receiving an indication of buffered traffic in an individually addressed frame by a non-AP MLD is shown in accordance with an embodiment.

[0173] In operation 1601, the STA of the non-AP MLD may transition from the doze state to the awake state, and may send a PS-Poll frame or a U-APSD trigger frame to retrieve the buffered service when the STA receives an indication of the buffered service to be processed from the TIM element in the beacon frame. Then, the STA of the non-AP MLD may initiate a frame exchange with the AP of the AP MLD. Then, the process proceeds to operation 1603.

[0174] In operation 1603, when the non-AP MLD receives an indication or link recommendation of pending buffered services for other STAs affiliated with the non-AP MLD, the indicated or recommended STA may wake up and may send PS-poll and U-APSD trigger frames to the corresponding AP of the AP MLD to retrieve the buffered services.

[0175] In operation 1605, when the non-AP MLD may receive a check beacon or BPCC having a value different from a value previously received for the current link, the STA of the non-AP MLD attempts to receive a next beacon frame on the current link.

[0176] In operation 1607, when the non-AP MLD may receive a QoS null frame or a downlink frame in which more data is set to 0, the receiving STA may transition to the doze state.

[0177] Unless otherwise specified, references to singular elements are not intended to mean one and only one, but rather one or more. For example, "a" module may refer to one or more modules. Without further limitation, an element preceded by "a", "an", "the" or "said" does not exclude the presence of additional identical elements.

[0178] Headings and subheadings, if any, are used for convenience only and do not limit the invention. The word "exemplary" is used to mean serving as an example or illustration. To the extent that the terms "including," "having," and the like are used, such terms are intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when used as a transitional word in the claims. Relational terms such as first and second, and the like may be used to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

[0179] Phrases such as on the one hand, this aspect, another aspect, some aspects, one or more aspects, an embodiment, this embodiment, another embodiment, some embodiments, one or more embodiments, an example, this example, an example, some examples, one or more examples, a configuration, this configuration, another configuration, some configurations, one or more configurations, subject technology, disclosure, the present disclosure, other variations thereof, etc. are for convenience and do not imply that the disclosure associated with such phrases is essential to the subject technology or that such disclosure applies to all configurations of the subject technology. The disclosure associated with such phrases may apply to all configurations or one or more configurations. The disclosure associated with such phrases may provide one or more examples. Phrases such as aspects or some aspects may refer to one or more aspects and vice versa, and this applies similarly to the other aforementioned phrases.

[0180] The phrase "at least one of," following a list of items, where the terms "and" or "or" are used to separate any one of the items, modifies the list as a whole, rather than each member of the list. The phrase "at least one of," does not require selection of at least one of the items; rather, the phrase allows for a meaning that includes at least one of any one item and / or at least one of any combination of items and / or at least one of each item. For example, each of the phrases "at least one of A, B, and C" or "at least one of A, B, or C" means only A, only B, or only C; any combination of A, B, and C; and / or at least one of each of A, B, and C.

[0181] It should be understood that the specific order or hierarchy of steps, operations or processes disclosed is an illustration of an exemplary method. Unless otherwise explicitly stated, it should be understood that the specific order or hierarchy of steps, operations or processes can be performed in a different order. Some of the steps, operations or processes can be performed simultaneously or as part of one or more other steps, operations or processes. The attached method claims (if any) present the elements of various steps, operations or processes in a sample order and are not meant to be limited to the specific order or hierarchy presented. These can be performed serially, linearly, in parallel, or in different orders. It should be understood that the instructions, operations, and systems described can generally be integrated together in a single software / hardware product or packaged into multiple software / hardware products.

[0182] The present disclosure is provided to enable any person skilled in the art to practice the various aspects described herein. In some instances, known structures and components are shown in block diagram form to avoid blurring the concept of the subject technology. The present disclosure provides various examples of the subject technology, and the subject technology is not limited to these examples. It will be apparent to those skilled in the art that various modifications to these aspects will be apparent, and the principles described herein can be applied to other aspects.

[0183] All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later become known to one of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims. In addition, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element should be interpreted under the provisions of .C. §112, sixth paragraph, unless the element is explicitly recited using the phrase "means for..." or, in the case of a method claim, the phrase "step for..." is used to recite the element.

[0184] The title, background technology, figure description, abstract, and drawings are incorporated into the present disclosure and are provided as illustrative examples of the present disclosure rather than as limiting descriptions. It should be understood that the submitted abstract will not be used to limit the scope or meaning of the claims. In addition, in the specific implementation, it can be seen that the description provides illustrative examples, and various features are grouped together in various implementations for the purpose of simplifying the present disclosure. The method of the present disclosure should not be interpreted as reflecting the intention that the claimed subject matter requires more features than the features explicitly stated in each claim. On the contrary, as reflected in the following claims, the inventive subject matter lies in less than all the features of a single disclosed configuration or operation. The attached claims are incorporated into the specific implementation, wherein each claim itself is a subject matter claimed separately.

[0185] The claims are not intended to be limited to the aspects described herein, but are to be given the full scope consistent with the language of the claims and to encompass all legal equivalents. Nevertheless, the claims are not intended to encompass subject matter that does not satisfy applicable patent law requirements, nor should they be interpreted in such a manner.

Claims

1. An access point (AP) multi-link device (MLD) associated with a wireless network, the AP MLD comprising: a first AP and one or more second APs attached to the AP MLD; as well as a processor coupled to the first AP and one or more second APs, the processor being configured to: performing individually addressed frame exchange between a first station (STA) attached to a non-AP MLD and the first AP attached to the AP MLD via a first link, wherein the first STA and one or more second STAs are attached to the non-AP MLD, sending a downlink frame to the first STA attached to the non-AP MLD via the first link, the downlink frame including an indication of the presence of buffered traffic to the non-AP MLD on one or more second links, or a link recommendation for the one or more second links to retrieve the buffered traffic, wherein each of the one or more second links is established between a second AP attached to the AP MLD and a corresponding second STA attached to the non-AP MLD, receiving, from a second STA attached to the non-AP MLD via a second link, a frame for requesting transmission of buffered traffic via the second link, and In response to the frame, buffered traffic is sent to the second STA attached to the non-AP MLD via the second link.

2. The AP MLD according to claim 1, wherein: A traffic identifier (TID) of the buffered traffic is not mapped to the first link, and the TID of the buffered traffic is mapped to the one or more second links.

3. The AP MLD according to claim 1 or 2, wherein: When the downlink frame is transmitted, the one or more second STAs attached to the non-AP MLD are in a doze state.

4. The AP MLD according to any one of the preceding claims, wherein: The indication of the presence of buffered traffic or the link recommendation for the one or more second links is included in a control field of the downlink frame.

5. The AP MLD according to any one of the preceding claims, wherein: The indication of the presence of buffered traffic or the link recommendation for the one or more second links is included in a buffer status report within a control field of the downlink frame.

6. A non-access point (AP) multi-link device (MLD) associated with a wireless network, the non-AP MLD comprising: a first STA and one or more second STAs attached to the non-AP MLD; as well as A processor coupled to the first STA and one or more second STAs, the processor being configured to: performing individually addressed frame exchange between a first AP attached to an AP MLD and the first STA attached to the non-AP MLD via a first link, wherein the first AP and one or more second APs are attached to the AP MLD, receiving a downlink frame from the first AP attached to the AP MLD via the first link, the downlink frame including an indication of the presence of buffered traffic to the non-AP MLD on one or more second links, or a link recommendation for the one or more second links to retrieve the buffered traffic, wherein each of the one or more second links is established between a second AP attached to the AP MLD and a corresponding second STA attached to the non-AP MLD, sending a frame requesting transmission of buffered services via the second link to a second AP attached to the AP MLD via the second link, and Buffered traffic is received from the second AP affiliated with the AP MLD via the second link.

7. The non-AP MLD according to claim 6, wherein: A traffic identifier (TID) of the buffered traffic is not mapped to the first link, and the TID of the buffered traffic is mapped to the one or more second links.

8. The non-AP MLD according to claim 6 or 7, wherein: When the downlink frame is transmitted, the one or more second STAs attached to the non-AP MLD are in a doze state, and The processor is further configured to coordinate the second STA to wake up and transition from the doze state to an awake state or an active state in response to receiving the downlink frame.

9. The non-AP MLD according to any one of claims 6 to 8, wherein: The indication of the presence of buffered traffic or the link recommendation for the one or more second links is included in a control field of the downlink frame.

10. The non-AP MLD according to any one of claims 6 to 9, wherein: The control field includes a bitmap for identifying the one or more second STAs and a field for identifying a purpose of the bitmap.

11. The non-AP MLD according to any one of claims 6 to 10, wherein: The indication of the presence of buffered traffic or the link recommendation for the one or more second links is included in a buffer status report within a control field of the downlink frame.

12. The non-AP MLD according to any one of claims 6 to 11, wherein: The processor is further configured to send, via the first link, a request to send the downlink frame including the buffer status report to the first AP attached to the AP MLD.

13. The non-AP MLD according to any one of claims 6 to 12, wherein: The downlink frame further includes information about an update of a basic service set (BSS) to which the AP MLD belongs, wherein the information about the update indicates that the non-AP MLD is required to check the update on at least a link between the AP MLD and the non-AP MLD.

14. The non-AP MLD according to any one of claims 6 to 13, wherein: The downlink frame further includes information indicating that there is no buffered traffic to the non-AP MLD on one or more second links or information indicating that it is recommended that one or more second links do not transition to an awake state.

15. The non-AP MLD according to any one of claims 6 to 14, wherein: When the non-AP MLD sends the indication of supporting reception of the indication of the presence of buffered traffic or the indication of the link recommendation, the indication of the presence of buffered traffic or the link recommendation for the one or more second links is included in the downlink frame.

Images