Resource request method, device and system

Abstract

A resource request method, device and system can be applied to the technical field of communication. The application can support the IEEE (Institute of Electrical and Electronic Engineers) protocol, such as an IEEE 802.11 be / Wi-Fi 7 / EHT (Institute of Electrical and Electronic Engineers) protocol, an IEEE 802.11 bn / UHR / Wi-Fi 8 protocol, an IEEE 802.15 / UWB (Ultra Wideband) protocol, an IEEE 802.11 bf / perception protocol, an integrated millimeter wave IMMW (Institute of Millimeter Wave) protocol and the like. The non-AP MLD sends an FT acknowledgement frame to the target AP MLD through the current AP MLD, the FT acknowledgement frame may include an RIC request, the RIC request including a resource descriptor field, and the resource descriptor resource may include an SCS descriptor element or a TWT element or a wake-up request element. The target AP MLD may send an FT ACK frame to the non-AP MLD through the current AP MLD. The method can effectively reduce the roaming delay and improve the roaming efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication technology, and in particular to a resource request method, device and system. BACKGROUND

[0002] In a roaming scenario, a non-access point (AP) multi-link device (non-AP MLD) can roam from a current AP MLD (current AP MLD) associated therewith to a target AP MLD (target AP MLD).

[0003] In the existing fast basic service set (BSS) transition (FT) protocol, the non-AP MLD can support negotiation of an uplink block acknowledgement session with the target AP MLD through the current AP MLD, and increase quality of service (QoS) service flow.

[0004] However, the existing resource request method increases roaming latency and reduces roaming efficiency. SUMMARY

[0005] Embodiments of the present application provide a resource request method, device and system, which can effectively reduce roaming latency and improve roaming efficiency.

[0006] In a first aspect, the embodiments of the present application provide a resource request method, which can be applied to a non-access point (AP) multi-link device (non-AP MLD). The non-AP MLD can be a WLAN device, or can be a chip or functional module or communication component in a WLAN device. The resource request method comprises:

[0007] The non-AP MLD sends a fast basic service set (BSS) transition (FT) confirm frame to a current access point multi-link device (AP MLD), the FT confirm frame is used for the non-AP MLD to request resources from a target AP MLD, the FT confirm frame includes a resource information container (RIC) request, the RIC request includes a resource descriptor field, and the 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 used to wake up a first AP affiliated to the target AP MLD; and the non-AP MLD receives an FT acknowledgement (ACK) frame from the current AP MLD in response to the FT confirm frame.

[0008] In the embodiments of the present application, at least one of the SCS descriptor element, the TWT element, or the wake-up request element is added in the FT confirm frame, which can effectively reduce the roaming delay, improve the roaming efficiency, and improve the roaming experience of the non-AP MLD.

[0009] In a second aspect, the embodiments of the present application provide a resource request method, which can be applied to a target access point multi-link device (target AP MLD). The target AP MLD can be a WLAN device, or a chip or a functional module or a communication component arranged in the WLAN device. The resource request method includes the following steps.

[0010] The target AP MLD receives a remote request from the current AP MLD, the remote request is used for the non-AP MLD to request resources from the target AP MLD, the remote request includes a resource information container (RIC) request, the RIC request includes a resource descriptor field, and the resource descriptor field includes at least one of the following: an SCS descriptor element, a TWT element, or a wake-up request element used to wake up a first AP affiliated to the target AP MLD; and the target AP MLD sends a remote response to the current AP MLD.

[0011] In the embodiments of the present application, the remote request can correspond to the FT confirmation frame, that is, the content in the remote request can be determined based on the FT confirmation frame. The remote response can correspond to the FT ACK frame, such as the content in the remote response can be determined based on the FT ACK frame.

[0012] In a third aspect, the embodiments of the present 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 can be a chip or a functional module or a communication component arranged in a WLAN device. The resource request method comprises:

[0013] The current AP MLD receives a fast basic service set transfer (FT) confirmation frame from a non-AP MLD, the FT confirmation frame being used for the non-AP MLD to request resources from a target AP MLD, the FT confirmation frame comprising a resource information container (RIC) request, the RIC request comprising a resource descriptor field, the resource descriptor field comprising at least one of a stream classification service (SCS) descriptor element, a target wake time (TWT) element or a wake request element, the wake request element being used to wake up a first AP affiliated to the target AP MLD; and the current AP MLD sends a remote request to the target AP MLD, the remote request being determined based on the FT confirmation frame (such as the remote request can comprise the RIC request).

[0014] In combination with the third aspect, in a possible implementation manner, the current AP MLD receives a remote response from the target AP MLD, and sends an FT ACK frame to the non-AP MLD, the FT ACK frame being determined based on the remote response.

[0015] In combination with the first aspect to the third aspect, in a possible implementation manner, the wake request element comprises wake-up indication information.

[0016] In combination with the first aspect to the third aspect, in a possible implementation manner, the wake-up indication information comprises updated wake-up parameters corresponding to the first AP.

[0017] In other words, the wake-up indication information can comprise updated wake-up parameters corresponding to the first AP.

[0018] In combination with the first aspect to the third aspect, in a possible implementation manner, the wake-up indication information comprises a basic service set identifier (BSSID) or a link ID of the first AP.

[0019] In the embodiments of the present application, the wake-up indication information includes a BSSID or a link ID, so as to explicitly indicate the first AP to wake up.

[0020] In combination with the first aspect to the third aspect, in a possible implementation, the wake-up indication information includes a link bitmap, 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.

[0021] In combination with the first aspect to the third aspect, in a possible implementation, the updated wake-up parameter includes at least one of a start time of the wake-up window, a duration of the wake-up window, or a time interval between adjacent wake-up windows; or the updated wake-up parameter includes a duration of the wake-up; or the updated wake-up parameter includes at least one of a bandwidth of the first AP, a number of spatial streams of the first AP, or a modulation and coding strategy (MCS) of the first AP.

[0022] Generally, when the first AP is in the power saving mode, the throughput of the non-AP MLD roaming to the target AP MLD is reduced. Meanwhile, if the first AP is the AP with the largest coverage in the target AP MLD, the non-AP MLD can not be able to timely roam to the target AP MLD when the first AP is in the power saving mode. Therefore, in the embodiments of the present application, the updated wake-up parameter can avoid the above situation and improve the roaming experience of the non-AP MLD.

[0023] In combination with the first aspect to the third aspect, in a possible implementation, the FT ACK frame includes an RIC data element (RDE) field, and the RDE field includes a status code field, which is used to indicate whether the non-AP MLD successfully requests the resource.

[0024] In combination with the first aspect to the third aspect, in a 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 an SCS descriptor element recommended 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 a TWT element recommended 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 a wake-up request element recommended by the target AP MLD.

[0025] With reference to the first aspect to the third aspect, in a possible implementation, the resource descriptor resource further includes a RIC descriptor element, and the RIC descriptor element includes a resource type field; 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 of an additional block acknowledgement 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 of an additional block acknowledgement ADDBA extension.

[0026] In the embodiments of the present application, a new resource request is added in the FT confirmation frame, and the resource type of the new resource request can be an enhanced block acknowledgement parameter. The new resource type can be used for HE dynamic fragmentation. In this way, the delay introduced by the parameter negotiation after roaming is avoided, and the roaming delay is effectively reduced.

[0027] In the embodiments of the present application, a new resource type is added in the FT confirmation frame, and the resource type of the new resource request can be an enhanced block acknowledgement parameter transfer. The new resource type can be used for block acknowledgement parameter negotiation in the context transfer scenario. In this way, in the context transfer scenario, the non-AP MLD or the target AP MLD can update other block acknowledgement parameters except the start SN, so that the target AP MLD and the non-AP MLD can establish a suitable block acknowledgement session protocol according to their own capabilities.

[0028] The content carried in the FT confirmation frame can also be carried in the reassociation request frame, and similarly, the content carried in the FTACK frame can also be carried in the reassociation response frame.

[0029] In a fourth aspect, the embodiments of the present application provide a resource request method. The method can be applied to a non-AP MLD, which can be a WLAN device, or a chip or a functional module or a communication component arranged in the WLAN device.

[0030] The non-AP MLD receives an FT response frame from a current AP MLD, and the FT response frame includes downlink block acknowledgement (block ACK, BA) information, the downlink BA information being used to request establishment of a downlink block acknowledgement session between the target AP MLD and the non-AP MLD; and the non-AP MLD sends an FT confirmation frame to the current AP MLD.

[0031] Alternatively, the non-AP MLD receives an FT confirmation frame from the current AP MLD, the FT confirmation frame including downlink block acknowledgement (BA) information used to request establishment of a downlink BA session between the target AP MLD and the non-AP MLD; and the non-AP MLD sends an FT ACK frame to the current AP MLD.

[0032] In the embodiments of the present application, the non-AP MLD and the target AP MLD are supported to negotiate downlink BA session parameters. Thus, the roaming delay can be effectively reduced, and the roaming efficiency is improved.

[0033] In a fifth aspect, the embodiments of the present application provide a resource request method, which can be applied to a target AP MLD. The target AP MLD can be a WLAN device, or can be a chip or a functional module or a communication component arranged in the WLAN device.

[0034] The target AP MLD sends a remote request to the current AP MLD, the remote request including downlink BA information used to request establishment of a downlink BA session between the target AP MLD and the non-AP MLD; and the target AP MLD receives a remote response from the current AP MLD.

[0035] With reference to the fifth aspect, in a possible implementation manner, the remote request includes the downlink BA information, including:

[0036] The remote request includes an FT response frame including the downlink BA information; or the remote request includes an FT confirmation frame including the downlink BA information.

[0037] In a sixth aspect, the embodiments of the present application provide a resource request method, which can be applied to a current AP MLD. The current AP MLD can be a WLAN device, or can be a chip or a functional module or a communication component arranged in the WLAN device. The resource request method includes:

[0038] The current AP MLD receives a remote request from a target AP MLD, the remote request including downlink BA information;

[0039] The current AP MLD sends an FT response frame (or an FT confirmation frame) to the non-AP MLD, the FT response frame (or the FT confirmation frame) being determined based on the remote request.

[0040] With reference to the sixth aspect, in a possible implementation manner, the current AP MLD can further receive an FT confirmation frame (or FT ACK frame) from the non-AP MLD, and send a far-end response to the target AP MLD.

[0041] With reference to the fourth aspect to the sixth aspect, in a possible implementation manner, the downlink BA information includes a BA parameter set, a BA timeout value, a BA start sequence control, and an ADDBA extension.

[0042] With reference to the fourth aspect to the sixth aspect, in a possible implementation manner, the FT response frame further includes a fast BSS transition element (FTE), and the FTE includes a message integrity code (MIC), where the MIC is used to verify the FT response frame; or the FT confirmation frame further includes the FTE, and the FTE includes the MIC, where the MIC is used to verify the FT confirmation frame.

[0043] In the seventh aspect, an embodiment of the present application provides a resource request method, which can be applied to a non-access point (AP) multi-link device (non-AP MLD). The non-AP MLD can be a WLAN device, or can be a chip or a functional module or a communication component arranged in the WLAN device. The resource request method includes the following steps.

[0044] Before the non-AP MLD sends the reassociation request frame, the non-AP MLD sends data forwarding indication information to the current AP MLD, where the data forwarding indication information is used to indicate a downlink TID of the current AP MLD for data forwarding.

[0045] In other words, the data forwarding indication information can be used to instruct the current AP MLD to transfer data of the downlink TID to the target AP MLD.

[0046] With reference to the seventh aspect, in a possible implementation manner, the current AP MLD and the target AP MLD have the same QoS configuration strategy.

[0047] With reference to the seventh aspect, in a possible implementation manner, the data forwarding indication information includes MLD address information of the target AP MLD or a buffer size, where the buffer size is used to indicate a maximum number of MSDUs buffered by the target AP MLD to the current AP MLD.

[0048] In an eighth aspect, an embodiment of the present application provides a communication apparatus, configured to execute the method in any one of the first aspect to the seventh aspect or any possible implementation manner.

[0049] In a ninth aspect, an embodiment of the present application provides a communication apparatus, comprising a processor, configured to execute the method in any one of the first aspect to the seventh aspect or any possible implementation manner.

[0050] In a possible implementation manner, the memory is located outside the communication apparatus.

[0051] In a possible implementation manner, the memory is located inside the communication apparatus.

[0052] In the embodiments of the present application, the processor and the memory can also be integrated into one device, that is, the processor and the memory can also be integrated together. For example, the communication apparatus can be a chip.

[0053] In a possible implementation manner, the communication apparatus further comprises a transceiver, configured to receive or send information.

[0054] In a tenth aspect, an embodiment of the present application provides a communication apparatus, comprising a logic circuit and an interface, wherein the logic circuit and the interface are coupled; the interface is configured to input and / or output information, and the logic circuit is configured to execute the method in any one of the first aspect to the seventh aspect or any possible implementation manner.

[0055] In an eleventh aspect, an embodiment of the present application provides a computer readable storage medium, configured to store a computer program, when running on a computer, to cause the method in any one of the first aspect to the seventh aspect or any possible implementation manner to be executed.

[0056] In a twelfth aspect, an embodiment of the present application provides a computer program product, when running on a computer, to cause the method in any one of the first aspect to the seventh aspect or any possible implementation manner to be executed.

[0057] In a thirteenth aspect, an embodiment of the present application provides a communication system, the communication system comprising a non-AP MLD and a target AP MLD, the non-AP MLD being configured to perform the method of any possible implementation of the first aspect or the first aspect (or the fourth aspect) above, the non-AP MLD being configured to perform the method of any possible implementation of the second aspect or the second aspect (or the fifth aspect) above.

[0058] As a possible implementation, the communication system further comprises a current AP MLD, the current AP MLD being configured to perform the method of any possible implementation of the third aspect or the third aspect (or the sixth aspect) above. BRIEF DESCRIPTION OF DRAWINGS

[0059] Figure 1a is a schematic diagram of an architecture of a communication system provided by an embodiment of the present application;

[0060] Figure 1b is another schematic diagram of an architecture of a communication system provided by an embodiment of the present application;

[0061] Figure 2 is a schematic diagram of an address of an MLD provided by an embodiment of the present application;

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

[0063] Figure 4 is a schematic diagram of a procedure of BA session establishment provided by an embodiment of the present application;

[0064] Figure 5a is a schematic diagram of a frame format of an ADDBA request frame / ADDBA response frame provided by an embodiment of the present application;

[0065] Figure 5b is a schematic diagram of a format of a BA parameter set field provided by an embodiment of the present application;

[0066] Figure 5c is a schematic diagram of a format of an ADDBA extension field provided by an embodiment of the present application;

[0067] Figure 6a is a schematic diagram of a frame format of an FT request frame provided by an embodiment of the present application;

