Resource request method, apparatus and system

Abstract

A resource request method, apparatus and system, capable of being applied to the technical field of communications. The present application can support IEEE protocols, such as IEEE 802.11be / WiFi 7 / EHT, IEEE 802.11bn / UHR / WiFi 8, IEEE 802.15 / UWB, and IEEE 802.11bf / sensing; and integrated millimeter wave (IMMW) protocols. The method comprises: a non-AP MLD sends an FT confirm frame to a target AP MLD by means of the current AP MLD, wherein the FT confirm frame may comprise an RIC request, the RIC request comprises a resource descriptor field, and the resource descriptor field may comprise an SCS descriptor element or a TWT element or a wake-up request element; and the target AP MLD may send an FT ACK frame to the non-AP MLD by means of the current AP MLD. The method can effectively reduce the roaming delay and improve the roaming efficiency.

Description

Resource request methods, devices and systems

[0001] This application claims priority to Chinese Patent Application No. 202410486936.3, filed on April 22, 2024, entitled “Resource Request Method, Apparatus and System”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to a resource request method, apparatus and system. Background Technology

[0003] In a roaming scenario, a non-AP multi-link device (non-AP MLD) can roam from its associated current AP MLD to the target AP MLD.

[0004] The existing Fast Basic Service Set (BSS) Transition (FT) protocol can support non-AP MLDs to negotiate uplink block acknowledgment sessions with the target AP MLD through the current AP MLD, and can also add quality of service (QoS) traffic.

[0005] However, existing resource request methods increase roaming latency and result in low roaming efficiency. Summary of the Invention

[0006] This application provides a resource request method, apparatus, and system that can effectively reduce roaming latency and improve roaming efficiency.

[0007] Firstly, embodiments of this application provide a resource request method, which can be applied to a non-AP multi-link device (non-AP MLD). The non-AP MLD can be a WLAN device, or a chip, functional module, or communication component disposed within the WLAN device. The resource request method includes:

[0008] The non-AP MLD sends a Fast Basic Service Set (BSS) Transition (FT) Confirmation frame to the current Access Point MLD (AP MLD). This FT Confirmation frame is used by the non-AP MLD to request resources from the target AP MLD. The FT Confirmation frame includes a Resource Information Container (RIC) Request, which includes a Resource Descriptor field. This Resource Descriptor field includes at least one of the following: a Stream Classification Service (SCS) Descriptor element, a Target Wake Time (TWT) element, or a Wake-up Request element. This Wake-up Request element is used to wake up the first AP belonging to the target AP MLD. The non-AP MLD receives an FT Acknowledgement (ACK) frame from the current AP MLD in response to the FT Confirmation frame.

[0009] In this embodiment of the application, by adding at least one of the following elements to the FT confirmation frame: SCS descriptor element, TWT element, or wake-up request element, roaming latency can be effectively reduced, roaming efficiency can be improved, and the roaming experience of non-AP MLD can be enhanced.

[0010] Secondly, embodiments of this application provide a resource request method, which can be applied to a target access point multi-link device (targetAP MLD). The target AP MLD can be a WLAN device, or a chip, functional module, or communication component disposed within the WLAN device. The resource request method includes:

[0011] The target AP MLD receives a remote request from the current AP MLD. This remote request is used by the non-AP MLD to request resources from the target AP MLD. The remote request includes a Resource Information Container (RIC) request, which includes a resource descriptor field. The resource descriptor field includes at least one of the following: an SCS descriptor element, a TWT element, or a wake-up request element. The wake-up request element is used to wake up the first AP belonging to the target AP MLD. The target AP MLD sends a remote response to the current AP MLD.

[0012] In this embodiment, the remote request can correspond to an FT acknowledgment frame, meaning the content of the remote request can be determined based on the FT acknowledgment frame. Similarly, the remote response can correspond to an FT ACK frame, meaning the content of the remote response can be determined based on the FT ACK frame.

[0013] Thirdly, embodiments of this application provide a resource request method, which can be applied to a current access point multi-link device (current AP MLD). The current AP MLD can be a WLAN device, or a chip, functional module, or communication component disposed within the WLAN device. The resource request method includes:

[0014] The current AP MLD receives a Fast Basic Service Set Transfer (FT) acknowledgment frame from a non-AP MLD. This FT acknowledgment frame is used by the non-AP MLD to request resources from the target AP MLD. The FT acknowledgment frame includes a Resource Information Container (RIC) request, which includes a Resource Descriptor field. This Resource Descriptor field includes at least one of the following: a Flow Classification Service (SCS) descriptor element, a Target Wake-up Time (TWT) element, or a Wake-up Request element. This Wake-up Request element is used to wake up the first AP belonging to the target AP MLD. The current AP MLD sends a remote request to the target AP MLD. This remote request is determined based on the FT acknowledgment frame (e.g., the remote request may include the aforementioned RIC request).

[0015] In conjunction with the third aspect, in one possible implementation, the current AP MLD receives a remote response from the target AP MLD and sends an FT ACK frame to the non-AP MLD, which is determined based on the remote response.

[0016] In conjunction with the first to third aspects, in one possible implementation, the wake-up request element includes wake-up indication information.

[0017] In conjunction with the first to third aspects, in one possible implementation, the wake-up indication information includes updated wake-up parameters corresponding to the first AP.

[0018] Alternatively, the wake-up indication information may include the updated wake-up parameters corresponding to the first AP.

[0019] In conjunction with the first to third aspects, in one possible implementation, the wake-up indication information includes the basic service set identifier (BSSID) or link identifier (linkID) of the first AP.

[0020] In this embodiment of the application, the wake-up indication information can clearly indicate the first AP to be woken up by including BSSID or link ID.

[0021] In conjunction with the first to third aspects, in one possible implementation, the wake-up indication information includes a link bitmap, where each bit in the link bitmap can correspond to a link, and each bit can be used to indicate whether to wake up the corresponding link.

[0022] In conjunction with the first to third aspects, in one possible implementation, the updated wake-up parameters include at least one of the following: the start time of the wake-up window, the duration of the wake-up window, or the time interval between adjacent wake-up windows; or, the updated wake-up parameters include the duration of the wake-up; or, the updated wake-up parameters include at least one of the following: the bandwidth of the first AP, the number of spatial streams of the first AP, and the modulation and coding scheme (MCS) of the first AP.

[0023] Generally, when the first AP is in power-saving mode, the throughput of non-AP MLDs roaming to the target AP MLD will decrease. Furthermore, if the first AP has the largest coverage area among the target AP MLDs, then when the first AP is in power-saving mode, non-AP MLDs may not be able to roam to the target AP MLD in a timely manner. Therefore, the updated wake-up parameters described above in this embodiment can avoid these situations and improve the roaming experience for non-AP MLDs.

[0024] In conjunction with the first to third aspects, in one possible implementation, the FT ACK frame includes a RIC data element (RDE) field, which includes a status code field used to indicate whether the non-AP MLD has successfully requested the resource.

[0025] In conjunction with the first to third aspects, in one possible implementation, the status code field is used to indicate to the non-AP MLD that the target AP MLD rejects the resource corresponding to the SCS descriptor element, and the FT ACK frame includes the SCS descriptor element proposed by the target AP MLD; or, the status code field is used to indicate to the non-AP MLD that the target AP MLD rejects the resource corresponding to the TWT element, and the FT ACK frame includes the TWT element proposed by the target AP MLD; or, the status code field is used to indicate to the non-AP MLD that the target AP MLD rejects the resource corresponding to the wake-up request element, and the FT ACK frame includes the wake-up request element proposed by the target AP MLD.

[0026] In conjunction with the first to third aspects, in one possible implementation, the resource descriptor resource further includes an RIC descriptor element, which includes a resource type field; wherein, when the resource type field is a first value, the RIC descriptor element further includes: a BA parameter set, a BA timeout value, a BA start sequence control, and a parameter set for adding block acknowledgment ADDBA extension; or, when the resource type field is a second value, the RIC descriptor element further includes: a BA parameter set, a BA timeout value, and a parameter set for adding block acknowledgment ADDBA extension.

[0027] In this embodiment, a new resource request is added to the FT confirmation frame. The resource type of this new resource request can be an enhanced block confirmation parameter, and the new resource type can be used for HE dynamic fragmentation. This avoids the delay introduced by parameter negotiation after roaming and effectively reduces roaming latency.

[0028] In this embodiment, a new resource type is added to the FT confirmation frame. This new resource request can be an enhanced block confirmation parameter transfer, and the added resource type can be used for block confirmation parameter negotiation in context transition scenarios. Therefore, in context transition scenarios, either the non-AP MLD or the target AP MLD can update block confirmation parameters other than the initial SN, allowing the target AP MLD and the non-AP MLD to establish a suitable block confirmation session protocol based on their own capabilities.

[0029] The content carried in the FT acknowledgment frame can also be carried in the reassociation request frame. Similarly, the content carried in the FT ACK frame can also be carried in the reassociation response frame.

[0030] Fourthly, embodiments of this application provide a resource request method, which can be applied to a non-AP MLD, where the non-AP MLD can be a WLAN device, or a chip, functional module, or communication component disposed within the WLAN device. The resource request method includes:

[0031] The non-AP MLD receives an FT response frame from the current AP MLD. This FT response frame includes downlink block acknowledgment (BA) information, which is used to request the establishment of a downlink block acknowledgment session between the target AP MLD and the non-AP MLD. The non-AP MLD then sends an FT acknowledgment frame to the current AP MLD.

[0032] Alternatively, the non-AP MLD receives an FT acknowledgment frame from the current AP MLD, which includes downlink block acknowledgment (BA) information. This downlink BA information is used to request the establishment of a downlink block acknowledgment session between the target AP MLD and the non-AP MLD. The non-AP MLD then sends an FTACK frame to the current AP MLD.

[0033] In this embodiment, negotiation of downlink block acknowledgment session parameters between the non-AP MLD and the target AP MLD is supported. This effectively reduces roaming latency and improves roaming efficiency.

[0034] Fifthly, embodiments of this application provide a resource request method, which can be applied to a target AP MLD, which may be a WLAN device, or a chip, functional module, or communication component disposed within the WLAN device. The resource request method includes:

[0035] The target access point multi-link device (AP MLD) sends a remote request to the current AP MLD. This remote request includes downlink block acknowledgment (BA) information, which is used to request the establishment of a downlink block acknowledgment session between the target AP MLD and the non-AP MLD. The target AP MLD receives the remote response from the current AP MLD.

[0036] In conjunction with the fifth aspect, in one possible implementation, the remote request includes downlink BA information, including:

[0037] The remote request includes an FT response frame that includes the downlink BA information; or, the remote request includes an FT acknowledgment frame that includes the downlink BA information.

[0038] Sixthly, embodiments of this application provide a resource request method, which can be applied to a current access point multi-link device (current AP MLD). The current AP MLD can be a WLAN device, or a chip, functional module, or communication component disposed within the WLAN device. The resource request method includes:

[0039] The current AP MLD receives a remote request from the target AP MLD, which includes downlink BA information;

[0040] The current AP MLD sends an FT response frame (or FT acknowledgment frame) to the non-AP MLD, which is determined based on the remote request.

[0041] In conjunction with the sixth aspect, in one possible implementation, the current AP MLD can also receive FT acknowledgment frames (or FT ACK frames) from a non-AP MLD, and send a remote response to the target AP MLD.

[0042] In conjunction with aspects four through six, in one possible implementation, the downlink BA information includes: BA parameter set, BA timeout value, BA start sequence control, and ADDBA extension.

[0043] In conjunction with aspects four through six, in one possible implementation, the FT response frame further includes a fast basic service set transition element (FTE) that includes message integrity codes (MIC) used to verify the FT response frame; or, the FT acknowledgment frame further includes an FTE that includes a MIC used to verify the FT acknowledgment frame.

[0044] Seventhly, embodiments of this application provide a resource request method, which can be applied to a non-AP multi-link device (non-AP MLD). The non-AP MLD can be a WLAN device, or a chip, functional module, or communication component disposed within the WLAN device. The resource request method includes:

[0045] Before the non-AP MLD sends a reassociation request frame, the non-AP MLD sends a data forwarding indication message to the current AP MLD. This data forwarding indication message is used to instruct the current AP MLD to perform a downlink TID for data forwarding.

[0046] Alternatively, the data forwarding indication information can be used to instruct the current AP MLD to transfer the downlink TID data to the target AP MLD.

[0047] In conjunction with the seventh aspect, in one possible implementation, the current AP MLD and the target AP MLD have the same QoS configuration policy.

[0048] In conjunction with the seventh aspect, in one possible implementation, the data forwarding indication information includes the MLD address information or buffer size of the target AP MLD, which is used to indicate to the current AP MLD the maximum number of MSDUs cached by the target AP MLD.

[0049] Eighthly, embodiments of this application provide a communication device for performing the methods of any one of the first to seventh aspects or any possible implementation thereof. The communication device includes a module having the capability to perform the methods of any one of the first to seventh aspects or any possible implementation thereof.

[0050] Ninthly, embodiments of this application provide a communication device including a processor for executing the methods shown in any one of the first to seventh aspects or any possible implementations thereof. The processor executes a program stored in a memory, and when the program is executed, the methods shown in any one of the first to seventh aspects or any possible implementations thereof are executed.

[0051] In one possible implementation, the memory is located outside the aforementioned communication device.

[0052] In one possible implementation, the memory is located within the aforementioned communication device.

[0053] In this embodiment, the processor and memory can also be integrated into a single device, that is, the processor and memory can be integrated together. For example, the communication device can be a chip.

[0054] In one possible implementation, the communication device further includes a transceiver for receiving or sending information.

[0055] In a tenth aspect, embodiments of this application provide a communication device including a logic circuit and an interface, wherein the logic circuit and the interface are coupled; the interface is used for inputting and / or outputting information, and the logic circuit is used for performing the method described in any one of the first to seventh aspects or any possible implementation thereof.

[0056] Eleventhly, embodiments of this application provide a computer-readable storage medium for storing a computer program that, when run on a computer, causes the methods shown in any of the first to seventh aspects or any possible implementation thereof to be executed.

[0057] In a twelfth aspect, embodiments of this application provide a computer program product that, when run on a computer, causes the methods shown in any of the first to seventh aspects or any possible implementations above to be executed.

[0058] In a thirteenth aspect, embodiments of this application provide a communication system comprising a non-AP MLD and a target AP MLD. The non-AP MLD is used to perform the method shown in the first aspect or any possible implementation of the first aspect (or the fourth aspect) described above, and the non-AP MLD is used to perform the method shown in the second aspect or any possible implementation of the second aspect (or the fifth aspect) described above.

[0059] As one possible implementation, the communication system also includes a current AP MLD, which is used to perform the methods shown in any possible implementation of the third aspect or the sixth aspect described above. Attached Figure Description

[0060] Figure 1a is a schematic diagram of an architecture of a communication system provided in an embodiment of this application;

[0061] Figure 1b is a schematic diagram of another architecture of the communication system provided in an embodiment of this application;

[0062] Figure 2 is a schematic diagram of the address of MLD provided in an embodiment of this application;

[0063] Figure 3 is a schematic diagram of the system architecture in a roaming scenario provided in an embodiment of this application;

[0064] Figure 4 is a schematic diagram of the BA session establishment process provided in an embodiment of this application;

