Communication method and apparatus, storage medium, program product, and chip

Abstract

Provided are a communication method and apparatus, a storage medium, a program product, and a chip. The method comprises: sending first information, wherein the first information indicates a transfer priority of at least one context.

Description

Communication methods and devices, storage media, software products and chips

[0001] This disclosure claims priority to Chinese Patent Application No. 202510395843.4, filed on March 28, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure belongs to the field of Wi-Fi communication technology, specifically relating to a communication method and apparatus, storage medium, software product and chip. Background Technology

[0003] Roaming refers to the ability of a non-access point station (non-AP STA) to switch from one wireless access point station (AP STA) to another in a wireless local area network (WLAN) while the WLAN continues to provide services to it. Summary of the Invention

[0004] In a first aspect, embodiments of this disclosure provide a communication method, the method comprising:

[0005] Send a first message, which indicates the transfer priority of at least one context.

[0006] In one implementation, the first information includes at least one set of transfer priority information, each set of transfer priority information indicating the transfer priority of at least one context in the corresponding context category.

[0007] In one implementation, the context category includes Block Confirmation (BA) related context, Stream Classification Service (SCS) related context, or Target Wake-up Time (TWT) related context.

[0008] In one implementation, the first information is carried in a first authentication frame, a Fast Basic Service Set Transfer (FT) request frame, a link reconstruction request frame, or a link establishment request frame.

[0009] In one implementation, the method further includes:

[0010] Receive second information, which indicates the context that needs to be transferred and / or the context that needs to be renegotiated.

[0011] In one implementation, the second information further includes recommendation parameters, which are parameters for establishing the context that needs to be renegotiated.

[0012] In one implementation, the second information is also used to indicate the context in which demolition is required.

[0013] In one implementation, the context that needs to be demolished is by default a context other than the context that needs to be transferred and the context that needs to be renegotiated.

[0014] In one implementation, the second information is carried in a second authentication frame, an FT response frame, a link reconstruction response frame, or a link establishment response frame.

[0015] In one implementation, the method further includes:

[0016] Send a third message, which is used to request the establishment of a context that needs to be renegotiated.

[0017] In one implementation, the third information is carried in the RIC request field.

[0018] Secondly, embodiments of this disclosure provide a communication method, the method comprising:

[0019] Receive first information, which indicates the transfer priority of at least one context.

[0020] In one implementation, the first information includes at least one set of transfer priority information, each set of transfer priority information indicating the transfer priority of at least one context in the corresponding context category.

[0021] In one implementation, the context category includes Block Confirmation (BA) related context, Stream Classification Service (SCS) related context, or Target Wake-up Time (TWT) related context.

[0022] In one implementation, the first information is carried in a first authentication frame, a Fast Basic Service Set Transfer (FT) request frame, a link reconstruction request frame, or a link establishment request frame.

[0023] In one implementation, the method further includes:

[0024] Send a second message indicating the context that needs to be transferred and / or the context that needs to be renegotiated.

[0025] In one implementation, the second information further includes recommendation parameters, which are parameters for establishing the context that needs to be renegotiated.

[0026] In one implementation, the second information is also used to indicate the context in which demolition is required.

[0027] In one implementation, the context that needs to be demolished is by default a context other than the context that needs to be transferred and the context that needs to be renegotiated.

[0028] In one implementation, the second information is carried in a second authentication frame, an FT response frame, a link reconstruction response frame, or a link establishment response frame.

[0029] In one implementation, the method further includes:

[0030] Receive third information, which is used to request the establishment of a context that needs to be renegotiated.

[0031] In one implementation, the third information is carried in the RIC request field.

[0032] Thirdly, embodiments of this disclosure provide a communication device, the communication device comprising:

[0033] A sending module is configured to send first information, the first information indicating the transfer priority of at least one context.

[0034] Fourthly, embodiments of this disclosure provide a communication device, the communication device comprising:

[0035] A receiving module is configured to receive first information, the first information indicating the transfer priority of at least one context.

[0036] Fifthly, embodiments of this disclosure provide a communication device, including a processor and a memory communicatively connected to the processor;

[0037] The memory stores computer-executed instructions;

[0038] The processor executes computer execution instructions stored in the memory to implement the method according to the first aspect or the second aspect.

[0039] In a sixth aspect, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the method according to the first or second aspect.

[0040] In a seventh aspect, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method described according to the first or second aspect.

[0041] Eighthly, embodiments of this disclosure provide a chip including at least one processor and an interface circuit, the interface circuit being connected to the at least one processor, the at least one processor executing program instructions to perform the method according to the first or second aspect.

[0042] In one embodiment, the chip is a chip in a chip module.

[0043] Ninthly, embodiments of this disclosure provide a module device, the module device including a power module, a storage module, and a chip module;

[0044] The power module is used to provide electrical energy to the module device;

[0045] The storage module is used to store data and instructions;

[0046] The chip module is used to perform the method according to the first aspect or the second aspect. Attached Figure Description

[0047] Figure 1 is a schematic diagram of an application scenario according to some embodiments.

[0048] Figure 2 is a flowchart illustrating one of the related processes in some technologies.

[0049] Figure 3 is a flowchart of one FT process in some technologies.

[0050] Figure 4 is a flowchart of another FT process in some technologies.

[0051] Figure 5 is a schematic diagram of the frame structure of the block confirmation parameter set field in some technologies.

[0052] Figure 6 is a flowchart of another FT process in some technologies.

[0053] Figure 7 is a flowchart of another FT process in some technologies.

[0054] Figure 8 is a schematic diagram of resource requests in some technologies.

[0055] Figure 9 is a schematic diagram of the process of establishing a multi-link connection between multi-link devices in some technologies.

[0056] Figure 10 is a schematic diagram of the structure of an FT request frame in some technologies.

[0057] Figure 11 is a schematic diagram of the structure of FT response frames in some technologies.

[0058] Figure 12 is a flowchart illustrating a communication method according to some embodiments.

[0059] Figure 13 is a schematic diagram of the structure of an FT request frame according to some examples.

[0060] Figure 14 is a schematic diagram of the structure of a transfer priority field for a context based on some examples.

[0061] Figure 15 is a flowchart illustrating another communication method according to some embodiments.

[0062] Figure 16 is a schematic diagram of the structure of an FT response frame based on some examples.

[0063] Figure 17 is a schematic diagram of the structure of a context field that needs to be transferred and / or renegotiated, based on some examples.

[0064] Figure 18 is a flowchart of an FT process based on some examples.

[0065] Figure 19 is a flowchart illustrating another FT process based on some examples.

[0066] Figure 20 is a flowchart illustrating another communication method according to some embodiments.

[0067] Figure 21 is a flowchart illustrating another communication method according to some embodiments.

[0068] Figure 22 is a flowchart illustrating another communication method according to some embodiments.

[0069] Figure 23 is a schematic diagram of the structure of a communication device according to some embodiments.

[0070] Figure 24 is a schematic diagram of the structure of another communication device according to some embodiments.