[0068] Figure 6b is a schematic diagram of a format of a fast BSS transition element (FTE) provided by an embodiment of the present application;

[0069] Figure 6c is a schematic diagram of a format of an MDE provided by an embodiment of the present application;

[0070] Figure 7 is a frame format schematic diagram of an FT response frame provided by an embodiment of the present application;

[0071] Figure 8 is a frame format schematic diagram of an FT confirmation frame provided by an embodiment of the present application;

[0072] Figure 9 is a frame format schematic diagram of an FT ACK frame provided by an embodiment of the present application;

[0073] Figure 10 is a format schematic diagram of RIC request / RIC response provided by an embodiment of the present application;

[0074] Figure 11 is a flow schematic diagram of a resource request method provided by an embodiment of the present application;

[0075] Figure 12a is a frame format schematic diagram provided by an embodiment of the present application;

[0076] Figure 12b is a state transition schematic diagram provided by an embodiment of the present application;

[0077] Figure 13 is a structure schematic diagram of a communication device provided by an embodiment of the present application;

[0078] Figure 14 is another structure schematic diagram of a communication device provided by an embodiment of the present application;

[0079] Figure 15 is still another structure schematic diagram of a communication device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0080] In order to facilitate understanding of the technical solutions of the present application, the present application will be further described below with reference to the drawings.

[0081] The terms "first" and "second" and the like in the specification of the present application, claims, and drawings are only used to distinguish different objects, and are not used to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device, etc. including a series of steps or units is not limited to the listed steps or units, but can optionally include other steps or units not listed, or can optionally include other steps or units inherent to the process, method, product, or device, etc.

[0082] Reference to an "example" herein means that a particular feature, structure, or characteristic described in connection with the example can be included in at least one example of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same example, nor are they necessarily mutually exclusive of other examples. One of skill in the art will understand that an example described herein can be combined with another example to create another example.

[0083] In the present application, "at least one" means one or more, "multiple" means two or more, "at least two" means two or three and more, and "and / or" is used to describe the association relationship of the associated objects, which means that there can be three relationships, for example, "A and / or B" can mean: only A, only B, and A and B exist at the same time, where A and B can be singular or plural. "Or" means that there can be two relationships, such as only A, only B; when A and B are not mutually exclusive, it can also mean that there are three relationships, such as only A, only B, and A and B exist at the same time. The character " / " generally represents an "or" relationship between the associated objects before and after it. "At least one of the following" or similar expressions means any combination of these items. For example, at least one 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".

[0084] In the present application, "sending" and "receiving" represent the direction of signal transmission. For example, "sending information to XX" can be understood as that the destination of the information is XX, which can include direct sending through the air interface, or indirect sending through the air interface by other units or modules. "Receiving information from YY" can be understood as that the source of the information is YY, which can include direct receiving from YY through the air interface, or indirect receiving from YY through the air interface by other units or modules. "Sending" can also be understood as the "output" of the chip interface, and "receiving" can also be understood as the "input" of the chip interface. In other words, sending and receiving can be carried out between devices, such as between network devices and terminal devices, or can be carried out within a device, such as between components, modules, chips, software modules or hardware modules within a device through a bus, wire or interface.

[0085] The present application provides a resource request method, device and system, which can effectively reduce roaming delay, improve roaming efficiency, and improve user experience during roaming.

[0086] The following introduces a system related to the embodiments of the present application.

[0087] The technical solutions provided in the embodiments of the present application can be applied to a wireless local area network (WLAN) system, such as Wi-Fi and the like. The technical solutions provided in the embodiments of the present application can be applicable to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 series of protocols (or standards), for example, the 802.11be protocol, the 802.11bn protocol (or Wi-Fi 8, also referred to as ultra high reliability (UHR) or ultra high reliability and throughput (UHRT), and the like), or a next-generation protocol of the 802.11bn protocol or a protocol supporting ambient power (AMP), and the like, which are not listed one by one. The technical solutions provided in the embodiments of the present application can also be applied to a wireless personal area network (WPAN) based on integrated millimeter wave (IMMW) and ultrawideband (UWB) technology, and the like. The technical solutions provided in the embodiments of the present application can be applicable to the IEEE 802.15 series of protocols, for example, the 802.15.4a protocol, the 802.15.4z protocol or the 802.15.4ab protocol, or a future generation UWB WPAN protocol, and the like, which are not listed one by one. The technical solutions provided in the embodiments of the present application can also be applied to a spark link or nearlink standard protocol. The technical solutions provided in the embodiments of the present application can also be applied to a communication system, for example, can be an internet of things (IoT) system, a vehicle-to-everything (V2X) system (X can represent any thing), a device-to-device (D2D) system, a narrow band IoT (NB-IoT) system, a long term evolution (LTE) system, a 5th-generation (5G) communication system, and a new communication system to be generated in future communication development, and the like. For example, the V2X can include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P) or vehicle-to-network (V2N) communication, and the like.

[0088] The WLAN system can provide high-rate and low-latency transmission. As the WLAN application scenarios continue to evolve, the WLAN system will be applied to more scenarios or industries, such as the Internet of Things industry, the Internet of Vehicles industry, or the banking industry, enterprise offices, sports venues, exhibition halls, concert halls, hotel rooms, dormitories, hospital rooms, classrooms, supermarkets, squares, streets, production workshops, and warehouses, etc. Of course, the device (such as an access point or a station) supporting WLAN communication or sensing can be a sensor node in a smart city (such as a smart water meter, a smart electricity meter, a smart air detection node), a smart device in a smart home (such as a smart camera, a projector, a display screen, a television, a sound system, a refrigerator, a washing machine, etc.), a node in the Internet of Things, an entertainment terminal (such as an augmented reality (AR) device, a virtual reality (VR) device, etc.), a smart device in a smart office (such as a printer, a projector, a loudspeaker, a sound system, etc.), a vehicle-to-vehicle device in the Internet of Vehicles, infrastructure in daily life scenarios (such as a vending machine, a self-service navigation station in a supermarket, a self-service checkout device, a self-service ordering machine, etc.), and a device in a large sports or music venue, etc.

[0089] Although the embodiments of the present application mainly take WLAN as an example, especially the network applying to the IEEE 802.11 series standards. The various aspects involved in the embodiments of the present application can be extended to other networks adopting various standards or protocols. For example, Bluetooth, high performance radio LAN (HIPERLAN) (a wireless standard similar to the IEEE 802.11 standard), and a wide area network (WAN) or other now known or later developed networks.

[0090] The method provided by the embodiments of the present application can be implemented by a communication device in a communication system. For example, the communication device can be an access point (AP) or a station (STA) or a multi-link device. The following is described in detail:

[0091] The AP is a device with wireless communication function, which supports communication or sensing or energy transmission by using WLAN protocol, has the function of communication or sensing with other devices (such as non-AP STA or other AP) in the WLAN network or energy transmission, and of course, can also have the function of communication or sensing or energy transmission with other devices. Alternatively, the AP is equivalent to a bridge connecting wired and wireless networks, and mainly functions to connect various wireless network clients together and then access the wireless network to the Ethernet. In the WLAN system, the AP can be referred to as an AP station (AP STA). The above device can be a whole device, or a chip, processing system or functional module installed in the whole device, and the device installed with the chip or processing system or functional module can realize the method and function of the embodiments of the present application under the control of the chip or processing system or functional module. The AP in the embodiments of the present application is a device providing services for non-AP STA, which can support 802.11 series protocol or subsequent protocol, etc. For example, the AP can be an access point for terminals (such as mobile phones) to enter wired (or wireless) network, which is mainly deployed in homes, buildings and parks, and the typical coverage radius is dozens of meters to hundreds of meters, and of course, can also be deployed outdoors. For another example, the AP can be a communication server, a router, a switch, a network bridge and other communication entities; the AP can include various forms of macro base stations, micro base stations, relay stations, etc. Of course, the AP can also be a chip or processing system or module in the above various forms of devices, so as to realize the method and function of the embodiments of the present application. The description of the AP herein is also applicable to the AP multi-link device (AP MLD) shown below.

[0092] The STA is a device with wireless communication function, supports communication or sensing or energy transmission by using WLAN protocol, and has the ability to communicate or sense or energy transmission with other non-AP STAs or access points in the WLAN network. In the WLAN system, the station can be referred to as a non-access point station (non-AP STA). For example, the STA is any user communication device that allows a user to communicate or sense or energy transmission with an AP and then communicate with a WLAN. The above device can be a whole device, or a chip or processing system or functional module installed in the whole device. The device installed with the chip or processing system or functional module can realize the method and function of the embodiments of the present application under the control of the chip or processing system or functional module. For example, the STA can be a wireless communication chip, a wireless sensor or a wireless communication terminal, and can also be referred to as a user. For another example, the STA can be a mobile phone supporting Wi-Fi communication function, a tablet computer supporting Wi-Fi communication function, a set-top box supporting Wi-Fi communication function, a smart television supporting Wi-Fi communication function, a smart wearable device supporting Wi-Fi communication function, a vehicle-mounted communication device supporting Wi-Fi communication function and a computer supporting Wi-Fi communication function. Of course, the STA can also be a chip or processing system or module in the above various forms of devices, so as to realize the method and function of the embodiments of the present application. The description of the STA herein is also applicable to the non-AP multi-link device (non-AP MLD) shown below.

[0093] The multi-link device in the embodiments of the present application can be a device with a single radio frequency module (such as an AP or a non-AP STA), or a device with multiple radio frequency modules. The number of radio frequency modules included in the multi-link device in the embodiments of the present application is not limited. The non-AP MLD shown below in the present application can include a device with multiple radio frequency modules, or a device (STA) with a single radio frequency module. The AP MLD can include a device with multiple radio frequency modules, or a device (such as an AP) with a single radio frequency module.

[0094] Exemplarily, a multi-link device (MLD) refers to a device that has multiple radio frequency modules working on different frequency bands or channels at the same time. When the channels on which the two radio frequency modules in a multi-link device work are far enough apart, they can operate independently without interfering with each other. If any two radio frequency modules support a link to be transmitted while the other link is received, it can be said that the two links support simultaneous transmitting and receiving (STR) capability, otherwise, it can be said that the two links do not have non-simultaneous transmitting and receiving (NSTR) capability. A multi-link device includes multiple affiliated stations, which can be physical stations or logical stations, and each station can work on a link or a frequency band or a channel. The affiliated stations shown here can be APs or non-AP STAs. For the convenience of description, the multi-link device with affiliated stations as APs can be referred to as a multi-link AP or a multi-link AP device or an AP multi-link device (AP MLD). The multi-link device with affiliated stations as non-AP STAs can be referred to as a multi-link STA or a multi-link STA device or a STA multi-link device (STA MLD), or the multi-link device with affiliated stations as non-AP STAs can be referred to as a multi-link non-AP or a multi-link non-AP device or a non-AP multi-link device (non-AP MLD). The multi-link device (here, it can be a non-AP MLD or an AP MLD) is a communication device with wireless communication function. The communication device can be a whole device, or a chip or a processing system or a functional module installed in the whole device, and the chip or the processing system or the functional module can implement the method or function of the embodiments of the present application.

[0095] The MLD can implement wireless communication in compliance with the 802.11 series protocols, for example, in compliance with the extremely high throughput (EHT) or the 802.11be protocol or the 802.11bn protocol, to realize communication with other devices. Of course, the other devices can be multi-link devices or can not be multi-link devices.

[0096] Figure 1a is a schematic diagram of a communication system provided by the embodiments of the present application. As shown in Figure 1aAs shown, 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, and n can be greater than or equal to 1. The AP MLD and the non-AP MLD can communicate in parallel through link 1, link 2, …, and link n. STA1 in the non-AP MLD is associated with AP1 in the AP MLD, STA2 in the non-AP MLD is associated with AP2 in the AP MLD, STAn in the non-AP MLD is associated with APn in the AP MLD, and so on. Thus, one or more non-AP STAs in the non-AP MLD and one or more APs in the AP MLD can communicate or sense, etc., after the association. The frequency bands in which the multi-link device (including the AP MLD and the non-AP MLD) operates can include, but are not limited to, sub 1 GHz, 2.4 GHz, 5 GHz, 6 GHz, and high frequency 60 GHz, etc. With the development of standards, the multi-link device can also support other frequency bands, and the embodiments of the present application are not limited thereto.

[0097] Figure 1b is another architecture of a communication system provided by an embodiment of the present application. The 802.11 standard focuses on the 802.11 physical layer (PHY) and medium access control (MAC) layer part of the multi-link device, so the multi-link device includes the 802.11 PHY and MAC layer. Figure 1b The PHY and MAC layer are shown by way of example.