[0065] Figure 5a is a schematic diagram of the frame format of the ADDBA request frame / ADDBA response frame provided in the embodiments of this application;

[0066] Figure 5b is a schematic diagram of the format of the BA parameter set field provided in an embodiment of this application;

[0067] Figure 5c is a schematic diagram of the format of the ADDBA extended field provided in the embodiment of this application;

[0068] Figure 6a is a schematic diagram of the frame format of the FT request frame provided in an embodiment of this application;

[0069] Figure 6b is a schematic diagram of the format of the fast BSS transition element (FTE) provided in the embodiment of this application;

[0070] Figure 6c is a schematic diagram of the MDE format provided in an embodiment of this application;

[0071] Figure 7 is a schematic diagram of the frame format of the FT response frame provided in an embodiment of this application;

[0072] Figure 8 is a schematic diagram of the frame format of the FT confirmation frame provided in an embodiment of this application;

[0073] Figure 9 is a schematic diagram of the frame format of the FT ACK frame provided in an embodiment of this application;

[0074] Figure 10 is a schematic diagram of the RIC request / RIC response format provided in the embodiments of this application;

[0075] Figure 11 is a flowchart illustrating a resource request method provided in an embodiment of this application;

[0076] Figure 12a is a schematic diagram of a frame format provided in an embodiment of this application;

[0077] Figure 12b is a schematic diagram of state transitions provided in an embodiment of this application;

[0078] Figure 13 is a schematic diagram of a communication device provided in an embodiment of this application;

[0079] Figure 14 is a schematic diagram of another structure of the communication device provided in an embodiment of this application;

[0080] Figure 15 is a schematic diagram of another structure of the communication device provided in the embodiments of this application. Detailed Implementation

[0081] To facilitate understanding of the technical solution of this application, the application will be further described below with reference to the accompanying drawings.

[0082] The terms "first" and "second," etc., used in the specification, claims, and drawings of this application are used only to distinguish different objects and not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0083] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0084] In this application, "at least one (item)" refers to one or more, "more than one" refers to two or more, "at least two (items)" refers to two or three or more, and "and / or" is used to describe the relationship between related objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. "Or" indicates that there can be two relationships, such as only A exists or only B exists; when A and B are not mutually exclusive, it can also mean that there are three relationships, such as only A exists, only B exists, or both A and B exist simultaneously. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items. For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c".

[0085] In this application, "send" and "receive" indicate the direction of signal transmission. For example, "send information to XX" can be understood as the destination of the information being XX, which can include direct transmission via the air interface or indirect transmission via the air interface from other units or modules. "Receive information from YY" can be understood as the source of the information being YY, which can include direct reception from YY via the air interface or indirect reception from YY via the air interface from other units or modules. "Send" can also be understood as the "output" of a chip interface, and "receive" can also be understood as the "input" of a chip interface. In other words, sending and receiving can occur between devices, such as between network devices and terminal devices, or within a device, such as between components, modules, chips, software modules, or hardware modules within the device via buses, traces, or interfaces.

[0086] This application provides a resource request method, apparatus, and system that can effectively reduce roaming latency, improve roaming efficiency, and enhance the user experience during roaming.

[0087] The following describes the system involved in the embodiments of this application.

[0088] The technical solutions provided in this application can be applied to wireless local area network (WLAN) systems, such as Wi-Fi. For example, the technical solutions provided in this application can be applied to the IEEE 802.11 series of protocols (or standards), such as the 802.11be protocol, the 802.11bn protocol (or Wi-Fi 8, also known as ultra-high reliability (UHR) or ultra-high reliability and throughput (UHRT)), or next-generation protocols of the 802.11bn protocol, or protocols supporting ambient power (AMP), etc., and will not be listed exhaustively. The technical solutions provided in this application can also be applied to wireless personal area networks (WPANs) based on integrated millimeter wave (IMMW) and ultra-wideband (UWB) technologies. The technical solutions provided in the embodiments of this application can be applied to the IEEE 802.15 series protocols, such as the 802.15.4a, 802.15.4z, or 802.15.4ab protocols, or future UWB WPAN protocols, etc., and will not be listed one by one. The technical solutions provided in the embodiments of this application can also be applied to the Spark Link or NearLink standard protocol. The technical solutions provided in the embodiments of this application can also be applied to the following communication systems, such as Internet of Things (IoT) systems, vehicle-to-everything (V2X, where X can represent anything), device-to-device (D2D), narrowband Internet of Things (NB-IoT) systems, long term evolution (LTE) systems, 5th generation (5G) communication systems, and new communication systems that will emerge in the future development of communication, etc. For example, V2X can include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), or vehicle-to-network (V2N) communication.