[0071] Figure 25 is a schematic diagram of the structure of another communication device according to some embodiments. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0073] For ease of understanding, the application scenarios applicable to the embodiments of this disclosure will be described below with reference to Figure 1.

[0074] Figure 1 is a schematic diagram of an application scenario according to some embodiments. Referring to Figure 1, taking a wireless local area network as an example, it includes AP STA101, AP STA102, and non-AP STA103.

[0075] The basic service set (BSS) to which AP STA101 belongs and the extended service set (ESS) to which AP STA102 belongs belong to the same BSS. Non-AP STA103 can roam from AP STA101 to AP STA102.

[0076] It should be noted that the above application scenarios are merely examples. In one implementation, the AP STA can also be an access point multi-link device (AP MLD), and the non-AP STA can also be a non-access point multi-link device (non-AP MLD). The application scenarios may also include other numbers of devices, and this disclosure does not limit this.

[0077] To explain this disclosure more clearly, the relevant technologies involved in this disclosure will be introduced first below.

[0078] 1. Basic Service Set (BSS)

[0079] BSS is a fundamental component of an 802.11 network, used to describe a group of communicating mobile devices in an 802.11 WLAN.

[0080] There are two types of BSSs: one is the infrastructure-mode BSS, which includes one AP STA and several non-AP STAs; the other is the stand-alone-mode BSS, which consists of several non-AP STAs. This disclosure mainly discusses the infrastructure-mode BSS.

[0081] Each BSS has a unique identifier called the Basic Service Set Identifier (BSSID).

[0082] 2. Extended Service Set (ESS)

[0083] It is a union of BSSs with the same identifier connected by a distribution system (DS), but ESS does not include DS.

[0084] 3. Roaming-related content

[0085] In IEEE 802.11, the association process between a non-AP STA and an ESS AP STA is relatively time-consuming, requiring complete authentication and key generation, as shown in Figure 2. On the AP STA side, a context also needs to be established based on the capabilities of the non-AP STA, involving the allocation and initialization of space for many variables, cache allocation, etc.

[0086] When a non-AP STA roams within an ESS to a new AP STA (i.e., the target AP STA), it needs to reassociate with the target AP STA. The reassociation process is similar to the associativity process, and it also involves ESS routing updates (including DS mapping updates), which is time-consuming and can lead to prolonged service communication interruptions (>100ms). The reassociation process also involves forwarding downlink data cached on the current AP STA to the target AP STA. How to perform ESS routing updates and downlink data forwarding is currently implemented by the AP STA and is independent of the standard.

[0087] IEEE 802.11r introduced Fast BSS Transition (FT). For example, a non-AP MLD can pre-compile a key generation process with the target AP MLD through the current AP MLD, and then re-associate with the target AP MLD, which greatly reduces the service communication interruption (50ms). Figure 3 is a flowchart of one FT process, and Figure 4 is a flowchart of another FT process.

[0088] 4. Block Acknowledgment (BA)

[0089] In IEEE 802.11, for frames that require acknowledgment, the sending end waits for an acknowledgment after a short inter-frame space (SIFS) after sending each frame. If no acknowledgment is received, the frame is retransmitted, so that the station can sequentially submit the Media Access Control Service Data Unit (MSDU) upwards after receiving the frame.

[0090] As physical layer speeds increase, this mechanism becomes too costly. Therefore, a block acknowledgment mechanism was introduced. This involves both parties pre-negotiating a block acknowledgment protocol for data streams identified by certain traffic identifiers (TIDs). The negotiation process also involves determining how the parties allocate buffers. After establishing the block acknowledgment protocol, the sending end transmits multiple frames (typically aggregated into an aggregated Media Access Control Protocol Data Unit (MPDU) within a Physical Layer Protocol Data Unit (PPDU)) to trigger acknowledgment at the receiving end.

[0091] The parameters of the block confirmation protocol are shown in Figure 5, including the aggregated MSDU (A-MSDU) subfield, the block confirmation policy subfield, the TID subfield, and the cache size subfield. Setting the value of the block confirmation policy subfield to 1 indicates that block confirmation is enabled, and the value of the cache size subfield indicates the size of the sliding window.

[0092] Both the sending and receiving ends maintain a bitmap in the block acknowledgment, indicating which MPDUs were successfully transmitted and which were not. The sending end retransmits the MPDUs that were not successfully transmitted. In a block acknowledgment, the receiving end may have preceding MPDUs that were not successfully transmitted. To ensure the sequential submission of MPDUs upwards, it needs to buffer the successfully received MPDUs and wait for the retransmission of the preceding failed MPDUs.

[0093] In one implementation, during the FT process, a block acknowledgment protocol can be established simultaneously with the reassociation of the non-AP MLD with the target AP MLD. As shown in Figure 4, the signaling required to establish the block acknowledgment protocol can be carried through a resource information container (RIC).

[0094] In one implementation, during the FT process, a block acknowledgment protocol can be established in advance before the non-AP MLD is reassociated with the target AP MLD, to further reduce service interruption time caused by switching AP MLDs. As shown in Figures 6 and 7, the signaling required to establish the block acknowledgment protocol can be carried via RIC.

[0095] After a non-AP MLD is reassociated with the target AP MLD, the sending end (non-AP MLD or AP MLD) will start transmitting from the first MPDU that was not successfully transmitted (MSDUs that were successfully transmitted with the current AP MLD (i.e., the old AP MLD) also need to be transmitted again).

[0096] 5. RIC

[0097] A Resource Request (RIC) is a collection of elements used to represent a resource request or response. When an RIC is used to initiate a request, it includes one or more resource requests, each describing a specific resource requirement. As shown in Figure 8, each resource request consists of a resource descriptor element (RDE) and one or more alternative resource descriptors. The format of a resource request is shown in Figure 8.

[0098] 6. Multi-link devices

[0099] A multi-link device is a wireless communication device that supports parallel transmission across multiple links. It is also known as a multi-link device (MLD) or a multi-band device. For example, in a wireless local area network (WLAN), this communication device supports communication using the IEEE 802.11 series of protocols, including 802.11be, 802.11ax, or 802.11a / b / g / n / ac.

[0100] A multilink device includes one or more affiliated sites (STAs). For example, the Extremely High Throughput (EHT) in IEEE 802.11be defines a multilink device as potentially including up to 15 affiliated sites.

[0101] The affiliated site can be an AP STA or a non-AP STA. For ease of description, this disclosure refers to a multi-link device whose affiliated site is an AP STA as a multi-link access point device or access point multi-link device (AP MLD); and a multi-link device whose affiliated site is a non-AP STA as a multi-link site device or site multi-link device (STA MLD). An AP MLD can contain multiple AP STAs, and a non-AP MLD can contain one or more non-AP STAs. One or more links can be established between two multi-link devices (through association requests / responses in the association process on a certain link). Figure 9 is a schematic diagram of the process of establishing a multi-link connection between multi-link devices.