[0098] As shown, the multi-link device (such as a multi-link AP or a multi-link non-AP) can include a PHY (such as PHY#1 and PHY#2 shown) 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, in the MAC layer, there can be a high-MAC layer (such as high-MAC shown) and multiple low-MAC layers (such as low-MAC#1 and low-MAC#2 shown). Figure 1b Figure 1b As shown, the multi-link device (such as a multi-link AP or a multi-link non-AP) can include a PHY (such as PHY#1 and PHY#2 shown) 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, in the MAC layer, there can be a high-MAC layer (such as high-MAC shown) and multiple low-MAC layers (such as low-MAC#1 and low-MAC#2 shown). Figure 1b Figure 1b As shown, the multi-link device (such as a multi-link AP or a multi-link non-AP) can include a PHY (such as PHY#1 and PHY#2 shown) 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, in the MAC layer, there can be a high-MAC layer (such as high-MAC shown) and multiple low-MAC layers (such as low-MAC#1 and low-MAC#2 shown). Figure 1b ​​As shown, the plurality of APs included in the multi-link AP are independent of each other at the low MAC layer and the PHY, and share the high MAC layer. The plurality of STAs included in the multi-link non-AP are independent of each other at the low MAC layer and the PHY, and share the high MAC layer. The high MAC layer is connected to the plurality of low MAC layers respectively, and the high MAC layer can be shared by the plurality of links. Exemplarily, the high MAC layer mainly completes operations such as allocation and encryption and decryption of sequence numbers (SNs) and packet numbers (PNs) of MAC service data units (MSDUs). Exemplarily, the low MAC layer mainly completes operations such as assembly, channel access, packet sending and receiving confirmation of MAC protocol data units (MPDUs) of respective links. The functions implemented by the high MAC layer or the low MAC layer shown herein are only examples, and should not be construed as a limitation on the embodiments of the present application.

[0099] In Figure 1b , the PHY#1 layer, the low MAC#1 layer and the high MAC layer in the multi-link AP can be regarded as the AP#1, and the PHY#2 layer, the low MAC#2 layer and the high MAC layer can be regarded as the AP#2, that is, the multi-link AP can include two AP entities. In the multi-link non-AP, the case is similar, that is, the high MAC layer in the multi-link non-AP is also shared by the plurality of links, the PHY#1 layer, the low MAC#1 layer and the high MAC layer are regarded as the STA#1 (or referred to as the non-AP STA#1), and the PHY#2 layer, the low MAC#2 layer and the high MAC layer are regarded as the STA#2 (or referred to as the non-AP STA#2), that is, the multi-link non-AP includes two STA entities (i.e., two non-AP STA entities). As Figure 1b shown, the PHY#1 of the AP#1 in the multi-link AP and the PHY#1 of the STA#1 in the multi-link non-AP work on the same channel, for example, the AP#1 in the multi-link AP and the STA#1 in the multi-link non-AP implement communication through a link (such as the link#1 shown in the figure). Figure 1b As shown, the PHY#2 of the AP#2 in the multi-link AP and the PHY#2 of the STA#2 in the multi-link non-AP work on another same channel, for example, the AP#2 in the multi-link AP and the STA#2 in the multi-link non-AP implement communication through a link (such as the link#2 shown in the figure). Figure 1b As shown, the PHY#1 of the AP#1 in the multi-link AP and the PHY#1 of the STA#1 in the multi-link non-AP work on the same channel, for example, the AP#1 in the multi-link AP and the STA#1 in the multi-link non-AP implement communication through a link (such as the link#1 shown in the figure).

[0100] Exemplarily, the high MAC layer or the low MAC layer can be implemented by one processor in a chip system of the multi-link device, and can also be implemented by different software processing modules in one chip system, and the like, which are not listed herein. Figure 1b The function module division of the multi-link device can be performed, Figure 1b Each module shown can be implemented in the form of hardware or in the form of a software function module, etc. Figure 1b The PHY and MAC layers shown can be understood as a logical function division, and other division manners can also be used in actual implementation, which is not limited in the present application. Figure 1b The multi-link device includes two stations, and in actual implementation, the multi-link device can further include more or fewer stations, which is not listed here.

[0101] Figure 2 The address diagram of the MLD provided by the embodiment of the present application is shown in FIG. 2. As shown in FIG. 2, Figure 2 For the multi-link device, each link in each multi-link device can correspond to a link address, such as link address 1 (linkaddress 1) and link address 2 (linkaddress 2) in FIG. 2. That is, each link in each MLD can have a respective MAC address (MAC address). In addition, the multi-link device can also correspond to an MLD MAC address (MLD MAC address). As shown in the architecture shown in FIG. 2, 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 the respective links. For example, the MLD MAC address can also be referred to as the high MAC layer address of the MLD, and the link address can also be referred to as the low MAC layer address of the MLD. Figure 2 Figure 1b

[0102] Figure 3 The system architecture diagram in the roaming scenario provided by the embodiment of the present application is shown in FIG. 3. The system architecture can include at least two AP MLDs and at least one non-AP MLD. Figure 3 Two AP MLDs, such as AP MLD 1 and AP MLD 2, and one non-AP MLD are exemplarily shown. In the roaming scenario, the non-AP MLD can roam from the AP MLD 1 to the AP MLD 2. The roaming shown in the present application can be replaced by switching or moving, that is, the roaming, switching or moving can be replaced by each other.

[0103] Figure 3 ​​In this case, the non-AP MLD can roam from the AP MLD 1 to the AP MLD 2, and therefore, as a possible implementation manner, the AP MLD 1 can also be referred to as a current AP MLD or a source AP MLD or an old AP MLD, and the AP MLD 2 can also be referred to as a target AP MLD or a new AP MLD, and the non-AP MLD can also be referred to as a fast transition originator (FTO). The specific names of the non-AP MLD, the AP MLD 1 and the AP MLD 2 are not limited in the embodiments of this application. For ease of description, the current AP MLD and the target AP MLD are described below.

[0104] In the roaming scenario, different MLDs can have at least one of the following operations: the non-AP MLD can negotiate a new key with the target AP MLD; the non-AP MLD can perform resource negotiation with the target AP MLD; the non-AP MLD can perform re-association with the target AP MLD; and the target AP MLD and the current AP MLD can perform context transfer. Of course, the steps performed by different MLDs in the roaming scenario can not be limited to this. For the specific method in the roaming scenario, refer to the following Figure 11 The details are not described here.

[0105] Before introducing the method provided by the embodiments of this application, the following first introduces the terms or names related by the embodiments of this application.

[0106] 1, Distributed system (distributed system, DS)

[0107] A DS can be used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS). The DS system can deliver downlink data of a non-AP MLD (or STA) to an AP MLD (or AP) to which the non-AP MLD is associated. Similarly, the AP can deliver uplink data of a non-AP MLD (or STA) to the network through the DS for transmission.

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

[0109] A non-AP MLD can request to reassociate with an AP MLD through a reassociation request frame. The reassociation request frame can be used by the non-AP MLD to request to establish a link and activate DS service according to 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, a non-AP MLD can send a reassociation request frame to a target AP MLD to request to reassociate with the target AP MLD. The target AP MLD can send a reassociation response frame to feedback the result of the non-AP MLD's request to reassociate.

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

[0111] Table 1. Frame format of reassociation request frame

[0112]

[0113]

[0114] Table 2. Frame format of reassociation response frame

[0115]

[0116] The re-association request frame shown in Table 1 and the re-association response frame shown in Table 2 are only examples, and the format of the re-association request frame or the re-association response frame can be updated later as the standard evolves, and thus the format of the re-association request frame and the re-association response frame shown in the embodiments of the present application is not limited to Table 1 and Table 2.

[0117] 3. Primitives of the DS system

[0118] The current 802.11 standard defines a distributed system-station-notification request (DS-STA-NOTIFY.request) primitive, which can be used by an AP to update the DS's mapping of STAs-to-APs.

[0119] By sending the primitive, the AP can change the data path between the indicated STA and the DS, or the data path between the non-AP MLD and the DS. The DS can deliver MSDUs 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. Exemplarily, the update type defined by the primitive can include: ADD (corresponding to the initial association operation), MOVE (corresponding to the re-association operation), and DELETE (corresponding to the disassociation operation).

[0120] The format of the above-mentioned primitive is shown below as an example.

[0121]

[0122] Table 3 shows an exemplary definition of the STA address and the update type.

[0123] Table 3 primitive

[0124]

[0125]

[0126] The above-mentioned description of the update type is only an example, and should not be understood as a limitation on the embodiments of the present application.

[0127] 4. Establishment of a block acknowledgement (blockack, BA) session

[0128] Figure 4 FIG. 1 is a flowchart of the establishment of a BA session provided by the embodiments of the present application. In a multi-link scenario, a block acknowledgement session can be established between the two communicating parties. For example, before using multi-link aggregation transmission, the two communicating parties can establish a block acknowledgement session.

[0129] As shown in FIG. 1, the two communicating parties can establish a block acknowledgement session before using multi-link aggregation transmission. Figure 4As shown, the initiator can send an add block acknowledgement (ADDBA) request (ADDBA request) frame, and the responder can receive the ADDBA request frame. The responder can send an ADDBA response frame, and the initiator can receive the ADDBA response frame. After the BA session is established through the ADDBA request frame and the ADDBA response frame, the initiator can send a data packet and a block ACK request (BAR) frame (i.e., a BA request frame), and the responder can send a block ACK (BA) after receiving the data packet and the BA request frame. The initiator or the responder can terminate the BA session for the corresponding TID through a delete BA (DELBA) frame. That is, for one or more TIDs, the initiator or the responder can delete the BA session by sending a DELBA frame.

[0130] As for a BA session established between the initiator and the responder, a specific traffic identifier (TID) can be used. The TID can be used for one-way data transmission from the initiator to the responder. For example, for downlink data transmission, the AP as the initiator can initiate the process of establishing a BA session. For uplink data transmission, the non-AP STA as the initiator can initiate the process of establishing a BA session.

[0131] For example, the downlink initiator BA session can include, but is not limited to, at least one of the following parameters:

[0132] TID, sequence number (SN) allocated for each MSDU, block ACK policy, whether MSDU aggregation is allowed, whether fragmentation is allowed, whether HE fragmentation operation is supported, window start position of the sending buffer (denoted as WinStart_O), window size of the sending buffer (denoted as WinSize_O), sending success or failure status of each MPDU in the window, and retransmission number.

[0133] For example, the downlink responder BA session can include, but is not limited to, at least one of the following parameters:

[0134] TID, block ACK policy, whether MSDU aggregation is allowed, whether fragmentation is allowed, whether HE fragmentation operation is supported, bit map of the responder scoreboard, window start position of the scoreboard (denoted as WinStart_R), window size of the scoreboard (denoted as WinSize_R), window start position of the receive reordering buffer (denoted as WinStart_B), and window size of the receive reordering buffer (denoted as WinSize_B).

[0135] The bitmap of the scoreboard can be used to record which MSDU is received successfully. The receive reorder buffer can be used to buffer the received MSDUs. Generally, the MAC layer needs to deliver the received MSDUs to the logical link control (LLC) layer in sequence. If a certain MSDU is not received successfully, the other MSDUs behind the MSDU cannot be successfully delivered to the LLC layer even if they are received successfully.

[0136] Figure 5a is a frame format diagram of the ADDBA request frame / ADDBA response frame provided by an embodiment of the present application.

[0137] As shown in Figure 5a The ADDBA request frame / ADDBA response frame can include at least one of the following: frame control, duration (or time duration), address 1, address 2, address 3, sequence control, HT control, frame body, or frame check sequence (FCS). Figure 5a The frame format or the order of the fields shown is only an example, and should not be understood as a limitation to the embodiments of the present application.

[0138] Table 4 exemplarily shows the main fields included in the frame body of the ADDBA request frame. However, the embodiments of the present application are not limited to the frame body of the ADDBA request frame.

[0139] Table 4 Frame body of ADDBA request frame

[0140]

[0141]

[0142] Table 5 exemplarily shows the main fields included in the frame body of the ADDBA response frame. However, the embodiments of the present application are not limited to the frame body of the ADDBA response frame.

[0143] Table 5 Frame body of ADDBA response frame

[0144] order Information 1 Category 2 Block ACK action 3 dialog token 4 Status code 5 Block ACK parameter set 6 Block ACK timeout value 7 Add Block Acknowledgement Extension (ADDBA extension) (optional)

[0145] The specific description of the frame body shown in Table 4 and Table 5 can also refer to the 802.11 standard, etc., and will not be described in detail here.

[0146] Figure 5b is a format diagram of the BA parameter set field provided by an embodiment of the present application. As shown in the figure, Figure 5b the BA parameter set field can include at least one of the following: aggregated-MSDU (A-MSDU) supported, BA policy, TID or buffer size. The A-MSDU supported field can be used to indicate whether aggregated-MSDU is 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 receiving buffer.

[0147] Figure 5c is a format diagram of the ADDBA extension field provided by an embodiment of the present application. As shown in the figure, Figure 5c the ADDBA extension field can include element ID, length or ADDBA extended parameter set. The ADDBA extended parameter set field can 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 the non-HE initiator / responder allows / supports fragmentation. The HE fragmentation operation field can be used to indicate the level of HE dynamic fragmentation. The extended buffer size field can be used to extend the length of the buffer size field in the BA parameter set field.

[0148] The format of each field shown above is only an example, and the format of each field is not limited to this.

[0149] 5、fast BSS transition (FT) action frame

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

[0151] The FT action frames shown in the embodiments of the present application are only examples, and other frames with similar functions can also appear in the future as the standard evolves, and the embodiments of the present application are not limited in this regard.

[0152] Table 6 exemplarily shows values of the FT action field.

[0153] Table 6 FT action field values

[0154]

[0155]

[0156] The correspondence between the values of the FT action field shown in Table 6 and the description is only an example, and the values of the FT action field corresponding to the FT action frame can also be updated in the future as the standard evolves, and the embodiments of the present application are not limited in this regard.

[0157] Figure 6a is a frame format diagram of the FT request frame provided by the embodiments of the present application. As shown in Figure 6a The FT request frame can include at least one of the following: category, FT action, STA address, target AP address, or FT request frame body. The description of each field can refer to the related standard or protocol, and will not be described in detail here.

[0158] Table 7 exemplarily shows the main content in the frame body of the FT request frame.

[0159] Table 7 FT request frame body

[0160]

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

[0162] Figure 6c is a format diagram of an MDE provided by an embodiment of the present application. As shown in Figure 6c , the MDE can 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 mobility domain. The FT capability and policy field can be used to indicate the fast transition capability and policy. The FT capability and policy field can include fast BSS transition over DS or resource request protocol capability. The fast BSS transition over DS field 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 perform resource negotiation with a target AP MLD through a current AP MLD through an FT confirmation frame / FT ACK frame.

[0163] Figure 7 is a frame format diagram of an FT response frame provided by an embodiment of the present application. As shown in Figure 7As shown, the FT response frame can include at least one of the following: category, FT action, STA address, target AP address, status code, or FT response frame body. The description of each field can refer to the 802.11 standard, etc., and will not be described in detail here.

[0164] Table 8 exemplarily shows the main content in the frame body of the FT response frame.

[0165] Table 8 FT response frame body

[0166]

[0167] Figure 8 is a frame format schematic diagram of the FT confirmation frame provided by the embodiments of the present application. As shown, Figure 8 the FT confirmation frame can include at least one of the following: category, FT action, STA address, target AP address, or FT confirmation frame body. The description of each field can refer to the 802.11 standard, etc., and will not be described in detail here.

[0168] Table 9 exemplarily shows the main content in the frame body of the FT confirmation frame.

[0169] Table 9 FT confirmation frame body

[0170]

[0171] Figure 9 is a frame format schematic diagram of the FT ACK frame provided by the embodiments of the present application. As shown, Figure 9 the FT ACK frame can include at least one of the following: category, FT action, STA address, target AP address, status code, or FT ACK frame body. The description of each field can refer to the 802.11 standard, etc., and will not be described in detail here.

[0172] Table 10 exemplarily shows the main content in the frame body of the FT ACK frame.

[0173] Table 10 FT ACK frame body

[0174]

[0175] The RIC in the FT confirmation 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 description uses RIC request and RIC response as examples.

[0176] Figure 10 This is a schematic diagram of the format of the RIC request / RIC response provided in an embodiment of the present application. Figure 10 The example shows one RIC request / one RIC response. However, in a specific implementation, the FT confirmation frame may also include multiple RIC requests, and the FT ACK frame may also include multiple RIC responses. The formats of these RIC requests / RIC responses can refer to Figure 10 Each of the multiple RIC requests may correspond to a resource request.

[0177] like Figure 10 As shown, the RIC request / RIC response may include a resource information container data element (RIC data element, RDE) and a resource descriptor (resource descriptor).