[0089] WLAN systems can provide high-speed, low-latency transmission. As WLAN application scenarios continue to evolve, WLAN systems will be applied to more scenarios or industries, such as the Internet of Things industry, the Internet of Vehicles industry, the banking industry, enterprise offices, stadiums and exhibition halls, concert halls, hotel rooms, dormitories, hospital wards, classrooms, shopping malls, squares, streets, production workshops and warehouses, etc. Of course, devices that support WLAN communication or sensing (such as access points or sites) can be sensor nodes in smart cities (such as smart water meters, smart electricity meters, and smart air monitoring nodes), smart devices in smart homes (such as smart cameras, projectors, displays, televisions, speakers, refrigerators, and washing machines), nodes in the Internet of Things (IoT), entertainment terminals (such as wearable devices for augmented reality (AR) and virtual reality (VR), smart devices in smart offices (such as printers, projectors, loudspeakers, and speakers), vehicle-to-everything (V2X) devices, infrastructure in daily life scenarios (such as vending machines, self-service navigation kiosks in supermarkets, self-service checkout machines, and self-service ordering machines), and equipment in large sports and music venues.

[0090] Although the embodiments of this application primarily use WLAN as an example, especially networks applied to the IEEE 802.11 series of standards, the various aspects involved in the embodiments of this application can be extended to other networks employing various standards or protocols. For example, Bluetooth, high-performance radio LAN (HIPERLAN) (a wireless standard similar to the IEEE 802.11 standard), and wide area networks (WANs) or other networks now known or to be developed in the future.

[0091] The method provided in this application embodiment can be implemented by a communication device in a communication system. For example, the communication device can be an access point (AP), a station (STA), or a multi-link device. The following is a detailed description:

[0092] An Access Point (AP) is a device with wireless communication capabilities that supports communication, sensing, or power transmission using WLAN protocols. It has the function of communicating or sensing with other devices in a WLAN network (such as non-access point stations (non-AP STAs) or other access points), and can also communicate, sense, or transmit power with other devices. Alternatively, an access point acts as a bridge connecting wired and wireless networks, primarily connecting various wireless network clients together and then connecting the wireless network to an Ethernet network. In a WLAN system, an access point can be called an Access Point Station (AP STA). The aforementioned device can be a complete unit or a chip, processing system, or functional module installed within a complete unit. Devices with these chips, processing systems, or functional modules can implement the methods and functions of the embodiments described in this application under the control of the chips, processing systems, or functional modules. The AP in the embodiments of this application is a device that provides services to non-AP STAs and can support 802.11 series protocols or subsequent protocols. For example, an access point can be an access point for a terminal (such as a mobile phone) to enter a wired (or wireless) network, mainly deployed in homes, buildings, and parks, with a typical coverage radius of tens to hundreds of meters. Of course, it can also be deployed outdoors. Another example is that an AP can be a communication server, router, switch, bridge, or other communication entity; an AP can include various forms of macro base stations, micro base stations, repeaters, etc. Of course, an AP can also be a chip, processing system, or module in the above-mentioned devices, thereby implementing the methods and functions of the embodiments of this application. The description of APs herein also applies to the AP multi-link device (AP MLD) shown below.

[0093] A Station-Style (STA) is a device with wireless communication capabilities that supports communication, sensing, or power transmission using the WLAN protocol. It has the ability to communicate, sense, or transmit power with other non-AP STAs or access points in a WLAN network. In a WLAN system, a station can be called a non-access point station (non-AP STA). For example, an STA is any user communication device that allows a user to communicate with an AP (Access Point) or sense or transmit power, thereby communicating with the WLAN. The aforementioned device can be a complete unit, or it can be a chip, processing system, or functional module installed within a complete unit. Devices with these chips, processing systems, or functional modules can implement the methods and functions of the embodiments of this application under the control of the chips, processing systems, or functional modules. For example, an STA can be a wireless communication chip, a wireless sensor, or a wireless communication terminal, and can also be referred to as a user. Furthermore, an STA can be a mobile phone supporting Wi-Fi communication, a tablet computer supporting Wi-Fi communication, a set-top box supporting Wi-Fi communication, a smart TV supporting Wi-Fi communication, a smart wearable device supporting Wi-Fi communication, an in-vehicle communication device supporting Wi-Fi communication, and a computer supporting Wi-Fi communication. Of course, the STA can also be a chip, processing system, or module in the various types of devices described above, thereby implementing the methods and functions of the embodiments of this application. The description of the STA herein also applies to the non-AP multi-link device (non-AP MLD) shown below.

[0094] The multi-link device in this application embodiment can be a device with a single RF module (such as an AP or a non-AP STA) or a device with multiple RF modules. This application embodiment does not limit the number of RF modules included in the multi-link device. The non-AP MLD shown below in this application can include a device with multiple RF modules or a device with a single RF module (STA). The AP MLD can include a device with multiple RF modules or a device with a single RF module (such as an AP).

[0095] For example, a multi-link device (MLD) refers to a device that simultaneously has multiple radio frequency modules, each operating on different frequency bands or channels. When the channel spacing between two radio frequency modules within a multi-link device is sufficiently large, they can operate independently without interfering with each other. If any two radio frequency modules support simultaneous transmission on one link and reception on the other, then the two links can be said to support simultaneous transmitting and receiving (STR) capability; otherwise, they are said to lack simultaneous transmitting and receiving (NSTR) capability. A multi-link device includes multiple affiliated sites, which can be physical or logical sites. Each site can operate on one link, one frequency band, or one channel, etc. The affiliated site shown here can be an AP or a non-AP STA. For ease of description, this application embodiment may refer to a multi-link device with an AP as its affiliated site as a multi-link AP, a multi-link AP device, or an AP multi-link device (AP MLD). A multi-link device belonging to a non-AP STA is called a multi-link STA, a multi-link STA device, or a STA multi-link device (STA MLD). Alternatively, a multi-link device belonging to a non-AP STA is called a multi-link non-AP, a multi-link non-AP device, or a non-AP multi-link device (non-AP MLD). A multi-link device (which can be either a non-AP MLD or an AP MLD) is a communication device with wireless communication capabilities. This communication device can be a complete device, or it can be a chip, processing system, or functional module installed in a complete device. These chips, processing systems, or functional modules can implement the methods or functions of the embodiments of this application.

[0096] MLD can implement wireless communication by following the 802.11 series of protocols, such as Extremely High Throughput (EHT), 802.11be, or 802.11bn, thereby enabling communication with other devices. These other devices may or may not be multi-link devices.

[0097] Figure 1a is a schematic diagram of an architecture of a communication system provided in an embodiment of this application. As shown in Figure 1a, the AP MLD includes AP1, AP2, ..., APn, and the non-AP MLD includes STA1 (i.e., non-AP STA 1), STA2, ..., STAN. Here, n is a positive integer, which can be greater than or equal to 1. The AP MLD and the non-AP MLD can communicate in parallel using link 1, link 2, ..., link n. STA1 in the non-AP MLD establishes an association with AP1 in the AP MLD, STA2 in the non-AP MLD establishes an association with AP2 in the AP MLD, STAN in the non-AP MLD establishes an association with APn in the AP MLD, and so on. Thus, after one or more non-AP STAs in the non-AP MLD establish an association with one or more APs in the AP MLD, they can communicate or perform sensing, etc. The frequency bands in which the multi-link devices (including AP MLD and non-AP MLD) operate can include, but are not limited to: sub 1GHz, 2.4GHz, 5GHz, 6GHz, and high frequency 60GHz, etc. As standards evolve, multi-link devices can also support other frequency bands, and the embodiments in this application are not limited to this.

[0098] Figure 1b is a schematic diagram of another architecture of the communication system provided in an embodiment of this application. The 802.11 standard focuses on the 802.11 physical layer (PHY) and medium access control (MAC) layer in multi-link devices, so Figure 1b exemplarily shows the PHY and MAC layers.

[0099] As shown in Figure 1b, a multi-link device (such as a multi-link AP or a multi-link non-AP) may include a PHY layer (PHY#1 and PHY#2 as shown in Figure 1b) and a MAC layer. The physical layer can be used to process physical layer signals, and the MAC layer can be used to process MAC layer signals. Further, the MAC layer can be divided into a high-MAC layer (high MAC as shown in Figure 1b) and multiple low-MAC layers (low MAC#1 and low MAC#2 as shown in Figure 1b). As shown in Figure 1b, the multiple APs included in a multi-link AP are independent of each other in the low-MAC layer and PHY layer, but share the high-MAC layer. The multiple STAs included in a multi-link non-AP are independent of each other in the low-MAC layer and PHY layer, but share the high-MAC layer. The high-MAC layer is connected to multiple low-MAC layers respectively, and the high-MAC layer can be shared by multiple links. For example, the high-MAC layer mainly completes the allocation of the sequence number (SN) and packet number (PN) of the MAC service data unit (MSDU), as well as encryption and decryption operations. For example, the lower MAC layer mainly performs operations such as assembling MAC protocol data units (MPDUs) for their respective links, channel access, packet transmission, and reception acknowledgment. The functions implemented by the higher or lower MAC layers shown here are merely examples and should not be construed as limiting the embodiments of this application.

[0100] In Figure 1b, the PHY#1 layer, low MAC#1 layer, and high MAC layer in a multi-link AP can be considered as AP#1, and the PHY#2 layer, low MAC#2 layer, and high MAC layer can be considered as AP#2. This means a multi-link AP can include two AP entities. The situation is similar in a multi-link non-AP; the high MAC layer is also shared by multiple links. The PHY#1 layer, low MAC#1 layer, and high MAC layer are considered as STA#1 (or non-AP STA#1), and the PHY#2 layer, low MAC#2 layer, and high MAC layer are considered as STA#2 (or non-AP STA#2). This means a multi-link non-AP includes two STA entities (i.e., two non-AP STA entities). As shown in Figure 1b, the PHY#1 of AP#1 in a multi-link AP and the PHY#1 of STA#1 in a multi-link non-AP operate on the same channel. For example, AP#1 in a multi-link AP and STA#1 in a multi-link non-AP communicate through a link (link #1 as shown in Figure 1b). In a multi-link AP, the PHY#2 of AP#2 and the PHY#2 of STA#2 in a multi-link non-AP operate on the same channel. For example, AP#2 in a multi-link AP and STA#2 in a multi-link non-AP communicate through a link (link #2 as shown in Figure 1b).

[0101] For example, either the high MAC layer or the low MAC layer can be implemented by a processor in the chip system of the multi-link device, or they can be implemented by different software processing modules in a single chip system, etc., which will not be listed here. Figure 1b can be a division of functional modules in the multi-link device. The modules shown in Figure 1b can be implemented in hardware or software. The PHY and MAC layers shown in Figure 1b can be understood as a division of logical functions. In actual implementation, there can be other division methods, which are not limited in this application. Figure 1b shows an example of a multi-link device including two stations. In specific implementations, a multi-link device can also include more or fewer stations, which will not be listed here.

[0102] Figure 2 is a schematic diagram of the MLD address provided in an embodiment of this application. As shown in Figure 2, for a multi-link device, each link in each multi-link device can correspond to a link address, such as link address 1 and link address 2 in Figure 2. That is, each link in each MLD can have its own MAC address. The multi-link device can also correspond to an MLD MAC address. Taking the architecture shown in Figure 1b as an example, the high MAC layer can be identified by the MLD MAC address corresponding to the MLD, and the low MAC layer can be identified by the MAC address corresponding to the link. For example, low MAC#1 and low MAC#2 can correspond to the MAC addresses of their respective links. The MLD MAC address can also be called the high MAC layer address of the MLD, and the link address can also be called the low MAC layer address of the MLD.

[0103] Figure 3 is a schematic diagram of the system architecture in a roaming scenario provided by an embodiment of this application. This system architecture may include at least two AP MLDs and at least one non-AP MLD. Figure 3 exemplarily illustrates two AP MLDs, such as AP MLD 1 and AP MLD 2, and one non-AP MLD. In a roaming scenario, the non-AP MLD can roam from AP MLD 1 to AP MLD 2. The roaming shown in this application can also be replaced by handover or movement; that is, roaming, handover, or movement can be interchanged.

[0104] In Figure 3, a non-AP MLD can roam from AP MLD 1 to AP MLD 2. Therefore, as a possible implementation, AP MLD 1 can also be called the current AP MLD, the source AP MLD, or the old AP MLD, and AP MLD 2 can also be called the target AP MLD or the new AP MLD. The non-AP MLD can also be called the fast transition originator (FTO). The specific names of the non-AP MLD, AP MLD 1, and AP MLD 2 are not limited in this embodiment. For ease of description, the current AP MLD and the target AP MLD will be used in the following description.

[0105] In roaming scenarios, different MLDs can perform at least one of the following operations: a non-AP MLD can negotiate a new key with the target AP MLD; a non-AP MLD can negotiate resources with the target AP MLD; a non-AP MLD can re-associate with the target AP MLD; and the target AP MLD and the current AP MLD can perform a context transfer. Of course, the steps performed by different MLDs in roaming scenarios are not limited to these. For specific methods in roaming scenarios, please refer to Figure 11 below, which will not be detailed here.

[0106] Before introducing the methods provided in the embodiments of this application, the terms or nouns involved in the embodiments of this application will be introduced below.

[0107] 1. Distributed System (DS)

[0108] A DS (Distributed Service Set) system can be used to interconnect multiple basic service sets (BSSs) and integrate local area networks (LANs) to create an extended service set (ESS). A DS system can deliver downlink data from a non-AP MLD (or STA) to the AP MLD (or AP) associated with that non-AP MLD; similarly, an AP can deliver uplink data from a non-AP MLD (or STA) to the network via DS for transmission.

[0109] 2. Reassociation request frame and reassociation response frame

[0110] A non-AP MLD can request reassociation with an AP MLD via a reassociation request frame. This reassociation request frame can be used by the non-AP MLD to request link establishment and activate DS service based on STA-to-AP mapping information. A reassociation response frame can be used to respond to the reassociation request frame. For example, in a roaming scenario, the non-AP MLD can send a reassociation request frame to the target AP MLD to request reassociation. The target AP MLD can then send a reassociation response frame to indicate the result of the non-AP MLD's reassociation request.

[0111] For example, the formats of the reassociation request frame and the reassociation response frame can be as follows:

[0112] Table 1. Frame format of reassociation request frames.

[0113] Table 2 Frame format of reassociative response frames

[0114] The reassociation request frames shown in Table 1 and the reassociation response frames shown in Table 2 are only examples. As the standard progresses, the format of the reassociation request frames or reassociation response frames may be updated in the future. Therefore, the format of the reassociation request frames and reassociation response frames shown in the embodiments of this application is not limited to Table 1 and Table 2.

[0115] 3. Primitives of the DS system

[0116] The 802.11 standard currently defines the Distributed System-Site-Notification Request (DS-STA-NOTIFY.request) primitive, which APs can use to update the STA-to-AP mapping information of the DS.

[0117] By sending this primitive, the AP can change the data path between the STA and DS it indicates, or the data path between the non-AP MLD and the DS. The DS can then submit the MSDU sent to the STA or non-AP MLD to the currently associated AP or AP MLD. The DS-STA-NOTIFY.request primitive mainly includes the MAC address of the corresponding STA or non-AP MLD and the update type. For example, the update type defined by this primitive can include: Add (ADD) (corresponding to the initial association operation), Move (MOVE) (corresponding to the re-association operation), and Delete (DELETE) (corresponding to the deassociation operation).

[0118] The following example illustrates the format of the above primitives.

[0119] DS-STA-NOTIFY.request(

[0120] STA address

[0121] Update type

[0122] )

[0123] Table 3 provides an example of the definitions for STA addresses and update types.

[0124] Table 3 Primitives

[0125] The above description of update types is merely an example and should not be construed as limiting the embodiments of this application.

[0126] 4. Block Acknowledgment (BA) Session Establishment

[0127] Figure 4 is a schematic diagram of the BA session establishment process provided in an embodiment of this application. In a multi-link scenario, the two communicating parties can establish a block acknowledgment session. For example, before using multi-link aggregation transmission, the two communicating parties can establish a block acknowledgment session.

[0128] As shown in Figure 4, the initiating end can send an AddBlock ACK (ADDBA) request frame, which the responding end receives. The responding end can send an ADDBA response frame, which the initiating end receives. After establishing a BA session through the ADDBA request and response frames, the initiating end can send a data packet and a Block ACK (BAR) request frame (i.e., a BA request frame). Upon receiving this data packet and BA request frame, the responding end can send a Block ACK (BA). Either the initiating or responding end can terminate the BA session for the corresponding TID by sending a Delete BA (DELBA) frame. That is, for one or more TIDs, either the initiating or responding end can delete the BA session by sending a DELBA frame.

[0129] A Business Provider (BA) session established between the initiating and responding endpoints can have a specific traffic identifier (TID). The TID can be used for unidirectional data transmission from the initiating to the responding endpoint. For example, for downlink data transmission, the AP (Access Point) can initiate the BA session establishment process as the initiating endpoint. For uplink data transmission, a non-AP STA (Standard Operating System) can initiate the BA session establishment process as the initiating endpoint.

[0130] For example, a downlink sender block acknowledgment session may include, but is not limited to, at least one of the following parameters:

[0131] The following parameters are specified: TID, sequence number (SN) assigned to each MSDU, block acknowledgment policy, whether MSDU aggregation is allowed, whether fragmentation is allowed, whether HE fragmentation operation is supported, window start position of the transmit buffer (e.g., WinStart_O), window size of the transmit buffer (e.g., WinSize_O), transmission success or failure status of each MPDU within the window, and number of retransmissions.

[0132] For example, a downlink receiver block acknowledgment session includes, but is not limited to, at least one of the following parameters:

[0133] TID, block acknowledgment policy, whether MSDU aggregation is allowed, whether fragmentation is allowed, whether HE fragmentation operation is supported, bit map of the receiver's scoring board, starting position of the scoring board window (e.g., denoted as WinStart_R), window size of the scoring board (e.g., denoted as WinSize_R), starting position of the receive reordering buffer window (e.g., denoted as WinStart_B) and window size (e.g., denoted as WinSize_B).

[0134] The bitmap of the scoring board can be used to record which MSDUs were successfully received. The receive reordering buffer can be used to buffer the received MSDUs. Generally speaking, the MAC layer needs to deliver the received MSDUs to the logical link control (LLC) layer in order. If an MSDU is not successfully received, then other MSDUs following that MSDU, even if they are successfully received, cannot be successfully delivered to the LLC layer.

[0135] Figure 5a is a schematic diagram of the frame format of the ADDBA request frame / ADDBA response frame provided in the embodiments of this application.

[0136] As shown in Figure 5a, an ADDBA request frame / ADDBA response frame may include at least one of the following: frame control, duration (or duration), address 1, address 2, address 3, sequence control, HT control, framebody, or framecheck sequence (FCS). The frame format or the order of the fields shown in Figure 5a are merely examples and should not be construed as limiting the embodiments of this application.

[0137] Table 4 exemplarily illustrates the main fields included in the frame body of an ADDBA request frame. However, the embodiments of this application are not limited to this for the frame body of an ADDBA request frame.

[0138] Table 4 Frame Body of ADDBA Request Frame

[0139] Table 5 exemplarily illustrates the main fields included in the frame body of an ADDBA response frame. However, the embodiments of this application are not limited to this for the frame body of an ADDBA response frame.

[0140] Table 5 Frame body of ADDBA response frame

[0141] For detailed explanations of the frame bodies shown in Tables 4 and 5, please refer to the 802.11 standard, etc., which will not be elaborated here.

[0142] Figure 5b is a schematic diagram of the format of the BA parameter set fields provided in an embodiment of this application. As shown in Figure 5b, the BA parameter set fields may include at least one of the following: aggregated-MSDU (A-MSDU supported), block acknowledgment policy (BA policy), TID, or buffer size. The A-MSDU support field can be used to indicate whether aggregated MSDUs are supported. The BA policy field can be used to indicate the BA policy. The TID can be used to indicate the TID corresponding to the established BA session. The buffer size field can be used to indicate the size of the receive buffer.

[0143] Figure 5c is a schematic diagram of the format of the ADDBA extended field provided in an embodiment of this application. As shown in Figure 5c, the ADDBA extended field may include an element ID, a length, or an ADDBA extended parameter set. The ADDBA extended parameter set field may include at least one of the following: no-fragmentation, HE fragmentation operation, or extended buffer size. The no-fragmentation field can be used to indicate whether non-HE initiating / responding ends allow / support fragmentation. The HE fragmentation operation field can be used to indicate the level of dynamic HE fragmentation. The extended buffer size field can be used to extend the length of the buffer size field in the BA parameter set field.

[0144] The formats of the fields shown above are merely examples, and the embodiments of this application are not limited to these formats.

[0145] 5. Fast Basic Service Set Transition (FT) Action Frame

[0146] FT action frames can include FT request frames, FT response frames, FT confirm frames, and FT ACK frames. For example, FT request and FT response frames can be used to negotiate a new pairwise transient key (PTK) security association (PTKSA). FT confirm and FT ACK frames can be used to negotiate resource requests. FT confirm frames can be used by a non-AP MLD to request resources, or in other words, the FT confirm frame can be used by a non-AP MLD to request resources from a target AP MLD. FT ACK frames are used in response to FT confirm frames.

[0147] The FT action frames shown in the embodiments of this application are merely examples. As the standard progresses, other frames with similar functions may appear in the future. Therefore, the embodiments of this application do not limit the scope of these frames.

[0148] Table 6 provides an example of the values ​​for the FT Action field.

[0149] Table 6. FT Action Field Values

[0150] The correspondence between the values ​​and descriptions of the FT action fields shown in Table 6 is only an example. As the standard progresses, the values ​​of the FT action fields corresponding to the FT action frames may be updated in the future. This application embodiment does not limit this.

[0151] Figure 6a is a schematic diagram of the frame format of an FT request frame provided in an embodiment of this application. As shown in Figure 6a, the FT request frame may include at least one of the following: category, FT action, STA address, target AP address, or FT request framebody. Explanations of each field can be found in relevant standards or protocols, and will not be detailed here.

[0152] Table 7 provides an example of the main contents of the frame body of an FT request frame.

[0153] Table 7 FT Request Frame Body

[0154] Figure 6b is a schematic diagram of the format of the fast BSS transition element (FTE) provided in the embodiment of this application. As shown in Figure 6b, the FTE may include at least one of the following: element ID, length, message integrity codes (MIC) control, MIC, a random number provided by the authenticator (such as ANounce), a random number provided by the applicant (such as SNounce), or optional parameter(s).

[0155] Figure 6c is a schematic diagram of the MDE format provided in an embodiment of this application. As shown in Figure 6c, the MDE may include at least one of the following: element ID, length, mobility domain identifier (MDID), or FT capability and policy. The MDID field can be used to indicate the ID of the mobile domain. The FT capability and policy field can be used to indicate fast BSS transition over DS or resource request protocol capability. The FT field over DS can be used to indicate whether fast BSS transition over DS is supported, and the resource request protocol capability field can be used to indicate whether resource request protocol is supported. For example, a non-AP MLD can negotiate resources with the target AP MLD through an FT acknowledgment frame / FT ACK frame, and with the current AP MLD.

[0156] Figure 7 is a schematic diagram of the frame format of the FT response frame provided in an embodiment of this application. As shown in Figure 7, the FT response frame may include at least one of the following: category, FT action, STA address, target AP address, status code, or FT response framebody. For explanations of each field, please refer to the 802.11 standard, etc., which will not be detailed here.

[0157] Table 8 illustrates, for example, the main contents of the frame body of an FT response frame.

[0158] Table 8 FT Response Frames

[0159] Figure 8 is a schematic diagram of the frame format of the FT confirmation frame provided in an embodiment of this application. As shown in Figure 8, the FT confirmation frame may include at least one of the following: category, FT action, STA address, target AP address, or FT confirmframebody. For explanations of each field, please refer to the 802.11 standard, etc., and will not be detailed here.

[0160] Table 9 provides an example of the main contents of the frame body of an FT confirmation frame.

[0161] Table 9 FT Confirmation Frame

[0162] Figure 9 is a schematic diagram of the frame format of the FT ACK frame provided in an embodiment of this application. As shown in Figure 9, the FT ACK frame may include at least one of the following: category, FT action, STA address, target AP address, status code, or FT ACK framebody. For explanations of each field, please refer to the 802.11 standard, etc., and will not be detailed here.

[0163] Table 10 illustrates, for example, the main contents of the frame body of an FTACK frame.

[0164] Table 10 FT ACK Frame Body

[0165] The RIC in the FT acknowledgment frame shown in Table 9 can also be called an RIC request or resource request, and the RIC in the FT ACK frame shown in Table 10 can also be called an RIC response or resource response. For ease of description, the following explanations will use RIC requests and RIC responses as examples.

[0166] Figure 10 is a schematic diagram of the format of a RIC request / RIC response provided in an embodiment of this application. Figure 10 exemplarily illustrates one RIC request / one RIC response. However, in specific implementations, an FT acknowledgment frame may also include multiple RIC requests, and an FT ACK frame may also include multiple RIC responses. The formats of these RIC requests / RIC responses can all refer to Figure 10. Each of the multiple RIC requests mentioned above can correspond to a resource request.

[0167] As shown in Figure 10, the RIC request / RIC response may include a Resource Information Container Data Element (RDE) and a Resource Descriptor.

[0168] For RIC requests or RIC responses, RDEs may include at least one of the following: element ID, length, RDE ID, number of resource descriptors (resourcedescriptorcount), and status code (statuscode).

[0169] The RDE ID field indicates the identifier of the RIC request / RIC response. The Resource Descriptor Count field indicates the number of resource descriptor fields following the RDE. The Status Code field indicates whether the non-AP MLD successfully requested the resource requested in the RIC request. In other words, the Status Code field indicates whether the non-AP MLD successfully requested the resource corresponding to the RIC request. When the RDE is carried within an RIC request, the Status Code field is reserved.

[0170] The resource descriptor field can be used to indicate a specific resource descriptor. When the resource request is used for block acknowledgment parameter negotiation, this resource descriptor field can include a resource type and variable parameters. The resource type field indicates the resource type, and the variable parameters field carries the parameters corresponding to the resource type. When the resource request is used for 802.11 QoS, the signaling carried by this resource descriptor field is detailed in Table 11.

[0171] The lengths or field order of the various FT action frames shown above are merely examples. The specific format of each FT action frame is not limited in the embodiments of this application.

[0172] Among the existing resource request methods, two types of resource requests can be supported: one is to establish an uplink BA session (that is, the resource request is used for uplink fast acknowledgment parameter negotiation), and the other is to add a quality of service (QoS) service flow (that is, the resource request is used for 802.11 QoS).

[0173] Table 11 exemplarily illustrates the contents of the resource descriptor field in existing resource request methods. The two resource types shown in Table 11 can be carried in different RIC requests. For example, an FT acknowledgment frame may include two RIC requests, which can be used to request an uplink BA session and add a QoS service flow, respectively.

[0174] Table 11

[0175] Table 12 provides an example of the values ​​of the resource type field and the contents of the variable parameter field in the RIC descriptor element of existing resource request methods.

[0176] Table 12

[0177] For further explanation of Table 12, please refer to the above description of BA session establishment, which will not be elaborated here.

[0178] As can be seen from Tables 11 and 12, among the existing resource request methods, the FT confirmation frame supports two types of resource requests: establishing an uplink BA session and adding QoS service flows.

[0179] When a non-AP MLD needs to request resources other than the two types mentioned above, it needs to reassociate with the target AP MLD before making the resource request. This makes it impossible to fully utilize multiple links, resulting in low transmission efficiency and increased roaming latency, thus leading to low roaming efficiency.

[0180] In view of this, embodiments of this application provide a resource request method, apparatus and system, which can effectively reduce roaming latency (or roaming time), improve roaming efficiency and enhance the user experience during roaming.

[0181] The method provided in this application includes a series of preparatory steps, such as resource requests before roaming or data pre-roaming. As shown below:

[0182] As an example, the method provided in this application embodiment considers resource requests under scenarios such as stream classification service (SCS), target wake time (TWT), and AP power saving. It further extends the currently supported resource request protocols by adding SCS-based resource requests, TWT-based resource requests, and wake-up requests. For example, regarding SCS, in existing resource request methods, the reassociated non-AP MLD can report a low-latency service to the target AP MLD via SCS. This introduces latency in resource negotiation and leads to QoS degradation during roaming. Therefore, in this application embodiment, by adding SCS-based resource requests to the FT confirmation frame, roaming latency can be effectively reduced and roaming efficiency improved.

[0183] As another example, the method provided in this application embodiment considers the establishment of a downlink BA session. The establishment of the downlink BA session is implemented based on currently supported resource request protocols.

[0184] As another example, the method provided in this application embodiment takes into account the updating of the BA session. It implements the updating of the BA session by considering context transitions based on currently supported resource request protocols.

[0185] As yet another example, the method provided in this application embodiment takes into account the problem of long data forwarding time in the existing data forwarding process and proposes an early data forwarding operation.

[0186] As another example, the method provided in this application, considering the ping-pong phenomenon that may occur in roaming scenarios, proposes a new state. In this state, the IEEE 802.1X control port is blocked, allowing the current AP MLD and non-AP MLD to retain PTKSA (or possibly GTKSA) for a period of time until timeout. Generally, the IEEE 802.1X control port can be used to control data transmission with the DS, such as controlling whether the DS system can deliver downlink data from a non-AP MLD to the AP MLD associated with that non-AP MLD, or whether it can deliver uplink data from a non-AP MLD to the network through the DS system. The aforementioned IEEE 802.1X control port can also be simply referred to as the control port. For related explanations of the control port, please refer to the 802.11 standard, which will not be detailed here.

[0187] The examples above can be found below, but will not be detailed here. The examples above can be combined with each other; however, explanations for such combinations will not be provided here.

[0188] In this embodiment of the application, as a possible implementation, the steps performed by the non-AP MLD before sending the reassociation request frame can be called pre-roaming. When the non-AP MLD receives the reassociation response frame and the status code field of the reassociation response frame indicates success, it can be said that the non-AP MLD has successfully roamed to the target AP MLD.

[0189] Figure 11 is a flowchart illustrating a resource request method provided in an embodiment of this application. This method can be applied to non-AP MLD, target AP MLD, or current AP MLD. Explanations of non-AP MLD, target AP MLD, and current AP MLD can be found above and will not be detailed here. Explanations of DS can also be found above and will not be detailed here.

[0190] In Figure 11, the data path between the current AP MLD and the DS indicates that the DS can submit data destined for the non-AP MLD to the current AP MLD, or receive data from the non-AP MLD from the current AP MLD. A secure session has been successfully established between the non-AP MLD and the current AP MLD, and data transmission has been successful. Before the non-AP MLD sends an FT request, it can decide to roam to the target AP MLD based on the BSS transfer process triggered by the current AP MLD; alternatively, the non-AP MLD can also proactively initiate a BSS transfer to determine whether to roam to the target AP MLD. The process before the non-AP MLD sends an FT request can refer to the 802.11 standard, etc., and this embodiment does not limit it.

[0191] In Figure 11, solid and dashed lines can represent different transmission paths or different transmission methods. For example, solid lines in Figure 11 can represent air interface transmission, while dashed lines can represent transmission via DS or wired transmission.

[0192] As shown in Figure 11, the resource request method may include:

[0193] 1101. The non-AP MLD sends an FT request frame (i.e., the FT request in Figure 11) to the current AP MLD, and the current AP MLD receives the FT request frame.

[0194] After receiving the FT request frame, the current AP MLD can send the corresponding remote request to the target AP MLD through DS.

[0195] In other words, the content of this remote request can originate from an FT request frame. For example, the current AP MLD can parse the FT request frame to determine its destination address (i.e., the address of the target AP MLD) and carry the information that needs to be sent to the target AP MLD within the FT request frame in the remote request. Alternatively, the current AP MLD can directly encapsulate the FT request frame within the remote request. For instance, the FT request frame may include the address of the non-AP MLD, the address of the target AP MLD, RSNE (PMKR0name), MDE, or FTE (SNonce, R0KH-ID).

[0196] The target AP MLD receives the aforementioned remote request and sends a remote response to the current AP MLD in response to the request. The current AP MLD receives the remote response.

[0197] Table 13 illustrates the payload format for remote requests / responses.

[0198] Table 13

[0199] The FT packet type field indicates whether the data carried is a remote request or a remote response. For example, a value of 0 indicates a remote request, and a value of 1 indicates a remote response. The FT action length field indicates the length of the FT action frame field; it can be set to an unsigned number, representing an octet length. The AP address field indicates the address of the current AP MLD, such as the MLD address. The target AP MLD can use this AP address field to determine the destination address of the remote response. The FT action frame field carries the FT action frame, from the type field to the action frame body.

[0200] Table 13 illustrates examples of FT request frames directly encapsulated in remote requests and FT response frames directly encapsulated in remote responses. However, it should not be construed as limiting the embodiments of this application.

[0201] The explanations regarding remote requests and responses provided here also apply below, and will not be elaborated upon further.

[0202] 1102. The current AP MLD sends an FT response frame (i.e., the FT response in Figure 11) to the non-AP MLD, and the non-AP MLD receives the FT response frame.

[0203] The content of this FT response frame can come from the remote response described in step 1101. For an explanation of the remote response, please refer to the description of the remote request above; it will not be elaborated upon here.

[0204] For example, the FT response frame may include the address of the non-AP MLD, the address of the target AP MLD, RSNE (PMKR0Name), MDE or FTE (ANonce, SNonce, R1KH-ID, R0KH-ID).

[0205] After exchanging FT request frames and FT response frames, the non-AP MLD and the target AP MLD can successfully establish a new PTKSA.

[0206] 1103. The non-AP MLD sends an FT acknowledgment frame (i.e., the FT acknowledgment in Figure 11) to the current AP MLD, and the current AP MLD receives the FT acknowledgment frame.

[0207] FT acknowledgment frames can be used by a non-AP MLD to request resources from a target AP MLF. After receiving this FT acknowledgment frame, the current AP MLD can send a remote request to the target AP MLD. The content of this remote request can come from the FT acknowledgment frame. The target AP MLD receives the remote request and sends a remote response to the current AP MLD in response to the remote request. The current AP MLD receives the remote response.

[0208] For example, an FT confirmation frame may include the non-AP MLD address, the address of the target AP MLD, RSNE (PMKR1Name), MDE, FTE (MIC, ANOnce, SNonce, R1KH-ID, R0KH-ID), or a RIC request. For an explanation of the RIC request, please refer to the description in Figure 10 above or below; it will not be detailed here.

[0209] 1104. The current AP MLD sends an FT ACK frame (i.e., FT ACK in Figure 11) to the non-AP MLD, and the non-AP MLD receives the FT ACK frame.

[0210] The content of the FT ACK frame can be derived from the remote response described in step 1103. For example, the FT ACK frame may include the non-AP MLD address, the address of the target AP MLD, RSNE (PMKR1Name), MDE, FTE (MIC, ANOnce, SNonce, R1KH-ID, R0KH-ID), timeout interval element (TIE) (such as indicating the reassociation deadline), or RIC response. For an explanation of the RIC response, please refer to the description in Figure 10 above or below; it will not be detailed here.

[0211] 1105. The non-AP MLD sends an early downlink (DL) data forwarding request frame to the current AP MLD (as shown in Figure 11), and the current AP MLD receives the early downlink data forwarding request frame.

[0212] Optionally, the current AP MLD can also perform early downlink data forwarding.

[0213] After step 1105, the current AP MLD can copy the data it needs to send to the non-AP MLD and send it to the target AP MLD. For an explanation of the early downlink data forwarding request frame, please refer to the forwarding instruction information below or the explanations in Examples 1 to 5; details will not be provided here.

[0214] In this embodiment, the current AP MLD can begin downlink data forwarding before sending a context transfer response, thereby effectively reducing the latency introduced by data forwarding (or data migration) and improving roaming efficiency. The early downlink data forwarding shown here is relative to the downlink / uplink data forwarding after step 1108 below. Alternatively, in a specific implementation, the early downlink data forwarding after step 1105 and the downlink data forwarding after step 1108 can be used interchangeably, and both can be referred to as downlink data forwarding.

[0215] 1106. The non-AP MLD sends a reassociation request frame (i.e., the reassociation request in Figure 11) to the target AP MLD, and the target AP MLD receives the reassociation request frame.

[0216] Reassociation request frames may include RSNE (PMKR1Name), MDE, FTE (MIC, ANOnce, SNonce, R1KH-ID, R0KH-ID), and RSNXE. For a description of reassociation request frames, please refer to Table 1 above or below; details will not be provided here.

[0217] For example, if a non-AP MLD moves into the coverage area of ​​a target AP MLD, or if a non-AP MLD determines that the signal quality of the target AP MLD is greater than that of the current AP MLD, the non-AP MLD can send a reassociation request frame to the target AP MLD via the air interface.

[0218] 1107. The target AP MLD sends a context transfer request to the current AP MLD, and the current AP MLD receives the context transfer request.

[0219] Step A: The current AP MLD should stop transmitting uplink data to the DS and downlink data to non-AP MLDs. In other words, upon receiving a context transfer request from the target AP MLD, the current AP MLD can stop downlink data transmission and submit data to the DS through its own MAC service access point (SAP).

[0220] Step B: The target AP MLD updates the STA-to-AP mapping relationship using the DS-STA-NOTIFY.request primitive, such as updating the type as mobile. This primitive can also include the MAC address of the non-AP MLD (e.g., the MLD MAC address).

[0221] 1108. The current AP MLD sends a context transfer response to the target AP MLD, and the target AP MLD receives the context transfer response.

[0222] For example, the current AP MLD can stop submitting MSDUs to the DS, or in other words, stop transmitting downlink data to non-AP MLDs. Then, a context transfer response is sent to the target AP MLD via the DS.

[0223] After the target AP MLD and the current AP MLD exchange a context transfer request and a context transfer response, the current AP MLD can perform at least one of uplink data forwarding or downlink data forwarding. For example, the current AP MLD can forward uplink data from a non-AP MLD to the target AP MLD. As shown in step 1105 above, the current AP MLD can perform early downlink data forwarding, thus allowing it to continue performing downlink data forwarding even if it has not completed early downlink data forwarding.

[0224] 1109. The target AP MLD sends a reassociation response frame (i.e., the reassociation response in Figure 11) to the non-AP MLD, and the non-AP MLD receives the reassociation response frame.

[0225] The reassociation response frame may include RSNE (PMKR1Name), MDE, FTE (MIC, ANOnce, SNonce, R1KH-ID, R0KH-ID, GTK(N), BIGTK(Q)), and RSNXE. For details regarding reassociation requests, please refer to Table 2 above or below; further explanation is not provided here.

[0226] Optionally, the current AP MLD can also send an endmarker of DL dataforwarding to the target AP MLD. This endmarker can be used to indicate the end of DL data forwarding (such as the current AP MLD's transmit buffer).

[0227] Optionally, the current AP MLD can also send an uplink data forwarding end flag (not shown in Figure 11) to the target AP MLD. This uplink data forwarding end flag can be used to indicate the end of uplink data forwarding (i.e., the reordering buffer of the current AP MLD).

[0228] For example, the downlink data pre-transmission end identifier and the uplink data pre-transmission end identifier may be carried in the same frame or in different frames, and this application embodiment does not limit this. For example, the downlink data pre-transmission end identifier and the uplink data pre-transmission end identifier may also be unified into a single identifier, which can indicate the end of both downlink and uplink data pre-transmission.

[0229] The steps shown in Figure 11 are merely examples. In a specific implementation, the resource request method may have more or fewer steps than shown in Figure 11. For example, steps 1103 and 1104 above may be optional. Similarly, step 1105 above may be optional, and so on. These will not be listed individually here.

[0230] The following details the frame format involved in the embodiments of this application.

[0231] As one possible implementation, the FT acknowledgment frame includes a RIC request, which includes a resource descriptor field. For details on the format of the FT acknowledgment frame, please refer to the description in Figure 8, etc.; for details on the format of the RIC request, please refer to the description in Figure 10 above, etc.

[0232] As another possible implementation, the FT ACK frame includes a RIC response, which includes a resource descriptor field. For details on the format of the FT ACK frame, please refer to the description in Figure 9, and for details on the format of the RIC response, please refer to the description in Figure 10 above.

[0233] As another possible implementation, the reassociation request frame may include a RIC request, which includes a resource descriptor field. Further details regarding the reassociation request frame can be found in Table 1, etc., and the format of the RIC request can be found in the description in Figure 10 above, etc.

[0234] As another possible implementation, the reassociation response frame may include a RIC response, which includes a resource descriptor field. Further details regarding the reassociation response frame can be found in Table 2, etc., and the format of the RIC response can be found in the description in Figure 10 above, etc.

[0235] For descriptions of remote requests corresponding to FT acknowledgment frames and remote responses corresponding to FT ACK frames, please refer to the descriptions of FT acknowledgment frames and FT ACK frames; they will not be detailed here.

[0236] Optionally, the FT acknowledgment frame / reassociation request frame may also carry a buffer status report for the non-AP MLD. This buffer status report may indicate the buffer size, the corresponding TID (TID corresponding to the aforementioned buffer size), or the access category (AC). Based on this buffer status report, the target AP MLD can decide whether to allow the non-AP MLD to roam to it, or determine the number of APs to wake up based on the buffer size, etc.

[0237] The following details the contents of RIC requests / RIC responses.

[0238] The resource descriptor field in a RIC request may include at least one of the following: an SCS descriptor element (as shown in (1) below), a TWT element (as shown in (2) below), a wake-up request element (as shown in (3) below), a RIC descriptor element corresponding to a resource type of enhanced block acknowledgment parameter (as shown in (4) below), or a RIC descriptor element corresponding to a resource type of enhanced block acknowledgment parameter transfer (as shown in (5) below). This resource descriptor field may also include a TSPEC element or a RIC descriptor element as shown in Table 11. For explanations of the TSPEC element or the RIC descriptor element used to request an uplink BA session, please refer to the above or the 802.11 standard, etc., and will not be elaborated further here.

[0239] This application embodiment illustrates an example where a resource descriptor field is included in the RIC request / RIC response, and this resource descriptor field includes an SCS descriptor element, a TWT element, or a wake-up request element, etc. (as shown in the frame format of Figure 10). However, as another possible implementation, the FT confirmation frame / reassociation request frame and the SCS descriptor element shown in this application embodiment may have other formats, or the FT confirmation frame / reassociation request frame and the TWT element may have other formats, or the FT confirmation frame / reassociation request frame and the wake-up request element (or wake-up indication information) may have other formats. This application embodiment does not limit the specific location of the SCS descriptor element (or the fields included in that element) in the FT confirmation frame / reassociation request frame (e.g., it may be located in a certain field, or in a certain element, or in a certain position in the frame body of the FT confirmation frame, etc.), the TWT element (or the fields included in that element) in the FT confirmation frame / reassociation request frame, or the wake-up request element (or wake-up indication information) in the FT confirmation frame / reassociation request frame. This explanation also applies to FT ACK frames / reassociation response frames.

[0240] As one possible implementation, the RDE in the RIC response includes a status code field. As an example, this status code field can indicate that the non-AP MLD successfully requested the resource corresponding to the RIC request. For example, for an RIC request including an SCS descriptor element, the status code field can indicate that the non-AP MLD successfully requested the resource corresponding to the SCS. For an RIC request including a TWT element, the status code field can indicate that the non-AP MLD successfully requested the resource corresponding to the TWT. For an RIC request including a wake-up request element, the status code field can indicate that the non-AP MLD successfully woke up the first AP. As another example, the status code field can indicate that the non-AP MLD did not request the resource corresponding to the RIC request, or the status code field can be used to indicate to the non-AP MLD that the target AP MLD rejected the resource corresponding to the RIC request. The RIC response can include a suggested SCS descriptor element, a suggested TWT element, or a suggested wake-up request element. That is, the RIC response can include resources suggested by the target AP MLD to the non-AP MLD.

[0241] As another possible implementation, the TWT element in the RIC response can include four response methods: accept TWT parameters, change TWT parameters, indicate TWT parameters, and reject TWT parameters. That is, the TWT element in the RIC response indicates the response method; therefore, an RIC response carrying a TWT element may not include a status code field, which is a reserved field.

[0242] To facilitate the distinction between the SCS descriptor element in the RIC request and the SCS descriptor element in the RIC response, this embodiment refers to the SCS descriptor element in the RIC response as the suggested SCS descriptor element. However, in specific implementations, the distinction between the SCS descriptor elements in the RIC request / RIC response may not be made, and they may be uniformly referred to as SCS descriptor elements. This description also applies to TWT elements / suggested TWT elements and wake-up request elements / suggested wake-up request elements, and will not be elaborated further.

[0243] The following details each element.

[0244] (1) SCS descriptor element

[0245] The SCS descriptor element can be used by a non-AP MLD to request resources corresponding to an SCS from a target AP MLD. For example, the SCS descriptor element can be used by a non-AP MLD to report a low-latency SCS flow to a target AP MLD (i.e., requesting resources for a low-latency SCS flow). The suggested SCS descriptor element is used by the target AP MLD to suggest SCS parameters to the non-AP MLD.

[0246] For example, the SCS descriptor element / suggested SCS descriptor element may include at least one of the following: element ID, length, SCS ID, request type, intra-access category priority element (optional), flow classification element (TCLAS element) (optional), flow allocation processing element (TCLAS Processing element) (optional), QoS characteristics element, and optional subelements.

[0247] For details on the fields in the SCS descriptor element, please refer to the 802.11 standard; they will not be elaborated here.

[0248] (2) TWT element

[0249] The TWT element can be used by a non-AP MLD to request resources corresponding to a TWT from a target AP MLD. The TWT element can also be used by a non-AP MLD to report a periodic target wake-up time to the target AP MLD (i.e., requesting resources for a periodic TWT).

[0250] For explanations of the various fields in the TWT element, please refer to the 802.11 standard, which will not be detailed here.

[0251] (3) Wake up the request element

[0252] The wake-up request element is used by a non-AP MLD to wake up the first AP belonging to the target AP MLD.

[0253] As an example, the RIC response may include a suggested wake-up request element, which is used by the target AP MLD to suggest parameters for waking up the first AP to the non-AP MLD. In this case, the suggested wake-up request element can be included in the RIC response regardless of whether the target AP MLD agrees with the parameters indicated by the wake-up request element. Both the first AP and the non-AP MLD can use the content indicated by the wake-up request element in the RIC response as the final parameters (or real values).

[0254] As another example, the RIC response may not include the proposed wake-up request element if the target AP MLD agrees to the parameters indicated in the wake-up request element. Conversely, the RIC response includes the proposed wake-up request element if the target AP MLD rejects the parameters indicated in the wake-up request element.

[0255] Considering that one or more APs belonging to the target AP MLD may be unable to roam to the target AP MLD in a timely manner when they are in at least one of the following modes: periodic scheduling power-saving mode (or scheduled AP power-saving mode), non-periodic power-saving mode (or wakeable non-scheduled AP power-saving mode), and listening mode of low bandwidth low flow low coding scheme (MCS). The modes shown here can be understood as power-saving modes. Generally, there are two states in a power-saving mode: a wake-up state and a sleep state. Therefore, this application proposes a wake-up request element. If the target AP MLD receives this wake-up request element, it can wake up the first AP, enabling the non-AP MLD to successfully roam to the target AP MLD. After roaming to the target AP MLD, it can directly transmit data with the first AP.

[0256] As an example, the resource descriptor field may not include the wake-up request element. In this case, after the target AP MLD receives an FT acknowledgment frame or a reassociation request frame, if the first AP belonging to the target AP MLD is in power-saving mode, that first AP can automatically exit power-saving mode.

[0257] As another example, the wake-up request element can include wake-up indication information. For instance, if the wake-up indication information does not include the BSSID or link ID of any AP, it indicates that all APs in the target AP MLD will be woken up. Alternatively, if the wake-up indication information includes the BSSID or link ID of the first AP, it indicates that the first AP will be woken up. The wake-up indication information can include a BSSID field or a link ID field, which can indicate a first AP. Alternatively, the wake-up indication information can include multiple BSSID fields or link ID fields, each indicating an AP. That is, the wake-up indication information can be used to wake up one or more first APs. Furthermore, the wake-up indication information can include a link bitmap, where each bit corresponds to a link, and each bit can be used to indicate whether to wake up the corresponding link. For example, the link bitmap can be a 16-bit (for example only) link bitmap, where a bit set to 1 indicates a request to wake up the corresponding AP, and a bit set to 0 indicates that the corresponding AP will not be woken up.

[0258] In this embodiment, the non-AP MLD can instruct one or more first APs belonging to the target AP MLD to exit power-saving mode via wake-up indication information (as described in method 1 below), or the non-AP MLD can wake up (or temporarily suspend) one or more first APs belonging to the target AP MLD via wake-up indication information (as described in method 2 below), or the non-AP MLD can instruct one or more first APs to update wake-up parameters via wake-up indication information (as described in method 3 below). The wake-up indication information can be provided in the following ways:

[0259] Method 1: The wake-up instruction information can be used to instruct the first AP to exit the power-saving mode.

[0260] In this case, after the first AP exits the energy-saving mode, it does not need to re-enter the energy-saving mode.

[0261] Method 2: Wake-up indication information can be used to wake up the first AP.

[0262] In this case, the wake-up indication information can also be called a wake-up activation indication. When the first AP does not need to be in the wake-up state, the non-AP MLD can send a wake-up deactivation indication again, which can instruct the first AP to switch back to the sleep state from the wake-up state.

[0263] Method 3: The wake-up indication information includes updated wake-up parameters corresponding to the first AP. That is, the first AP can switch between wake-up state and sleep state based on the updated wake-up parameters in the wake-up indication information.

[0264] For example, the first AP is in a periodic scheduling power-saving mode. In this mode, the first AP can establish periodic wake-up windows. Within these windows, the first AP is in a wake-up state; outside of these windows, it is in a sleep state. For instance, beacon frames, probe response frames, or probe response frames may include wake-up parameters that indicate the periodic wake-up windows. These parameters may include the start time of the wake-up window (or the start time of the initial wake-up window or the start time of the wake-up window before the update, etc.), the duration of the wake-up window (or the duration of the initial wake-up window or the duration of the wake-up window before the update), or the interval between adjacent wake-up windows (or the initial time interval or the time interval before the update). For instance, the beacon frames, probe response frames, or probe response frames may also include the first AP's BSSID, link ID, or link bitmap, etc. For instance, the beacon frames, probe response frames, or probe response frames may be frames sent from other APs in the target AP MLD (excluding the first AP) to the non-AP MLD.

[0265] Taking method 3 above as an example, the FT confirmation frame or reassociation request frame can carry a new set of periodic wake-up window parameters, namely the updated wake-up parameters shown above. These updated wake-up parameters can include the start time of the wake-up window (or the updated start time of the wake-up window), the duration of the wake-up window (or the updated duration of the wake-up window), or the time interval between adjacent wake-up windows (or the updated time interval). Therefore, the first AP can update the start time of the wake-up window, increase the duration of the wake-up window, or decrease the time interval of the wake-up window. In the updated wake-up parameters, the duration of the wake-up window is longer than the duration of the wake-up window before the update, and the time interval between adjacent wake-up windows is shorter than the time interval before the update.

[0266] Taking Method 1 as an example, the wake-up indication information can request the first AP to exit the periodic scheduling power-saving mode. Method 2 will not be listed here. As shown above, the FT acknowledgment frame / reassociation request frame can also carry a cache status report; details regarding the cache status report will not be elaborated here.

[0267] For example, the first AP is in a non-scheduled power-saving mode. In this non-periodic power-saving mode, the non-AP MLD can send a wake-up request to the target AP MLD through a link. This wake-up request can include a link ID field or a BSSID field, which can be used to indicate the AP to be woken up. Alternatively, the wake-up request can include a link bitmap, which can also indicate the AP to be woken up. Unlike the periodic scheduled power-saving mode, when the first AP is in the non-scheduled power-saving mode, the wake-up status of the first AP is not periodic.

[0268] Taking method 3 above as an example, the wake-up indication information in the FT confirmation frame / reassociation request frame may include the duration of wake-up, that is, the duration of the first AP's wake-up. The duration of wake-up may be the duration of the first AP's wake-up state. The first AP can update the duration of wake-up based on the duration indicated by the wake-up indication information.

[0269] Taking Method 1 as an example, the wake-up indication information can instruct the first AP to exit the non-scheduled power-saving mode. Method 2 will not be listed here. As shown above, the FT acknowledgment frame / reassociation request frame can also carry a cache status report; details regarding the cache status report will not be elaborated here.

[0270] For example, the first AP is in a low-bandwidth, low-flow, low-MCS listening mode. In this mode, the non-AP MLD can request the first AP to exit the listening mode or switch to a specified high-bandwidth, high-flow, high-MCS state.

[0271] Taking method 3 above as an example, the wake-up indication information in the FT confirmation frame / reassociation request frame may include updated wake-up parameters. These updated wake-up parameters may include at least one of the following: the bandwidth of the first AP, the number of spatial streams of the first AP, and the MCS of the first AP. For example, the bandwidth indicated in the updated wake-up parameters may be greater than the bandwidth of the first AP before the update, or the number of spatial streams indicated in the updated wake-up parameters may be greater than the number of spatial streams of the first AP before the update, or the MCS indicated in the updated wake-up parameters may be higher than the MCS of the first AP before the update. Through these updated wake-up parameters, the first AP can switch to a working state with the specified bandwidth, number of spatial streams, or MCS.

[0272] Taking method 1 above as an example, the wake-up indication information can instruct the first AP to exit the listening mode. Method 2 will not be listed here. As shown above, the FT acknowledgment frame / reassociation request frame can also carry a cache status report; details regarding the cache status report will not be elaborated here.

[0273] Table 14 exemplarily illustrates the content of the resource descriptor in the resource request method provided in this application embodiment. The different elements shown in Table 13 can be carried in different RIC requests (or RIC responses). For example, an FT confirmation frame or a reassociation request frame may include one or more RIC requests, each RIC request corresponding to a resource type.

[0274] The resource descriptor fields in Table 14 for resource types QoS and block acknowledgment parameters can be as described above or the 802.11 standard, etc., and will not be detailed here. The resource descriptor fields for resource types SCS, TWT, or wake-up parameters can be referred to in (1) to (3) above. The content of Table 14 can be carried in FT acknowledgment frames / FT ACK frames, or it can also be carried in reassociation request frames / reassociation response frames.

[0275] Table 14

[0276] In this embodiment, a new resource request is added to the FT acknowledgment frame (or reassociation request frame). The resource type of the new resource request can be SCS, TWT, or wake-up parameters. The non-AP MLD and the target AP MLD can complete QoS resource negotiation, uplink block acknowledgment session resource negotiation, SCS resource negotiation, TWT resource negotiation, or wake-up parameter negotiation through the interaction of FT acknowledgment frames and FT ACK frames (or reassociation request frames and reassociation response frames). This effectively reduces roaming latency and improves the user's roaming experience.

[0277] Furthermore, the non-AP MLD can also wake up the first AP in power-saving mode via an FT confirmation frame (or reassociation request frame), mitigating the impact of the first AP being in power-saving mode on the roaming of the non-AP MLD. Generally, when the first AP is in power-saving mode, the throughput of the non-AP MLD roaming to the target AP MLD will decrease. Simultaneously, if the first AP is the AP with the largest coverage area in the target AP MLD, then when the first AP is in power-saving mode, the non-AP MLD may not be able to roam to the target AP MLD in a timely manner. Therefore, by adding a wake-up request element in this embodiment, the above situations can be avoided, improving the roaming experience of the non-AP MLD.

[0278] (4) RIC descriptor element corresponding to the block confirmation parameter set with resource type "enhanced".

[0279] As described above regarding the establishment of a block acknowledgment session, the block acknowledgment protocol has been extended in the 801.11ax standard to define HE dynamic fragmentation. Therefore, this application embodiment can add a new resource type, such as enhanced block acknowledgment parameters (or extended block acknowledgment parameters). For example, based on existing block acknowledgment parameters, an ADDBA extended parameter set field can be added.

[0280] For an explanation of the resource descriptor fields corresponding to the newly added resource type, namely the enhanced block acknowledgment parameters, please refer to Table 15. For an explanation of the variable parameter fields corresponding to this resource type, please refer to Table 16.

[0281] (5) RIC descriptor element corresponding to block confirmation parameter transfer with resource type "enhanced".

[0282] Context transfer during roaming can effectively avoid packet loss caused by roaming, thereby improving roaming performance. To achieve context transfer, the target AP MLD can continue to allocate MSDUs based on the current AP MLD's SN allocation order, allowing the target AP MLD to continue transmitting MSDUs. In other words, the current AP MLD can indicate the next SN to the target AP MLD.

[0283] During context transfer, except for the starting SN number which does not need to be negotiated, other block ACK parameters can be updated or renegotiated according to the capabilities of the target AP MLD. Therefore, embodiments of this application can add a new resource type, such as enhanced block ACK parameter transfer (or extended block ACK parameter transfer). Through enhanced block ACK parameter transfer, non-AP MLD or target AP MLD can also update other block ACK parameters except for the starting SN number.

[0284] For an explanation of the resource descriptor fields corresponding to the newly added resource type, namely the enhanced block acknowledgment parameter transfer, please refer to Table 15. For an explanation of the variable parameter fields corresponding to this resource type, please refer to Table 16.

[0285] Table 15 exemplarily illustrates the contents of the resource descriptor field in the resource request method provided in the embodiments of this application.

[0286] Table 15

[0287] The descriptions of other resource types in Table 15 can be found above and will not be detailed here. The format of the resource descriptor field corresponding to the enhanced block acknowledgment parameter or enhanced block acknowledgment parameter transfer can be found in Figure 10. For example, the resource descriptor field may include the resource type and variable parameters. Table 15 exemplarily shows the TWT element, SCS descriptor element, and wake-up request element. As another possible implementation, the RIC request / RIC response may not include at least one of the above TWT element, SCS descriptor element, or wake-up request element. Combinations of the above elements will not be listed individually here.

[0288] Table 16 exemplarily shows the values ​​of the resource type field corresponding to the block acknowledgment parameter of resource type "enhanced" (for example only), as well as the contents of the variable parameter field. Table 16 also shows the values ​​of the resource type field corresponding to the block acknowledgment parameter transfer of resource type "enhanced" in Table 15, as well as the contents of the variable parameter field.

[0289] Table 16

[0290] For an explanation of the block confirmation parameter set in Table 16, please refer to Figure 5b; for an explanation of the parameter set for the ADDBA extension, please refer to Figure 5c.

[0291] In this embodiment, a new resource request is added to the FT confirmation frame (or reassociation request frame). The resource type of this new resource request can be an enhanced block confirmation parameter, and the newly added resource type can be used for HE dynamic fragmentation. This avoids the delay introduced by parameter negotiation after roaming and effectively reduces roaming latency.

[0292] In this embodiment, a new resource type is added to the FT confirmation frame (or reassociation request frame). This new resource request type can be an enhanced block confirmation parameter transfer. The added resource type can be used for block confirmation parameter negotiation in context transition scenarios. Therefore, in context transition scenarios, either the non-AP MLD or the target AP MLD can update block confirmation parameters other than the initial SN, allowing the target AP MLD and the non-AP MLD to establish a suitable block confirmation session protocol based on their own capabilities.

[0293] As can be seen from Tables 11 and 12 above, the existing resource request methods only support negotiation of uplink block acknowledgment session parameters between the non-AP MLD and the target AP MLD, and do not support negotiation of downlink block acknowledgment session parameters. Normally, the establishment of a downlink block acknowledgment session is initiated by the AP. However, in the existing resource request methods (i.e., in the current FT protocol), the FT acknowledgment frame is sent by the STA or the non-AP MLD; there is no instance of the target AP MLD sending an FT acknowledgment frame, thus causing the current FT protocol to not support the establishment of a downlink block acknowledgment session.

[0294] The resource request method provided in this application supports negotiation of downlink block acknowledgment session parameters between a non-AP MLD and a target AP MLD. This effectively reduces roaming latency and improves roaming efficiency.

[0295] To support the establishment of downlink block acknowledgment sessions, embodiments of this application provide the following implementation:

[0296] Method A: Newly defined FT ADDBA request frame and FT ADDBA response frame.

[0297] The format of the newly defined FT ADDBA request frame / FT ADDBA response frame can be shown in Table 17:

[0298] Table 17

[0299] The frame body of an FT ADDBA request frame may include downlink BA information, which may include, but is not limited to, a block ACK parameter set, a block ACK timeout value, a block ACK starting sequence control, or an ADDBA extension.

[0300] The frame body of an FT ADDBA response frame may include proposed downlink BA information, which may include, but is not limited to, a block ACK parameter set, a block ACK timeout value, or an added block ACK extension. For a description of FT ADDBA request frames / FT ADDBA response frames, please refer to the description of FT action frames above; further details will not be provided here.

[0301] For example, an FT ADDBA request frame / FT ADDBA response frame may include a MIC, which can be used to verify the FT ADDBA request frame / FT ADDBA response frame. The calculation method of the MIC can be similar to the MIC calculation method of the FT acknowledgment frame in the current TF protocol, and will not be described in detail here. For example, an FT ADDBA request frame / FT ADDBA response frame may include a TIE, which can be used to indicate the deadline for reassociation.

[0302] As one possible implementation, it is possible to support the target AP MLD to directly send FT ABBDA request frames to the non-AP MLD through the current AP MLD, and to support the non-AP MLD to directly send FT ADDBA response frames to the target AP MLD through the current AP MLD.

[0303] As another possible implementation, it can support the target AP MLD sending a remote request to the current AP MLD, which in turn sends an FT ADDBA request frame to the non-AP MLD. Conversely, the non-AP MLD sends an FT ADDBA response frame to the current AP MLD, which in turn sends a remote response to the target AP MLD. As an example, the formats of the remote request and remote response can be as shown in Table 13, and will not be detailed here. As another example, the remote request and remote response may not indicate an FT action frame; that is, the FT action frame in Table 13 can be replaced with downlink BA information. The embodiments of this application do not limit the relationship between the remote request and the FT ADDBA request frame, or the relationship between the remote response and the FT ADDBA response frame.

[0304] For example, the target AP MLD may send an FT ADDBA request frame after receiving a remote response from the current AP MLD (the content of which comes from an FT response frame). Alternatively, the target AP MLD may send an FT ADDBA request frame before sending a reassociation response frame. The transmission order of the FT ADDBA request frame and the FT ADDBA response frame with other frames is not limited in this embodiment. This description also applies to methods B and C.

[0305] It is understood that the FT ADDBA request frame and FT ADDBA response frame are not shown in Figure 11 above, and Figure 11 should not be construed as a limitation on the embodiments of this application.

[0306] Method B: The target AP MLD is allowed to send an FT acknowledgment frame, and the non-AP MLD replies with an FT ACK frame.

[0307] The FT acknowledgment frame may include downlink BA information, which can be used to request the establishment of a downlink block acknowledgment session between the target AP MLD and the non-AP MLD. This downlink BA information may include, but is not limited to, a block ACK parameter set, a block ACK timeout value, or an added block acknowledgment extension (ADDBA extension).

[0308] The FT ACK frame may include proposed downlink BA information. That is, the FT ACK frame may include parameter information for the downlink block acknowledgment session proposed by the non-AP MLD. This proposed downlink BA information may include, but is not limited to, the block ACK parameter set, the block ACK timeout value, or the addition of an ADDBA extension.

[0309] For example, an FT acknowledgment frame / FT ACK frame may include a MIC, which can be used to verify the FT acknowledgment frame / FT ACK frame. A description of the MIC can be found in Figure 11 or relevant standards, and will not be detailed here. For example, an FT acknowledgment frame / FT ACK frame may include a TIE.

[0310] As one possible implementation, it is possible to support the target AP MLD to send FT acknowledgment frames to the non-AP MLD through the current AP MLD, and to support the non-AP MLD to send FT ACK frames to the target AP MLD through the current AP MLD.

[0311] As another possible implementation, the target AP MLD can send a remote request to the current AP MLD, which includes downlink BA information. Upon receiving the remote request, the current AP MLD can send an FT acknowledgment frame to the non-AP MLD. The non-AP MLD then sends an FT ACK frame in response to the FT acknowledgment frame. Upon receiving the FT ACK, the current AP MLD can send a remote response to the target AP MLD. As an example, the formats of the remote request and remote response can be as shown in Table 13, and will not be detailed here. As another example, the remote request and remote response may not indicate an FT action frame; that is, the FT action frame in Table 13 can be replaced with downlink BA information. The embodiments of this application do not limit the relationship between the remote request and the FT acknowledgment frame, or the relationship between the remote response and the FT ACK frame.

[0312] It is understood that Figure 11 above does not show the FT acknowledgment frame sent by the target AP MLD, nor the FT ACK frame replied by the non-AP MLD, and should not be construed as a limitation on the embodiments of this application.

[0313] In Method C, the FT response frame includes downlink BA information, and the FT acknowledgment frame includes suggested downlink BA information. For an explanation of downlink BA information, please refer to Method B; it will not be detailed here.

[0314] For example, an FT response frame may include a RIC request, which includes a resource descriptor field, the resource descriptor including an RIC descriptor element corresponding to a downlink block acknowledgment parameter of resource type. An FT acknowledgment frame may include an RIC response, which includes a proposed RIC descriptor element corresponding to a downlink block acknowledgment parameter of resource type.

[0315] For example, the FT response frame / FT acknowledgment frame may include a MIC, such as one carried in the FTE. The MIC can be used to verify the FT response frame / FT acknowledgment frame. For instance, if the MIC verification fails after receiving an FT response frame, the non-AP MLD can discard the FT response frame or discard the downlink BA information within it.

[0316] For example, the FT response frame / FT acknowledgment frame may include a TIE.

[0317] In this embodiment of the application, the enabled target AP MLD can establish a downlink block confirmation session with the non-AP MLD during roaming, avoiding the delay introduced by negotiating the downlink block confirmation session after roaming, thereby effectively reducing roaming latency and improving roaming efficiency.

[0318] Among existing resource request methods, a non-AP MLD can send a reassociation request frame to the target AP MLD over the air interface. This reassociation request frame can carry an element that indicates the TID for context transfer. Upon receiving this reassociation request frame, the target AP MLD can send a context transfer request to the current AP MLD. Thus, the current AP MLD performs a downlink context transfer. Considering the time-consuming data forwarding process, this can lead to reduced roaming efficiency for the non-AP MLD.

[0319] Therefore, this application embodiment further optimizes the resource request method. As shown in Figure 11, before the non-AP MLD sends a reassociation request, the non-AP MLD can send an early downlink data forwarding request to the current AP MLD. This early downlink data forwarding request can include data forwarding information, which can be used to indicate the downlink TID that the current AP MLD should perform data forwarding, or the downlink TID that the current AP MLD needs to transfer context, or the context of which TIDs of the current AP MLD need to perform data forwarding. The data forwarding information can include at least one of the following:

[0320] (1) Non-default transfer field: When this field is set to 0, it indicates that the context of all TIDs is being transferred; when this field is set to 1, it indicates that the context of a specific TID is being transferred. When the non-default transfer field is 1, the aforementioned forwarding indication information may also include downlink TID information. This downlink TID information (such as the TID bitmap or TID field shown below) can be used to indicate which downlink TIDs require context transfer, that is, it can indicate which downlink TIDs' contexts need to be transferred. Of course, as another possible implementation, the data forwarding information may not include the non-default transfer field. For example, if the data forwarding information does not include downlink TID information, it can indicate that the context of all TIDs is being transferred; or if the data forwarding information includes downlink TID information, it indicates that the context of a specific TID is being transferred.

[0321] (2) TID bitmap field (or DL ​​TID bitmap field): When the corresponding bit is set to 1, it indicates that the corresponding TID will perform downlink data forwarding; when the corresponding bit is set to 0, it indicates that the corresponding TID will not perform downlink data forwarding. This TID bitmap field can also be replaced by the TID field, which can be used to indicate the downlink TID that performs downlink data forwarding.

[0322] (3) Address field of target AP MLD: used to indicate the MAC address of the target AP MLD.

[0323] By indicating the address of the target AP MLD, the current AP MLD can effectively know which AP MLD it needs to transfer data to.

[0324] (4) Buffer size field: used to indicate to the current AP MLD the maximum number of MSDUs that the target AP MLD can cache.

[0325] By indicating the buffer size field, the current AP MLD can effectively know the maximum number of MSDUs that the target AP MLD can cache. Therefore, if the number of MSDUs cached by the current AP MLD to the target AP MLD exceeds the number indicated by the buffer size field, the target AP MLD can discard some MSDUs, such as the oldest cached MSDU.

[0326] As an example 1, the aforementioned data forwarding information can be carried in a BTM response frame. For instance, before sending an FT request to the target AP MLD, a non-AP MLD can send this BTM response frame to the current AP MLD, and this BTM response frame can include the aforementioned data forwarding information.

[0327] As another example 2, the aforementioned data forwarding information can be carried in a disassociation frame. For instance, before sending a reassociation request frame to the target AP MLD, the non-AP MLD can send this disassociation frame to the current AP MLD.

[0328] As another example 3, the aforementioned data forwarding information can be carried in a newly defined frame (the early downlink data forwarding request frame shown in Figure 11). For example, the non-AP MLD can send this newly defined frame before sending the reassociation request frame to the target AP MLD.

[0329] As another example 4, the aforementioned data forwarding information can be carried in an FT acknowledgment frame. The formats of the frames that the aforementioned data forwarding information can carry are not listed individually in this embodiment.

[0330] As another example 5, the aforementioned data preflight information can be carried in a reassociation request frame. If the non-AP MLD does not send a frame containing the data preflight information to the current AP MLD before sending the reassociation request frame to the target AP MLD, then the non-AP MLD can carry the data preflight information through the reassociation request frame. After receiving the reassociation request frame, the target AP MLD sends a context transfer request to the current AP MLD, which includes the data preflight information.

[0331] For downlink transmissions, the current AP MLD needs to inform the target AP MLD of the next SN. The next SN can be used to indicate the starting number of MSDUs delivered from the DS to the target AP MLD with a destination address that is not an AP MLD. This next SN information can be carried in the context transfer response, or it can be carried in the downlink data pre-transfer end identifier, etc., which will not be listed here.

[0332] In this embodiment, the current AP MLD and the target AP MLD undergoing context transfer have the same QoS configuration policy. Alternatively, all AP MLDs belonging to the same mobile domain can have the same QoS configuration policy. The same QoS configuration policy may include the same QoS map element, which can represent the mapping rule from differentiated services code point (DSCP) to TID. One possible implementation is that all APs with context transfer capabilities within the same mobile domain carry the same QoS map element in the beacon frame. Another possible implementation is to transfer the current QoS map policy of the corresponding non-AP MLD (including uplink and downlink QoS configuration policies, QoS Map elements, and TID mapping rules corresponding to the traffic streams added by adding traffic streams (ADDTS) and SCS) to the target AP MLD in the context transfer response, while simultaneously carrying the transferred QoS Map element in the Reassociation Response frame.

[0333] In addition to the early downlink data fronthaul and uplink / downlink data fronthaul shown in the embodiments of this application, this application also provides a new payload type, such as data fronthaul. This new payload type can be used for data fronthaul from the current AP MLD to the target AP MLD.

[0334] Figure 12a is a schematic diagram of a frame format provided in an embodiment of this application. As shown in Figure 12a, the frame may include at least one of the following: LLC, subnetwork access protocol (SNAP), payload type, and payload. The LLC may include a destination service access point (DSAP), a source service access point (SSAP), and control. The SNAP may include a vendor code and an ethertype. This embodiment of the application does not limit the LLC and SNAP fields. For example, the payload field may include at least one of the following: TID, SN, endmark bit, destination address (DA), source address (SA), length, and MSDU. The TID field indicates the TID corresponding to the MSDU, the SN field indicates the SN corresponding to the MSDU, the end flag bit indicates whether uplink or downlink data forwarding has ended, the destination address field indicates the destination of the MSDU, the source address field indicates the source of the MSDU, and the length field indicates the length of the MSDU. The target AP MLD can determine whether the corresponding MSDU is for uplink or downlink data forwarding based on whether the MLD address of the non-AP MLD is carried in the DA or SA, and whether to place the MSDU in the downlink transmit buffer or the uplink receive buffer.

[0335] The number of bytes or bits occupied by each field shown in Figure 12a is merely an example and should not be construed as a limitation on the embodiments of this application. If a reserved bit is included after the end identifier bit, it will not be shown in Figure 12a.

[0336] Table 18 provides an example of the values ​​for the load type field.

[0337] Table 18

[0338] The values ​​of the load type field shown in Table 18 are merely examples and should not be construed as limiting the embodiments of this application.

[0339] In practical applications, a ping-pong phenomenon may occur during roaming. For example, after a non-AP MLD switches from the current AP MLD to a target AP MLD, the received signal strength indication (RSSI) of the target AP MLD (for example only) may be worse than that of the current AP MLD. In this case, the non-AP MLD may switch back to the current AP MLD, resulting in a poor user experience.

[0340] To mitigate the degraded user experience caused by the Ping-Pong phenomenon, this application provides an improved method. When a non-AP MLD successfully switches to a target AP MLD, both the non-AP MLD and the current AP MLD can switch to a new state, such as state 3a. In this state, both the non-AP MLD and the current AP MLD retain the PTKSA for a period of time, or they may also retain the GTKSA. However, the IEEE 802.1X controlled port (hereinafter referred to as the control port) is blocked, and the non-AP MLD and the current AP MLD can send Class 1 or Class 2 frames, or Class 1, Class 2, and Class 3 frames. Specifically, the time for retaining the PTKSA (or GTKSA) can be BSS MAX IDLE PERIOD, or other predefined time values.

[0341] Figure 12b is a schematic diagram of state transitions provided in an embodiment of this application. The state transitions of the device are shown below:

[0342] Status 1: Unauthenticated or unassociated.

[0343] The state transitions shown in Figure 12b can apply to non-AP MLDs, current AP MLDs, or target AP MLDs, etc. For ease of description, the following text will use non-AP MLDs as examples to illustrate each state. For instance, in state 1, a non-AP MLD can send category 1 frames.

[0344] If a non-AP MLD successfully completes preassociation security negotiation (PASN) authentication, the non-AP MLD can switch to state 1a.

[0345] Status 1a: PASN authentication, unassociated status.

[0346] In state 1a, a non-AP MLD can send either Category 1 frames or protected Category 2 frames.

[0347] When a non-AP MLD is in state 1a, performing a deauthentication operation will allow it to switch back to state 1.

[0348] Status 2: Certified (except for uncertified directional multi-gigabit (DMG) sites (DMG STAs), unassociated status.

[0349] In state 2, a non-AP MLD can send frames of type 1 and frames of type 2.

[0350] When a non-AP MLD is in state 1 or state 1a and has successfully authenticated (except for PASN and FILS authentication), it can switch to state 2.

[0351] When a non-AP MLD is in state 2, performing a de-authentication operation (except for DMG STAs that do not undergo authentication) will switch back to state 1.

[0352] In this application's embodiments, "excluding DMG STAs that do not undergo certification" means that DMG STAs may not need to undergo certification. The DMG STAs shown in this application's embodiments that do not undergo certification are merely examples. As standards evolve, other types of devices may emerge that do not undergo certification, and this application's embodiments do not limit this.

[0353] Status 3: Certified (except for DMG STAs that are not certified), associated (RSNA certification pending) status.

[0354] In state 3, a non-AP MLD can send Category 1, Category 2, and Category 3 frames. Simultaneously, the control port is closed.

[0355] When a non-AP MLD is in state 2, and successfully (re)associates and requests RSNA, it can switch to state 3.

[0356] If a non-AP MLD is in state 3, and the deassociation operation is performed or the reassociation (non-AP MLD and non-domain BSS control point site) fails, then it will switch back to state 2.

[0357] When a non-AP MLD is in state 3, if deauthentication is performed (except for DMG STAs that do not perform authentication), it will switch back to state 1.

[0358] Status 4: Certified (except for DMG STAs that are not certified), Associated (RSNA established or not required) status.

[0359] In state 4, a non-AP MLD can send frames of categories 1, 2, and 3. The control port is also open.

[0360] When a non-AP MLD is in state 3 and successfully completes a four-way handshake, it can switch to state 4.

[0361] When a non-AP MLD is in state 2, it can switch to state 4 under the following conditions: successful (re)association - no RSNA requirement; fast BSS transfer; individual domain BSS four-way handshake; fast initial link establishment (re)association and key confirmation.

[0362] If a non-AP MLD is in state 4, and the deassociation operation is performed or the reassociation (non-AP MLD and non-domain BSS control point site) fails, then it will switch back to state 2.

[0363] When a non-AP MLD is in state 4, if deauthentication is performed (except for DMG STAs that do not perform authentication), it will switch back to state 1.

[0364] In this embodiment of the application, after the non-AP MLD is successfully reassociated with the target AP MLD, the non-AP MLD and the target AP MLD can switch to state 4. The non-AP MLD and the current AP MLD can switch to state 3a.

[0365] Status 3a: Authenticated (except for DMG STAs that are not authenticated), not associated (RSNA established) status.

[0366] In state 3a, a non-AP MLD can send category 1,2 frames or category 1,2,3 frames, and close the control port.

[0367] Within a certain period of time, when a non-AP MLD determines that the RSSI of the target AP MLD is worse than the RSSI of the current AP MLD, the non-AP MLD can re-associate with the current AP MLD, that is, the non-AP MLD and the current AP MLD can switch to state 4.

[0368] After a certain period of time, or when a non-AP MLD associates with the current AP MLD, the non-AP MLD and the current AP MLD switch to state 1.

[0369] In this embodiment of the application, the newly defined state 3a can effectively solve the ping-pong phenomenon that occurs during roaming and improve the user experience.

[0370] This application also provides a format for a context transfer response. The context transfer response may include at least one of the following: a status code indicating whether the context transfer request was successful; the MAC address of the Non-AP MLD; a QoS mapping element; and a downlink BA context or uplink BA context.

[0371] For example, the downlink BA context may include, but is not limited to: TID; uplink / downlink bit (UL / DL bit) (which may be used to indicate uplink BA context or downlink BA context); next SN; window start position of the transmit buffer (e.g., denoted as WinStart_O), window size of the transmit buffer (e.g., denoted as WinSize_O); one or more SCS descriptor elements; BA parameters, such as whether A-MSDU is supported, BA timeout value, no fragmentation, HE fragmentation, etc.

[0372] For example, the uplink BA context may include, but is not limited to: TID; uplink / downlink bits (UL / DL bits), bitmap of the scoreboard; the start position of the scoreboard window (e.g., denoted as WinStart_R), the size of the scoreboard window (e.g., WinSize_R); the start position of the receive reordering buffer window (e.g., denoted as WinStart_B) and the size of the window (e.g., WinSize_B); one or more SCS descriptor elements; BA parameters, such as whether A-MSDU is supported, BA timeout value, no fragmentation, HE fragmentation, etc. For a description of the SCS descriptor elements, please refer to the above or the description in the 802.11 standard, etc., which will not be detailed here.

[0373] The above context transfer response is merely an example and should not be construed as limiting the embodiments of this application.

[0374] The following describes the communication device provided in the embodiments of this application.

[0375] This application divides the communication device into functional modules according to the above method embodiments. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application is illustrative and only represents one logical functional division; other division methods may be used in actual implementation. The communication device of the embodiments of this application will be described in detail below with reference to Figures 13 to 15.

[0376] The communication device shown in the embodiments of this application may also be called a sensing communication device or a ranging communication device, etc. This application does not limit the specific name of the device.

[0377] Figure 13 is a schematic diagram of a communication device provided in an embodiment of this application. As shown in Figure 13, the communication device includes a processing module 1301 and a transceiver module 1302. The transceiver module 1302 can implement corresponding communication functions, and the processing module 1301 is used to implement corresponding processing functions. For example, the transceiver module 1302 can also be called an interface module, a communication interface, a communication module, or an input / output interface, etc.

[0378] In some embodiments of this application, the communication device can be used to perform the actions executed by the non-AP MLD in the above method embodiments. In this case, the non-AP MLD can be the WLAN device itself or a chip or functional module configurable in the device. The transceiver module 1302 is used to perform transceiver-related operations or input / output-related operations of the non-AP MLD in the above method embodiments, and the processing module 1301 is used to perform processing-related operations of the non-AP MLD in the above method embodiments.

[0379] The transceiver module 1302 can be used to send or output FT acknowledgment frames and to receive or input FT response frames. The processing module 1301 can be used to generate the FT acknowledgment frame and parse the FT response frame.

[0380] As an example, transceiver module 1302 can be used to send FT acknowledgment frames, such as sending the FT acknowledgment frame to the current AP MLD. Transceiver module 1302 may include radio frequency modules, antenna modules, etc.

[0381] As another example, transceiver module 1302 can be used to output FT acknowledgment frames. Transceiver module 1302 may include input / output modules, etc.

[0382] For example, transceiver module 1302 can also be used to send or output FT acknowledgment frames, and to receive or input FT ACK frames. For example, processing module 1301 can be used to generate FT acknowledgment frames and parse FT ACK frames.

[0383] For example, the transceiver module 1302 can also be used to send or output an early downlink data forwarding request. The processing module 1301 can be used to generate the early downlink data forwarding request.

[0384] For example, transceiver module 1302 can also be used to send or output reassociation request frames, and to receive or input reassociation response frames. For example, processing module 1301 can be used to generate the reassociation request frame and parse the reassociation response frame.

[0385] For example, the transceiver module 1302 can also be used to receive or input FT acknowledgment frames, and to send or output FT ACK frames, etc.

[0386] For further details on non-AP MLD, please refer to the method implementation examples shown above, which will not be listed here again.

[0387] Reusing Figure 13, in some other embodiments of this application, the communication device can be used to perform the actions performed by the current AP MLD in the above method embodiments. In this case, the communication device can be the WLAN device itself or a chip or functional module configurable in the device. The transceiver module 1302 is used to perform transceiver-related operations or input / output-related operations of the current AP MLD in the above method embodiments, and the processing module 1301 is used to perform processing-related operations of the current AP MLD in the above method embodiments.

[0388] The transceiver module 1302 can be used to receive or input FT request frames, and to send or output remote requests corresponding to the FT request frames. Similarly, the processing module 1301 can be used to parse FT request frames or generate remote requests corresponding to the FT request frames.

[0389] As an example, transceiver module 1302 can be used to receive FT request frames from a non-AP MLD. This transceiver module 1302 may include an RF module, an antenna module, etc.

[0390] As another example, transceiver module 1302 can be used to input FT request frames. After the FT request frame is processed by the antenna and radio frequency module, it is input to processing module 1301 through transceiver module 1302, so that processing module 1301 can parse the FT request frame. Transceiver module 1302 may include input / output modules, etc.

[0391] For example, transceiver module 1302 can also be used to receive or input remote responses, and to send or output FT response frames corresponding to the remote responses. For example, processing module 1301 can be used to parse remote responses and generate FT response frames.

[0392] For example, transceiver module 1302 can also be used to receive or input FT acknowledgment frames, and to send or output remote requests corresponding to the FT acknowledgment frames. Processing module 1301 can be used to generate the remote request, etc.

[0393] For example, transceiver module 1302 can also be used to receive or input remote responses, and to send or output FT ACK frames. Processing module 1301 can be used to generate FT ACK frames.

[0394] For example, the transceiver module 1302 can also be used to receive or input early downlink data forwarding requests, or to send or output the early downlink data forwarding requests.

[0395] For a detailed explanation of the current AP MLD, please refer to the method implementation examples shown above, which will not be listed here again.

[0396] Reusing Figure 13, in some other embodiments of this application, the communication device can be used to perform the actions performed by the target AP MLD in the above method embodiments. In this case, the target AP MLD can be the WLAN device itself or a chip or functional module configurable in the device. The transceiver module 1302 is used to perform transceiver-related operations or input / output-related operations of the target AP MLD in the above method embodiments, and the processing module 1301 is used to perform processing-related operations of the target AP MLD in the above method embodiments.

[0397] The transceiver module 1302 can be used to receive or input remote requests, and to send or output remote responses. Similarly, the processing module 1301 can be used to parse remote requests and generate remote responses.

[0398] As an example, transceiver module 1302 can be used to receive remote requests and send remote responses. Transceiver module 1302 may include a radio frequency module, an antenna module, etc.

[0399] As another example, transceiver module 1302 can be used to input remote requests and output remote responses. For instance, transceiver module 1302 may include input / output modules, etc.

[0400] For example, the transceiver module 1302 can also be used to receive or input early downlink data forwarding requests.

[0401] For example, the transceiver module 1302 can also be used to receive or input a reassociation request frame. The processing module 1301 can be used to parse the reassociation request frame.

[0402] For example, transceiver module 1302 can also be used to send or output a reassociation response frame. Processing module 1301 can be used to generate the reassociation response frame.

[0403] For a detailed explanation of the target AP MLD, please refer to the method implementation examples shown above, which will not be listed here again.

[0404] Optionally, in the above embodiments, the communication device may further include a storage module, which can be used to store instructions and / or data. The processing module 1301 can read the instructions and / or data in the storage module so that the device can implement the aforementioned method embodiments.

[0405] For detailed explanations of terms or nouns such as FT request frame, FT response frame, FT acknowledgment frame, FT ACK frame, early downlink data forwarding request, reassociation request frame, reassociation response frame, context transfer request, and context transfer response in the above embodiments, please refer to the descriptions in the above method embodiments, and they will not be detailed here.

[0406] The specific descriptions of the transceiver module and processing module shown in the above embodiments are merely examples. For the specific functions or execution steps of the transceiver module and processing module, please refer to the above method embodiments, which will not be described in detail here.

[0407] It is understood that the module division in the above-described device is merely a logical functional division. Each function can correspond to a functional module, or two or more functions can be integrated into one functional module. In actual implementation, all or some modules can be integrated into a single physical entity, or they can be distributed across different physical entities. Furthermore, the aforementioned functional modules can be implemented in hardware, software, or a combination of both. Whether a function is executed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0408] In one example, the functional unit in any of the above devices may be one or more integrated circuits configured to implement the above methods, such as: one or more application-specific integrated circuits (ASICs), or one or more central processing units (CPUs), one or more microcontroller units (MCUs), one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms.

[0409] The apparatus of the embodiments of this application has been described above. The possible product forms of the described apparatus are described below. Any product possessing the functions of the apparatus described in FIG. 13 above falls within the protection scope of the embodiments of this application. The following description is merely illustrative and does not limit the product form of the apparatus of the embodiments of this application to this.

[0410] In one possible implementation, in the communication device shown in FIG13, the processing module 1301 may be one or more processors, and the transceiver module 1302 may be a transceiver, or the transceiver module 1302 may also be a transmitting module and a receiving module. The transmitting module may be a transmitter, and the receiving module may be a receiver. The transmitting module and the receiving module are integrated into one device, such as a transceiver. In the embodiments of this application, the processor and the transceiver may be coupled, etc., and the connection method of the processor and the transceiver is not limited in the embodiments of this application. In the process of executing the above method, the process of sending information in the above method may be the process of the processor outputting the above information. When outputting the above information, the processor outputs the above information to the transceiver so that the transceiver can transmit it. After the above information is output by the processor, it may need to undergo other processing before reaching the transceiver. Similarly, the process of receiving information in the above method may be the process of the processor receiving the input above information. When the processor receives the input information, the transceiver receives the above information and inputs it into the processor. Furthermore, after the transceiver receives the aforementioned information, the information may need to undergo further processing before being input into the processor.

[0411] Figure 14 is a schematic diagram of another structure of the communication device provided in an embodiment of this application. As shown in Figure 14, the communication device 140 includes one or more processors 1420 and transceivers 1410.

[0412] In some embodiments of this application, the communication device can be used to execute the steps, methods, or functions performed by the non-AP MLD described above. For example, the processor 1420 can be used to execute the functions or steps implemented by the processing module 1301 shown in FIG. 13, and the transceiver 1410 can be used to execute the functions or steps implemented by the transceiver module 1302 shown in FIG. 13. Detailed descriptions of the processor 1420 and transceiver 1410 can be found in FIG. 13 or the method embodiments shown above, and will not be elaborated further here.

[0413] In other embodiments of this application, the communication device is used to execute the steps, methods, or functions currently performed by the AP MLD. For example, the processor 1420 can be used to execute the functions or steps implemented by the processing module 1301 shown in FIG. 13, and the transceiver 1410 can be used to execute the functions or steps implemented by the transceiver module 1302 shown in FIG. 13. Detailed descriptions of the processor 1420 and transceiver 1410 can be found in FIG. 13 or the method embodiments shown above, and will not be elaborated further here.

[0414] In some embodiments of this application, the communication device can be used to execute the steps, methods, or functions performed by the target AP MLD described above. For example, the processor 1420 can be used to execute the functions or steps implemented by the processing module 1301 shown in FIG. 13, and the transceiver 1410 can be used to execute the functions or steps implemented by the transceiver module 1302 shown in FIG. 13. Detailed descriptions of the processor 1420 and transceiver 1410 can be found in FIG. 13 or the method embodiments shown above, and will not be elaborated further here.

[0415] In various implementations of the apparatus shown in Figure 14, the transceiver may include a receiver for performing a receiving function (or operation) and a transmitter for performing a transmitting function (or operation). The transceiver is also used to communicate with other devices / appliances via a transmission medium.

[0416] Optionally, the communication device 140 may further include one or more memories 1430 for storing program instructions and / or data. The memory 1430 is coupled to the processor 1420. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 1420 may operate in conjunction with the memory 1430. The processor 1420 may execute program instructions stored in the memory 1430. Optionally, at least one of the above-mentioned memories may be included in the processor.

[0417] This embodiment does not limit the specific connection medium between the transceiver 1410, processor 1420, and memory 1430. In Figure 14, the memory 1430, processor 1420, and transceiver 1410 are connected via a bus 1440, indicated by a thick line. The connection methods between other components are merely illustrative and not intended to be limiting. The bus can be categorized as an address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 14, but this does not imply that there is only one bus or one type of bus.

[0418] In the embodiments of this application, the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules within the processor.

[0419] In this application embodiment, the memory may include, but is not limited to, non-volatile memory such as hard disk drive (HDD) or solid-state drive (SSD), random access memory (RAM), erasable programmable read-only memory (EPROM), read-only memory (ROM), or compact disc read-only memory (CD-ROM), etc. Memory is any storage medium capable of carrying or storing program code having instruction or data structure forms, and capable of being read and / or written by a computer (such as the device shown in this application), but is not limited to this. The memory in this application embodiment may also be a circuit or any other device capable of implementing storage functions, used to store program instructions and / or data.

[0420] Processor 1420 is primarily used for processing communication protocols and data, controlling the entire device, executing software programs, and processing software program data. Memory 1430 is primarily used for storing software programs and data. Transceiver 1410 may include control circuitry and an antenna. The control circuitry is primarily used for converting baseband signals to radio frequency signals and processing radio frequency signals. The antenna is primarily used for transmitting and receiving radio frequency signals in the form of electromagnetic waves. Input / output devices, such as touchscreens, displays, and keyboards, are primarily used for receiving user input data and outputting data to the user.

[0421] When the device is powered on, the processor 1420 can read the software program in the memory 1430, interpret and execute the instructions of the software program, and process the data of the software program. When data needs to be transmitted wirelessly, the processor 1420 performs baseband processing on the data to be transmitted and outputs the baseband signal to the radio frequency (RF) circuit. The RF circuit processes the baseband signal and transmits the RF signal outward in the form of electromagnetic waves through the antenna. When data is sent to the device, the RF circuit receives the RF signal through the antenna, converts the RF signal into a baseband signal, and outputs the baseband signal to the processor 1420. The processor 1420 converts the baseband signal into data and processes the data.

[0422] In another implementation, the radio frequency circuitry and antenna can be set up independently of the processor performing baseband processing. For example, in a distributed scenario, the radio frequency circuitry and antenna can be arranged remotely, independent of the device.

[0423] The apparatus shown in this application embodiment may have more components than those in Figure 14, and this application embodiment does not limit this. The methods executed by the processor and transceiver shown above are merely examples, and the specific steps executed by the processor and transceiver can be referred to the methods described above.

[0424] In another possible implementation, in the device shown in FIG13, the processing module 1301 can be one or more logic circuits, and the transceiver module 1302 can be an input / output interface, or a communication interface, or an interface circuit, or an interface, etc. Alternatively, the transceiver module 1302 can also be a transmitting module and a receiving module, where the transmitting module can be an output interface and the receiving module can be an input interface, and the transmitting module and the receiving module are integrated into one module, such as an input / output interface.

[0425] Figure 15 is a schematic diagram of another structure of the communication device provided in an embodiment of this application. As shown in Figure 15, the communication device includes a logic circuit 1501 and an interface 1502. That is, the processing module 1301 can be implemented using the logic circuit 1501, and the transceiver module 1302 can be implemented using the interface 1502. The logic circuit 1501 can be a chip, a processing circuit, an integrated circuit, or a system-on-chip (SoC) chip, etc., and the interface 1502 can be a communication interface, an input / output interface, pins, or interface circuits, etc. For example, Figure 15 illustrates a communication device that is a chip, which includes the logic circuit 1501 and the interface 1502.

[0426] In this embodiment, the logic circuit and the interface can also be coupled to each other. The specific connection method of the logic circuit and the interface is not limited in this embodiment. For example, the logic circuit 1501 can be used to execute the functions or steps implemented by the processing module 1301 shown in FIG. 13, and the interface 1502 can be used to execute the functions or steps implemented by the transceiver module 1302 shown in FIG. 13. For a detailed description of the logic circuit 1501 and the interface 1502, please refer to FIG. 13 or the method embodiment shown above, which will not be detailed here.

[0427] The apparatus shown in the embodiments of this application can be implemented in hardware or software, and the embodiments of this application do not limit this.

[0428] This application also provides a communication system that includes at least two of a non-AP MLD, a current AP MLD, or a target AP MLD. The non-AP MLD, the current AP MLD, and the target AP MLD can be used to perform the methods in any of the foregoing embodiments.

[0429] In addition, this application also provides a computer program for implementing the operations and / or processes performed by various devices in the method provided in this application.

[0430] This application also provides a computer-readable storage medium storing computer code that, when executed on a computer, causes the computer to perform the operations and / or processes performed by the various devices in the methods provided in this application.

[0431] This application also provides a computer program product comprising computer code or a computer program that, when run on a computer, causes the operations and / or processes performed by various entities in the method provided in this application to be executed.

[0432] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or modules, or they may be electrical, mechanical, or other forms of connection.

[0433] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the technical effects of the solutions provided in the embodiments of this application.

[0434] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0435] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0436] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A resource request method, characterized in that, The method includes: A non-AP MLD sends a Fast Basic Service Set Transfer (FT) acknowledgment frame to the current access point MLD (AP MLD). The FT acknowledgment frame is used by the non-AP MLD to request resources from the target AP MLD. The FT acknowledgment frame includes a Resource Information Container (RIC) request. The RIC request includes a resource descriptor field. The resource descriptor field includes at least one of the following: a Flow Classification Service (SCS) descriptor element, a Target Wake-up Time (TWT) element, or a wake-up request element. The wake-up request element is used to wake up the first AP belonging to the target AP MLD. The non-AP MLD receives an FT positive ACK frame from the current AP MLD.

2. A resource request method, characterized in that, The method includes: The target access point multi-link device (AP MLD) receives a remote request from the current AP MLD. The remote request is used by a non-access point multi-link device (non-AP MLD) to request resources from the target AP MLD. The remote request includes a Resource Information Container (RIC) request, which includes a resource descriptor field. The resource descriptor field includes at least one of the following: a Flow Classification Service (SCS) descriptor element, a Target Wake-up Time (TWT) element, or a wake-up request element. The wake-up request element is used to wake up the first AP belonging to the target AP MLD. The target AP MLD sends a remote response to the current AP MLD.

3. The method according to claim 1 or 2, characterized in that, The wake-up request element includes wake-up indication information.

4. The method according to claim 3, characterized in that, The wake-up indication information includes updated wake-up parameters corresponding to the first AP.

5. The method according to claim 4, characterized in that, The wake-up indication information includes the Basic Service Set Identifier (BSSID) or Link Identifier (LinkID) of the first AP.

6. The method according to claim 4 or 5, characterized in that, The updated wake-up parameters include at least one of the following: the start time of the wake-up window, the duration of the wake-up window, or the time interval between adjacent wake-up windows; or, The updated wake-up parameters include the duration of the wake-up; or, The updated wake-up parameters include at least one of the following: the bandwidth of the first AP, the number of spatial streams of the first AP, and the modulation and coding scheme (MCS) of the first AP.

7. The method according to any one of claims 1-6, characterized in that, The FT ACK frame includes a RIC data element RDE field, which includes a status code field used to indicate whether the non-AP MLD has successfully requested the resource.

8. The method according to claim 7, characterized in that, The status code field is used to indicate to the non-AP MLD that the target AP MLD rejects the resource corresponding to the SCS descriptor element, and the FT ACK frame includes the SCS descriptor element suggested by the target AP MLD; or, The status code field is used to indicate to the non-AP MLD that the target AP MLD rejects the resource corresponding to the TWT element, and the FT ACK frame includes the TWT element suggested by the target AP MLD; or, The status code field is used to indicate to the non-AP MLD that the target AP MLD rejects the resource corresponding to the wake-up request element, and the FT ACK frame includes the wake-up request element proposed by the target AP MLD.

9. The method according to any one of claims 1-8, characterized in that, The resource descriptor also includes a RIC descriptor element, which includes a resource type field; wherein... When the resource type field is the first value, the RIC descriptor element further includes: a BA parameter set, a BA timeout value, a BA start sequence control, and a parameter set for the Add Block Acknowledgment ADDBA extension; or, When the resource type field is the second value, the RIC descriptor element also includes: a BA parameter set, a BA timeout value, and a parameter set for adding block confirmation ADDBA extension.

10. A resource request method, characterized in that, The method includes: The non-AP MLD receives a Fast Basic Service Set Transfer (FT) response frame from the current AP MLD. The FT response frame includes downlink block acknowledgment (BA) information, which is used to request the establishment of a downlink block acknowledgment session between the target AP MLD and the non-AP MLD. The non-AP MLD sends an FT acknowledgment frame to the current AP MLD; or, The non-AP MLD receives a Fast Basic Service Set Transfer (FT) acknowledgment frame from the current AP MLD. The FT acknowledgment frame includes downlink block acknowledgment (BA) information, which is used to request the establishment of a downlink block acknowledgment session between the target AP MLD and the non-AP MLD. The non-AP MLD sends an FT positive ACK frame to the current AP MLD.

11. A resource request method, characterized in that, The method includes: The target access point multi-link device (AP MLD) sends a remote request to the current AP MLD. The remote request includes downlink block acknowledgment (BA) information, which is used to request the establishment of a downlink block acknowledgment session between the target AP MLD and the non-AP MLD. The target AP MLD receives a remote response from the current AP MLD.

12. The method according to claim 11, characterized in that, The remote request includes downlink BA information, including: The remote request includes a Fast Basic Service Set Transfer (FT) response frame, the FT response frame including the downlink BA information; or... The remote request includes an FT acknowledgment frame, which includes downlink BA information.

13. The method according to any one of claims 10-12, characterized in that, The downlink BA information includes: BA parameter set, BA timeout value, BA start sequence control, and ADDBA extension.

14. The method according to claim 10 or 12, characterized in that, The FT response frame further includes a Fast Basic Service Set Transfer (FTE), the FTE including a Message Integrity Encoding (MIC), the MIC being used to verify the FT response frame; or... The FT confirmation frame also includes an FTE, and the FTE includes a MIC, which is used to verify the FT confirmation frame.

15. A communication device, characterized in that, Includes a module for performing the method as described in any one of claims 1-14.

16. A communication device, characterized in that, Includes a processor for performing the method as described in any one of claims 1-14.

17. The method according to claim 16, characterized in that, The communication device also includes a transceiver for sending or receiving information.

18. A communication device, characterized in that, Includes logic circuits and interfaces, wherein the logic circuits and interfaces are coupled; The interface is used for inputting and / or outputting information, and the logic circuit is used for performing the method as described in any one of claims 1-14.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, which, when executed, performs the method as described in any one of claims 1-14.

20. A computer program product, characterized in that, When the computer program product is executed, the method described in any one of claims 1-14 is performed.

21. A communication system, characterized in that, The method includes a non-access point multilink device (non-AP MLD) and a target access point multilink device (AP MLD), wherein the non-AP MLD is used to perform the method as described in any one of claims 1, 3-9, and the target AP MLD is used to perform the method as described in any one of claims 2-9; or, the non-AP MLD is used to perform the method as described in any one of claims 10, 12-14, and the target AP MLD is used to perform the method as described in any one of claims 11-14.

Images