[0102] Multilink devices can implement wireless communication by following the 802.11 series of protocols, such as EHT, or 802.11be-based or compatible with 802.11be, thereby enabling communication with other devices, which may or may not be multilink devices.

[0103] APs that support IEEE 802.11be and later protocols are all in AP MLD form.

[0104] A non-AP STA cannot be associated with an AP MLD, but it can be associated with an AP STA to which the AP MLD belongs.

[0105] When the roaming target of a non-AP MLD is an AP MLD, the non-AP MLD initiates a reassociation process or a FT process through one of its affiliated non-AP STAs.

[0106] When the roaming target of a non-AP MLD is an AP STA, the non-AP MLD can select a non-AP STA belonging to the same frequency band as the target AP STA and initiate a reassociation process or FT process using the MLD address to ensure that the MAC address remains unchanged.

[0107] 7. Stream classification service (SCS)

[0108] SCS is a technology used to improve the quality of service (QoS) of Wi-Fi networks.

[0109] A non-AP STA can send an SCS request to an AP STA, or a non-AP MLD can send an SCS request to an AP MLD. The SCS request may include an SCS ID, QoS requirements, and SCS characteristics. SCS characteristics may include, for example, the source Internet Protocol (IP) address, which is the IP address of the originating device (non-AP STA or non-AP MLD) of the data stream to be classified and processed.

[0110] An AP STA can send an SCS response to a non-AP STA, or an AP MLD can send an SCS response to a non-AP MLD. The SCS response indicates agreement to the SCS request, or it indicates disagreement with the SCS request and carries recommended new parameters.

[0111] After the SCS protocol is established, the AP STA or AP MLD should meet the negotiated QoS when scheduling uplink and downlink data transmission.

[0112] 8. Target wake time (TWT)

[0113] TWT is an energy-saving mechanism in Wi-Fi networks. Non-AP STAs and AP STAs can establish a wake-up protocol to save power. For example, non-AP STAs and AP STAs can negotiate a specific wake-up time (wake-up point or wake-up period). The non-AP STA will wake up at the wake-up time to exchange data with the AP STA, while remaining in sleep mode at other times.

[0114] Alternatively, a restricted target wake-up time (R-TWT) service period can be used to guarantee low-latency, high-reliability service QoS. For example, the R-TWT SP is broadcast by the AP STA in a beacon frame so that other stations stop using the channel before the R-TWT SP and do not participate in channel contention at the start of the R-TWT SP. This ensures that non-AP STAs can compete for and schedule the channel, achieving low-latency, high-reliability service transmission.

[0115] 9. The structure of each frame during the FT process