[0178] For an RIC request or an RIC response, the RDE may include at least one of the following: element ID, length, RDEID, number of resource descriptors (resourcedescriptorcount), and status code (statuscode).

[0179] The RDE ID field can be used to indicate the identifier of the RIC request / RIC response. The Resource Descriptor Number field can be used to indicate the number of resource descriptor fields following the RDE. The Status Code field can be used to indicate whether the non-AP MLD successfully requested the resource requested in the RIC request. In other words, the Status Code field can be used to indicate whether the non-AP MLD successfully requested the resource corresponding to the RIC request. When the RDE is included in the RIC request, the Status Code field is reserved.

[0180] The Resource Descriptor field can be used to indicate a specific resource descriptor. When the resource request is for Block ACK parameter negotiation, the Resource Descriptor field can include a resource type (resource type) and variable parameters (variable parameters). The Resource Type field can be used to indicate the resource type, and the Variable Parameters field is used to carry parameters corresponding to the resource type. When the resource request is for 802.11 QoS, the signaling carried by the Resource Descriptor field is detailed in Table 11.

[0181] The length of each FT action frame or the order of fields shown above is only an example, and the embodiments of the present application are not limited to the specific format of each FT action frame.

[0182] In the existing resource request method, two types of resource requests can be supported. One is to establish an uplink BA session (i.e., the resource request is used for uplink fast confirmation parameter negotiation), and the other is to increase a quality of service (QoS) service flow (i.e., the resource request is used for 802.11 QoS).

[0183] Table 11 exemplarily shows the content of the resource descriptor field in the existing resource request method. The two types of resources shown in Table 11 can be carried in different RIC requests. For example, the FT confirmation frame can include two RIC requests, which can be used to request an uplink BA session and increase a QoS service flow, respectively.

[0184] Table 11

[0185]

[0186] Table 12 exemplarily shows the values of the resource type field and the content of the variable parameter field in the RIC descriptor element in the existing resource request method.

[0187] Table 12

[0188]

[0189] Other descriptions about Table 12 can also refer to the related descriptions about the establishment of the BA session above, which will not be described in detail here.

[0190] As can be seen from Table 11 and Table 12, in the existing resource request method, the FT confirmation frame supports two types of resource requests, i.e., establishing an uplink BA session and increasing a QoS service flow.

[0191] When the non-AP MLD needs to request other resources in addition to the above two types of resources, the non-AP MLD needs to request resources after reassociating with the target AP MLD, so that the multi-link cannot be fully utilized, resulting in low transmission efficiency, and further resulting in an increase in roaming delay and low roaming efficiency.

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

[0193] The method provided by the embodiments of the present application provides a series of preparations, including resource request before roaming or data forwarding before roaming, etc. As shown below:

[0194] As an example, the method provided by the embodiments of the present application considers resource requests in scenarios such as stream classification service (SCS), target wake time (TWT) and AP energy saving. On the basis of the currently supported resource request protocol, further extension is made, and SCS-based resource request, TWT-based resource request and wake-up request are added. For SCS, for example, in the existing resource request method, the non-AP MLD after reassociation can report a low-latency service to the target AP MLD through SCS. This will introduce the latency of resource negotiation and also cause the QoS to decrease during roaming. Therefore, in the embodiments of the present application, the SCS-based resource request is added in the FT confirmation frame, which can effectively reduce the roaming latency and improve the roaming efficiency.

[0195] As another example, the method provided by the embodiments of the present application considers the establishment of a downlink BA session. The establishment of the downlink BA session is realized on the basis of the currently supported resource request protocol.

[0196] As yet another example, the method provided by the embodiments of the present application considers the update of the BA session. The update of the BA session is realized on the basis of the currently supported resource request protocol and in consideration of the context transfer.

[0197] As yet another example, the method provided by the embodiments of the present application considers the problem of long time consumption in the existing data forwarding process, and proposes an early data forwarding operation.

[0198] As another example, the method provided by the embodiments of the present application considers the Ping-pong phenomenon that may occur in the roaming scenario, and proposes a new state. In this state, the IEEE 802.1X control port is blocked, allowing the current AP MLD and the non-AP MLD to retain the PTKSA (or also including the GTKSA) for a period of time until the timeout. Generally, the IEEE 802.1X control port can be used to control the data transmission with the DS, such as being used to control whether the DS system can deliver the downlink data of the non-AP MLD to the AP MLD associated with the non-AP MLD, or whether the uplink data of the non-AP MLD can be delivered to the network through the DS system. The above-mentioned IEEE 802.1X control port can also be referred to as a control port, and the related description of the control port can be referred to the 802.11 standard, which will not be described in detail here.

[0199] The above-mentioned various examples can be referred to below, which will not be described in detail here. The above-mentioned various examples can be combined with each other, and the combined description will not be described in detail here.

[0200] In the embodiments of the present application, as a possible implementation manner, the steps performed by the non-AP MLD before sending the re-association request frame can be referred to as before roaming, and after receiving the re-association response frame, and the state code field of the re-association response frame indicates success, it can be indicated that the non-AP MLD successfully roams to the target AP MLD.

[0201] Figure 11 FIG. 1 is a flow diagram of a resource request method provided by the embodiments of the present application. The method can be applied to a non-AP MLD, a target AP MLD or a current AP MLD, and the description of the non-AP MLD, the target AP MLD and the current AP MLD can be referred to the above, which will not be described in detail here. The description of the DS can be referred to the above, which will not be described in detail here.

[0202] Figure 11In the current AP MLD and the DS, the data path represents that the DS can submit data to the current AP MLD or receive data from the current AP MLD. The non-AP MLD and the current AP MLD have successfully established a security session and have successfully transmitted data. Before the non-AP MLD sends the FT request, the non-AP MLD can decide to roam to the target AP MLD based on the BSS transition procedure triggered by the current AP MLD, or the non-AP MLD can actively perform BSS transition to decide to roam to the target AP MLD. For the procedure before the non-AP MLD sends the FT request, refer to 802.11 standards and the like, and embodiments of the present application are not limited thereto.

[0203] Figure 11 The solid line and the dashed line in the current AP MLD and the DS can represent different transmission paths or different transmission modes. For example, Figure 11 The solid line in the current AP MLD and the DS can represent air transmission, and the dashed line can represent transmission through the DS or wired transmission.

[0204] As shown in FIG. 10, the resource request method can include the following steps. Figure 11

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

[0206] After the current AP MLD receives the FT request frame, the current AP MLD can send a remote request to the target AP MLD through the DS.

[0207] That is, the content in the remote request can come from the FT request frame. For example, the current AP MLD can obtain the destination address (i.e., the address of the target AP MLD) of the FT request frame by analyzing the FT request frame, and carry the information in the FT request frame that needs to be sent to the target AP MLD in the remote request. For another example, the current AP MLD can directly encapsulate the FT request frame in the remote request. For example, the FT request frame can include the address of the non-AP MLD, the address of the target AP MLD, RSNE (PMKR0name), MDE or FTE (SNonce, R0KH-ID).

[0208] The target AP MLD receives the remote request and sends a remote response to the remote request to the current AP MLD. The current AP MLD receives the remote response. ​​

[0209] Table 13 exemplarily shows the load format of the remote request / remote response.

[0210] Table 13

[0211] size Information 1 FT packet type 2 FT action length 6 AP address variable FT action frame

[0212] Wherein, the FT packet type field can indicate whether the field carries a remote request or a remote response. For example, the FT packet type field is 0, which indicates a remote request, and the FT packet type field is 1, which indicates a remote response. The FT action length field is used to indicate the length of the FT action frame field. For example, the field can be set as an unsigned number, which indicates the octet length of the FT action frame field. The AP address field can be used to indicate the address of the current AP MLD, such as the MLD address of the current AP MLD. The target AP MLD can obtain the destination address of the remote response through the AP address field. The FT action frame field can carry the FT action frame, such as the category field to the action frame body.

[0213] Table 13 is exemplarily shown in the case that the FT request frame is directly encapsulated in the remote request, and the FT response frame is directly encapsulated in the remote response. However, it should not be understood as a limitation to the embodiments of the present application.

[0214] The description of the remote request and the remote response herein is also applicable to the following, which will not be described in detail.

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

[0216] The content in the FT response frame can come from the remote response introduced in step 1101. The description of the remote response can refer to the description of the remote request above, which will not be described in detail herein.

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

[0218] Through the exchange of the FT request frame and the FT response frame, the non-AP MLD and the target AP MLD can successfully establish a new PTKSA.

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

[0220] The FT confirmation frame can be used for non-AP MLD to request resource from target AP MLD. After the current AP MLD receives the FT confirmation frame, it can send a remote request to the target AP MLD. The content in the remote request can come from the FT confirmation frame. The target AP MLD receives the remote request and sends a remote response for the remote request to the current AP MLD. The current AP MLD receives the remote response.

[0221] For example, the FT confirmation frame can include non-AP MLD address, address of target AP MLD, RSNE (PMK R1 Name), MDE, FTE (MIC, ANonce, SNonce, R1 KH-ID, R0 KH-ID) or RIC request. The description of RIC request can refer to the description in the above Figure 10 or below, which will not be described here in detail.

[0222] 1104、The current AP MLD sends a 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.

[0223] The content of the FT ACK frame can come from the remote response introduced in step 1103. For example, the FT ACK frame can include non-AP MLD address, address of target AP MLD, RSNE (PMK R1 Name), MDE, FTE (MIC, ANonce, SNonce, R1 KH-ID, R0 KH-ID), timeout interval element (TIE) (such as indicating reassociation deadline) or RIC response. The description of RIC response can refer to the description in the above Figure 10 or below, which will not be described here in detail.

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

[0225] Optionally, the current AP MLD can also perform early DL data forwarding.

[0226] As in step 1105, the current AP MLD can send a copy of the data it needs to send to the non-AP MLD to the target AP MLD. The description of the early downlink data forwarding request frame can refer to the description of the forwarding indication information or examples 1-5 below, which will not be described in detail here.

[0227] In the embodiment of the application, the current AP MLD can start downlink data forwarding before it sends the 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. Alternatively, in specific implementation, the early downlink data forwarding after step 1105 and the downlink data forwarding after step 1108 can not be distinguished, such as both can be referred to as downlink data forwarding.

[0228] 1106, the non-AP MLD sends a re-association request frame (i.e. re-association request) to the target AP MLD, and the target AP MLD receives the re-association request frame. Figure 11

[0229] The re-association request frame can include RSNE (PMKR1Name), MDE, FTE (MIC, ANonce, SNonce, R1KH-ID, R0KH-ID), RSNXE. The description of the re-association request frame can refer to Table 1 above or below, which will not be described in detail here.

[0230] For example, the non-AP MLD moves into the coverage of the target AP MLD, or the 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 re-association request frame to the target AP MLD through the air interface.

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

[0232] Step A (step A), the current AP MLD should stop transmitting uplink data to the DS through itself and transmitting downlink data to the non-AP MLD. That is, the current AP MLD can stop downlink data transmission and data submission to the DS through its own MAC service access point (service access point SAP) in the case of receiving the context transfer request from the target AP MLD. ​

[0233] Step B, the target AP MLD updates the STA-to-AP mapping by DS-STA-NOTIFY.request primitive, such as update type is moving. Meanwhile, the primitive can also include the MAC address of the non-AP MLD (such as MLD MAC address).

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

[0235] For example, the current AP MLD can stop submitting MSDU to the DS, or in other words, stop downlink data transmission to the non-AP MLD. Then, the context transfer response is sent to the target AP MLD through the DS.

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

[0237] 1109、The target AP MLD sends a re-association response frame (i.e. re-association response in the re-association request) to the non-AP MLD, and the non-AP MLD receives the re-association response frame. Figure 11

[0238] The re-association response frame can include RSNE (PMKR1Name), MDE, FTE (MIC, ANonce, SNonce, R1KH-ID, R0KH-ID, GTK(N), BIGTK(Q)), RSNXE. The description of the re-association request can refer to Table 2 or the following, which will not be described in detail here.

[0239] Optionally, the current AP MLD can also send an end marker of downlink data forwarding to the target AP MLD. The end marker of downlink data forwarding can be used to indicate the end of downlink data (such as the sending buffer of the current AP MLD) forwarding.

[0240] Optionally, the current AP MLD can also send an end marker of uplink data forwarding to the target AP MLD.​ Figure 11 (not shown) The uplink data forward transmission end flag may be used to indicate the end of the forward transmission of uplink data (ie, the reordering buffer of the current AP MLD).

[0241] Exemplarily, the downlink data forward transmission end identifier and the uplink data forward transmission end identifier can be carried in the same frame, or carried in different frames, and this embodiment of the present application does not limit this. Exemplarily, the downlink data forward transmission end identifier and the uplink data forward transmission end identifier can also be unified into one identifier, which can indicate the end of the downlink data forward transmission and the end of the uplink data forward transmission.

[0242] Figure 11 The steps shown are only examples. In a specific implementation, the resource request method may have more Figure 11 More or fewer steps. For example, the above steps 1103 and 1104 may be optional. For another example, the above step 1105 may be optional, etc., which are not listed here one by one.

[0243] The following is a detailed introduction to the format of the frames involved in the embodiments of the present application.

[0244] As a possible implementation, the FT confirmation frame includes a RIC request, which includes a resource descriptor field. For the format of the FT confirmation frame, please refer to Figure 8 For the description of RIC request format, please refer to the above Figure 10 Description, etc.

[0245] As another possible implementation, the FT ACK frame includes a RIC response, and the RIC response includes a resource descriptor field. For the format of the FT ACK frame, please refer to Figure 9 For the description of RIC response format, please refer to the above Figure 10 Description, etc.

[0246] As another possible implementation, the reassociation request frame may include a RIC request, which includes a resource descriptor field. For other descriptions of the reassociation request frame, please refer to Table 1, etc., and for the format of the RIC request, please refer to the above Figure 10 Description, etc.

[0247] As another possible implementation, the reassociation response frame may include a RIC response, which includes a resource descriptor field. For other descriptions of the reassociation response frame, please refer to Table 2, etc., and for the format of the RIC response, please refer to the above Figure 10 Description, etc.

[0248] The remote request corresponding to the FT confirmation frame and the remote response corresponding to the FT ACK frame can refer to the description of the FT confirmation frame and the FT ACK frame, which will not be described in detail here.

[0249] Optionally, the FT confirmation frame / reassociation request frame can also carry a buffer status report of the non-AP MLD. The buffer status report can indicate a buffer size, a corresponding TID (corresponding to the aforementioned buffer size), or an access category (AC). Thus, the target AP MLD can decide whether to allow the non-AP MLD to roam to the target AP MLD based on the buffer status report, or decide the number of wake-up APs according to the buffer size, etc.

[0250] The contents in the RIC request / RIC response are described in detail below.