[0116] As shown in Figure 10, the FT request frame includes a category field, an action field, a STA address field, a target AP address field, and an FT request frame body. The target AP address field sets the basic service set identifier (BSSID) (#3522) of the BSS to which the target AP STA belongs. The information included in the FT request frame body is shown in Table 1.

[0117] Table 1

[0118] As shown in Figure 11, the FT response frame includes a type field, an FT action field, a STA address field, a destination AP address field, a status code field, and an FT response frame body. The information included in the FT response frame body is shown in Table 2.

[0119] Table 2

[0120] One of the goals of IEEE 802.11bn (Ultra High Reliability, UHR) is to reduce latency, which can be achieved by improving the roaming process. One proposed optimization scheme is context transfer (e.g., block acknowledgment related context, SCS, TWT, etc.) and / or data forwarding (transferring data from the buffer to the target AP). For example, when the target AP MLD receives a reassociation request, it can send a context transfer request to the current AP MLD, requesting the current AP MLD to send a context transfer response to the target AP MLD when it confirms that the context can be transferred.

[0121] The motions adopted by IEEE 802.11bn include:

[0122] Motion 27: As part of the seamless roaming process, the following operations can be performed during roaming:

[0123] (1) After triggering a pending request / response signaling exchange that initiates a DS mapping change notification from the current AP MLD to the target AP MLD, ① the current AP MLD can transmit buffered downlink (DL) data frames within a to be defined (TBD) period; ② the non-AP MLD can pull buffered DL data frames from the current AP MLD; ③ the non-AP MLD can send uplink (UL) data to the target AP MLD; ④ it is assumed that the target AP MLD can pass data frames to the non-AP MLD after the DS mapping change.

[0124] (2) The current AP MLD can forward DL data to the target AP MLD. When and how to forward DL data to the target AP MLD is yet to be determined.

[0125] Motion 44:

[0126] (1) Define the request frame sent by the non-AP MLD in state 4 to initiate the roaming process. The roaming process performs a context transfer to the target AP MLD and performs the necessary changes to the DS mapping from the current AP MLD to the target AP MLC.

[0127] (2) Define the response frame sent by the current AP MLD to the non-AP MLD to indicate that the non-AP MLD can send a Class 3 frame to the target AP MLD.

[0128] During request / response frame exchange, the details of data transmission from the non-AP MLD to the current AP MLD are yet to be determined.

[0129] The context of the transfer is yet to be determined.

[0130] The specific type of frame used for request / response frames between the non-AP MLD and the current MLD / target AP MLD is yet to be determined.

[0131] Motion 162: As part of the seamless roaming process, a roaming preparation process may be performed prior to the request / response transfer, including:

[0132] (1) Transfer or renegotiate the context to the target AP MLD. That is, transfer the context related to the non-AP MLD from the current AP MLD to the target AP MLD, or renegotiate these contexts.

[0133] (2) Establish a link with the target AP MLD.

[0134] The context that can be transferred or renegotiated is yet to be determined.

[0135] Motion 279: IEEE 802.11bn defines a Seamless Mobility Domain (SMD), the exact name of which is yet to be determined. This SMD contains multiple AP MLDs, and non-AP MLDs can roam between multiple AP MLDs within the SMD using a seamless roaming process.

[0136] (1) The logical SMD management entity (SMD-ME, exact name to be determined) provides association, IEEE 802.1X Authenticator (802.1X control port management to be determined) and robust secure network association (RSNA) key management for all non-AP MLDs within the SMD.

[0137] SMD-ME can be a system management entity (SME).

[0138] (2) When switching AP MLDs within SMD, non-AP MLDs maintain association and secure association with SMD-ME.

[0139] (3) Non-AP MLD uses an improved FT process to switch from one SMD to another in the MD (mobile domain).

[0140] Motion 280: EE 802.11bn defines an SMD that includes a MAC-SAP (unified connection DS) for the entire SMD or a separate MAC-SAP for each AP MLD (each AP MLD is directly connected to the DS).

[0141] (1) When each AP MLD is directly connected to the DS, the DS mapping will be updated when a non-AP MLD roams to another AP MLD within the SMD.

[0142] (2) In the case where each AP MLD is directly connected to the DS, the 802.1X Authenticator component in the SMD-ME interacts with the 802.1X Authenticator component in the AP MLD, and the 802.1X Authenticator component in the AP MLD manages the 802.1X controlled ports of the non-AP MLD.

[0143] (3) When there is only one MAC-SAP in SMD, the 802.1X Authenticator in SMD-ME manages the 802.1X controlled port of non-AP MLD.

[0144] Motion 284:

[0145] As part of the seamless roaming process, a non-AP MLD in state 4 can roam through a target AP MLD belonging to the Seamless Mobility Domain (SMD), with conditions and details to be determined.

[0146] Motion 285:

[0147] To ensure the security of seamless roaming, when a non-AP MLD is roaming from the current AP MLD to a target AP MLD within the same SMD, a pairwise master key security association (PMKSA) established with the SMD Management Entity (SMD-ME) should be used to protect communication with both the current AP MLD and the target AP MLD.

[0148] Motion 286:

[0149] To ensure the security of seamless roaming, when a non-AP MLD is roaming from the current AP MLD to a target AP MLD within the same SMD, a pairwise transient key security association (PTKSA) established with the SMD Management Entity (SMD-ME) should be used to protect communication with both the current AP MLD and the target AP MLD.

[0150] Motion 282:

[0151] When a non-AP MLD roams from the current AP MLD to the target AP MLD, the non-AP MLD can request the context from the current AP MLD that needs to be transferred from the current AP MLD to the target AP MLD.

[0152] The detailed context that can be requested is yet to be determined.

[0153] The above applies to both the current AP MLD and the target AP MLD that support context transfer.

[0154] Motion 283: As part of the seamless roaming process, a non-AP MLD can initiate a roaming preparation process with a target AP MLD by sending a request frame to its current AP MLD. Details of the roaming preparation request frame are to be determined.

[0155] (1) The request frame indicates the set of links to be established with the target AP MLD.

[0156] (2) The current AP MLD sends a response frame to the non-AP MLD to indicate the link establishment status (accept / reject). If the link setup is accepted, the transferable context will be transferred to the target AP MLD. Detailed roaming preparation response frames are yet to be determined.

[0157] Whether / how to perform context renegotiation in these request / response frames remains to be determined.

[0158] The selection of the multi-candidate target AP MLD is yet to be determined.

[0159] Based on the above motion, the following questions remain: 1. How to determine which contexts need to be transferred and which contexts need to be renegotiated? 2. Who should make the decision?

[0160] To address the aforementioned technical problems, this disclosure provides a communication method in which a first device can send first information to a second device, the first information indicating the transfer priority of at least one context. The second device can decide, based on its own resource situation, at least one of the following: which uplink transmission contexts need to be transferred, which contexts need to be renegotiated, and which contexts need to be torn down, etc. The first device is a non-AP STA or a non-AP MLD, and the second device is the first device's current AP MLD or target AP MLD during roaming.

[0161] Table 3 shows the full Chinese and English names corresponding to the English abbreviations in the various figures of the embodiments of this disclosure:

[0162] Table 3

[0163] The technical solutions disclosed herein will now be described in detail through embodiments. It should be noted that the following embodiments may exist independently or in combination with each other; identical or identical content will not be repeated in different embodiments.

[0164] Figure 12 is a flowchart illustrating a communication method according to some embodiments. As shown in Figure 12, the method includes: S1201.

[0165] S1201, the first device sends first information to the second device, the first information indicating the transfer priority of at least one context.

[0166] In other words, the second device receives the first information sent by the first device.

[0167] In this embodiment of the disclosure, the first device can be a non-AP STA, a non-AP MLD, or an FTO.

[0168] In this embodiment of the disclosure, the second device can be the current AP MLD or the target AP MLD of the first device during roaming. Alternatively, the second device can be the current AP STA or the target AP STA of the first device during roaming.

[0169] In one implementation, if the second device is the current AP MLD, the current AP MLD can send the first information to the target AP MLD; that is, the first device sends the first information to the target AP MLD through the current AP MLD. Alternatively, if the second device is the current AP STA, the current AP STA can send the first information to the target AP STA; that is, the first device sends the first information to the target AP STA through the current AP STA.

[0170] The following explanation will use the example of the second device being the current AP MLD or the target AP MLD.

[0171] If the second device is the current AP MLD, the first device sends the first information to the second device, and the second device sends the first information to the third device. The third device can decide on the transfer context based on its own resource situation, such as deciding on at least one of the following: which uplink transmissions need to be transferred, which contexts need to be renegotiated, and which contexts need to be torn down.

[0172] In one implementation of this approach, if the second device is the current AP MLD, the second device can provide the third device with the size of each context to be transferred. The third device can decide on the context to be transferred based on the first information, the size of these contexts, and its own resource situation.

[0173] In this embodiment of the disclosure, the third device can be the target AP MLD of the first device during roaming.

[0174] Before the first device sends the first information to the second device, the first device may set a transfer priority for the transfer context and determine the transfer priority of at least one context.

[0175] For example, the first device can determine the transfer priority of a context based on its importance. The context with the highest transfer priority can be indicated as the one that can be transferred first.

[0176] In one implementation, the first information includes at least one set of transfer priority information, each set of transfer priority information indicating the transfer priority of at least one context in the corresponding context category.

[0177] In other words, the first information may include at least one set of transfer priority information, each set of transfer priority information corresponding to a context category, that is, each set of transfer priority information indicates the transfer priority of at least one context in that context category.

[0178] For example, at least one set of transfer priority information can be as shown in Table 4.

[0179] Table 4

[0180] In Table 4, taking Group 1 as an example, the context category corresponding to Group 1 is category a, which includes information a1, information a2, ...

[0181] It should be noted that since different context categories use different resources, there is no resource contention, so there is no need to set transfer priorities for contexts in different context categories. However, since contexts within a single context category use the same resources, resource contention exists. Therefore, setting transfer priorities for contexts within each context category is necessary for the second device to make a decision.

[0182] Taking Table 4 as an example, the context transfer priority in category a is independent of the context transfer priority in category b. When performing context transfer, the context transfer priority in category a has no effect on the context transfer in category b, and similarly, the context transfer priority in category b has no effect on the context transfer in category a.

[0183] In one implementation, the context category includes at least one of the following: BA-related context, SCS-related context, and TWT-related context.

[0184] For example, the BA-related context includes at least one of the following: block acknowledgment parameters, block acknowledgment timeout value, scoreboard status parameters, receive reordering buffer control status parameters, send buffer control status parameters, etc.

[0185] For example, block confirmation parameters may include parameters such as TID and cache size.

[0186] The block acknowledgment timeout value indicates a period of time. For example, for some TID-identified services, if the timer starts after transmitting data A, and there is no data transmission within the time indicated by the block acknowledgment timeout value, the block acknowledgment protocol is invalidated.

[0187] The scoreboard status parameters may include at least one of the following: scoreboard window start value, scoreboard window size (i.e., scoreboard window length), and scoreboard window bitmap.

[0188] The receive reordering buffer control state parameters may include at least one of the following: the start position of the receive window, the size of the receive window (i.e., the length of the receive window), and the bitmap within the receive window.

[0189] The transmit buffer control status parameters can include the start position of the transmit window and the transmit window size (i.e., the transmit window length).

[0190] For example, the SCS-related context may include the SCS ID, traffic specification (TSPEC) parameters, etc.

[0191] The SCS ID can be used to indicate the parameters of the requested flow classification service. For example, when the SCS ID is 7, it means that the first device requests the second device to transfer the parameters of the flow classification service corresponding to SCS ID 7 to the third device.

[0192] TSPEC parameters may include, for example, the maximum service interval (MSI) and the minimum service interval (MinSI).

[0193] For example, the TWT-related context may include the iTWT-related context and / or the R-TWT-related context. iTWT (individual TWT) refers to the individual TWT, and R-TWT is the restricted target wake time.

[0194] The following explains how the context transfer priority is represented in each context category.

[0195] In one implementation, the BA-related context can be identified by a TID. For example, the transfer priority information of the BA-related context may include a first TID list, which includes at least one TID, where the transfer priority of a preceding TID is higher than that of a following TID. The preceding TID may refer to the first element in the first TID list. For instance, the first TID list is represented as [TID1, TID2, TID3, TID4, TID5], where the transfer priority of TID1 is higher than that of TID2, TID3, TID4, and TID5, and vice versa.

[0196] In one implementation, the SCS-related context can be identified by an SCS ID. For example, the transfer priority information of the SCS-related context may include a first SCS ID list, which includes at least one SCS ID, where the transfer priority of an earlier SCS ID is higher than that of a later SCS ID and its corresponding transfer priority. The earlier SCS ID may refer to the first element in the first SCS ID list. For example, the first SCS ID list may be represented as [SCS ID1, SCS ID2, SCS ID3, SCS ID4, SCS ID5], where the transfer priority of SCS ID1 is higher than that of SCS ID2, SCS ID3, SCS ID4, and SCS ID5, and the transfer priority of SCS ID2 is higher than that of SCS ID3, SCS ID4, and SCS ID5, and so on.

[0197] In one implementation, the corresponding iTWT context can be identified by a TWT ID. For example, the transfer priority information of the iTWT context may include a first TWT ID list, which includes at least one TWT ID. The TWT ID listed earlier in the list has a higher transfer priority than the TWT IDs listed later and their corresponding transfer priorities. The earlier TWT ID may refer to the first element in the first TWT ID list. Detailed examples can be found in the TID or SCS ID examples above, and will not be repeated here.

[0198] In one implementation, the corresponding R-TWT context can be identified by a TWT ID.

[0199] For example, the transfer priority information of the R-TWT related context may include a second TWT ID list, which includes at least one TWT ID, with the transfer priority of the preceding TWT ID being higher than that of the following TWT ID and its corresponding transfer priority. The preceding TWT ID may refer to the first element in the second TWT ID list.

[0200] The transmission format of the first information, namely the frame it is carried, will be explained below.

[0201] In one implementation, the first information may be carried in a first authentication frame, an FT request frame, a link reconfiguration request frame, or a link setup request frame.

[0202] It should be noted that for link reconstruction request frames or link establishment request frames, if the second device and the third device belong to the same seamless roaming domain (SMD), the first information can be carried in the link reconstruction request frame. If the second device and the third device do not belong to the same SMD, the first information can be carried in the link establishment request frame.

[0203] The first authentication frame can be an authentication request frame, where the first information is carried within the first authentication frame. The first device can send the first authentication frame to the second device, in which case the second device is the target AP MLD, as shown in Figure 18.

[0204] When the first information is carried in an FT request frame, the first device can send an FT request frame to the second device, and the second device can send an FT request frame to the third device. That is, the first device forwards the FT request frame to the third device through the second device. In this way, the second device is the current AP MLD, as shown in Figure 19.

[0205] For example, as shown in Figure 13, an FT request frame may include an RSN field, a (mobility domain, MD) field, an FT field, an RSN extension field, a basic multilink element field, and a context transfer priority field.

[0206] The structure of the context transfer priority field is shown in Figure 14, including the element ID field, length field, element ID extension field, control field, BA context TID list field, SCS ID list field, iTWT process list field, and R-TWT ID list field.

[0207] The control field has multiple subfields that indicate whether the TID list field of the BA context exists, the length of the SCS ID list field, the length of the iTWT process list field, and the length of the R-TWT ID list field.

[0208] The TID list field of the BA context may include a first TID list, which includes at least one TID. For example, the TID list field of the BA context consists of 3 bytes (one byte contains 8 bits), with each 3 bits representing a TID. TIDs appearing before each other in the TID list field have higher transfer priority than TIDs appearing after them. The context of the first TID (which can be understood as the first element in the first TID list) has the highest transfer priority, and the context of the last TID (which can be understood as the last element in the first TID list) has the lowest transfer priority.

[0209] The SCS ID list field may include a first SCS ID list, which includes at least one SCS ID. The SCS IDs listed before the SCS ID list field have higher transfer priority than the SCS IDs listed after the SCS ID list field. The context of the first SCS ID in the SCS ID list field (which can be understood as the first element in the first SCS ID list) has the highest transfer priority, and the context of the last SCS ID (which can be understood as the last element in the first SCS ID list) has the lowest transfer priority.

[0210] The iTWT process list field may include a first TWT ID list, which contains at least one TWT ID. TWT IDs appearing before each other in the iTWT process list field have higher transfer priority than TWT IDs appearing after them. The context of the first TWT ID in the iTWT ID list field (which can be understood as the first element in the first TWT ID list) has the highest transfer priority, and the context of the last TWT ID (which can be understood as the last element in the first TWT ID list) has the lowest transfer priority.

[0211] The R-TWT ID list field can be a second TWT ID list, which includes at least one TWT ID. TWT IDs appearing before each other in the R-TWT ID list field have higher transfer priority than TWT IDs appearing after them and their corresponding transfer priorities. The context of the first TWT ID in the R-TWT ID list field (which can be understood as the first element in the second TWT ID list) has the highest transfer priority, and the context of the last TWT ID (which can be understood as the last element in the second TWT ID list) has the lowest transfer priority.

[0212] When the first information is carried in a link reconstruction request frame, the first device can send the link reconstruction request frame to the second device. In this mode, the second device is the target AP MLD. Alternatively, the first device can send the link reconstruction request frame to the second device, and the second device can then send the link reconstruction request frame to the third device. That is, the first device forwards the link reconstruction request frame to the third device through the second device. In this mode, the second device is the current AP MLD.

[0213] When the first information is carried in a link establishment request frame, the first device can send a link establishment request frame to the second device, and the second device can send a link establishment request frame to the third device. In other words, the first device forwards the link establishment request frame to the third device through the second device. In this method, the second device is the current AP MLD.

[0214] In the embodiment shown in Figure 12, the first device sends first information to the second device to indicate the transfer priority of at least one context. The second device can transfer the context based on the transfer priority of at least one context.

[0215] The following section explains which contexts need to be transferred and / or which contexts need to be renegotiated.

[0216] Figure 15 is a flowchart illustrating another communication method according to some embodiments. As shown in Figure 15, the method includes: S1501.

[0217] S1501, the second device sends second information to the first device, the second information indicating the context that needs to be transferred and / or the context that needs to be renegotiated.

[0218] In other words, the first device receives the second information sent by the second device.

[0219] In one implementation, the context to be transferred can include any of the following context categories: BA-related context, SCS-related context, or TWT-related context, etc.

[0220] In one implementation, the context that needs to be renegotiated may include any of the following context categories: BA-related context, SCS-related context, or TWT-related context, etc.

[0221] TWT-related contexts may include iTWT-related contexts and / or R-TWT-related contexts.

[0222] It is understandable that the context that needs to be transferred refers to the context that needs to be transferred from the current AP MLD to the target AP MLD, and the context that needs to be renegotiated refers to the context in which the target AP MLD needs to renegotiate with the first device.

[0223] In one implementation, the second information indicating the BA-related context to be transferred can take the form of, for example, indicating a second TID list, where each TID in the second TID list corresponds to a context.

[0224] In one implementation, the second information indicating the SCS-related context to be transferred can take the form of, for example, indicating a second list of SCS IDs, where each SCS ID in the second list corresponds to a context.

[0225] In one implementation, the second information indicating the iTWT-related context to be transferred can take the form of, for example, indicating a third list of TWT IDs, where each TWT ID in the third list corresponds to a context.

[0226] In one implementation, the second information indicating the R-TWT-related context to be transferred can take the form of, for example, indicating a fourth TWT ID list, where each TWT ID in the fourth TWT ID list corresponds to a context.

[0227] In one implementation, the second information is also used to indicate the context in which demolition is required.

[0228] It is understood that the context that needs to be removed is the context used in the communication between the first device and the current AP MLD, which is a context that is not needed in the communication between the first device and the target AP MLD. The indication of the context that needs to be removed is similar to that of the context that needs to be transferred, and the default is a context other than the context that needs to be transferred and the context that needs to be renegotiated.

[0229] In one implementation, the second information also includes recommendation parameters, which are parameters for establishing the context that needs to be renegotiated.

[0230] For example, the renegotiation context is the BA-related context, and recommended parameters may include the buffer size negotiated in the BA protocol, etc.

[0231] In one implementation, the second information can be carried in a second authentication frame, an FT response frame, a link reconstruction response frame, or a link establishment response frame.

[0232] It should be noted that for link reconstruction request frames or link establishment request frames, if the second device and the third device belong to the same SMD, the second information can be carried in the link reconstruction response frame. If the second device and the third device do not belong to the same SMD, the second information can be carried in the link establishment response frame.

[0233] The second authentication frame can be an authentication response frame. Second information is carried within the second authentication frame. The second device can send the second authentication frame to the first device. In this mode, the second device is the target AP MLD, as shown in Figure 18.

[0234] When the second information is carried in the FT response frame, the third device sends the FT response frame to the second device, and the second device can send the FT response frame to the first device. That is, the third device forwards the FT response frame to the first device through the second device. In this way, the second device is the current AP MLD, for example, refer to Figure 19.

[0235] For example, as shown in Figure 16, an FT response frame may include an RSN field, an MD field, an FT field, a basic multilink element field, a context field that needs to be transferred, and / or a context field that needs to be renegotiated.

[0236] The structure of the context fields that need to be transferred and / or renegotiated is shown in Figure 17, including the element ID field, length field, element ID extension field, control field, BA parameter field, SCS parameter field, iTWT parameter field, and R-TWT parameter field.

[0237] The control field has multiple subfields that indicate the length of the BA parameter field, the SCS parameter field, the iTWT parameter field, and the R-TWT ID parameter of the BA context, respectively.

[0238] The BA parameter field may include a second TID list, where each TID in the second TID list corresponds to a context, where the context refers to the context in the BA-related context.

[0239] In one implementation, if the context that needs to be renegotiated includes BA-related contexts, the BA parameter field can indicate the recommended parameters corresponding to the BA-related contexts.

[0240] The SCS parameter field may include a second SCS list, where each SCS ID in the second SCS list corresponds to a context, where the context refers to the context in the SCS-related context.

[0241] In one implementation, if the context that needs to be renegotiated includes the SCS-related context, the BA parameter field can indicate the recommended parameters corresponding to the SCS-related context.

[0242] The iTWT parameter field may include a third list of TWT IDs, where each TWT ID in the third list corresponds to a context, and the context here refers to the context in the iTWT-related context.

[0243] In one implementation, if the context that needs to be renegotiated includes the iTWT-related context, the BA parameter field can indicate the recommended parameters corresponding to the iTWT-related context.

[0244] The R-TWT parameter field may include a fourth TWT ID list, where each TWT ID in the fourth TWT ID list corresponds to a context, where the context refers to the context in the R-TWT related context.

[0245] In one implementation, if the context requiring renegotiation includes R-TWT-related contexts, the BA parameter field can indicate the recommended parameters corresponding to the R-TWT-related contexts.

[0246] When the second information is carried in a link reconstruction response frame, the second device can send a link reconstruction response frame to the first device. In this mode, the second device is the target AP MLD. Alternatively, the third device can send a link reconstruction response frame to the second device, and the second device can then send a link reconstruction response frame to the first device. That is, the third device sends a link reconstruction response frame to the first device through the second device. In this mode, the second device is the current AP MLD.

[0247] When the first information is carried in the link establishment response frame, the third device can send a link establishment response frame to the second device, and the second device can send a link establishment response frame to the first device. In other words, the third device forwards the link establishment response frame to the first device through the second device. In this method, the second device is the current AP MLD.

[0248] In the embodiment shown in Figure 15, the second device sends second information to the first device to indicate the contexts that need to be transferred and / or the contexts that need to be renegotiated. The first device can know which contexts need to be transferred, and / or which contexts need to be renegotiated.

[0249] For ease of understanding, detailed examples are given below to illustrate that the first information is carried in the first authentication frame and the second information is carried in the second authentication frame, or the first information is carried in the FT request frame and the second information is carried in the FT response frame.

[0250] Example 1

[0251] As shown in Figure 18, before reassociation, the FTO can send a first authentication frame to the target AP MLD, which indicates first information. The target AP MLD then sends a second authentication frame to the FTO, which indicates second information.

[0252] Example 2

[0253] As shown in Figure 19, before reassociation, the FTO can send an FT request frame to the target AP MLD through the current AP MLD. The FT request frame indicates the first information. The target AP MLD sends an FT response frame to the FTO through the current AP MLD. The FT response frame indicates the second information.

[0254] If the second information indicates a context that needs to be renegotiated, or if the first device can determine which contexts need to be renegotiated, the first device can request to establish a connection with the target AP MLD in the following manner.

[0255] Figure 20 is a flowchart illustrating another communication method according to some embodiments. As shown in Figure 20, the method includes: S2001.

[0256] S2001, The first device sends third information to the second device, the third information being used to request the establishment of a context that needs to be renegotiated.

[0257] In other words, the second device receives the third information sent by the first device.

[0258] The first device requests the establishment of a context that needs to be renegotiated, which may be a context that needs to be renegotiated as indicated in the second information provided by the second device.

[0259] In other words, the third information can indicate the contexts that need to be renegotiated and request the establishment of these contexts. For example, the third information can indicate the ID of the context to be renegotiated. For instance, if the context to be renegotiated is an SCS-related context, then the ID can be an SCS ID, which can be indicated in the form of a list of SCS IDs; if the context to be renegotiated is a TWT-related context, then the ID can be a TWT ID, which can be indicated in the form of a list of TWT IDs; if the context to be renegotiated is a BA-related context, then the ID can be a TID, which can be indicated in the form of a list of TIDs.

[0260] In one implementation, the third information can be carried in the RIC request field.

[0261] Taking the second device as the current AP MLD as an example, the first device sends the third information to the second device, and the second device sends the third information to the third device. That is, the first device sends the third information to the third device through the second device, and the second device can establish a context that needs to be renegotiated with the first device.

[0262] Taking the second device as the target AP MLD as an example, the first device sends third information to the second device, and the second device can establish a context that needs to be renegotiated with the first device.

[0263] In the embodiment shown in Figure 18, the first device sends a third message to the second device to request the establishment of a context that needs to be renegotiated. The target AP MLD can then establish the renegotiated context with the first device.

[0264] The following uses the second device as the current AP MLD as an example to illustrate the interaction between the second device and the third device through Figures 21 and 22.

[0265] Figure 21 is a flowchart illustrating another communication method according to some embodiments. As shown in Figure 21, the method includes: S2101.

[0266] S2101, the second device sends a fourth message to the third device, the fourth message being used to indicate parameters of the context to which the transfer is requested.

[0267] In other words, the third device receives the fourth message sent by the second device.

[0268] In one implementation, the fourth piece of information also indicates the size of the context for which the request is transferred.

[0269] In one implementation, where the fourth information only indicates parameters of the context to be transferred, the third device can determine the size of the context based on the parameters of the context to be transferred. This size could, for example, refer to the number of bits the context occupies during transmission. The third device can then decide which context to transfer based on the first information, the sizes of these contexts, and its own resource availability.

[0270] In one implementation, the context to be transferred may include any of the following context categories: BA-related context, SCS-related context, or TWT-related context, etc.

[0271] For example, the parameters of the context in the BA-related context may include the window length of the receiving sliding window, the starting position of the receiving sliding window, the window length of the sending sliding window, the starting position of the sending sliding window, the amount of data forwarded, etc. The amount of data includes, for example, the amount of data in the receiving sliding window that has not yet been submitted and the amount of data in the sending sliding window that has not yet been successfully sent.

[0272] In the embodiment shown in Figure 21, the second device sends fourth information to the third device to indicate parameters of the context to which the transfer is requested. The third device can decide on the transfer context based on the first information, the parameters of these contexts, and its own resource situation.

[0273] In one implementation, for S2101, transmission can be made between the step FT request and the step FT response as shown in FIG19.

[0274] Figure 22 is a flowchart illustrating another communication method according to some embodiments. As shown in Figure 22, the method includes: S2201-S2201.

[0275] S2201, The third device sends a fifth message to the second device. The fifth message is used to request parameters of the context to be transferred.

[0276] In other words, the second device receives the fifth message sent by the third device.

[0277] S2202, the second device sends a fourth message to the third device, the third message being used to indicate parameters of the context to which the transfer is requested.

[0278] In other words, the third device receives the fourth message sent by the second device.

[0279] The relevant description of the fourth information can be found in the above embodiments, and will not be repeated here.

[0280] In the embodiment shown in Figure 22, the third device sends a fifth message to the second device to request parameters of the context to be transferred. The second device sends a fourth message to the third device to indicate the parameters of the context to be transferred. The third device can then decide on the context to be transferred based on these parameters.

[0281] In one implementation, steps S2201 and S2202 can be transmitted between the step authentication request and the step authentication response as shown in Figure 18.

[0282] In one implementation, for S2201 and S2202, transmission can be made between step FT request and step FT response as shown in FIG19.

[0283] Figure 23 is a schematic diagram of a communication device according to some embodiments. The communication device 230 is applied to a first device, which is a non-AP STA or a non-AP MLD. Referring to Figure 23, the communication device 230 includes:

[0284] The sending module 2301 is used to send first information, which indicates the transfer priority of at least one context.

[0285] In one implementation, the first information includes at least one set of transfer priority information, each set of transfer priority information indicating the transfer priority of at least one context in the corresponding context category.

[0286] In one implementation, the context categories include Block Confirmation (BA) related context, Stream Classification Service (SCS) related context, or Target Wake-up Time (TWT) related context.

[0287] In one implementation, the first information is carried in the first authentication frame, the Fast Basic Service Set Transfer (FT) request frame, the link reconstruction request frame, or the link establishment request frame.

[0288] In one implementation, the communication device 230 further includes a receiving module 2302, which is used for:

[0289] Receive a second message indicating the context that needs to be transferred and / or the context that needs to be renegotiated.

[0290] In one implementation, the second information also includes recommendation parameters, which are parameters for establishing the context that needs to be renegotiated.

[0291] In one implementation, the second information is also used to indicate the context in which demolition is required.

[0292] In one implementation, the context that needs to be demolished is, by default, any context other than the context that needs to be transferred or the context that needs to be renegotiated.

[0293] In one implementation, the second information is carried in the second authentication frame, the FT response frame, the link reconstruction response frame, or the link establishment response frame.

[0294] In one implementation, the sending module 2301 is further configured to:

[0295] Send a third message, which is used to request the establishment of a context that needs to be renegotiated.

[0296] In one implementation, the third information is carried in the RIC request field.

[0297] The communication device 230 can execute the steps performed by the first device in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0298] Figure 24 is a schematic diagram of a communication device according to some embodiments. The communication device 240 is applied to a second device, which is either a target AP MLD or a current AP MLD of the first device during roaming. Referring to Figure 24, the communication device 240 includes:

[0299] The receiving module 2401 receives first information, which indicates the transfer priority of at least one context.

[0300] In one implementation, the first information includes at least one set of transfer priority information, each set of transfer priority information indicating the transfer priority of at least one context in the corresponding context category.

[0301] In one implementation, the context categories include Block Confirmation (BA) related context, Stream Classification Service (SCS) related context, or Target Wake-up Time (TWT) related context.

[0302] In one implementation, the first information is carried in the first authentication frame, the Fast Basic Service Set Transfer (FT) request frame, the link reconstruction request frame, or the link establishment request frame.

[0303] In one implementation, the device 240 further includes a transmitting module 2402, which is used for:

[0304] Send a second message indicating the context that needs to be transferred and / or the context that needs to be renegotiated.

[0305] In one implementation, the second information also includes recommendation parameters, which are parameters for establishing the context that needs to be renegotiated.

[0306] In one implementation, the second information is also used to indicate the context in which demolition is required.

[0307] In one implementation, the context that needs to be demolished is, by default, any context other than the context that needs to be transferred or the context that needs to be renegotiated.

[0308] In one implementation, the second information is carried in the second authentication frame, the FT response frame, the link reconstruction response frame, or the link establishment response frame.

[0309] In one implementation, the receiving module 2401 is further configured to:

[0310] Receive third information, which is used to request the establishment of a context that needs to be renegotiated.

[0311] In one implementation, the third information is carried in the RIC request field.

[0312] The communication device 240 can execute the steps performed by the second device in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0313] Figure 25 is a schematic diagram of a communication device 70 according to some embodiments. Referring to Figure 25, the device 70 may include a transceiver 71, a memory 72, and a processor 73. The transceiver 71 may include a transmitter and / or a receiver. The transmitter may also be referred to as a transmitter, transmitter, transmitting port, or transmitting interface, etc., and the receiver may also be referred to as a receiver, receiver, receiving port, or receiving interface, etc. Exemplarily, the transceiver 71, memory 72, and processor 73 are interconnected via a bus 74.

[0314] Memory 72 is used to store program instructions;

[0315] The processor 73 is used to execute the program instructions stored in the memory, so that the communication device 70 performs the steps performed by the first device or the second device in the above method embodiment.

[0316] The transceiver 71 is used to perform the transmission and reception functions of the communication device 70 in the above communication method.

[0317] The communication device 70 can be a chip, module, integrated development environment (IDE), etc.

[0318] The communication device 70 can execute the steps executed by the first device or the second device in the above method embodiments. The implementation principle and beneficial effects are similar, and will not be described again here.