[0251] The resource descriptor field in the RIC request can 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 the resource type being an enhanced block acknowledgment parameter (as shown in (4) below), or a RIC descriptor element corresponding to the resource type being an enhanced block acknowledgment parameter transfer (as shown in (5) below). The resource descriptor field can also include a TSPEC element or a RIC descriptor element as shown in Table 11. The description of the TSPEC element or the RIC descriptor element for requesting an uplink BA session can refer to the foregoing or 802.11 standards, etc., which will not be described in detail here.

[0252] The embodiments of the present application are exemplified by the resource descriptor field including the SCS descriptor element, the TWT element, or the wake-up request element in the RIC request / RIC response (as shown in (1), (2), and (3) above). Figure 10But as another possible implementation, the FT confirmation frame / reassociation request frame and the SCS descriptor element can have other formats, or the FT confirmation frame / reassociation request frame and the TWT element can have other formats, or the FT confirmation frame / reassociation request frame and the wake-up request element (or wake-up indication information) can have other formats. The specific location of the SCS descriptor element (or each field included in the element) in the FT confirmation frame / reassociation request frame (such as can be located in a certain field, or in a certain element, or in a certain location of the frame body of the FT confirmation frame, etc.), the specific location of the TWT element (or each field included in the element) in the FT confirmation frame / reassociation request frame, and the specific location of the wake-up request element (or wake-up indication information) in the FT confirmation frame / reassociation request frame are not limited by the embodiments of the present application. The description herein is also applicable to the FT ACK frame / reassociation response frame.

[0253] As a possible implementation, the RDE in the RIC response includes a status code field. As an example, the status code field can indicate that the non-AP MLD successfully requested the resource corresponding to the RIC request. For the RIC request including the SCS descriptor element, the status code field can indicate that the non-AP MLD successfully requested the resource corresponding to the SCS. For the RIC request including the TWT element, the status code field can indicate that the non-AP MLD successfully requested the resource corresponding to the TWT. For the RIC request including the 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 the resource suggested by the target AP MLD to the non-AP MLD.

[0254] As another possible implementation, for the TWT element in the RIC response, the TWT element can include 4 types of responses: accept the TWT parameter, replace the TWT parameter, indicate the TWT parameter, and reject the TWT parameter. That is, the TWT element in the RIC response indicates the response type, so the RIC response carrying the TWT element can not include the status code field, which is a reserved field.

[0255] To distinguish the SCS descriptor element in the RIC request and the SCS descriptor element in the RIC response, the SCS descriptor element in the RIC response is referred to as the proposed SCS descriptor element in the embodiments of the present application. However, in the specific implementation, the SCS descriptor element in the RIC request / RIC response can not be distinguished, and is referred to as the SCS descriptor element. The description herein is also applicable to the TWT element / proposed TWT element, the wake-up request element / proposed wake-up request element, and will not be described in detail.

[0256] The following describes each element in detail.

[0257] (1) SCS descriptor element

[0258] The SCS descriptor element can be used for the non-AP MLD to request the resource corresponding to the SCS from the target AP MLD. For example, the SCS descriptor element can be used for the non-AP MLD to report a low-latency SCS flow to the target AP MLD (i.e., to request the resource of the low-latency SCS flow). The proposed SCS descriptor element is used for the target AP MLD to propose the SCS parameter to the non-AP MLD.

[0259] For example, the SCS descriptor element / proposed SCS descriptor element can include at least one of the following: an element identifier (element ID), a length, an SCS identifier (SCS ID), a request type, an intra-access category priority element (optional), a traffic class element (TCLAS element) (optional), a traffic class processing element (TCLAS Processing element) (optional), a QoS characteristics element, and optional subelements.

[0260] The description of each field in the SCS descriptor element can refer to the 802.11 standard, and will not be described in detail herein.

[0261] (2) TWT element

[0262] The TWT element can be used for the non-AP MLD to request the resource corresponding to the TWT from the target AP MLD. The TWT element can be used for the non-AP MLD to report a periodic target wake-up time to the target AP MLD (i.e., to request the resource of the periodic TWT).

[0263] The description of each field in the TWT element can refer to the 802.11 standard, which will not be described in detail here.

[0264] (3) Wakeup request element

[0265] The wakeup request element is used for the non-AP MLD to wake up the first AP affiliated to the target AP MLD.

[0266] As an example, the RIC response can include a suggested wakeup request element, which is used for the target AP MLD to suggest the parameters of waking up the first AP to the non-AP MLD. At this time, the RIC response can carry the suggested wakeup request element regardless of whether the target AP MLD agrees to the parameters indicated in the wakeup request element. The first AP and the non-AP MLD can both take the content indicated in the wakeup request element in the RIC response as the final parameters (or real values).

[0267] As another example, when the target AP MLD agrees to the parameters indicated in the wakeup request element, the RIC response can not include the suggested wakeup request element. When the target AP MLD refuses the parameters indicated in the wakeup request element, the RIC response includes the suggested wakeup request element.

[0268] Considering that one or more APs affiliated to the target AP MLD are in at least one of the following modes: periodically scheduled power saving mode (or scheduled AP power saving mode), non-periodic power saving mode (or non-scheduled AP power saving mode that can be woken up), and low-bandwidth, low-flow, and low-modulation and coding scheme (MCS) listening mode, the non-AP MLD can not be able to roam to the target AP MLD in time. Each mode shown here can be understood as a power saving mode. Generally, there are two states in the power saving mode, namely, the wake-up state and the sleep state. Therefore, an embodiment of the present application proposes a wakeup request element. After the target AP MLD obtains the wakeup request element, the first AP can be woken up, so that the non-AP MLD can successfully roam to the target AP MLD and directly perform data transmission with the first AP after roaming to the target AP MLD.

[0269] As an example, the resource descriptor field can not include the wakeup request element. At this time, after the target AP MLD receives the FT confirmation frame or the reassociation request frame, when the first AP affiliated to the target AP MLD is in the power saving mode, the first AP can automatically exit the power saving mode.

[0270] As another example, the wake-up request element can include wake-up indication information. For example, the wake-up indication information does not include the BSSID or the link ID of any AP, which indicates to wake up all APs in the target AP MLD. For another example, the wake-up indication information includes the BSSID or the link ID of a first AP, which indicates to wake up the first AP. For example, the wake-up indication information can include one BSSID field or link ID field, which can indicate one first AP. For another example, the wake-up indication information can include multiple BSSID fields or link ID fields, each of which can indicate one AP. That is, the wake-up indication information can be used to wake up one or more first APs. For another example, the wake-up indication information can include a link bitmap, each bit of which can correspond 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 (only as an example) link bitmap, and when the bit is 1, it indicates to request to wake up the corresponding AP, and when the bit is 0, it indicates not to wake up the corresponding AP.

[0271] In the embodiments of the present application, the non-AP MLD can indicate one or more first APs affiliated to the target AP MLD to exit the power saving mode through the wake-up indication information (as follows, way 1), or the non-AP MLD can wake up (or temporarily suspend) one or more first APs affiliated to the target AP MLD through the wake-up indication information (as follows, way 2), or the non-AP MLD can indicate one or more first APs to update the wake-up parameters through the wake-up indication information (as follows, way 3). The wake-up indication information can have the following ways:

[0272] Way 1, the wake-up indication information can be used to indicate the first AP to exit the power saving mode.

[0273] In this case, after the first AP exits the power saving mode, it can no longer enter the power saving mode.

[0274] Way 2, the wake-up indication information can be used to wake up the first AP.

[0275] In this case, the wake-up indication information can also be called 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 indicate the first AP to switch from the wake-up state to the sleep state.

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

[0277] For example, the first AP is in a periodically scheduled power save mode. In the periodically scheduled power save mode, the first AP can establish a periodic wake-up window, in which the first AP is in a wake-up state, and outside of which the first AP is in a sleep state. The wake-up parameter can be included in a beacon frame, a probe response frame, or a probe response frame, which can be used to indicate the parameters of the periodic wake-up window. The parameters can 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), 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 interval or the interval before the update). The beacon frame, the probe response frame, or the probe response frame can also include the BSSID or the link ID or the link bitmap of the first AP. The beacon frame, the probe response frame, or the probe response frame can be a frame sent by an AP other than the first AP in the target AP MLD to the non-AP MLD.

[0278] For example, the first AP is in a periodically scheduled power save mode. In the periodically scheduled power save mode, the first AP can establish a periodic wake-up window, in which the first AP is in a wake-up state, and outside of which the first AP is in a sleep state. The wake-up parameter can be included in a beacon frame, a probe response frame, or a probe response frame, which can be used to indicate the parameters of the periodic wake-up window. The parameters can 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), 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 interval or the interval before the update). The beacon frame, the probe response frame, or the probe response frame can also include the BSSID or the link ID or the link bitmap of the first AP. The beacon frame, the probe response frame, or the probe response frame can be a frame sent by an AP other than the first AP in the target AP MLD to the non-AP MLD.

[0279] For example, the first AP is in a periodically scheduled power save mode. In the periodically scheduled power save mode, the first AP can establish a periodic wake-up window, in which the first AP is in a wake-up state, and outside of which the first AP is in a sleep state. The wake-up parameter can be included in a beacon frame, a probe response frame, or a probe response frame, which can be used to indicate the parameters of the periodic wake-up window. The parameters can 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), 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 interval or the interval before the update). The beacon frame, the probe response frame, or the probe response frame can also include the BSSID or the link ID or the link bitmap of the first AP. The beacon frame, the probe response frame, or the probe response frame can be a frame sent by an AP other than the first AP in the target AP MLD to the non-AP MLD.

[0280] For example, the first AP is in a non-scheduled power saving mode. In the non-periodic power saving mode, the non-AP MLD can send a wake-up request to the target AP MLD through a certain link, and the 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, or the wake-up request can include a link bitmap, which can 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 state of the first AP is not periodic.

[0281] For example, in the above mode 3, the wake-up indication information in the FT confirmation frame / reassociation request frame can include a duration of wake-up, i.e., a duration of wake-up of the first AP. The duration of wake-up can be a duration of the first AP in the wake-up state. The first AP can update the duration of wake-up based on the duration indicated by the wake-up indication information.

[0282] For example, in the above mode 1, the wake-up indication information can indicate the first AP to exit the non-scheduled power saving mode. For mode 2, this will not be listed one by one. As shown above, the FT confirmation frame / reassociation request frame can also carry a buffer status report, and the description of the buffer status report will not be described in detail here.

[0283] For example, the first AP is in a low-bandwidth, low-flow, and 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 state of large bandwidth, high flow, and high MCS.

[0284] For example, in the above mode 3, the wake-up indication information in the FT confirmation frame / reassociation request frame can include updated wake-up parameters, which can include at least one of the following: a bandwidth of the first AP, a number of spatial streams of the first AP, and an MCS of the first AP. The bandwidth indicated in the updated wake-up parameters can 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 can 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 can be higher than the MCS of the first AP before the update. Through the updated wake-up parameters, the first AP can switch to a working state of a specified bandwidth, a number of spatial streams, or an MCS.

[0285] For example, in the above mode 1, the wake-up indication information can indicate the first AP to exit the listening mode. For mode 2, this will not be listed one by one. As shown above, the FT confirmation frame / reassociation request frame can also carry a buffer status report, and the description of the buffer status report will not be described in detail here.

[0286] Table 14 exemplarily shows the content of the resource descriptor in the resource request method provided by the embodiments of the present application. The different elements shown in Table 13 can be carried in different RIC requests (or RIC responses). For example, the FT confirmation frame or the re-association request frame can include one or more RIC requests, and each RIC request can correspond to one resource type.

[0287] The resource descriptor field in Table 14 when the resource type is QoS and the block confirmation parameter can be carried in the above or 802.11 standard, and will not be described here in detail. The resource descriptor field in Table 14 when the resource type is SCS or TWT or wake-up parameter can refer to (1) to (3) above. The content of Table 14 can be carried in the FT confirmation frame / FT ACK frame, or can also be carried in the re-association request frame / re-association response frame.

[0288] Table 14

[0289]

[0290] In the embodiments of the present application, a new resource request is added in the FT confirmation frame (or the re-association request frame), and the resource type of the new resource request can be SCS or TWT or wake-up parameter. Through the interaction of the FT confirmation frame and the FT ACK frame (or the re-association request frame and the re-association response frame) between the non-AP MLD and the target AP MLD, the resource negotiation of QoS, the resource negotiation of the uplink block confirmation session, the resource negotiation of SCS, the resource negotiation of TWT or the negotiation of the wake-up parameter can be completed, so as to effectively reduce the roaming delay and improve the roaming experience of the user.

[0291] Further, the non-AP MLD can also wake up the first AP in the energy saving mode through the FT confirmation frame (or the re-association request frame), so as to reduce the impact of the first AP in the energy saving mode on the roaming of the non-AP MLD. Generally, when the first AP is in the energy saving mode, the throughput of the non-AP MLD roaming to the target AP MLD will be reduced. At the same time, if the first AP is the AP with the largest coverage range in the target AP MLD, when the first AP is in the energy saving mode, the non-AP MLD can not be able to roam to the target AP MLD in time. Therefore, in the embodiments of the present application, the newly added wake-up request element can avoid the above situation and improve the roaming experience of the non-AP MLD.

[0292] (4) RIC descriptor element corresponding to the resource type of the enhanced block confirmation parameter set

[0293] As introduced above in the introduction of the block acknowledgement session establishment, the block acknowledgement protocol is extended in the 801.11ax standard, and HE dynamic fragmentation is defined. Therefore, the embodiments of the present application can add a new resource type, such as enhanced block ACK parameters (or extended block ACK parameters). As in the existing block ACK parameters, a new ADDBA extended parameter set field is added.

[0294] The description of the resource descriptor field corresponding to the new resource type, i.e., the enhanced block ACK parameters, can refer to Table 15, and the description of the variable parameter field corresponding to the resource type can refer to Table 16.

[0295] (5) RIC descriptor element corresponding to the resource type of enhanced block ACK parameter transfer

[0296] During the context transfer, the packet loss caused by roaming can be effectively avoided, thereby improving the roaming performance. In order to realize the context transfer, the target AP MLD can continue to allocate SNs for MSDUs based on the SN allocation sequence of the current AP MLD, so that the target AP MLD can continue to transmit the MSDUs. That is, the current AP MLD can indicate to the target AP MLD what the next SN is.

[0297] In the context transfer, except that the starting SN number does not need to be negotiated, other block acknowledgement parameters can be updated or re-negotiated according to the capabilities of the target AP MLD. Therefore, the embodiments of the present application can add a new resource type, such as enhanced block ACK parameters transfer (or extended block ACK parameters transfer). Through the enhanced block ACK parameters transfer, the non-AP MLD or the target AP MLD can also update other block acknowledgement parameters except the starting SN number.

[0298] The description of the resource descriptor field corresponding to the new resource type, i.e., the enhanced block ACK parameters transfer, can refer to Table 15, and the description of the variable parameter field corresponding to the resource type can refer to Table 16.

[0299] Table 15 exemplarily shows the content of the resource descriptor field in the resource request method provided by the embodiments of the present application.

[0300] Table 15

[0301]

[0302]

[0303] The descriptions of other resource types in Table 15 can refer to the above and will not be described in detail here. The format of the resource descriptor field corresponding to the enhanced block acknowledgement parameter or the enhanced block acknowledgement parameter transfer can refer to Figure 10 The resource descriptor field can include a resource type and a variable parameter. Table 15 exemplarily shows the TWT element, the SCS descriptor element, and the wake-up request element. As another possible implementation, at least one of the above TWT element, the SCS descriptor element, or the wake-up request element can not be included in the RIC request / RIC response. For combinations of the above elements, they will not be listed one by one here.

[0304] Table 16 exemplarily shows the value of the resource type field corresponding to the resource type of the enhanced block acknowledgement parameter (only as an example) and the content in the variable parameter field. At the same time, Table 16 also shows the value of the resource type field corresponding to the resource type of the enhanced block acknowledgement parameter transfer in Table 15 and the content in the variable parameter field.

[0305] Table 16

[0306]

[0307] In Table 16, the description of the block acknowledgement parameter set can refer to Figure 5b , and the description of the parameter set of the ADDBA extension can refer to Figure 5c .

[0308] In the embodiments of the present application, a new resource request is added in the FT confirmation frame (or the reassociation request frame), and the resource type of the new resource request can be the enhanced block acknowledgement parameter. The new resource type can be used for HE dynamic fragmentation. Thus, the delay introduced by the parameter negotiation after roaming is avoided, and the roaming delay is effectively reduced.

[0309] In the embodiments of the present application, a new resource type is added in the FT confirmation frame (or the reassociation request frame), and the resource type of the new resource request can be the enhanced block acknowledgement parameter transfer. The new resource type can be used for block acknowledgement parameter negotiation in the context transfer scenario. Thus, in the context transfer scenario, the non-AP MLD or the target AP MLD can update other block acknowledgement parameters except the starting SN, so that the target AP MLD and the non-AP MLD can establish a suitable block acknowledgement session protocol according to their own capabilities.

[0310] As can be seen from the above Table 11 or Table 12, in the existing resource request method, only the negotiation of the uplink block acknowledgement session parameters between the non-AP MLD and the target AP MLD is supported, and the negotiation of the downlink block acknowledgement session parameters is not supported. Generally, the establishment of the downlink block acknowledgement session is initiated by the AP end. However, in the existing resource request method (i.e., in the current FT protocol), the FT acknowledgement frame is sent by the STA or the non-AP MLD, and there is no case that the FT acknowledgement frame is sent by the target AP MLD, thereby causing that the current FT protocol does not support the establishment of the downlink block acknowledgement session.

[0311] In the resource request method provided by the embodiments of the present application, the negotiation of the downlink block acknowledgement session parameters between the non-AP MLD and the target AP MLD is supported. Therefore, the roaming delay can be effectively reduced, and the roaming efficiency can be improved.

[0312] To support the establishment of the downlink block acknowledgement session, the embodiments of the present application provide the following implementation manners:

[0313] Manner A, newly define the FT ADDBA request frame and the FT ADDBA response frame.

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

[0315] Table 17

[0316]

[0317] The frame body of the FT ADDBA request frame can include the downlink BA information, which can include but is not limited to the block acknowledgement parameter set, the block acknowledgement timeout value, the block acknowledgement starting sequence control, or the addition of the block acknowledgement extension (ADDBA extension), etc.

[0318] The frame body of the FT ADDBA response frame can include the suggested downlink BA information, which includes but is not limited to the block acknowledgement parameter set, the block acknowledgement timeout value, or the addition of the block acknowledgement extension (ADDBA extension), etc. The description of the FT ADDBA request frame / FT ADDBA response frame can refer to the description of the FT action frame above, and will not be described in detail here.

[0319] Exemplarily, the FT ADDBA request frame / FT ADDBA response frame can include a MIC, which can be used to verify the FT ADDBA request frame / FT ADDBA response frame. The MIC can be calculated in a similar way as the MIC of the FT confirmation frame in the current TF protocol, which is not described herein again. Exemplarily, the FT ADDBA request frame / FT ADDBA response frame can include a TIE, which can be used to indicate a deadline of re-association.

[0320] As a possible implementation, the target AP MLD can be supported to send the FT ADDBA request frame directly to the non-AP MLD through the current AP MLD, and the non-AP MLD can be supported to send the FT ADDBA response frame directly to the target AP MLD through the current AP MLD.

[0321] As another possible implementation, the target AP MLD can be supported to send a remote request to the current AP MLD, and the current AP MLD can be supported to send the FT ADDBA request frame to the non-AP MLD. The non-AP MLD can be supported to send the FT ADDBA response frame to the current AP MLD, and the current AP MLD can be supported to send a remote response to the target AP MLD. As an example, the format of the remote request and the remote response can be as shown in Table 13, which is not described herein again. As another example, the FT action frame in the remote request and the remote response can also not be indicated, that is, the FT action frame in Table 13 can also be replaced by the downlink BA information. The relationship between the remote request and the FT ADDBA request frame, and the relationship between the remote response and the FT ADDBA response frame are not limited in the embodiments of the present application.

[0322] Exemplarily, the target AP MLD can send the FT ADDBA request frame after receiving the remote response (the content of the remote response comes from the FT response frame) from the current AP MLD. Alternatively, the target AP MLD can also send the FT ADDBA request frame before sending the re-association response frame. The transmission sequence of the FT ADDBA request frame and the FT ADDBA response frame and other frames is not limited in the embodiments of the present application. The description herein is also applicable to the mode B and the mode C.

[0323] It can be understood that the above Figure 11 The FT ADDBA request frame and the FT ADDBA response frame are not shown, and should not be Figure 11 understood as a limitation of the embodiments of the present application.

[0324] In the mode B, the target AP MLD is allowed to send the FT confirmation frame, and the non-AP MLD replies the FT ACK frame.

[0325] The FT confirmation frame can include downlink BA information, which can be used to request to establish a downlink block acknowledgement session between the target AP MLD and the non-AP MLD. The downlink BA information can include, but is not limited to, a block ACK parameter set, a block ACK timeout value, or an ADDBA extension, etc.

[0326] The FT ACK frame can include suggested downlink BA information. That is, the FT ACK frame can include parameter information of a downlink block acknowledgement session suggested by the non-AP MLD. The suggested downlink BA information can include, but is not limited to, a block ACK parameter set, a block ACK timeout value, or an ADDBA extension, etc.

[0327] For example, the FT confirmation frame / FT ACK frame can include a MIC, which can be used to verify the FT confirmation frame / FT ACK frame. The description of the MIC can refer to the Figure 11 or related standards, which will not be described here in detail. For example, the FT confirmation frame / FT ACK frame can include a TIE.

[0328] As a possible implementation, the target AP MLD can send a FT confirmation frame to the non-AP MLD through the current AP MLD, and the non-AP MLD can send a FT ACK frame to the target AP MLD through the current AP MLD.

[0329] As another possible implementation, the target AP MLD can send a remote request to the current AP MLD, and the remote request can include downlink BA information. After receiving the remote request, the current AP MLD can send a FT confirmation frame to the non-AP MLD. The non-AP MLD can send a FT ACK frame to the target AP MLD in response to the FT confirmation frame, and the current AP MLD can send a remote response to the target AP MLD after receiving the FT ACK. As an example, the format of the remote request and the remote response can be as shown in Table 13, which will not be described here in detail. As another example, the remote request and the remote response can also not indicate the FT action frame, that is, the FT action frame in Table 13 can also be replaced by the downlink BA information. The relationship between the remote request and the FT confirmation frame, and the relationship between the remote response and the FT ACK frame are not limited by the embodiments of the present application.

[0330] It can be understood that the above Figure 11 The FT confirmation frame sent by the target AP MLD and the FTACK frame replied by the non-AP MLD should not be taken as a limitation on the embodiments of the present application. Figure 11 It should not be taken as a limitation on the embodiments of the present application.

[0331] In the FT response frame, the downlink BA information is included in the manner C, and the FT confirmation frame includes the suggested downlink BA information. The description of the downlink BA information can refer to the manner B, which will not be described in detail here.

[0332] For example, the FT response frame can include a RIC request, which includes a resource descriptor field, and the resource descriptor resource includes a RIC descriptor element corresponding to the resource type of the downlink block confirmation parameter. The FT confirmation frame can include a RIC response, which includes the suggested RIC descriptor element corresponding to the resource type of the downlink block confirmation parameter.

[0333] For example, the FT response frame / FT confirmation frame can include a MIC, which can be carried in the FTE. The MIC can be used to verify the FT response frame / FT confirmation frame. For example, after the non-AP MLD receives the FT response frame, if the MIC verification fails, the non-AP MLD can discard the FT response frame or discard the downlink BA information in the FT response frame.

[0334] For example, the FT response frame / FT confirmation frame can include a TIE.

[0335] In the embodiments of the present application, the target AP MLD can enable the non-AP MLD to establish a downlink block confirmation session during roaming, avoiding the delay introduced by the negotiation of the downlink block confirmation session after roaming, thereby effectively reducing the roaming delay and improving the roaming efficiency.

[0336] In the existing resource request method, the non-AP MLD can send a reassociation request frame to the target AP MLD over the air interface. The reassociation request frame can carry an element, which can be used to indicate the TID for context transfer. After receiving the reassociation request frame, the target AP MLD can send a context transfer request to the current AP MLD. Thus, the current AP MLD performs downlink context transfer. Considering that the data forwarding process is time-consuming, which will result in the roaming efficiency of the non-AP MLD.

[0337] Therefore, the embodiments of the present application further optimize the resource request method, such as Figure 11As shown, before the non-AP MLD sends the re-association request, the non-AP MLD can send an early DL data forwarding request to the current AP MLD, and the early DL data forwarding request can include data forwarding information, which can be used to indicate the downlink TIDs for which the current AP MLD needs to perform data forwarding, or the downlink TIDs for which the current AP MLD needs to transfer the context, or the downlink TIDs for which the current AP MLD needs to perform data forwarding. The data forwarding information can include at least one of the following:

[0338] (1) A non-default transfer field: when the field is set to 0, it can indicate that the context of all TIDs is transferred; when the field is set to 1, it can indicate that the context of specified TIDs is transferred. When the non-default transfer field is 1, the above-mentioned forwarding indication information can further include downlink TID information, which (such as the TID bitmap or the TID field shown below) can be used to indicate the downlink TIDs for which the context needs to be transferred, i.e., which downlink TIDs need to transfer the context. Of course, as another possible implementation, the data forwarding information can not include the non-default transfer field. For example, if the data forwarding information does not include the downlink TID information, it can indicate that the context of all TIDs is transferred; for example, if the data forwarding information includes the downlink TID information, it indicates that the context of specified TIDs is transferred.

[0339] (2) A TID bitmap field (or a DL TID bitmap field): when the corresponding bit is set to 1, it can indicate that the corresponding TID performs downlink data forwarding; when the corresponding bit is set to 0, it can indicate that the corresponding TID does not perform downlink data forwarding. The TID bitmap field can be replaced by a TID field, which can be used to indicate the downlink TIDs that perform downlink data forwarding.

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

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

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

[0343] By indicating the buffer size field, the current AP MLD can effectively know the number of MSDUs that the target AP MLD can buffer at most. Thus, when the current AP MLD buffers more MSDUs to the target AP MLD than the number indicated by the buffer size field, the target AP MLD can discard some MSDUs, such as the earliest buffered MSDUs.

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

[0345] As another example 2, the above data forwarding information can be carried in a disassociation frame. The non-AP MLD can send the disassociation frame to the current AP MLD before sending the re-association request frame to the target AP MLD.

[0346] As yet another example 3, the above data forwarding information can be carried in a newly defined frame (such as an early downlink data forwarding request frame as shown in the figure). Figure 11 The non-AP MLD can send the newly defined frame before sending the re-association request frame to the target AP MLD.

[0347] As yet another example 4, the above data forwarding information can be carried in an FT confirmation frame. The format of the frame in which the above data forwarding information can be carried is not listed one by one in the embodiments of the present application.

[0348] As yet another example 5, the above data forwarding information can be carried in a re-association request frame. If the non-AP MLD does not send a frame including the data forwarding information to the current AP MLD before sending the re-association request frame to the target AP MLD, the non-AP MLD can carry the data forwarding information through the re-association request frame. After receiving the re-association request frame, the target AP MLD sends a context transfer request to the current AP MLD, and the context transfer request includes the data forwarding information.

[0349] For downlink transmission, the current AP MLD needs to tell the target AP MLD the next SN. The next SN can be used to represent the starting number of MSDUs delivered from the DS to the target AP MLD and destined for the non-AP MLD. The information of the next SN can be carried in the context transfer response, or can also be carried in the downlink data forwarding end identifier, and the like, which are not listed one by one here.

[0350] In the embodiments of the present application, the current AP MLD and the target AP MLD performing the 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 can include the same QoS mapping element (QoS map element), which can represent the mapping rule of differentiated services code point (DSCP) to TID. One possible implementation is that all APs with context transfer in the same mobile domain carry the same QoS mapping element in the beacon frame. Another possible implementation is to transfer the current QoS mapping policy of the corresponding non-AP MLD (including the uplink and downlink QoS configuration policy QoS Map element and the TID mapping rule of the service stream added by the ADD traffic stream (ADDTS) and SCS) to the target AP MLD in the context transfer response, and carry the transferred QoS Map element in the Reassociation Response frame.

[0351] For the early downlink data forwarding and uplink / downlink data forwarding shown in the embodiments of the present application, the present application further provides a new payload type, such as data forwarding. The new payload type can be used for the current AP MLD to perform data forwarding to the target AP MLD.

[0352] Figure 12a is a frame format diagram provided by the embodiments of the present application. As Figure 12aAs shown, the frame can include at least one of the following: LLC, subnetwork access protocol (SNAP), payload type, and payload. The LLC can include destination service access point (DSAP), source service access point (SSAP), and control. The SNAP can include vendor code and ethertype. For the LLC field and the SNAP field, embodiments of the present application are not limited. As shown, the payload field can include at least one of the following: TID, SN, end mark bit, destination address (DA), source address (SA), length, MSDU. The TID field can be used to indicate the TID corresponding to the MSDU, the SN field can be used to indicate the SN corresponding to the MSDU, the end mark bit can be used to indicate whether the uplink data forwarding or the downlink data forwarding is ended, the destination address field can be used to indicate the destination of the MSDU, the source address field can be used to indicate the source of the MSDU, and the length field can be used to indicate the length of the MSDU. The target AP MLD can determine whether the corresponding MSDU is uplink data forwarding or downlink data forwarding according to whether the MLD address of the non-AP MLD is carried in the DA or the SA, and place the MSDU in the downlink sending buffer or the uplink receiving buffer.