[0319] This disclosure provides a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) storing computer-executable instructions that, when executed on a computer, cause any of the aforementioned communication methods to be executed.

[0320] This disclosure also provides a computer program product that can be executed by a processor, such that when the computer program product is executed by a computer, the communication methods described above are performed.

[0321] This disclosure provides a chip, which includes at least one processor and an interface circuit. The interface circuit and the at least one processor are connected, and the processor executes the technical solution shown in the above method embodiment by running program instructions.

[0322] In one implementation, the chip can also be a chip module.

[0323] The chips in some embodiments of this disclosure can be used to execute the technical solutions shown in the above method embodiments. The detailed implementation methods and technical effects are similar, and will not be repeated here.

[0324] This disclosure provides a module device, which includes a power module, a storage module, and a chip module.

[0325] The power module is used to provide electrical energy to the module device.

[0326] Storage modules are used to store data and instructions.

[0327] The chip modules of some embodiments of this disclosure can be used to execute the technical solutions shown in the above method embodiments. The detailed implementation methods and technical effects are similar, and will not be repeated here.

[0328] All or part of the steps in the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above-described method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), random access memory (RAM), flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0329] This disclosure describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this disclosure with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0330] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0331] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0332] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. Therefore, if these modifications and variations to the embodiments of this disclosure fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include these modifications and variations.