[0353] Figure 12a The number of bytes or bits occupied by each field shown is only an example, and should not be construed as a limitation on the embodiments of the present application. Figure 12a The length of each field shown should not be construed as a limitation on the embodiments of the present application. As shown, there can be a reserved bit after the end mark bit. For the reserved bit, Figure 12a is not shown.

[0354] Table 18 exemplarily shows the value of the payload type field.

[0355] Table 18

[0356]

[0357] The value of the payload type field shown in Table 18 is only an example, and should not be construed as a limitation on the embodiments of the present application.

[0358] In practice, ping-pong may occur during roaming. For example, after a non-AP MLD switches from the current AP MLD to the target AP MLD, the target AP MLD's received signal strength indication (RSSI) may (for example) be lower than the current AP MLD's RSSI. In this case, the non-AP MLD may switch back to the current AP MLD, resulting in a poor user experience.

[0359] To alleviate the deterioration in user experience caused by the Ping-Pong phenomenon, an embodiment of the present application provides an improved method. When the non-AP MLD successfully switches to the target AP MLD, 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 may also retain the GTKSA. However, the IEEE 802.1X controlled port (hereinafter referred to as the control port) is blocked, and frames of category 1 and category 2 or frames of category 1, category 2, and category 3 can be sent between the non-AP MLD and the current AP MLD. Specifically, the time for retaining the PTKSA (or GTKSA) can be the BSS MAX IDLE PERIOD, or other predefined time values.

[0360] Figure 12b This is a state transition diagram provided by an embodiment of the present application. The state transition of the device is as follows:

[0361] State 1: Unauthenticated or unassociated state.

[0362] Figure 12b The state transitions shown can apply to non-AP MLD, the current AP MLD, or the target AP MLD. For ease of description, the following uses non-AP MLD as an example to illustrate each state. For example, in state 1, the non-AP MLD can send class 1 frames.

[0363] For example, when the non-AP MLD successfully performs pre-association security negotiation (PASN) authentication, the non-AP MLD may switch to state 1a.

[0364] State 1a: PASN authentication, unassociated state.

[0365] As in this state 1a, the non-AP MLD can send category 1 frames, or protected category 2 frames.

[0366] When the non-AP MLD is in state 1a, performs deauthentication operation, it can be switched back to state 1.

[0367] State 2: authenticated (except for non-authenticated directional multi-gigabit (DMG) stations (DMG STAs)), unassociated state.

[0368] As in this state 2, the non-AP MLD can send category 1 frames, type 2 frames.

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

[0370] When the non-AP MLD is in state 2, performs deauthentication (except for non-authenticated DMG STAs) operation, it is switched back to state 1.

[0371] The "except for non-authenticated DMG STAs" in the embodiments of the application means that the DMG STAs can not be authenticated. The non-authentication of the DMG STAs shown in the embodiments of the application is only an example, and as the standard progresses, other types of devices can also appear in the future, and the embodiments of the application do not limit this.

[0372] State 3: authenticated (except for non-authenticated DMG STAs), associated (pending RSNA authentication) state.

[0373] As in this state 3, the non-AP MLD can send category 1, category 2, and category 3 frames. At the same time, the control port is closed.

[0374] When the non-AP MLD is in state 2, successfully (re)associates and requires RSNA, it can be switched to state 3.

[0375] When the non-AP MLD is in state 3, performs disassociation operation or unsuccessfully (re)associates (non-AP MLD and non-Individual BSS control point station), it is switched back to state 2.

[0376] When the non-AP MLD is in state 3, performs deauthentication (except for non-authenticated DMG STAs), it is switched back to state 1.

[0377] State 4: State of authentication (except for DMG STAs that do not authenticate), association (RSNA is established or not required).

[0378] As in this state 4, the non-AP MLD can send frames of categories 1, 2, 3. The control port is open at the same time.

[0379] When the non-AP MLD is in state 3, the four-step handshake is successfully performed, and the non-AP MLD can be switched to state 4.

[0380] When the non-AP MLD is in state 2, in the following cases, the non-AP MLD can be switched to state 4: successful (re)association-no RSNA requirement; fast BSS transition; individual BSS four-step handshake; fast initial link setup (re)association and key confirmation.

[0381] When the non-AP MLD is in state 4, the disassociation operation is performed or the (re)association is not successful (the non-AP MLD and the non-individual BSS control point station), the non-AP MLD is switched back to state 2.

[0382] When the non-AP MLD is in state 4, the deauthentication (except for DMG STAs that do not authenticate) is performed, the non-AP MLD is switched back to state 1.

[0383] In the embodiment of the application, after the non-AP MLD successfully (re)associates with the target AP MLD, the non-AP MLD and the target AP MLD can be switched to state 4. The non-AP MLD and the current AP MLD can be switched to state 3a.

[0384] State 3a: State of authentication (except for DMG STAs that do not authenticate), no association (RSNA is established).

[0385] As in this state 3a, the non-AP MLD can send frames of categories 1, 2 or categories 1, 2, 3, and the control port is closed.

[0386] Within a certain time, when the 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 reassociate the current AP MLD, that is, the non-AP MLD and the current AP MLD can be switched to state 4.

[0387] After a certain time is exceeded, or when the non-AP MLD disassociates the current AP MLD, the non-AP MLD and the current AP MLD are switched to state 1.

[0388] In the embodiments of the present application, the Ping-Pong phenomenon occurring in the roaming process can be effectively solved by the newly defined state 3a, and the user experience is improved.

[0389] The embodiments of the present application also provide a format of a context transfer response. The context transfer response can include at least one of the following: a status code (status code) for responding to whether the context transfer request is successful; a MAC address of the Non-AP MLD; a QoS mapping element; a downlink BA context or an uplink BA context.

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

[0391] For example, the uplink BA context can include but is not limited to: a TID; an uplink / downlink bit (UL / DL bit), a bitmap of the scoreboard; a window start position of the scoreboard (denoted as WinStart_R), a window size of the scoreboard (denoted as WinSize_R); a window start position of the receive reorder buffer (denoted as WinStart_B) and a window size (denoted as WinSize_B); one or more SCS descriptor elements; BA parameters such as whether to support A-MSDU, BA timeout value, no fragmentation, HE fragmentation, etc. For the description of the SCS descriptor element, reference can be made to the description in the foregoing or the 802.11 standard, and will not be described in detail here.

[0392] The context transfer response described above is only an example, and should not be construed as a limitation of the embodiments of the present application.

[0393] The communication device provided by the embodiments of the present application will be introduced below.

[0394] The embodiments of the present application divide the functions of the communication device according to the above-mentioned method embodiments, for example, each function module can be divided according to each function, or two or more functions can be integrated into one processing module. The integrated module can be realized in the form of hardware or in the form of a software function module. It should be noted that the division of the modules in the present application is illustrative, and is only a logical function division. When actually implemented, another division method can be used. The communication device of the embodiments of the present application will be described in detail below. Figures 13 to 15 The communication device of the embodiments of the present application is described in detail.

[0395] The communication device shown in the embodiment of the present application may also be called a perception communication device or a ranging communication device, etc. The present application does not limit the specific name of the device.

[0396] Figure 13 This is a schematic diagram of the structure of a communication device provided in an embodiment of the present application. Figure 13 As shown, 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.

[0397] In some embodiments of the present application, the communication device can be used to execute the actions performed 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 execute the non-AP MLD's transceiver-related operations or input / output-related operations in the above method embodiments, and the processing module 1301 is used to execute the non-AP MLD's processing-related operations in the above method embodiments.

[0398] The transceiver module 1302 may be configured to send or output an FT confirmation frame and receive or input an FT response frame. For example, the processing module 1301 may be configured to generate the FT confirmation frame and parse the FT response frame.

[0399] As an example, the transceiver module 1302 may be configured to send an FT confirmation frame, such as sending the FT confirmation frame to the current AP MLD. For example, the transceiver module 1302 may include a radio frequency module, an antenna module, and the like.

[0400] As another example, the transceiver module 1302 may be configured to output an FT confirmation frame. For example, the transceiver module 1302 may include an input and output module.

[0401] For example, the transceiver module 1302 may be used to send or output FT confirmation frames and receive or input FT ACK frames. For example, the processing module 1301 may be used to generate FT confirmation frames and parse FT ACK frames.

[0402] For example, the transceiver module 1302 may be further configured to send or output an early downlink data forward transmission request. The processing module 1301 may be configured to generate the early downlink data forward transmission request.

[0403] For example, the transceiver module 1302 may be used to send or output a reassociation request frame and receive or input a reassociation response frame. For example, the processing module 1301 may be used to generate the reassociation request frame and parse the reassociation response frame.

[0404] The transceiver module 1302 can be configured to receive or input the FT request frame, and transmit or output a remote request corresponding to the FT request frame. The processing module 1301 can be configured to parse the FT request frame, or generate the remote request corresponding to the FT request frame, and the like.

[0405] The specific description of the non-AP MLD can also refer to the method embodiments shown above, which will not be listed one by one here.

[0406] Multiplexing Figure 13 In some embodiments of the application, the communication apparatus can be configured to perform the actions performed by the current AP MLD in the above method embodiments, and at this time, the communication apparatus can be a WLAN device itself or a chip or functional module configured in the device. The transceiver module 1302 is configured to perform the transceiving-related operations or input / output-related operations of the current AP MLD in the above method embodiments, and the processing module 1301 is configured to perform the processing-related operations of the current AP MLD in the above method embodiments.

[0407] The transceiver module 1302 can be configured to receive or input the FT request frame, and transmit or output a remote request corresponding to the FT request frame. The processing module 1301 can be configured to parse the FT request frame, or generate the remote request corresponding to the FT request frame, and the like.

[0408] As an example, the transceiver module 1302 can be configured to receive the FT request frame from the non-AP MLD. The transceiver module 1302 can include a radio frequency module, an antenna module, and the like.

[0409] As another example, the transceiver module 1302 can be configured to input the FT request frame. After the FT request frame is processed by the antenna, the radio frequency module, and the like, the transceiver module 1302 inputs the FT request frame to the processing module 1301, so that the processing module 1301 parses the FT request frame. The transceiver module 1302 can include an input / output module, and the like.

[0410] The transceiver module 1302 can also be configured to receive or input the remote response, and transmit or output the FT response frame corresponding to the remote response. The processing module 1301 can be configured to parse the remote response, and generate the FT response frame.

[0411] The transceiver module 1302 can also be configured to receive or input the FT confirmation frame, and transmit or output a remote request corresponding to the FT confirmation frame. The processing module 1301 can be configured to generate the remote request, and the like.

[0412] The transceiver module 1302 can also be configured to receive or input the remote response, and transmit or output the FT ACK frame. The processing module 1301 can be configured to generate the FT ACK frame.

[0413] The transceiver module 1302 can be configured to receive or input the early downlink data forwarding request, or transmit or output the early downlink data forwarding request.

[0414] The specific description of the target AP MLD can also refer to the method embodiments shown above, which will not be listed one by one here.

[0415] Multiplexing Figure 13 In some embodiments of the application, the communication apparatus can be configured to perform the actions performed by the target AP MLD in the above method embodiments. The target AP MLD can be the WLAN device itself or a chip or functional module configured in the device. The transceiver module 1302 can be configured to perform the transceiving-related operations or input / output-related operations of the target AP MLD in the above method embodiments. The processing module 1301 can be configured to perform the processing-related operations of the target AP MLD in the above method embodiments.

[0416] The transceiver module 1302 can be configured to receive or input the remote request, and transmit or output the remote response. The processing module 1301 can be configured to parse the remote request, and generate the remote response, etc.

[0417] As an example, the transceiver module 1302 can be configured to receive the remote request, and transmit the remote response. The transceiver module 1302 can include a radio frequency module, an antenna module, etc.

[0418] As another example, the transceiver module 1302 can be configured to input the remote request, and output the remote response. The transceiver module 1302 can include an input / output module, etc.

[0419] The transceiver module 1302 can also be configured to receive or input the early downlink data forwarding request.

[0420] The transceiver module 1302 can also be configured to receive or input the re-association request frame. The processing module 1301 can be configured to parse the re-association request frame.

[0421] The transceiver module 1302 can also be configured to transmit or output the re-association response frame. The processing module 1301 can be configured to generate the re-association response frame.

[0422] The specific description of the target AP MLD can also refer to the method embodiments shown above, which will not be listed one by one here.

[0423] Optionally, in each of the above embodiments, the communication apparatus can further include a storage module, which can be configured to store instructions and / or data. The processing module 1301 can read the instructions and / or data in the storage module to enable the apparatus to implement the above method embodiments.

[0424] In the above embodiments, the specific description of the terms or nouns such as FT request frame, FT response frame, FT confirmation frame, FT ACK frame, early downlink data forwarding request, re-association request frame, re-association response frame, context transfer request, context transfer response, and the like can refer to the description in the method embodiments, and will not be repeated here.

[0425] The specific description of the transceiver module and the processing module in the above embodiments is only an example. For the specific functions or executed steps of the transceiver module and the processing module, reference can be made to the above method embodiments, and will not be described here.

[0426] It can be understood that the division of the modules in the above apparatus is only a logical function division. One function module can correspond to each function, or two or more functions can be integrated into one function module. In actual implementation, all or part of the modules can be integrated into one physical entity, or can be distributed on different physical entities. In addition, the function modules can be implemented in the form of hardware, software, or a combination of hardware and software. Whether a certain function is implemented in the form of hardware or software depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0427] In one example, the functional units in any of the above apparatuses can 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.

[0428] The above introduces the apparatus of the embodiments of the present application, and the following introduces possible product forms of the apparatus. Any product form that has the functions of the above apparatus falls within the protection scope of the embodiments of the present application. The following introduction is only an example, and does not limit the product form of the apparatus of the embodiments of the present application to only this. Figure 13 Any product form of the apparatus has the functions of the above apparatus, and falls within the protection scope of the embodiments of the present application. The following introduction is only an example, and does not limit the product form of the apparatus of the embodiments of the present application to only this.