Claims

1. A communication method, comprising: Send a first message, which indicates the transfer priority of at least one context.

2. The method according to claim 1, wherein, The first information includes at least one set of transfer priority information, each set of transfer priority information indicating the transfer priority of at least one context in the corresponding context category.

3. The method according to claim 2, wherein, The context categories include Block Confirmation (BA) related context, Stream Classification Service (SCS) related context, or Target Wake-up Time (TWT) related context.

4. The method according to any one of claims 1-3, wherein, The first information is carried in the first authentication frame, the Fast Basic Service Set Transfer (FT) request frame, the link reconstruction request frame, or the link establishment request frame.

5. The method according to any one of claims 1-4, further comprising: Receive second information, which indicates the context that needs to be transferred and / or the context that needs to be renegotiated.

6. The method according to claim 5, wherein, The second information also includes recommended parameters, which are parameters for establishing the context that needs to be renegotiated.

7. The method according to claim 5 or 6, wherein, The second information is also used to indicate the context in which demolition is required.

8. The method according to claim 7, wherein, The context that needs to be removed is, by default, any context other than the context that needs to be transferred and the context that needs to be renegotiated.

9. The method according to any one of claims 5-8, wherein, The second information is carried in the second authentication frame, FT response frame, link reconstruction response frame, or link establishment response frame.

10. The method according to any one of claims 1-9, further comprising: Send a third message, which is used to request the establishment of a context that needs to be renegotiated.

11. The method according to claim 10, wherein, The third piece of information is carried in the Resource Information Container (RIC) request field.

12. A communication method, comprising: Receive first information, which indicates the transfer priority of at least one context.

13. The method according to claim 12, wherein, The first information includes at least one set of transfer priority information, each set of transfer priority information indicating the transfer priority of at least one context in the corresponding context category.

14. The method according to claim 13, wherein, The context categories include Block Confirmation (BA) related context, Stream Classification Service (SCS) related context, or Target Wake-up Time (TWT) related context.

15. The method according to any one of claims 12-14, wherein, The first information is carried in the first authentication frame, the Fast Basic Service Set Transfer (FT) request frame, the link reconstruction request frame, or the link establishment request frame.

16. The method according to any one of claims 12-15, further comprising: Send a second message indicating the context that needs to be transferred and / or the context that needs to be renegotiated.

17. The method according to claim 16, wherein, The second information also includes recommended parameters, which are parameters required to establish the context that needs to be renegotiated.

18. The method according to claim 16 or 17, wherein, The second information is also used to indicate the context in which demolition is required.

19. The method according to claim 18, wherein, The context that needs to be removed is, by default, any context other than the context that needs to be transferred and the context that needs to be renegotiated.

20. The method according to any one of claims 16-19, wherein, The second information is carried in the second authentication frame, FT response frame, link reconstruction response frame, or link establishment response frame.

21. The method according to any one of claims 12-20, further comprising: Receive third information, which is used to request the establishment of a context that needs to be renegotiated.

22. The method according to claim 21, wherein, The third piece of information is carried in the Resource Information Container (RIC) request field.

23. A communication device, comprising: A sending module is configured to send first information, the first information indicating the transfer priority of at least one context.

24. A communication device, comprising: A receiving module is configured to receive first information, the first information indicating the transfer priority of at least one context.

25. A communication device, comprising: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method according to any one of claims 1-11, or the method according to any one of claims 12-22.

26. A computer-readable storage medium, wherein, The computer-readable storage medium stores computer-executable instructions that, when executed by a processor, implement the method according to any one of claims 1-11, or the method according to any one of claims 12-22.

27. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-11, or the method according to any one of claims 12-22.

28. A chip comprising at least one processor, the at least one processor being configured to execute program instructions to perform the method according to any one of claims 1-11, or the method according to any one of claims 12-22.

Images