[0429] In a possible implementation manner, Figure 13 In the communication apparatus shown, the processing module 1301 can be one or more processors, and the transceiver module 1302 can be a transceiver, or the transceiver module 1302 can also be a sending module and a receiving module, the sending module can be a transmitter, and the receiving module can be a receiver, and the sending module and the receiving module are integrated in one device, for example, a transceiver. In the embodiment of the application, the processor and the transceiver can be coupled and the like, and the connection manner of the processor and the transceiver is not limited in the embodiment of the application. In the process of executing the above method, the process about sending information in the above method can be the process that the processor outputs the above information. When the above information is output, the processor outputs the above information to the transceiver, so as to be transmitted by the transceiver. After the above information is output by the processor, the above information can also need to be processed further, and then reaches the transceiver. Similarly, the process about receiving information in the above method can be the process that the processor receives the input above information. When the processor receives the input information, the transceiver receives the above information and inputs the processor. Further, after the transceiver receives the above information, the above information can need to be processed further, and then inputs the processor.

[0430] Figure 14 FIG. 13 is another structural schematic diagram of the communication apparatus provided by the embodiment of the application. As shown in the figure, Figure 14 The communication apparatus 140 includes one or more processors 1420 and a transceiver 1410.

[0431] In some embodiments of the application, the communication apparatus can be used to execute the steps or methods or functions executed by the non-AP MLD, for example, the processor 1420 can be used to execute the functions or steps implemented by the processing module 1301 as shown in Figure 13 The transceiver 1410 can be used to execute the functions or steps implemented by the transceiver module 1302 as shown in Figure 13 The specific description of the processor 1420 and the transceiver 1410 can be referred to the method embodiments shown in Figure 13 or the above, which will not be described in detail here.

[0432] In some embodiments of the application, the communication apparatus can be used to execute the steps or methods or functions executed by the non-AP MLD, for example, the processor 1420 can be used to execute the functions or steps implemented by the processing module 1301 as shown in Figure 13 The transceiver 1410 can be used to execute the functions or steps implemented by the transceiver module 1302 as shown in Figure 13 The specific description of the processor 1420 and the transceiver 1410 can be referred to the method embodiments shown in Figure 13 or the above, which will not be described in detail here.

[0433] In some embodiments of the present application, the communication device can be configured to perform the steps or methods or functions performed by the target AP MLD as described above, such as the processor 1420 can be configured to perform the functions or steps implemented by the processing module 1301 as shown in Figure 13 The transceiver 1410 can be configured to perform the functions or steps implemented by the transceiving module 1302 as shown in Figure 13 The specific description of the processor 1420 and the transceiver 1410 can be referred to the description of the processor 120 and the transceiver 110 in Figure 13 or the method embodiments shown above, which will not be described in detail here.

[0434] In various implementations of the apparatus shown in Figure 14 The transceiver can include a receiver configured to perform the functions (or operations) of receiving and a transmitter configured to perform the functions (or operations) of transmitting. And the transceiver is configured to communicate with other devices / apparatuses through transmission media.

[0435] Optionally, the communication device 140 can further include one or more memories 1430 configured to store program instructions and / or data. The memory 1430 is coupled to the processor 1420. The coupling between the apparatuses, units or modules in the embodiments of the present application is indirect coupling or communication connection between the apparatuses, units or modules, which can be electrical, mechanical or other forms, for information interaction between the apparatuses, units or modules. The processor 1420 can operate in cooperation with the memory 1430. The processor 1420 can execute the program instructions stored in the memory 1430. Optionally, at least one of the one or more memories described above can be included in the processor.

[0436] The specific connection medium between the transceiver 1410, the processor 1420 and the memory 1430 in the embodiments of the present application is not limited. In the embodiments of the present application, the memory 1430, the processor 1420 and the transceiver 1410 are connected through a bus 1440, which is represented by a thick line in Figure 14 The connection mode between other components is only schematically illustrated and is not limited. The bus can be divided into an address bus, a data bus, a control bus, etc. For convenience of representation, Figure 14 In the embodiments of the present application, only one thick line is used to represent the bus, but it does not mean that there is only one bus or only one type of bus. Figure 14

[0437] ​In the embodiments of the present application, the processor can be a general processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, etc., which can implement or execute the disclosed methods, steps and logic block diagrams in the embodiments of the present application. The general processor can be a microprocessor or any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as execution completed by a hardware processor, or executed by a combination of hardware and software modules in the processor, etc.

[0438] In the embodiments of the present application, the memory can include, but is not limited to, a non-volatile memory such as a hard disk drive (HDD) or a solid-state drive (SSD), a random access memory (RAM), an erasable programmable ROM (EPROM), a read-only memory (ROM) or a compact disc read-only memory (CD-ROM), etc. The memory can be any storage medium capable of carrying or storing program codes in the form of instructions or data structures and capable of being read and / or written by a computer (such as the device shown in the present application, etc.), but is not limited thereto. The memory in the embodiments of the present application can also be a circuit or any other device capable of realizing a storage function, used for storing program instructions and / or data.

[0439] The processor 1420 is mainly used for processing communication protocols and communication data, and controlling the whole device, executing software programs, and processing data of the software programs. The memory 1430 is mainly used for storing software programs and data. The transceiver 1410 can include a control circuit and an antenna, and the control circuit is mainly used for conversion between baseband signals and radio frequency signals and processing of the radio frequency signals. The antenna is mainly used for transmitting and receiving radio frequency signals in the form of electromagnetic waves. The input and output device, such as a touch screen, a display screen, a keyboard, etc., is mainly used for receiving data input by a user and outputting data to the user.

[0440] When the apparatus is powered on, the processor 1420 can read a software program in the memory 1430, interpret and execute instructions of the software program, and process data of the software program. When data needs to be sent wirelessly, the processor 1420 outputs a baseband signal to the radio frequency circuit after baseband processing of the data to be sent, and the radio frequency circuit converts the baseband signal into a radio frequency signal and sends the radio frequency signal in the form of an electromagnetic wave to the outside through an antenna. When data is sent to the apparatus, the radio frequency circuit receives a radio frequency signal through the antenna, converts the radio frequency signal into a baseband signal, and outputs the baseband signal to the processor 1420, and the processor 1420 converts the baseband signal into data and processes the data.

[0441] In another implementation, the radio frequency circuit and the antenna can be arranged independently of the processor that performs baseband processing, for example, in a distributed scenario, the radio frequency circuit and the antenna can be arranged remotely from the apparatus.

[0442] The apparatus shown in the embodiments of the present application can also have more components, etc., which are not limited in the embodiments of the present application. The methods performed by the processor and the transceiver shown above are only examples, and the specific steps performed by the processor and the transceiver can refer to the methods introduced above. Figure 14

[0443] In another possible implementation, Figure 13 In the apparatus shown, the processing module 1301 can be one or more logic circuits, and the transceiving module 1302 can be an input output interface, also called a communication interface, or an interface circuit, or an interface, etc. Alternatively, the transceiving module 1302 can also be a sending module and a receiving module, the sending module can be an output interface, and the receiving module can be an input interface, and the sending module and the receiving module are integrated in one module, for example, an input output interface.

[0444] Figure 15 is another structure diagram of a communication apparatus provided by the embodiments of the present application. As shown in Figure 15 Figure 15 The communication apparatus shown includes a logic circuit 1501 and an interface 1502. That is, the processing module 1301 can be implemented by the logic circuit 1501, and the transceiving module 1302 can be implemented by 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, a pin, or an interface circuit, etc. For example, Figure 15 is an example in which the above communication apparatus is a chip, and the chip includes the logic circuit 1501 and the interface 1502.

[0445] ​​In the embodiments of the present application, the logic circuit and the interface can also be coupled with each other. The present application does not limit the specific connection mode of the logic circuit and the interface. For example, the logic circuit 1501 can be used to execute the functions or steps implemented by the processing module 1301 as shown in Figure 13 For example, the interface 1502 can be used to execute the functions or steps implemented by the transceiving module 1302 as shown in Figure 13 The specific description of the logic circuit 1501 and the interface 1502 can be referred to the method embodiments shown in Figure 13 or the above, which will not be described here in detail.

[0446] The device shown in the embodiments of the present application can realize the method provided by the embodiments of the present application in the form of hardware, or realize the method provided by the embodiments of the present application in the form of software, etc. The present application does not limit this.

[0447] The embodiments of the present application also provide a communication system, which includes at least two of the non-AP MLD, the current AP MLD or the target AP MLD, and the non-AP MLD, the current AP MLD and the target AP MLD can be used to execute the method in any of the preceding embodiments.

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

[0449] The present application also provides a computer readable storage medium, which stores computer code, when the computer code runs on the computer, so that the computer executes the operations and / or processes performed by various devices in the method provided by the present application.

[0450] The present application also provides a computer program product, which includes computer code or computer program, when the computer code or computer program runs on the computer, so that the operations and / or processes performed by various devices in the method provided by the present application are executed.

[0451] In several embodiments provided by the present application, it should be understood that the disclosed system, device and method can be implemented by other ways. For example, the device embodiments described above are only schematic, for example, the division of the modules is only a logical function division, and actual implementation can have another division mode, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed mutual ones can be indirect coupling or communication connection through some interfaces, devices or modules, and can also be electrical, mechanical or other forms of connection.

[0452] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed to multiple network modules. Part or all of the modules can be selected according to actual needs to achieve the technical effects of the scheme provided by the embodiments of the present application.

[0453] In addition, each functional module in each embodiment of the present application can be integrated into one processing module, or each module can exist physically alone, or two or more modules can be integrated into one module. The integrated module can be realized in the form of hardware or in the form of a software functional module.

[0454] The integrated module, if realized in the form of a software functional module and sold or used as an independent product, can be stored in a computer readable storage medium. Based on this understanding, the technical scheme of the present application essentially or the part that contributes to the prior art, or all or part of the technical scheme can be embodied in the form of a software product. The computer software product is stored in a readable storage medium, including a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned readable storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program code storage media.

[0455] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A resource request method, characterized by, The method comprises: A non-access point multi-link device (non-AP MLD) sends a fast basic service set transfer (FT) confirmation frame to a current access point multi-link device (AP MLD), the FT confirmation frame is used for the non-AP MLD to request resources from a target AP MLD, the FT confirmation frame comprises a resource information container (RIC) request, the RIC request comprises a resource descriptor field, and the resource descriptor field comprises at least one of a stream classification service (SCS) descriptor element, a target wake-up time (TWT) element or a wake-up request element, and the wake-up request element is used for waking up a first AP affiliated to the target AP MLD. The non-AP MLD receives an FT acknowledgement (ACK) frame from the current AP MLD.

2. A resource request method, characterized by, The method comprises: A target access point multi-link device (AP MLD) receives a remote request from a current AP MLD, the remote request is used for a non-access point multi-link device (non-AP MLD) to request resources from the target AP MLD, the remote request comprises a resource information container (RIC) request, the RIC request comprises a resource descriptor field, and the resource descriptor field comprises at least one of a stream classification service (SCS) descriptor element, a target wake-up time (TWT) element or a wake-up request element, and the wake-up request element is used for waking up a first AP affiliated 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 comprises wake-up indication information.

4. The method of claim 3, wherein, The wake-up indication information comprises updated wake-up parameters corresponding to the first AP.

5. The method of claim 4, wherein, The wake-up indication information comprises a basic service set identification (BSSID) or a link identification (LinkID) of the first AP.

6. The method of claim 4 or 5, wherein The updated wake-up parameters comprise at least one of a start time of a wake-up window, a duration of the wake-up window or a time interval between adjacent wake-up windows; or The updated wake-up parameters comprise a duration of wake-up; or The updated wake-up parameters comprise at least one of a bandwidth of the first AP, a number of spatial streams of the first AP or a modulation and coding strategy (MCS) of the first AP.

7. The method according to any one of claims 1 to 6, characterized in that, The FT ACK frame comprises a RIC data element (RDE) field, the RDE field comprises a status code field, and the status code field is used to indicate whether the non-AP MLD successfully requests the resources.

8. The method of claim 7, wherein, The status code field is used to indicate the target AP MLD to the non-AP MLD that the target AP MLD rejects resources corresponding to the SCS descriptor element, and the FT ACK frame comprises a SCS descriptor element suggested by the target AP MLD; or The status code field is used to indicate the target AP MLD to the non-AP MLD that the target AP MLD rejects resources corresponding to the TWT element, and the FT ACK frame comprises a 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 a wake-up request element suggested by the target AP MLD.

9. The method according to any one of claims 1 to 8, characterized in that, The resource descriptor resource further includes a RIC descriptor element, and the RIC descriptor element 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 of an 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 of an ADDBA extension.

10. A resource request method, characterized by, The method comprises: A non-access point multi-link device (non-AP MLD) receives a fast basic service set transfer (FT) response frame from a current access point multi-link device (AP MLD), and the FT response frame includes downlink block acknowledgement (BA) information, wherein the downlink BA information is used to request establishment of a downlink BA session between a target AP MLD and the non-AP MLD; The non-AP MLD sends an FT acknowledgement (ACK) frame to the current AP MLD; or A non-access point multi-link device (non-AP MLD) receives a fast basic service set transfer (FT) acknowledgement (ACK) frame from a current access point multi-link device (AP MLD), and the FT ACK frame includes downlink block acknowledgement (BA) information, wherein the downlink BA information is used to request establishment of a downlink BA session between a target AP MLD and the non-AP MLD; The non-AP MLD sends an FT acknowledgement (ACK) frame to the current AP MLD. The method comprises:

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

12. The method of claim 11, wherein, The remote request includes a fast basic service set transfer (FT) response frame, and the FT response frame includes the downlink BA information; or The remote request includes an FT acknowledgement (ACK) frame, and the FT ACK frame includes downlink BA information. The downlink BA information includes: a BA parameter set, a BA timeout value, a BA start sequence control, and an ADDBA extension.

13. The method according to any one of claims 10-12, characterized in that, The FT response frame further includes a fast basic service set transfer element (FTE), and the FTE includes a message integrity code (MIC), wherein the MIC is used to verify the FT response frame; or 14. The method of claim 10 or 12, wherein, The FT ACK frame further includes an FTE, and the FTE includes a MIC, wherein the MIC is used to verify the FT ACK frame. A module for performing the method of any one of claims 1-14 is included.

15. A communications device, characterized by A processor is included for performing the method of any one of claims 1-14.

16. A communications device, characterized by ​ 17. The method of claim 16, wherein, The communication device further comprises a transceiver for transmitting or receiving information.

18. A communications device, characterized by comprises a logic circuit and an interface, the logic circuit and the interface being coupled; the interface is for inputting and / or outputting information, and the logic circuit is for performing the method according to any one of claims 1-14.

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

20. A computer program product, characterised in that, The computer program product, when executed, performs the method according to any one of claims 1-14.

21. A communication system, characterized by comprises a non-AP MLD and a target AP MLD, the non-AP MLD is configured to perform the method according to any one of claims 1, 3-9, and the target AP MLD is configured to perform the method according to any one of claims 2-9; or, the non-AP MLD is configured to perform the method according to any one of claims 10, 12-14, and the target AP MLD is configured to perform the method according to any one of claims 11-14.

Images