Wireless communication method and communication device

Abstract

The invention provides a wireless communication method and communication equipment. The method comprises: a first STA sending a first PPDU to a second STA, the first PPDU comprising first information and second information; wherein the first information is used for preempting the TXOP of the second STA and / or indicating that the first STA contains low-delay data to be transmitted; the second information is used for determining the legality of the first STA.

Description

Wireless communication method and communication device Technical Field

[0001] The present application relates to the field of communication technology, and more specifically, to a wireless communication method and a communication device. Background Art

[0002] In related art, if a station (STA) has low-latency data to be transmitted, the STA may send a preemption request (PR) to an access point (AP) to obtain a transmission opportunity (TXOP).

[0003] Summary of the Invention

[0004] The present application provides a wireless communication method and a communication device. The following introduces various aspects involved in the present application.

[0005] In a first aspect, a wireless communication method is provided, including: a first STA sends a first physical protocol data unit (PPDU) to a second STA, where the first PPDU includes first information and second information; wherein the first information is used to preempt the TXOP of the second STA and / or indicate that the first STA contains low-latency data to be transmitted; and the second information is used to determine the legitimacy of the first STA.

[0006] In a second aspect, a wireless communication method is provided, including: a second STA receives a first PPDU sent by a first STA, the first PPDU including first information and second information; wherein, the first information is used to preempt the TXOP of the second STA and / or indicate that the first STA contains low-latency data to be transmitted; the second information is used to determine the legitimacy of the first STA.

[0007] According to a third aspect, a communication device is provided, which is a first STA, and the communication device includes: a first communication module, used to send a first PPDU to a second STA, and the first PPDU includes first information and second information; wherein, the first information is used to preempt the TXOP of the second STA and / or indicate that the first STA contains low-latency data to be transmitted; the second information is used to determine the legitimacy of the first STA.

[0008] In a fourth aspect, a communication device is provided, which is a second STA, and the communication device includes: a first communication module, used to receive a first PPDU sent by a first STA, the first PPDU including first information and second information; wherein, the first information is used to preempt the TXOP of the second STA and / or indicate that the first STA contains low-latency data to be transmitted; the second information is used to determine the legitimacy of the first STA.

[0009] In a fifth aspect, a communication device is provided, comprising a processor and a memory, wherein the memory is used to store one or more computer programs, and the processor is used to call the computer program in the memory so that the communication device executes part or all of the steps in the method of the first aspect and / or the second aspect.

[0010] In a sixth aspect, an embodiment of the present application provides a communication system, which includes the above-mentioned communication device. In another possible design, the system may also include other devices that interact with the communication device in the solution provided in the embodiment of the present application.

[0011] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program, and the computer program enables a communication device to execute part or all of the steps in the methods of the above aspects.

[0012] In an eighth aspect, embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a communication device to perform some or all of the steps of the methods described in each of the above aspects. In some implementations, the computer program product may be a software installation package.

[0013] In a ninth aspect, an embodiment of the present application provides a chip comprising a memory and a processor, wherein the processor can call and run a computer program from the memory to implement some or all of the steps described in the methods of the above aspects.

[0014] In this embodiment of the present application, the first PPDU carries first information, which is used to preempt the TXOP of the second STA and / or indicate that the first STA contains low-latency data to be transmitted. Furthermore, this embodiment of the present application requires that the PPDU carrying the first information also carry second information, which is used to determine the legitimacy of the STA sending the first information. Requiring the PPDU to carry both the first and second information ensures the security of the communication system. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG1 is a schematic diagram of a wireless communication system to which an embodiment of the present application may be applied.

[0016] FIG2 is a schematic diagram illustrating the location of a message integrity code (MIC) in a data frame.

[0017] FIG3 is a schematic diagram of an encryption process of a medium access control (MAC) protocol data unit (MPDU).

[0018] FIG4 is a schematic diagram showing a construction method of additional authentication data (AAD).

[0019] FIG5 is a schematic diagram showing the format of the random number field.

[0020] FIG6 is a schematic diagram of the MPDU decryption process.

[0021] FIG7 is a schematic diagram of the format of the broadcast / multicast integrity protocol (BIP).

[0022] FIG8 is a schematic diagram of the format of the management MIC element (MME) in FIG7 .

[0023] FIG9 is a schematic diagram showing the construction method of the AAD of the BIP.

[0024] FIG10 is a schematic diagram showing the format of a null data PPDU (NDP) feedback report (NFRP) poll.

[0025] FIG11 is a schematic diagram showing the format of an NDP feedback report parameter set element.

[0026] FIG12 is a schematic diagram of the format of NDP.

[0027] FIG13 is an example diagram of the transmission process of the preemption request.

[0028] FIG. 14 is another exemplary diagram of the transmission process of the preemption request.

[0029] FIG15 is an example diagram of the transmission process of the low-latency indication.

[0030] FIG16 is a flow chart of a wireless communication method provided in accordance with an embodiment of the present application.

[0031] FIG17 is a schematic diagram of the format of a clear-to-send (CTS) frame.

[0032] FIG18 is a schematic diagram of the format of a control frame provided in an embodiment of the present application.

[0033] Figure 19 is a schematic diagram of the format of a CTS frame provided in an embodiment of the present application.

[0034] FIG20 is a flow chart of a wireless communication method provided in another embodiment of the present application.

[0035] FIG21 is a schematic diagram of the packet number (PN) interaction method provided in one embodiment of the present application.

[0036] FIG22 is a schematic diagram of a PN interaction method provided in another embodiment of the present application.

[0037] FIG23 is an example diagram of a PN bearing location provided by an embodiment of the present application.

[0038] FIG24 is an example diagram of a PN carrying position provided in another embodiment of the present application.

[0039] FIG25 is an example diagram of a PN bearing location provided in another embodiment of the present application.

[0040] FIG26 is a schematic diagram showing the format of a multi user request-to-send (MU-RTS) trigger frame.

[0041] FIG27 is an example diagram of a PN bearing location provided in another embodiment of the present application.

[0042] FIG28 is a flow chart of a wireless communication method provided in another embodiment of the present application.

[0043] FIG29 is a schematic diagram of the interaction method of the serial number provided in one embodiment of the present application.

[0044] FIG30 is a schematic diagram of the interaction method of the serial number provided in another embodiment of the present application.

[0045] Figure 31 is an example diagram of the serial number carrying position provided by an embodiment of the present application.

[0046] Figure 32 is an example diagram of the serial number carrying position provided by another embodiment of the present application.

[0047] Figure 33 is an example diagram of the serial number carrying position provided by another embodiment of the present application.

[0048] Figure 34 is a structural diagram of a communication device provided by an embodiment of the present application.

[0049] Figure 35 is a structural diagram of a communication device provided in another embodiment of the present application.

[0050] FIG36 is a schematic structural diagram of a device to which an embodiment of the present application can be applied. DETAILED DESCRIPTION

[0051] The technical solution in this application will be described below with reference to the accompanying drawings.

[0052] Communication System

[0053] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as wireless local area networks (WLAN), wireless fidelity (WiFi) or other communication systems.

[0054] 1 is a wireless communication system 100 used in an embodiment of the present application. The wireless communication system 100 may include an access point 110 and a station (STA) 120 accessing a network through the access point (AP) 110.

[0055] In some scenarios, an AP is also called an AP STA. In a sense, an AP is also a STA.

[0056] In some scenarios, a STA is also called a non-AP STA.

[0057] The communication in the communication system 100 may be between an AP and a STA, between STAs, or between a STA and a peer STA. A peer STA may refer to a device that communicates with a STA, for example, an AP or a STA.

[0058] An AP acts as a bridge between wired and wireless networks, connecting wireless network clients together and then connecting the wireless network to the Ethernet. An AP can be a terminal device with a WiFi chip (such as a mobile phone) or a network device (such as a router).

[0059] It should be understood that the roles of various communication devices in the communication system 100 are not absolute. Taking a mobile phone as an example, when the mobile phone is connected to a router, the mobile phone is a STA; when the mobile phone serves as a hotspot for other mobile phones, the mobile phone plays the role of an AP.

[0060] APs and STAs can be devices used in the Internet of Vehicles, IoT nodes and sensors in the Internet of Things (IoT), smart cameras, smart remote controls, smart water and electricity meters in smart homes, and sensors in smart cities.

[0061] In some embodiments, both the STA and the AP may support the 802.11be standard. The STA or AP may also support various current and future 802.11 family WLAN standards, such as 802.11ax, 802.11ac, 802.11n, 802.11g, 802.11b, and 802.11a.

[0062] There are one or more links between the STA and the AP. In some embodiments, the STA and the AP support multi-band communication. For example, the STA and the AP can communicate simultaneously on the 2.4 GHz, 5 GHz, 6 GHz, 45 GHz, and 60 GHz frequency bands, or communicate simultaneously on different channels in the same frequency band (or different frequency bands) to improve the communication throughput and / or reliability between devices. Such a device is generally referred to as a multi-band device, or a multi-link device (MLD), sometimes also referred to as a multi-link entity or a multi-band entity. The multi-link device can be an access point device or a site device. If the multi-link device is an access point device, the multi-link device can include one or more APs; if the multi-link device is a site device, the multi-link device can include one or more non-AP STAs.

[0063] A multi-link device including one or more APs may be referred to as an access point multi-link device (AP MLD), and a multi-link device including one or more non-AP STAs may be referred to as a non-AP multi-link device (non-AP MLD).

[0064] In the embodiment of the present application, the AP may include multiple APs, and the non-AP STA may include multiple STAs. Multiple links may be formed between the multiple APs and the multiple STAs, and data communication may be performed between the multiple APs and the multiple STAs through the corresponding links.

[0065] In an embodiment of the present application, a STA may be a mobile phone, a tablet computer (Pad), a laptop computer, a PDA, a mobile internet device (MID), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. that supports WLAN / WiFi technology.

[0066] The frequency bands supported by WLAN technology may include but are not limited to: low frequency bands (such as 2.4 GHz, 5 GHz, and 6 GHz) and high frequency bands (such as 45 GHz and 60 GHz).

[0067] FIG1 exemplarily illustrates an AP and two STAs. Optionally, the communication system 100 may include multiple APs and any other number of STAs, which is not limited in this embodiment of the present application. In FIG1 , the AP, STA 120a, and STA 120b may be located in the same basic service set (BSS). The AP may be associated with STA 120a. The AP may be associated with STA 120b.

[0068] It should be understood that in the embodiments of the present application, a device with communication functionality in a network / system may be referred to as a communication device. Taking the communication system 100 shown in FIG1 as an example, the communication device may include an AP 110 and a STA 120 with communication functionality. In addition, the communication device mentioned in the embodiments of the present application may also include other devices in the communication system 100, such as a network controller, a gateway, and other network entities (not shown in FIG1 ), which is not limited in the embodiments of the present application.

[0069] APs and STAs can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; they can also be deployed in the air on aircraft, balloons, and satellites. The embodiments of this application do not limit the scenarios in which APs and STAs are located.

[0070] It should be understood that all or part of the functions of the communication device in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (such as a cloud platform).

[0071] Message integrity code (MIC) for unicast data frames and / or unicast management frames

[0072] As shown in Figure 2, according to the Draft P802.11REVme_D4.1 standard, the counter mode (CTR) cipher block chaining (CBC) message authentication code (MAC) protocol (CTR with CBC-MAC protocol, CCMP) inserts a CCMP header between the medium access control (MAC) protocol data unit (MPDU, or MAC frame) frame header and frame body, and includes an encrypted MIC in the encrypted frame body, thereby achieving encryption and integrity protection of the data frame.

[0073] CCMP-128 adds 16 bytes to the original MPDU, of which the CCMP header and MIC field each occupy 8 bytes. CCMP-256 adds 24 bytes to the original MPDU, of which the CCMP header occupies 8 bytes and the MIC field occupies 16 bytes. The CCMP header is constructed based on the PN, ExtIV, and Key ID subfields. The PN consists of 48 bits, represented by 6 bytes. PN5 is the most significant byte of the PN; PN0 is the least significant byte of the PN.

[0074] As shown in Figure 3, CCMP uses fields in the MPDU header to construct the AAD. The CCM algorithm provides integrity protection for the fields in the AAD. When calculating the AAD, fields in the MPDU header that may change during retransmission are removed.

[0075] Figure 4 shows the structure of the AAD of the protocol version 0 (PV0) MPDU. FC represents the frame control (FC) field of the MPDU with certain subfields masked with mask 0. A1 represents the address 1 field of the MPDU. A2 represents the address 2 field of the MPDU. A3 represents the address 3 field of the MPDU. SC represents the sequence control (SC) field of the MPDU after masking the sequence number subfield. A4 represents the MPDU address 4 field (if present). QC represents the quality of service (QoS) control field (if present) of the MPDU including the MAC service data unit (MSDU) priority.

[0076] As shown in Figure 5, the CCM nonce can be constructed based on the PN, A2 (MPDU Address 2), and the MPDU's priority. For details, see Section 12.5.2.3.4 of the standard "Draft P802.11REVme_D4.1." If the binary value (most significant bit first) of the Type field in the FC field is 10 (10 indicates a data frame) and the MPDU header contains a QoS Control field, the MPDU's priority is equal to the value of the Traffic Identifier (TID) subfield. If the binary value (most significant bit first) of the Type field in the FC field is 00 (00 indicates a management frame) and the frame is a QoS Management Frame (QMF), the MPDU's priority is equal to the value of the Access Category Index (ACI) subfield in the Sequence Number field. Otherwise, the MPDU's priority is fixed at 0.

[0077] As shown in Figure 3, ciphertext and an encrypted MIC are generated based on the temporary key, AAD, nonce, and MPDU data. The CCM encryption algorithm is described in IETF RFC 3610. The key, nonce, plaintext data, and AAD described above are provided to the CCM encryption algorithm as K, N, m, and a in the encryption algorithm. The CCM encryption algorithm generates a result c. Result c includes the encrypted message and the encrypted authentication value U. The encrypted message represents the encrypted frame body, and the authentication value U represents the MIC.

[0078] In short, CCM encryption concatenates a portion of the frame header (i.e., the fields that make up the AAD) with the frame body to generate the MIC. The frame body is then encrypted in blocks to generate the encrypted data. For details, see IETF RFC 3610, "Counter with CBC-MAC (CCM)." The encryption algorithm is briefly described below.

[0079] The input information to be verified is: B_0||a||padding||m||padding, where B_0 is the total length information including the random number (nouce) and the content to be verified, a represents AAD, m represents the message to be encrypted, and || represents string concatenation.

[0080] The input information to be verified is encrypted (based on the Advanced Encryption Standard (AES)): X_1 = E(K, B_0), Xi_i+1 = E(K, Xi_i XOR B_i); for i = 1, ..., n, XOR represents an exclusive OR operation.

[0081] Generate verification field T:=first-M-bytes(X_n+1).

[0082] Encrypt the self-incrementing counter to generate a cipher stream: S_i=E(K,A_i)for i=0,1,2,...

[0083] Generate encrypted message x: c=m XOR(S_1||S_2||…).

[0084] Generate verification value U: U=T XOR first-M-bytes(S_0).

[0085] Generate the final encrypted content c:x||U.

[0086] Figure 6 illustrates the CCM processing process at the receiver. The receiver verifies the integrity of the authentication value and the frame body and decrypts the frame body. MIC verification is performed by comparing the received MIC with the calculated MIC. Only if the MIC verification succeeds is the plaintext returned.

[0087] Similar to CCMP, the Galois / Counter Mode (GCM) protocol (GCMP) inserts a GCMP header between the MAC frame header and the frame body, and inserts a MIC between the encrypted frame body and the frame check sequence (FCS) to implement encryption and integrity protection for data frames. This protocol uses the GCM method (based on the AES algorithm) to generate the MIC and encrypted data, as described in NIST Special Publication 800-38D. Specifically, the key, random number, plaintext data, and AAD can be passed to the GCM encryption algorithm as K, IV, P, and A, respectively. The GCM encryption algorithm generates ciphertext C and authentication tag T. Ciphertext C represents the encrypted frame body, and T represents the MIC.

[0088] MIC for broadcast and multicast management frames

[0089] According to the Draft P802.11REVme_D4.1 standard, in the Broadcast / Multicast Integrity Protocol (BIP), the beacon integrity group temporal key (BIGTK) is used to generate the MIC for beacon frames (a type of broadcast management frame), and the integrity group temporal key (IGTK) is used to generate the MIC for multicast management frames. The encapsulation location of the MIC in the BIP is shown in Figures 7 and 8.

[0090] BIP-CMAC-128 uses AES-128 in CMAC mode (with a 128-bit integrity key) and a CMAC TLen value of 128 bits (16 bytes) to provide data integrity and replay protection. BIP-CMAC-256 uses AES-256 in CMAC mode (with a 256-bit integrity key) and a CMAC TLen value of 128 bits (16 bytes) to provide data integrity and replay protection. NIST Special Publication 800-38B defines the CMAC algorithm, and NIST Special Publication 800-38D defines the GMAC algorithm. For BIP-CMAC-256, the output of CMAC is 128 bits (16 bytes) and is not truncate. For BIP-CMAC-128, the output of CMAC is truncated to 64 bits: MIC = Truncate-64 (CMAC Output).

[0091] As mentioned above, BIP-CMAC-128 uses AES with a 128-bit integrity key, and BIP-CMAC-256 uses AES with a 256-bit integrity key. The authentication tag for BIP-CMAC-128 and BIP-CMAC-256 should be 128 bits (16 bytes) and not truncate.

[0092] The AAD of the BIP is constructed based on the MPDU header. The AAD is constructed based on the FC field of the MPDU, the Address 1 (A1) field of the MPDU, the Address 2 (A2) field of the MPDU, and the Address 3 (A3) field of the MPDU. When constructing the AAD, the retry subfield (bit number 11, numbered starting from 0, representing the 12th least significant bit) in the FC field, the power management subfield (bit 12), and the more data subfield (bit 13) are masked with a mask of 0, and the other subfields are not adjusted. Figure 9 shows the format of the AAD. The length of the AAD is 20 bytes.

[0093] For BIP-GMAC-128 and BIP-GMAC-256, the initialization vector passed to the GMAC shall be the concatenation of A2 in the MAC header of the MPDU and a non-negative integer inserted in the MME IPN / BIPN field.

[0094] The MIC is calculated by concatenating the AAD and the management frame body containing the MME and inserted into the MME's MIC field. For protected beacon frames, the timestamp field in the frame body is masked with a zero mask during calculation. For BIP-CMAC-128, the MIC is 64 bits and is calculated based on AES-128-CMAC. For BIP-CMAC-256, the MIC is 128 bits and is calculated based on AES-128-GMAC.

[0095] In summary, BIP connects part of the management frame header (i.e., the fields that make up the AAD) and the frame body (including the MME, mainly the IPN / BIPN in the MME) together (denoted as m), and uses the CMAC or GMAC method to generate the MIC.

[0096] CMAC is a variant of the CBC-MAC method, see NIST SP800-38B-CMAC. BIGTK or IGTK, m, and the length of the MIC are used as the input parameters K, M, and Tlen of CMAC respectively.

[0097] GMAC is a special form of the GCM method used to generate message authentication codes on unencrypted data, as described in NIST Special Publication 800-38D. The input parameters for GMAC are K, IV, P, and A, respectively, using BIGTK or IGTK, IV (consisting of A2 and IPN / BIPN concatenated), m, and AAD.

[0098] NFR

[0099] According to the standard Draft P802.11REVme_D4.1, the AP can send an NDP feedback report poll (NFRP) trigger frame to obtain the NDPs of multiple STAs. Figure 10 shows the frame format of NFRP. After receiving the NFRP trigger frame, the STA transmits an NDP (the format of this NDP is called a high efficiency (HE) trigger based (TB) feedback NDP) in response. When the number of bytes of the STA's cached data is greater than or equal to the resource request buffer threshold, the STA's feedback status (FEEDBACK_STATUS) value is 1; otherwise, the STA's FEEDBACK_STATUS value is 0 (FEEDBACK_STATUS will be used to modulate the subcarrier of the long training field (LTF) of the transmitted NDP). The resource request buffer threshold may be indicated by the AP in the NDP feedback report parameter set element in a beacon frame, a probe response frame, an association response frame, and / or a reassociation response frame. Alternatively, if no such indication is received, the resource request buffer threshold is set to a default value. The default value may be 256 bytes.

[0100] Figure 11 shows the format of the NDP feedback report parameter set element. The resource request buffer threshold exponent field is used to calculate the buffer threshold between two different resource requests. Assuming that the value of the resource request buffer threshold exponent field is a, the resource request buffer threshold value can be equal to 2. a If the AP does not send an NDP feedback report parameter set element, the resource request buffer threshold can be equal to 256 bytes.

[0101] The HE TB feedback NDP format is shown in Figure 12. Referring to Figure 12, this NDP format adopts the HE TB PPDU format. Unlike the HE TB PPDU format, this NDP format does not have a data field. The packet extension (PE) field duration of this NDP format is 0 microseconds. This NDP format has 2 symbols of type 4x HE-LTF, and the guard interval (GI) used is 3.2 microseconds. The duration of a 1x HE-LTF symbol is 3.2 microseconds, the duration of a 2x HE-LTF symbol is 6.4 microseconds, and the duration of a 4x HE-LTF symbol is 12.8 microseconds. The GI is not included in the above durations.

[0102] The different resource unit subcarrier set indices (RU_TONE_SET_INDEX) in the HE-LTF field are used to identify the association identity (AID) and feedback status (FEEDBACK_STATUS) of different non-AP STAs, as shown in Table 1:

[0103] Table 1: HE-LTF subcarrier mapping for HE TB feedback NDP (11ax)

[0104] When the value of the spatially multiplexed users field in the NFRP trigger frame is 0, each RU_TONE_SET_INDEX corresponds to one non-AP STA (AID). When the bandwidth is 20 MHz, for a non-AP STA using RU_TONE_SET_INDEX = 1, FEEDBACK_STATUS = 1 corresponds to energy in subcarriers -113, -77, -41, 6, 42, and 78 in the HE-LTF, while all other subcarriers have no energy. FEEDBACK_STATUS = 0 corresponds to energy in subcarriers -112, -76, -40, 7, 43, and 79 in the HE-LTF, while all other subcarriers have no energy. When the bandwidth is 40 MHz or 80 MHz, the 20 MHz subcarrier mapping is expanded by 1 and 3 times, respectively, to allow for mapping of more non-AP STAs (AIDs). The starting association identifier in the NFRP trigger frame corresponds to a RU_TONE_SET_INDEX value of 1. For example, if the starting association identifier is 6, the non-AP STA with an AID value of 6 corresponds to a RU_TONE_SET_INDEX value of 1, the non-AP STA with an AID value of 7 corresponds to a RU_TONE_SET_INDEX value of 2, and so on.

[0105] When the Spatial Multiplexing User Number field in the NFRP trigger frame is set to 1, each RU_TONE_SET_INDEX corresponds to two non-AP STAs (AIDs), and these two non-AP STAs are distinguished by different pre-assigned precoding matrices. The starting association identifier in the NFRP trigger frame corresponds to a RU_TONE_SET_INDEX value of 1. For example, if the starting association identifier is 6, the two non-AP STAs with AID values ​​of 6 and 7 correspond to a RU_TONE_SET_INDEX value of 1, the two non-AP STAs with AID values ​​of 8 and 9 correspond to a RU_TONE_SET_INDEX value of 2, and so on.

[0106] Use a smaller interframe interval to transmit preemption requests (PRs)

[0107] The related proposal (11-23-1229-01-0uhr-preemption-for-low-latency-application-follow-up) proposes a solution for transmitting preemption requests using a smaller interframe interval. Referring to Figures 13 and 14, the AP divides the longer downlink PPDU into multiple shorter PPDUs. These multiple shorter PPDUs are transmitted continuously with an x ​​interframe space (xIFS). The xIFS is to be determined, for example, it can be the priority interframe space (PIFS). The preamble of the first short PPDU indicates whether the transmission within a certain period of time (such as the duration of this transmission) can be preempted (preemption). If preemption is possible, other STAs with low-latency data to be transmitted (such as STA2 and STA3 in Figure 14) can use an interframe interval (Tp) shorter than xIFS to transmit a preemption request (similar to a CTS frame) to the AP, thereby interrupting the AP's downlink transmission.

[0108] MU-RTS and Transmit Preemption Requests

[0109] A related proposal (11-23-1950-00-00bn-considerations-on-preemption-request) proposes two sequences for transmitting preemption requests. These sequences can be used to protect the preempted transmission from interference from hidden nodes in the overlapping basic service set (OBSS). For example, the MU-RTS / CTS sequence can be used to protect the transmission medium before a preemptive transmission. Alternatively, the MU-RTS / CTS sequence can be used to protect the transmission medium at the beginning of a TXOP where a preemptive transmission is to be performed.

[0110] Because multiple STAs may transmit preemption request frames at the same time, in order to prevent conflicts, the proposal also proposes that the PPDUs carrying preemption request frames must be consistent. In order to make the PPDUs transmitted by multiple STAs consistent, the scrambler initialization value (scrambler initialization value) and receiver address (receiver address, RA) to be used by the preemption request frame can be indicated in the signal (SIG) field of the preceding PPDU (such as the universal signal (U-SIG) field or the ultra high reliability (UHR)-SIG field). The scrambler initialization value is carried in the preamble of the PPDU and is used to generate the scrambling sequence of the PPDU; the RA indicates the STA receiving the frame. Alternatively, the scrambler initialization value and RA to be used by the preemption request frame can be set to fixed values.

[0111] Low latency indication

[0112] Related technologies also provide a method for prioritizing low-latency data transmission, in which a STA can indicate to the AP (via a CTS or modified NDP) on a reserved resource unit (RU) that it has low-latency data to transmit and / or needs to preempt a TXOP.

[0113] For example, as shown in Figure 15, the AP obtains the TXOP, and the AP performs at least one downlink transmission with the first STA. The first STA reserves at least one subchannel or RU when making an uplink response or confirmation to the AP. If other STAs generate low-latency data to be sent before the uplink response or confirmation, the other STAs can use the reserved subchannel or RU to send a low-latency indication in the uplink response or confirmation. After receiving the low-latency indication, the AP will use a buffer status report poll (BSRP) trigger frame to obtain the buffer status reports of multiple STAs or use NFRP to obtain the NDPs of multiple STAs. Then, the uplink transmission process based on the trigger frame is used to trigger each STA to perform uplink transmission.

[0114] Protection of MAC frame header and control frame

[0115] According to relevant proposals (such as 11-23-0312-00-0uhr-thoughts-on-secure-control-frames, 11-23-0356-01-0uhr-mac-header-protection, 11-23-1888-01-00bn-mac-header-protection-follow-up, 11-23-0352-01-0uhr-enhanced-security-discussion, 11-23-1102-00-0uhr-security-enhancement-follow-up, 11-23-0286-00-0uhr-trigger-frame-protection, and 11-23-1914-00-00bn-enhanced-security-considerations-in-uhr), part of the MAC frame header is not protected and may be used by attackers to send counterfeit QoS messages. Null frames or replay QoS data frames can cause the STA to perform unnecessary processing (such as preparing and transmitting TB PPDU), thereby consuming power. Alternatively, the attacker may impersonate the STA to enter power saving mode, and then continue to impersonate the STA to reassociate with the AP, thereby obtaining data previously cached by the AP, resulting in data leakage. The above proposal also points out that the MIC needs to be calculated separately for the MAC frame header and should not be encrypted together with the frame body. This is because the MAC frame header will change when it is retransmitted, and the MIC needs to be recalculated (the data volume of the MAC frame header is small, so the calculation overhead is small), while the frame body will not be re-encrypted when it is retransmitted (the data volume of the frame body is large, so the calculation overhead is large).

[0116] The above proposal also points out that the control frames with frame bodies (such as trigger frame (TF), block ack request (BAR) frame, block ack (BA) frame, NDP announcement (NDPA) frame) are currently unprotected. Therefore, such frames may be used by attackers to trigger STAs to initiate unnecessary transmissions, thereby consuming power; or such frames may be spoofed by attackers, resulting in data loss. Therefore, the above proposal points out that the MIC mechanism can be used to perform integrity verification on the MAC frame header and the frame body of the control frame to prevent tampering. The MIC can be generated using a control group temporal key (CGTK) dedicated to control frame protection, or it can be generated using a control pairwise transient key (CPTK) dedicated to control frame protection.

[0117] As described above, to meet the requirements for low-latency data transmission, related technologies have introduced several mechanisms. For example, if a STA has pending low-latency data to transmit, it can send a preemption request to the AP to obtain a TXOP. Alternatively, a STA can transmit a low-latency indication to indicate the availability of pending low-latency data and / or the need to preempt a TXOP. However, ensuring the security of such mechanisms remains a challenge. For example, related technologies do not protect preemption requests during transmission. Therefore, an attacker could impersonate a STA to send a preemption request, causing unnecessary interruption of the AP's downlink transmission, thereby increasing transmission latency. Furthermore, if an attacker impersonates a STA to send a preemption request, the AP could trigger the STA to perform unnecessary transmissions, thereby wasting power. Similarly, related technologies do not protect preemption requests during transmission of a low-latency indication. Therefore, an attacker could impersonate a STA to send a low-latency indication, causing unnecessary interruption of the AP's downlink transmission, thereby increasing transmission latency. Furthermore, if an attacker impersonates a STA to send a low-latency indication, the AP could trigger the STA to perform unnecessary transmissions, thereby wasting power.

[0118] In response to the above problems, the embodiments of the present application are described in detail below.

[0119] Figure 16 is a flow chart of a wireless communication method provided in an embodiment of the present application. The method of Figure 16 is described from the perspective of the interaction between the first STA and the second STA. The first STA may be a STA that wishes to seize the TXOP, or the first STA may be a STA with low-latency data (or traffic) to be transmitted. The second STA may be the owner of the TXOP. As an example, the first STA is a non-AP STA and the second STA is an AP; or both the first STA and the second STA are non-AP STAs.

[0120] Referring to Figure 16, in step S1610, a first STA sends a first PPDU to a second STA. The first PPDU includes first information. The first information may be used to preempt the second STA's TXOP and / or indicate that the first STA has low-latency data to be transmitted. If the first information is used to preempt the second STA's TXOP, the first information may be referred to as a preemption request or a preemption signal. If the first information is used to indicate that the first STA has low-latency data to be transmitted, the first information may be referred to as a low-latency indication.

[0121] The embodiments of the present application do not specifically limit the manner in which the first information is carried in the first PPDU. In some implementations, the first PPDU may include a first MAC frame, and the first information may be carried in the first MAC frame. The first MAC frame may be called a preemption request frame or a low latency indication frame. The first MAC frame may be, for example, a CTS frame. In other implementations, the first information may also be carried in a preamble of the first PPDU, such as a preamble of an NDP.

[0122] In addition to the first information, the first PPDU also includes second information. The second information is used to determine (or verify) the legitimacy of the first STA. That is, the second information is used to determine (or verify) whether the first information (or the frame containing the first information, or the PPDU containing the first information) is sent by a legitimate STA (a legitimate STA may refer to an STA that is authenticated and associated and has the correct transmission key). In other words, the second information can be used to determine (or verify) the integrity of the frame containing the first information (to prevent the frame containing the first information from being tampered with) or the integrity of the PPDU containing the first information (to prevent the PPDU containing the first information from being counterfeited). The embodiment of the present application introduces the second information to provide security protection for the transmission of the first information. Based on the second information, the second STA can identify whether the STA sending the first information is a legitimate STA, thereby preventing the transmission of the second STA from being interrupted by an attacker and / or preventing the second STA from triggering other STAs to perform unnecessary transmissions, thereby improving the security of the communication process.

[0123] In some implementations, the second information may be generated based on a certain type of key encryption. For example, the second information may be information generated based on a group key encryption. The group key mentioned here may be, for example, a combination of one or more of the following: group temporal key (GTK), integrity group temporal key (IGTK), BIGTK, and CGTK. For example, in the case where multiple STAs simultaneously send the first information, if there is no need to distinguish between the multiple STAs, the second information may be generated by group key encryption and sent together with the first information, thereby verifying the legitimacy of the STA that sent the first information.

[0124] In some implementations, the second information may be information generated based on pairwise key encryption. The pairwise key mentioned here may be, for example, a pairwise transient key (PTK), or CPTK. For example, in the case where multiple STAs simultaneously send the first information, if it is necessary to distinguish the multiple STAs, the second information may be generated by pairwise key encryption and sent together with the first information, thereby verifying the legitimacy of the STA that sent the first information. Of course, in this case, the second information sent by multiple STAs may also be encrypted using the group key mentioned above, and the distinction between the multiple STAs may be achieved in other ways. For example, different time domain, frequency domain and / or code domain resources may be pre-allocated or negotiated for multiple STAs.

[0125] The embodiments of the present application do not specifically limit the manner in which the second information is carried within the first PPDU. For example, the first PPDU may include a first MAC frame, and the second information may be carried within the first MAC frame. In another example, the second information may be carried within the preamble of the first PPDU. The following describes the content and carrying manner of the second information in more detail, using two embodiments.

[0126] Example 1: The second information is carried in a MAC frame

[0127] In the first embodiment, the first PPDU is used to carry the first MAC frame, and the second information is carried in the first MAC frame. For example, the second information can be the MIC carried in the first MAC frame. As mentioned above, the first MAC frame can be a preemption request frame or a low time indication frame; accordingly, the second information can be used to determine (or verify) the legitimacy of the STA sending the preemption request frame or low time indication frame. Alternatively, the second information can be used to determine (or verify) the integrity of the preemption request frame or low time indication frame.

[0128] The MIC generation method can be found in the description of "MIC for Broadcast Management Frames and Multicast Management Frames" in the previous section. The following uses the first MAC frame as a CTS frame as an example to illustrate the MIC generation method.

[0129] Figure 17 shows the frame format of a CTS frame. The entire frame header (including FC, duration (RA), PN, and FCS (optional) can be concatenated together to form the message to be verified (denoted as m). The key (such as a pairwise key or group key), m, and the length of the MIC (128 bits or 256 bits) are used as the CMAC input parameters K, M, and Tlen, respectively, and the MIC is generated using the CMAC method. CMAC is a variant of CBC-MAC, see NIST SP800-38B-CMAC.

[0130] Alternatively, the entire frame header (including FC, duration, RA), PN, and FCS (optional) can be concatenated together to form the AAD, the entire frame header (including FC, duration, RA), and FCS (optional) can be used as the message to be verified (denoted as m), and the RA and PN can be concatenated together to form the initialization vector. Then, the key (such as a pairwise key or group key), initialization vector, m, and AAD can be used as the input parameters K, IV, P, and A of the GMAC method, respectively, to generate the MIC. GMAC is a special form of the GCM method used to generate a MIC on unencrypted data. For details, see NIST Special Publication 800-38D.

[0131] The embodiment of the present application does not specifically limit the position of the MIC field in the first MAC frame.

[0132] In some implementations, the first MAC frame includes a first FCS field, and the MIC field is located before the first FCS field. For example, the first MAC frame may be a newly defined control frame or management frame. The MIC field may be carried before the FCS field of the control frame or management frame. Figure 18 illustrates a frame format of a control frame proposed in an embodiment of the present application. The first information mentioned above is the preemption information in Figure 18. As can be seen from Figure 18, the MIC field is located before the FCS field of the control frame.

[0133] In some implementations, the first MAC frame includes a first FCS field, and the MIC field is located after the first FCS field. Taking the first MAC frame as the CTS frame shown in Figure 19 as an example, the first FCS field can be the FCS1 field in Figure 19. As can be seen from Figure 19, the MIC is located after the FCS1. Furthermore, in some implementations, a second FCS field (i.e., the FCS2 field in Figure 19) can be added after the MIC field. The FCS2 field can be used for a cyclic redundancy check (CRC) of the entire frame body, FCS1, and MIC. The calculation algorithm for FCS2 can use the same calculation algorithm as that for FCS1. By setting the MIC field after the FCS field, the format before the MIC field can remain unchanged, thereby simplifying the implementation.

[0134] As mentioned above, MIC can be generated based on PN. PN can be used to prevent replay attacks. A replay attack means that an attacker can cache a monitored frame and then resend it without modification. If there is no anti-replay mechanism, the attacker can process the retransmitted frame as a legal frame. PN is generally a self-incrementing integer, or it can be a randomly generated integer each time. Generating MIC based on PN can generate a new MIC for each transmission. Even if the content of the retransmitted frame is exactly the same as the previous frame, due to the different PN, the retransmitted frame will carry a different MIC, which can prevent replay attacks. PN can be 16 bits, or 24 bits, or 32 bits, or 48 bits, or a larger number of bits. In this solution, 48 bits are used as an example.

[0135] In some scenarios, the PN used to generate the MIC can be sent by the second STA to the first STA through a preamble downlink transmission (which can be a MAC frame or a PPDU). For example, if the second STA does not distinguish between the STA that sends the first information (such as a preemption request or a low latency indication), then in order to prevent conflicts, the PPDUs carrying the first information sent by each STA at the same time need to be consistent. To ensure this, each STA needs to send the same type of PPDU, such as a non-high throughput PPDU (non-HT PPDU), a non-HT duplicate PPDU, or a TB PPDU. In addition, each STA needs to ensure that the preamble is consistent, and the same modulation and coding scheme (MCS) and number of spatial streams (NSS) need to be predefined or pre-negotiated. In addition, the second STA needs to send the same PN value to each STA in advance so that the MIC generated by each STA is the same.

[0136] The following describes the PN interaction method with reference to FIG20 .

[0137] Referring to FIG. 20 , before executing step S1610, the first STA receives a second PPDU sent by the second STA (see step S2010 in FIG. 20 ). The second PPDU includes target bits, which are part or all of the bits occupied by the PN. For example, where the target bits are part of the bits occupied by the PN and the target bits include M bits (M is a positive integer greater than or equal to 1), the target bits can be the M least significant bits, the M most significant bits, or any M bits of the bits occupied by the PN.

[0138] The second STA may transmit the PN to the first STA via a second PPDU within the current TXOP. Alternatively, if a TXOP is only allowed to be preempted once, the second STA may set the PN to be used for preemption of the TXOP in advance. For example, the second STA may notify all STAs, including the first STA, of the PN in advance using a management frame or a trigger frame (such as a basic trigger frame).

[0139] As an example, referring to Figure 21, the AP corresponds to the second STA mentioned above, STA2 or STA3 corresponds to the first STA mentioned above, and the first information is carried in the PR frame in Figure 21. Referring to Figure 21, the AP carries a PN in the data frame to STA1, and STA2 or STA3 can send a PR frame to the AP based on the PN.

[0140] As another example, see Figure 22. The AP corresponds to the second STA mentioned above, and STA2 or STA3 corresponds to the first STA. The first information is the low-latency indicator in Figure 22. Referring to Figure 22, the AP carries a PN in the data frame sent to STA1. STA2 or STA3 can send a low-latency indicator to the AP based on this PN. Furthermore, after receiving QoS Null frames from STA2 and STA3, the AP continues to carry the PN in trigger frames, enabling other STAs to send low-latency indicators via reserved subchannels.

[0141] The embodiments of the present application do not specifically limit the location of the target bit occupied by the PN in the second PPDU. For example, the second PPDU may include a second MAC frame, and the target bit may be carried in the second MAC frame. In another example, the target bit may be carried in the preamble of the second PPDU. Two possible embodiments are described below.

[0142] Example 1.1: Target bits occupied by PN are carried in MAC frame

[0143] In Example 1.1, the target bit is carried in a second MAC frame (the second MAC frame is carried in a second PPDU). The second MAC frame can be a data frame, a control frame, or a management frame. Taking a data frame as an example, the second MAC frame can be an ordinary downlink data frame or a QoS Null frame. Taking a control frame as an example, the second MAC frame can be a trigger frame, such as a basic trigger frame. The QoS Null frame, control frame, or management frame can be a QoS Null frame, control frame, or management frame attached to a downlink data frame. In other words, the QoS Null frame, control frame, or management frame can be carried in the same PPDU as the downlink data frame (i.e., the second PPDU mentioned above).

[0144] If the target bits only include part of the bits occupied by PN, in some implementations, before the first STA sends the first PPDU to the second STA, the first STA may also receive a third MAC frame sent by the second STA. The third MAC frame may include other bits occupied by PN except for the target bits. The third MAC frame mentioned here may be a beacon frame, or it may be another MAC frame carried in the same PPDU as the second MAC frame. As an example, the target bits may include the M least significant bits (M is a positive integer greater than or equal to 1) of the N bits occupied by PN. The remaining NM bits (i.e., the NM most significant bits occupied by PN) may be carried in the third MAC frame (such as carried in a beacon frame for periodic broadcast). The most significant bit changes less frequently, and carrying the most significant bit in the beacon frame can reduce the overhead required to indicate the PN.

[0145] The following describes, with reference to the accompanying drawings, examples of the specific carrying location of PN in the second MAC frame and / or the third MAC frame.

[0146] For example, the second MAC frame includes an aggregation control (A-Control) field (the A-Control field may be located in the HT Control field). The PN may be carried in the A-Control field. The second MAC frame may be any type of frame that includes an A-Control field. For example, the second MAC frame may be a downlink data frame. As another example, the second MAC frame may be a QoS Null frame attached to the downlink data frame (i.e., the QoS Null frame and the downlink data frame are carried in the same PPDU). Figure 23 shows an example of a QoS Null frame. As can be seen from Figure 23, the QoS Null frame includes the HT Control field, and the HT Control field includes the A-Control field. The PN may be carried in the control list field of the A-Control field.

[0147] Since the PN generally requires 48 bits, 24 of these 48 bits can be carried in the second MAC frame (such as the downlink data frame), and the remaining 24 bits can be carried in the third MAC frame (such as the QoS Null frame attached to the downlink data frame). The bits in the second and third MAC frames are concatenated to obtain the PN. Alternatively, the second STA can periodically broadcast the most significant 24 bits (or 22 bits) of the PN in a beacon frame. The most significant 24 bits (or 22 bits) of the PN can remain unchanged for several beacon periods (each beacon period is approximately 100 ms). The least significant 24 bits (or 26 bits) of the PN can then be carried in the second MAC frame (such as the downlink data frame or the QoS Null frame attached to the downlink data frame).

[0148] For another example, the second MAC frame may include one or more special user information fields (such as a special user information 2 field). The target bit may be carried in the one or more special user information fields. The second MAC frame may be any type of frame that includes a special user information field. For example, the second MAC frame may be a trigger frame (such as a basic trigger frame). Figure 24 illustrates the frame format of a basic trigger frame. As shown in Figure 24, the basic trigger frame includes a user information list field. The user information list field includes two special information user 2 fields. The AID12 field value in the special user information 2 field may be any reserved value between 2008 and 2047. One special user information 2 field may include 24 bits of PN. The PNs in the two special user information 2 fields are concatenated to obtain the PN value to be used. Alternatively, the basic trigger frame may carry only one special user information 2 field, which includes the least significant 24 bits (or 28 bits) of the PN, while the most significant 24 bits (or 20 bits) of the PN are carried and broadcast periodically in beacon frames. Optionally, one bit is selected from the reserved bits of the general information of the basic trigger frame to indicate that the basic trigger frame carries one or two special user information 2 fields.

[0149] Example 1.2: The target bits occupied by PN are carried in the SIG field

[0150] In Example 1.2, the target bit is carried in the SIG field of the second PPDU. Figure 25 shows a possible format of the second PPDU. As can be seen from Figure 25, the second PPDU includes a UHR-SIG field. The target bit can be carried in the UHR-SIG field. Similar to Example 1.1, if the target bit is part of the bits occupied by the PN, in some implementations, before the first STA sends the first PPDU to the second STA, the first STA can also receive a fourth MAC frame sent by the second STA. The fourth MAC frame can include other bits of the bits occupied by the PN in addition to the target bit. The fourth MAC frame mentioned here can be a beacon frame. As an example, the target bit can include the M least significant bits (M is a positive integer greater than or equal to 1) of the N bits occupied by the PN. The remaining NM bits (i.e., the NM most significant bits occupied by the PN) can be carried in the fourth MAC frame (e.g., carried in a beacon frame for periodic broadcast). The most significant bit changes less frequently, and carrying the most significant bit in the beacon frame can reduce the overhead required to indicate the PN.

[0151] In some implementations, the SIG field may include a user-specific field. The user-specific field may include one or more special user fields. The target bit may be carried in the one or more special user fields. Taking Figure 25 as an example, the UHR-SIG field includes a user-specific field, and one or more special user fields (i.e., the special user field, check code, and tail in Figure 25) may be added to the user-specific field, and the target bit may be carried in the special user field (Figure 25 contains multiple PNs, each PN represents a portion of the bits occupied by the PN, and multiple PNs are spliced ​​together to form a complete PN). For example, five special user fields may be added to the user-specific field of the UHR-SIG field in the UHR MU PPDU for single-user transmission. The first four special user fields of the five specific user fields carry 44 bits in the PN, and the fifth special user field carries 4 bits in the PN. Alternatively, only two, three, or four special user fields are added to the user-specific field of the UHR-SIG field, wherein the least significant 22 bits, the least significant 33 bits, or the least significant 44 bits of the PN are carried, and the corresponding most significant 26 bits, the most significant 15 bits, or the most significant 4 bits of the PN are carried in the fourth MAC frame (e.g., carried and broadcast periodically in a beacon frame). Similar processing can also be performed on the UHR-SIG field in the UHR MU PPDU used for orthogonal frequency division multiple access (OFDMA) transmission.

[0152] In some implementations, as shown in FIG25 , the SIG field (such as the UHR-SIG field) includes a common field. The common field may include fourth information. The fourth information is used to indicate the number of one or more special user fields. For example, the common field may include one or more fields such as spatial multiplexing, guard interval and LTF size, number of EHT-LTF symbols, LDPC additional symbol fragments, padding factor before FEC, packet extension deambiguation, and disregard, and the fourth information may be carried in the disregard field. For example, the bit value of the disregard field is all 1 by default, and the value of one of the bits can be set to 0 to indicate that the UHR-SIG field carries 2 or 3 or 4 or 5 special user fields.

[0153] The following describes Embodiment 1 in more detail with reference to specific examples. In the following examples, the STA that sends the preemption request or low-latency indication is the first STA mentioned above, and the AP is the second STA mentioned above. It should be noted that the following examples are intended solely to help those skilled in the art understand the embodiments of the present application, and are not intended to limit the embodiments of the present application to the specific numerical values ​​or specific scenarios illustrated. Those skilled in the art can readily make various equivalent modifications or variations based on the examples provided, and such modifications or variations also fall within the scope of the embodiments of the present application.

[0154] Example 1: The AP does not distinguish between STAs that send preemption requests and / or low latency indications

[0155] For simplicity, it is not necessary to identify the STA that sends the preemption request frame and / or low-latency indication frame. It is sufficient to only confirm that the preemption request frame and / or low-latency indication frame is sent by a legitimate STA. Therefore, the MIC carried in the preemption request frame and / or low-latency indication frame can be generated using a group key (e.g., GTK, IGTK, BIGTK, or CGTK). The MIC generation method is described in the section "MIC for Broadcast and Multicast Management Frames."

[0156] Taking the preemption request frame or low latency indication frame as CTS as an example, the format of the preemption request frame or low latency indication frame can be seen in Figure 17. The entire frame header (including frame control, duration, recipient address), PN and FCS (optional) can be connected together as the message to be verified (denoted as m), and the CMAC method is used to generate the MIC. CMAC is a variant of the CBC-MAC method, see NIST SP800-38B-CMAC. The group key (such as CGTK), m, and the length of the MIC (128 bits or 256 bits) are used as the input parameters K, M and Tlen of CMAC respectively.

[0157] And / or, the entire frame header (including frame control, duration, recipient address), PN, and FCS (optional) are concatenated together as AAD, the entire frame header (including frame control, duration, recipient address) and FCS (optional) are used as the message to be verified (denoted as m), the recipient address and PN are concatenated together as the initial vector, and the GMAC method is used to generate the MIC. GMAC is a special form of the GCM method used to generate a message authentication code on unencrypted data, see NIST Special Publication 800-38D. The group key (e.g., CGTK), initial vector, m, and AAD are used as the input parameters K, IV, P, and A of GMAC, respectively.

[0158] The MIC can be carried before or after the FCS field of the preemption request frame and / or the low latency indication frame. For example, if the preemption request frame and / or the low latency indication frame is a newly defined control frame (as shown in FIG18 ) or a management frame, the MIC can be carried before the frame check sequence (FCS) field.

[0159] For example, if the preemption request frame and / or the low latency indication frame is a CTS frame (as shown in Figure 19), the MIC can be carried after the FCS field. Furthermore, an FCS2 field can be added after the MIC field. The FCS2 field is used to calculate the CRC of the entire frame body, FCS1, and MIC, and its calculation method is the same as that of FCS1.

[0160] The STA may use a PPDU that occupies the entire working bandwidth of the STA to send a preemption request frame and / or a low latency indication frame, or may use a PPDU that occupies only part of the working bandwidth of the STA to send a preemption request frame and / or a low latency indication frame.

[0161] The MIC can be generated based on the PN. The PN is used to prevent replay attacks, where an attacker can cache a monitored frame and retransmit it without modification. If there is no anti-replay mechanism, the STA will process it as a valid frame. Using the PN, a new MIC is generated for each transmission, and even if the frame content is exactly the same, a different MIC will be generated. The PN is generally a self-increasing integer, but it can also be a randomly generated integer each time. In this example, to prevent conflicts, the PPDUs carrying preemption request frames and / or low latency indication frames sent by each STA at the same time must be consistent (for example, using non-HT PPDUs, non-HT duplicate PPDUs, or TB PPDUs), and the preamble must be consistent. The same MCS and NSS must be predefined or pre-negotiated. The AP needs to send the same PN value to each STA in advance. The AP can indicate this PN value in the preceding downlink frame and / or in the SIG field of the downlink PPDU, as shown in Figures 21 and 22.

[0162] The PN can be carried in the A-Control field in the HT Control field in the frame header of the downlink data frame. Alternatively, the PN can be carried in the A-Control field in the HT Control field in the frame header of a QoS Null frame (as shown in FIG. 23 ) attached to the downlink data frame.

[0163] Since a PN generally requires 48 bits, the 24-bit PN carried in the downlink data frame and the PN carried in the attached QoS Null frame can be concatenated to obtain the PN value to be used. Alternatively, the AP can carry the most significant 24 bits (or 22 bits) of the PN in beacon frames and broadcast them periodically. The most significant 24 bits (or 22 bits) of the PN can remain unchanged for several beacon periods (each beacon period is approximately 100ms), and the least significant 24 bits (or 26 bits) of the PN can be carried in the downlink data frame and / or the attached QoS Null frame.

[0164] Alternatively, in some implementations, the PN can be carried in a newly defined management frame or control frame (e.g., a basic trigger frame) attached to a downlink data frame. As shown in FIG24 , two special user information 2 fields can be carried in a basic trigger frame. The AID12 field value in the special user information 2 field is any reserved value between 2008 and 2047. One special user information 2 field includes 24 bits of the PN, and the PNs in the two special user information 2 fields are concatenated to obtain the PN value to be used. Alternatively, the basic trigger frame can also carry only one special user information 2 field, which includes the least significant 24 bits (or 28 bits) of the PN, while the most significant 24 bits (or 20 bits) of the PN are carried and broadcast periodically in the beacon frame. Optionally, one bit is selected from the reserved bits of the general information of the basic trigger frame to indicate that the basic trigger frame carries one or two special user information 2 fields.

[0165] Alternatively, in some implementations, the PN may be carried in the UHR-SIG field of the downlink PPDU. As shown in FIG. 25 , five special user fields are added to the user-specific field of the UHR-SIG field in a UHR MU PPDU for single-user transmission. The first four special user fields carry 44 bits of the PN, and the fifth special user field carries 4 bits of the PN. Alternatively, only two, three, or four special user fields are added to the user-specific field of the UHR-SIG field, each carrying the least significant 22 bits, least significant 33 bits, or least significant 44 bits of the PN. The corresponding most significant 26 bits, most significant 15 bits, or most significant 4 bits of the PN are carried and broadcast periodically in beacon frames. Optionally, one bit in the ignore field of the general field of the UHR-SIG field may be set to 0 to indicate that the UHR-SIG field carries two, three, four, or five special user fields. Similar processing may be performed on the UHR-SIG field in a UHR MU PPDU for OFDMA transmission.

[0166] Alternatively, a TXOP can be limited to being preempted only once. In this case, the PN to be used for preemption in the TXOP can be set in advance. For example, a management frame or a trigger frame (such as a basic trigger frame) can be used in advance to inform each STA of the PN.

[0167] Example 2: AP distinguishes STAs that send preemption requests and / or low latency indications

[0168] To improve efficiency and allow the AP to identify the specific STA that sends the preemption request frame and / or low latency indication frame, each STA needs to send the TB PPDU carrying the preemption request frame and / or low latency indication frame in different pre-assigned or negotiated frequency domains, time domains, and / or spatial domains. Therefore, the AP needs to indicate the following to the STA in the initial control frame: the RU or MRU to be used to send the TB PPDU carrying the preemption request frame and / or low latency indication frame. The initial control frame is generally a MU-RTS trigger frame (as shown in Figure 26). The initial control frame can be the first frame sent by the AP when acquiring a TXOP, or it can be an indication frame sent during the TXOP when the AP allows the STA to initiate preemption.

[0169] The MIC may be carried before the FCS field of the preemption request frame and / or the low latency indication frame, or may be carried after the FCS field. For details, please refer to the description of Example 1.

[0170] Because the TB PPDUs carrying preemption request frames and / or low latency indication frames sent by various STAs do not conflict with each other, the contents of the preemption request frames and / or low latency indication frames carried in the TB PPDUs can be identical or different. The MIC carried in the preemption request frames and / or low latency indication frames can be generated using a group key (e.g., GTK, IGTK, BIGTK, or CGTK) or a pairwise key (e.g., PTK or CPTK). For information on how to generate the MIC, see Example 1.

[0171] In Example 2, the PNs used by each STA when generating the MIC can be the same or different. Therefore, the PN used by each STA can be indicated by the AP as in Example 1. Alternatively, each STA can use its own PN and carry it in a preemption request frame and / or a low-latency indication frame (e.g., a CTS frame, as shown in Figure 27).

[0172] Example 2: The second information is carried in the preamble of the PPDU

[0173] In the second embodiment, the second information is not carried in the first MAC frame, but rather in the preamble of the first PPDU. For example, the second information can be carried in the LTF of the preamble. As an example, the second information is the secure LTF in the first PPDU. The second information can be used to determine (or verify) the legitimacy of the STA sending the first PPDU. Alternatively, the second information can be used to determine (or verify) the legitimacy of the first PPDU.

[0174] The secure-LTF may be generated or verified based on the key K and the sequence number C (the sequence number may be 16 bits, 24 bits, 32 bits, or 48 bits). The embodiment of the present application does not specifically limit the generation method and verification method of the secure-LTF.

[0175] As an example, at the transmitting end, the first STA uses a key K and a sequence number C to generate a random sequence R. The first STA then uses the random sequence R to randomize the phase of the subcarriers of each spatial stream and uses the random sequence R to perform quadrature amplitude modulation (QAM) on each subcarrier of each LTF symbol on each spatial stream.

[0176] On the receiving end, the second STA uses the same keys K and C to generate the same random sequence R. The second STA then uses the random sequence R to obtain the expected secure-LTF. The second STA then compares the expected secure-LTF with the received secure-LTF. If the expected secure-LTF and the received secure-LTF have a high signal correlation (e.g., the signal correlation exceeds a predefined threshold), the verification passes.

[0177] Exemplarily, a specific generation algorithm of secure-LTF is described in detail below.

[0178] LTF-Key-Seed = HMAC-Hash(K, "Preemption LTF key seed"). In the above formula, HMAC-Hash(key, message) indicates a hash function in the form of a hash-based message authentication code (HMAC). K is the key. message is the message content to be authenticated, and HMAC indicates the key-based hash method used for message authentication (see IETF RFC2104 standard). Hash indicates a specific hash function. For example, HMAC-SHA-256(K, "Preemption LTF key seed") means using the SHA-256 algorithm (a hash function with an output length of 256 bits), using K as the key, and the string "Preemption LTF key seed" as the message content to be authenticated.

[0179] LTF-Key-Material = KDF-Hash-Length(LTF-Key-Seed, "Preemption LTF Expansion", C). In the above formula, KDF-Hash-Length(K, Label, Context) indicates a pseudo-random method used to derive the key. Hash indicates a specific hash function. Length indicates the number of bits of the derived key. K is the key. Label indicates the purpose of the derived key. Context indicates the context used for derivation. For example, KDF-SHA-256(LTF-Key-Seed, "Preemption LTF Expansion", C) indicates the use of the SHA-256 algorithm (a hash function with an output length of 256 bits), the LTF-Key-Seed as the key, the string "Preemption LTF Expansion" to indicate the purpose of the derived key, and C to indicate the context used for derivation. C is a sequence number, which the AP and STA exchange before each preemption.

[0180] LTF-Key=L(LTF-Key-Material,0,128) means that data with a length of 128 bits is intercepted starting from the 0th bit of LTF-Key-Material.

[0181] Input-Value (16 octets) = LTF-ID (6 octets) || Ctr (6 octets) || block counter (4 octets), where "||" represents the concatenation of two byte streams. LTF-ID is a 6-byte identifier, Ctr is the string form of the sequence number C (if it is less than 6 bytes, the header can be padded with the escape character "\0"), and block counter is the string form of the block counter used during encryption (initialized to 0 at the beginning of each encryption and incremented by 1 for each block of data output during encryption).

[0182] The LTF-ID can use the basic service set identity (BSSID), which is the identifier of the current BSS (typically the AP's MAC address, which is 6 bytes long). Alternatively, the LTF-ID can use the MAC address of the first STA. Alternatively, the LTF-ID can be a 6-byte random sequence distributed in advance by the second STA and shared by multiple STAs.

[0183] S = AES-128-CTR (LTF-Key, Input-Value, block counter). In the above formula, AES-128-CTR is a 128-bit AES counter mode implementation. For details, see FIPS 197. LTF-Key is the encryption key, and Input-Value is the original text to be encrypted. The block counter increments by 1 for every 128 bits of output, and the Input-Value is updated accordingly. The random sequence R mentioned above can be composed of at least one S.

[0184] In some implementations, the second STA needs to indicate the sequence number in advance (similar to the PN in Example 1) so that the first STA can generate the secure-LTF. Referring to Figure 28, before executing step S1610, the first STA receives the second PPDU sent by the second STA (step S2810). The second PPDU includes target bits, which are part or all of the bits occupied by the sequence number. Taking the example where the target bits are part of the bits occupied by the sequence number and the target bits include M bits (M is a positive integer greater than or equal to 1), the target bits can be the M least significant bits, the M most significant bits, or any M bits of the bits occupied by the sequence number.

[0185] As an example, referring to Figure 29, the AP corresponds to the second STA mentioned above, STA2 or STA3 corresponds to the first STA mentioned above, and the first information is carried in the PR frame in Figure 29. Referring to Figure 29, the AP carries a sequence number in the data frame to STA1, and STA2 or STA3 can send a PR frame to the AP based on the sequence number.

[0186] As an example, see Figure 30. The AP corresponds to the second STA mentioned above, and STA2 or STA3 corresponds to the first STA mentioned above. The first information is the low-latency indication in Figure 30. Referring to Figure 30, the AP carries a sequence number in the data frame sent to STA1. STA2 or STA3 can send a low-latency indication to the AP based on this sequence number. Furthermore, after receiving QoS Null frames from STA2 and STA3, the AP continues to carry the sequence number in trigger frames, enabling other STAs to send low-latency indications via reserved subchannels.

[0187] This embodiment of the present application does not specifically limit the location of the target bit occupied by the sequence number in the second PPDU. For example, the second PPDU may include a second MAC frame, and the target bit may be carried in the second MAC frame. In another example, the target bit may be carried in the preamble of the second PPDU. Two possible implementations are described below.

[0188] Example 2.1: The target bits occupied by the sequence number are carried in the MAC frame

[0189] In Example 2.1, the target bit is carried in a second MAC frame (the second MAC frame is carried in a second PPDU). The second MAC frame can be a data frame, a control frame, or a management frame. Taking a data frame as an example, the second MAC frame can be an ordinary downlink data frame or a QoS Null frame. Taking a control frame as an example, the second MAC frame can be a trigger frame, such as a basic trigger frame. The QoS Null frame, control frame, or management frame can be a QoS Null frame, control frame, or management frame attached to a downlink data frame. In other words, the QoS Null frame, control frame, or management frame can be carried in the same PPDU as the downlink data frame (i.e., the second PPDU mentioned above).

[0190] If the target bits are part of the bits occupied by the sequence number, in some implementations, before the first STA sends the first PPDU to the second STA, the first STA may also receive a third MAC frame sent by the second STA. The third MAC frame may include bits other than the target bits among the bits occupied by the sequence number. The third MAC frame mentioned here may be a beacon frame, or it may be a MAC frame carried in the same PPDU as the second MAC frame. As an example, the target bits may include the M least significant bits (M is a positive integer greater than or equal to 1) of the N bits occupied by the sequence number. The remaining NM bits (i.e., the NM most significant bits occupied by the sequence number) may be carried in the third MAC frame (such as carried in a beacon frame for periodic broadcast). The most significant bit changes less frequently, and carrying the most significant bit in the beacon frame can reduce the overhead required to indicate the sequence number.

[0191] The following describes, with reference to the accompanying drawings, examples of specific carrying locations of the sequence numbers in the second MAC frame and / or the third MAC frame.

[0192] For example, the second MAC frame includes an A-Control field. The sequence number can be carried in the A-Control field (the A-Control field can be located in the HT Control field). In this example, the second MAC frame can be any type of frame that includes an A-Control field. For example, the second MAC frame can be a downlink data frame. For another example, the second MAC frame can be a QoS Null frame attached to the downlink data frame (that is, the QoS Null frame and the downlink data frame are both carried in the second PPDU). Figure 31 shows an example of a QoS Null frame. As can be seen from Figure 31, the QoS Null frame includes an HT Control field, and the HT Control field includes an A-Control field. The sequence number can be carried in the control list of the A-Control field.

[0193] Since the sequence number may occupy a large number of bits (e.g., 48 bits, which will be described below using 48 bits as an example), 24 of the 48 bits can be carried in the second MAC frame (e.g., the downlink data frame), and the remaining 24 bits of the 48 bits can be carried in the third MAC frame (e.g., the QoS Null frame attached to the downlink data frame). The sequence number can be obtained by concatenating the bits in the second and third MAC frames. Alternatively, the AP can carry the most significant 24 bits (or 22 bits) of the sequence number in a beacon frame and broadcast it periodically. The most significant 24 bits (or 22 bits) of the sequence number can remain unchanged for several beacon periods (each beacon period is approximately 100 ms). Then, the least significant 24 bits (or 26 bits) of the sequence number are carried in the second MAC frame (e.g., the downlink data frame or the QoS Null frame attached to the downlink data frame).

[0194] For another example, the second MAC frame may include one or more special user information fields (such as a special user information 2 field). The target bit may be carried in the one or more special user information fields. The second MAC frame may be any type of frame that includes a special user information field. For example, the second MAC frame may be a trigger frame (such as a basic trigger frame). Figure 32 shows the frame format of a basic trigger frame. As shown in Figure 32, the basic trigger frame includes a user information list field. The user information list field includes two special information user 2 fields. The AID12 field value in the special user information 2 field can be any reserved value between 2008 and 2047. One special user information 2 field may include 24 bits of a sequence number, and the sequence numbers in the two special user information 2 fields may be concatenated to obtain the sequence number value to be used. Alternatively, the basic trigger frame may carry only one special user information 2 field, which includes the least significant 24 bits (or 28 bits) of the sequence number, while the most significant 24 bits (or 20 bits) of the sequence number are carried and broadcast periodically in beacon frames. Optionally, one bit is selected from the reserved bits of the general information of the basic trigger frame to indicate that the basic trigger frame carries one or two special user information 2 fields.

[0195] Example 2.2: The target bits occupied by the sequence number are carried in the SIG

[0196] In Example 2.2, the second PPDU includes a SIG field, and the target bit is carried in the SIG field. Figure 33 shows a possible format of the second PPDU. As can be seen from Figure 33, the second PPDU includes a UHR-SIG field, and the target bit can be carried in the UHR-SIG field. If the target bit is part of the bits occupied by the sequence number, in some implementations, before the first STA sends the first PPDU to the second STA, the first STA may also receive a fourth MAC frame sent by the second STA. The fourth MAC frame may include bits other than the target bit among the bits occupied by the sequence number. The fourth MAC frame mentioned here may be a beacon frame. As an example, the target bit may include the M least significant bits (M is a positive integer greater than or equal to 1) of the N bits occupied by the sequence number. The remaining NM bits (i.e., the NM most significant bits occupied by the sequence number) may be carried in the fourth MAC frame (e.g., carried in a beacon frame for periodic broadcast). The most significant bit changes less frequently, and carrying the most significant bit in the beacon frame can reduce the overhead required to indicate the sequence number.

[0197] In some implementations, the SIG field may include a user-specific field. The user-specific field may include one or more special user fields. The target bit may be carried in the one or more special user fields. Taking Figure 33 as an example, the UHR-SIG field includes a user-specific field, and one or more special user fields (i.e., the special user field, check code, and tail in Figure 33) may be added to the user-specific field, and the target bit may be carried in the special user field (Figure 33 contains multiple sequence numbers, each of which represents a portion of the bits occupied by the sequence number, and multiple sequence numbers are spliced ​​together to form a complete sequence number). Exemplarily, five special user fields may be added to the user-specific field of the UHR-SIG field in the UHR MU PPDU for single-user transmission. The first four special user fields of the five specific user fields carry 44 bits in the sequence number, and the fifth special user field carries 4 bits in the sequence number. Alternatively, only two, three, or four special user fields are added to the user-specific fields of the UHR-SIG field, wherein the least significant 22 bits, least significant 33 bits, or least significant 44 bits of the sequence number are carried, and the corresponding most significant 26 bits, most significant 15 bits, or most significant 4 bits of the sequence number are carried and broadcast periodically in the beacon frame. Similar processing can also be performed on the UHR-SIG field in the UHR MU PPDU used for OFDMA transmission.

[0198] In some implementations, as shown in FIG33 , the SIG field (such as the UHR-SIG field) includes a common field. The common field may include fourth information. The fourth information is used to indicate the number of one or more special user fields. For example, the common field may include one or more fields such as spatial multiplexing, guard interval and LTF size, number of EHT-LTF symbols, LDPC additional symbol fragments, padding factor before FEC, packet extension deambiguation, and ignore, and the fourth information may be carried in the ignore field. For example, the bit value of the ignore field is all 1 by default, and the value of one of the bits can be set to 0 to indicate that the UHR-SIG field carries 2 or 3 or 4 or 5 special user fields.

[0199] The following describes the second embodiment in more detail with reference to specific examples. In the following examples, the STA that sends the preemption request or low latency indication is the first STA mentioned above, and the AP is the second STA mentioned above. It should be noted that the following examples are merely intended to help those skilled in the art understand the embodiments of the present application, and are not intended to limit the embodiments of the present application to the specific numerical values ​​or specific scenarios illustrated. Based on the examples given, those skilled in the art can obviously make various equivalent modifications or variations, and such modifications or variations also fall within the scope of the embodiments of the present application.

[0200] Example 3: The AP does not distinguish between STAs that send preemption requests and / or low latency indications

[0201] In order to prevent conflicts, the PPDUs carrying the first information (used to preempt the AP's TXOP or indicate low-latency data to be transmitted) sent by each STA, including the first STA, at the same time should be consistent. In order to make the PPDUs sent by each STA consistent, each STA can use TB PPDU to ensure the consistency of the preamble, and each STA needs to use the same MCS and NSS, and the number of LTF symbols generated by each STA needs to be consistent. The MCS, NSS and LTF symbol number used by each STA can be determined by predefinition or pre-negotiation. The QAM value of each subcarrier of each LTF symbol generated by each STA also needs to be consistent. Therefore, secure-LTF needs to be generated by the same group key (such as GTK, IGTK, BIGTK or CGTK). Since the bandwidth occupied by the PPDUs sent by each STA to carry the first information may be different, the number of subcarriers of the secure-LTF corresponding to the PPDUs sent by each STA may also be different. In this case, the maximum bandwidth of the PPDU can be predefined (for example, set to 20 MHz) or pre-negotiated (for example, defaulting to the bandwidth of the preamble downlink PPDU sent by the AP). Each STA then generates and uses the same random sequence R based on the number of subcarriers within this maximum bandwidth. If a STA's bandwidth is smaller, it can discard a portion of the random sequence R. For example, a STA actually sends two secure-LTF symbols, each occupying 122 tones. If the predefined or pre-negotiated maximum bandwidth is 80 MHz (corresponding to each secure-LTF occupying 488 tones), the STA can use the first x bits of the random sequence R (for spatial stream phase adjustment) and the following 122 bits (for subcarrier QAM value adjustment) in the first secure-LTF symbol. The STA can then discard the next 366 bits of the random sequence R and use the next 122 bits of the random sequence R in the second secure-LTF symbol.

[0202] The AP may indicate the sequence number C in the preceding downlink frame and / or the downlink PPDU. The indication method of the sequence number C is similar to the PN indication method in Example 1 and will not be repeated here.

[0203] Example 4: AP distinguishes STAs that send preemption requests and / or low latency indications

[0204] To improve efficiency, the AP can identify the specific STA that sends the preemption request and / or low-latency indication. In this case, each STA needs to send a TB PPDU carrying the preemption request and / or low-latency indication in a different, pre-assigned or negotiated frequency domain and / or time domain. Accordingly, each STA sends the secure-LTF in a different, pre-agreed frequency domain and / or time domain.

[0205] Since there is no collision problem, secure-LTF can be generated by a group key (such as GTK, IGTK, BIGTK or CGTK) or a pairwise key (such as PTK or CPTK).

[0206] The AP may indicate the sequence number C in the preceding downlink frame and / or the SIG field of the downlink PPDU. The indication method of the sequence number C is similar to the PN indication method in Example 1 and will not be repeated here.

[0207] The first PPDU mentioned in the above embodiments can occupy part of the working bandwidth of the first STA, or it can occupy the entire working bandwidth of the first STA. That is, the first STA can use a PPDU that occupies the entire working bandwidth of the first STA to send the first information, or it can use a PPDU that only occupies part of the working bandwidth of the first STA to send the first information. If the second information is a secure-LTF and the first PPDU occupies the entire working bandwidth of the first STA, then the secure-LTF also occupies the entire working bandwidth of the first STA; if the second information is a secure-LTF and the first PPDU occupies part of the working bandwidth of the first STA, then the secure-LTF also occupies the corresponding part of the working bandwidth of the first STA.

[0208] According to the content of the section "Protection of MAC Frame Header and Control Frame", the relevant technology considers the protection of control frames with frame bodies. However, the relevant technology does not consider the protection of control frames without frame bodies. In many cases, if the control frames without frame bodies are not protected, the system may also be attacked. Therefore, the methods provided in the various embodiments above can be applied to the protection of control frames without frame bodies. The control frames without frame bodies mentioned here may include, for example, one or more of the following: RTS frame, CTS frame, contention free-end (CF-End) frame, acknowledgment (Ack) frame, power save poll (PS-Poll) frame. As an example, the MIC field mentioned above can be added to the above control frame. Alternatively, the LTF of the PPDU carrying the above control frame can be set to secure-LTF. For detailed description, please refer to the above and will not be repeated here.

[0209] The method embodiments of the present application are described in detail above, and the device embodiments of the present application are described in detail below. It should be understood that the description of the method embodiments corresponds to the description of the device embodiments, so for parts not described in detail, reference can be made to the above method embodiments.

[0210] Figure 34 is a schematic diagram of the structure of a communication device provided in one embodiment of the present application. The communication device 3400 shown in Figure 34 may be the first STA mentioned in each of the aforementioned embodiments. The communication device 3400 may include a first communication module 3410. The first communication module 3410 is configured to send a first PPDU to a second STA. The first PPDU includes first information and second information; the first information is used to preempt the second STA's transmission opportunity TXOP and / or indicate that the first STA contains low-latency data to be transmitted; and the second information is used to determine the legitimacy of the first STA.

[0211] In some implementations, the second information is generated based on a group key or a pairwise key.

[0212] In some implementations, the group key includes one or more of the following: GTK, IGTK, BIGTK, and CGTK.

[0213] In some implementations, the first PPDU occupies part or all of the working bandwidth of the first STA.

[0214] In some implementations, the first PPDU is used to carry a first MAC frame, and the second information is the MIC in the first MAC frame.

[0215] In some implementations, the first MAC frame includes a first FCS field, and the field corresponding to the MIC is located before or after the first FCS field.

[0216] In some implementations, the field corresponding to the MIC is located after the first FCS field, and the first MAC frame further includes a second FCS field, and the second FCS field is located after the field corresponding to the MIC.

[0217] In some implementations, the second information is a secure LTF in the first PPDU.

[0218] In some implementations, the second information is generated based on the first parameter; wherein the second information is a MIC and the first parameter is a packet sequence number, or the second information is a secure LTF and the first parameter is a sequence number.

[0219] In some implementations, the communication device 3400 also includes: a second communication module, used to receive a second PPDU sent by the second STA before the first STA sends a first PPDU to the second STA, the second PPDU including a target bit, and the target bit is part or all of the bits occupied by the first parameter.

[0220] In some implementations, the second PPDU is used to carry a second MAC frame, and the second MAC frame includes the target bit.

[0221] In some implementations, the second MAC frame includes an aggregation control field, and the target bit is carried in the aggregation control field.

[0222] In some implementations, the second MAC frame includes one or more special user information fields, and the target bit is carried in the one or more special user information fields.

[0223] In some implementations, the second MAC frame includes a general information field, the general information field includes third information, and the third information is used to indicate the number of the one or more special user information fields.

[0224] In some implementations, the second MAC frame is a trigger frame.

[0225] In some implementations, the second MAC frame is a data frame, a control frame, or a management frame.

[0226] In some implementations, the communication device 3400 also includes: a third communication module, used to receive a third MAC frame sent by the second STA before the first STA sends the first PPDU to the second STA, and the third MAC frame includes other bits of the bits occupied by the first parameter except the target bit.

[0227] In some implementations, the third MAC frame is a beacon frame; or, both the third MAC frame and the second MAC frame are carried in the second PPDU.

[0228] In some implementations, the target bits include the M least significant bits of the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

[0229] In some implementations, the second PPDU includes a SIG field, and the target bit is carried in the SIG field.

[0230] In some implementations, the user-specific field of the SIG field includes one or more special user fields, and the target information is carried in the one or more special user fields.

[0231] In some implementations, the SIG field includes a general field, the general field includes fourth information, and the fourth information is used to indicate the number of the one or more special user fields.

[0232] In some implementations, the general field includes an ignore field, and the fourth information is carried in the ignore field.

[0233] In some implementations, the communication device 3400 further includes: a fourth communication module, configured to receive a fourth MAC frame sent by the second STA before the first STA sends the first PPDU to the second STA, the fourth MAC frame including other bits of the bits occupied by the first parameter except the target bit.

[0234] In some implementations, the fourth MAC frame is a beacon frame.

[0235] In some implementations, the target bits include the M least significant bits of the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

[0236] In some implementations, the second STA is an access point.

[0237] Figure 35 is a schematic diagram of the structure of a communication device provided by an embodiment of the present application. The communication device 3500 shown in Figure 35 can be the second STA mentioned in the various embodiments above. The communication device 3500 may include a first communication module 3510. The first communication module 3510 is used to receive a first physical protocol data unit (PPDU) sent by a first STA, where the first PPDU includes first information and second information; wherein the first information is used to preempt the transmission opportunity TXOP of the second STA and / or indicate that the first STA contains low-latency data to be transmitted; and the second information is used to determine the legitimacy of the first STA.

[0238] In some implementations, the second information is generated based on a group key or a pairwise key.

[0239] In some implementations, the group key includes one or more of the following: GTK, IGTK, BIGTK, and CGTK.

[0240] In some implementations, the first PPDU occupies part or all of the working bandwidth of the first STA.

[0241] In some implementations, the first PPDU is used to carry a first MAC frame, and the second information is the MIC in the first MAC frame.

[0242] In some implementations, the first MAC frame includes a first FCS field, and the field corresponding to the MIC is located before or after the first FCS field.

[0243] In some implementations, the field corresponding to the MIC is located after the first FCS field, and the first MAC frame further includes a second FCS field, and the second FCS field is located after the field corresponding to the MIC.

[0244] In some implementations, the second information is a secure LTF in the first PPDU.

[0245] In some implementations, the second information is generated based on the first parameter; wherein the second information is a MIC and the first parameter is a packet sequence number, or the second information is a secure LTF and the first parameter is a sequence number.

[0246] In some implementations, the communication device 3500 further includes: a second communication module, configured to send a second PPDU to the first STA before the second STA receives the first PPDU sent by the first STA, wherein the second PPDU includes a target bit, and the target bit is part or all of the bits occupied by the first parameter.

[0247] In some implementations, the second PPDU is used to carry a second MAC frame, and the second MAC frame includes the target bit.

[0248] In some implementations, the second MAC frame includes an aggregation control field, and the target bit is carried in the aggregation control field.

[0249] In some implementations, the second MAC frame includes one or more special user information fields, and the target bit is carried in the one or more special user information fields.

[0250] In some implementations, the second MAC frame includes a general information field, the general information field includes third information, and the third information is used to indicate the number of the one or more special user information fields.

[0251] In some implementations, the second MAC frame is a trigger frame.

[0252] In some implementations, the second MAC frame is a data frame, a control frame, or a management frame.

[0253] In some implementations, the communication device 3500 also includes: a third communication module, used to send a third MAC frame to the second STA before the second STA receives the first PPDU sent by the first STA, and the third MAC frame includes other bits of the bits occupied by the first parameter except the target bit.

[0254] In some implementations, the third MAC frame is a beacon frame; or, both the third MAC frame and the second MAC frame are carried in the second PPDU.

[0255] In some implementations, the target bits include the M least significant bits of the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

[0256] In some implementations, the second PPDU includes a SIG field, and the target bit is carried in the SIG field.

[0257] In some implementations, the user-specific field of the SIG field includes one or more special user fields, and the target information is carried in the one or more special user fields.

[0258] In some implementations, the SIG field includes a general field, the general field includes fourth information, and the fourth information is used to indicate the number of the one or more special user fields.

[0259] In some implementations, the general field includes an ignore field, and the fourth information is carried in the ignore field.

[0260] In some implementations, the communication device 3500 further includes: a fourth communication module, configured to send a fourth MAC frame to the first STA before the second STA receives the first PPDU sent by the first STA, the fourth MAC frame including other bits of the bits occupied by the first parameter except the target bit.

[0261] In some implementations, the fourth MAC frame is a beacon frame.

[0262] In some implementations, the target bits include the M least significant bits of the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

[0263] In some implementations, the second STA is an access point.

[0264] Figure 36 is a schematic block diagram of a communication device according to an embodiment of the present application. The dashed lines in Figure 36 indicate that the unit or module is optional. The device 3600 can be used to implement the method described in the above method embodiment. The device 3600 can be a chip or a communication device.

[0265] The device 3600 may include one or more processors 3610. The processor 3610 may support the device 3600 to implement the method described in the method embodiment above. The processor 3610 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be another general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0266] The apparatus 3600 may further include one or more memories 3620. The memories 3620 store programs that can be executed by the processor 3610, causing the processor 3610 to perform the methods described in the above method embodiments. The memories 3620 may be independent of the processor 3610 or integrated into the processor 3610.

[0267] The apparatus 3600 may further include a transceiver 3630. The processor 3610 may communicate with other devices or chips via the transceiver 3630. For example, the processor 3610 may transmit and receive data with other devices or chips via the transceiver 3630.

[0268] The present invention also provides a computer-readable storage medium for storing a program. The computer-readable storage medium can be applied to the communication device provided in the present invention, and the program enables a computer to execute the method performed by the communication device in each embodiment of the present invention.

[0269] The present application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to the communication device provided in the present application, and the program causes a computer to execute the method performed by the communication device in each embodiment of the present application.

[0270] The embodiments of the present application also provide a computer program. The computer program can be applied to the terminal or network device provided in the embodiments of the present application, and the computer program enables a computer to execute the method performed by the communication device in each embodiment of the present application.

[0271] It should be understood that the terms "system" and "network" in this application can be used interchangeably. In addition, the terms used in this application are only used to explain the specific embodiments of this application and are not intended to limit this application. The terms "first", "second", "third", and "fourth" in the specification and claims of this application and the accompanying drawings are used to distinguish different objects rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

[0272] In the embodiments of this application, the term "indication" may refer to a direct indication, an indirect indication, or an indication of an association. For example, "A indicates B" may refer to a direct indication of B, e.g., B can obtain information through A; it may refer to an indirect indication of B, e.g., A indicates C, e.g., B can obtain information through C; or it may refer to an association between A and B.

[0273] In the embodiment of the present application, "B corresponding to A" means that B is associated with A and B can be determined based on A. However, it should be understood that determining B based on A does not mean determining B based solely on A, but B can also be determined based on A and / or other information.

[0274] In the embodiments of the present application, the term "corresponding" may indicate a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship between indication and indication, configuration and configuration, etc.

[0275] In the embodiments of the present application, "pre-definition" or "pre-configuration" may be implemented by pre-storing corresponding codes, tables, or other methods that can be used to indicate relevant information in a device (e.g., a terminal device and a network device). The present application does not limit the specific implementation method. For example, pre-definition may refer to information defined in a protocol.

[0276] In the embodiments of this application, the term "and / or" is simply a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0277] In the embodiments of this application, the term "include" can refer to direct inclusion or indirect inclusion. Alternatively, the term "include" in the embodiments of this application can be replaced with "indicates" or "is used to determine." For example, "A includes B" can be replaced with "A indicates B" or "A is used to determine B."

[0278] In various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0279] In the embodiments of the present application, the “protocol” may refer to a standard protocol in the communication field, for example, it may include a WiFi protocol and related protocols used in future WiFi communication systems, and the present application does not limit this.

[0280] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0281] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0282] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0283] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0284] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A wireless communication method, characterized in that, Including: A first station STA sends a first Physical Protocol Data Unit (PPDU) to a second STA, where the first PPDU includes first information and second information; Among them, the first information is used to preempt the transmission opportunity (TXOP) of the second STA and / or indicate that the first STA includes low-latency data to be transmitted; The second information is used to determine the legitimacy of the first STA.

2. The method according to claim 1, wherein The second information is generated based on a group key or a pairwise key.

3. The method according to claim 2, characterized in that, The group key includes one or more of the following: Group Temporal Key (GTK), Integrity Group Temporal Key (IGTK), Beacon Integrity Group Temporal Key (BIGTK), and Control Group Temporal Key (CGTK).

4. The method according to any one of claims 1 to 3, characterized in that, The first PPDU occupies part or all of the working bandwidth of the first STA.

5. The method according to any one of claims 1 to 4, characterized in that, The first PPDU is used to carry a first Media Access Control (MAC) frame, and the second information is the Message Integrity Code (MIC) in the first MAC frame.

6. The method according to claim 5, characterized in that, The first MAC frame includes a first Frame Check Sequence (FCS) field, and the field corresponding to the MIC is before or after the first FCS field.

7. The method according to claim 6, characterized in that, The field corresponding to the MIC is after the first FCS field, and the first MAC frame further includes a second FCS field, and the second FCS field is after the field corresponding to the MIC.

8. The method according to any one of claims 1 to 4, characterized in that, The second information is the Secure Long Training Field (LTF) in the first PPDU.

9. The method according to any one of claims 1 to 8, characterized in that, The second information is generated based on a first parameter; where the second information is the MIC and the first parameter is the packet sequence number, or the second information is the secure LTF and the first parameter is the sequence number.

10. The method according to claim 9, wherein Before the first STA sends the first PPDU to the second STA, the method further includes: The first STA receives a second PPDU sent by the second STA, where the second PPDU includes target bits, and the target bits are part or all of the bits occupied by the first parameter.

11. The method according to claim 10, characterized in that, The second PPDU is used to carry a second MAC frame, and the second MAC frame contains the target bits.

12. The method according to claim 11, wherein The second MAC frame includes an aggregation control field, and the target bits are carried in the aggregation control field.

13. The method according to claim 11, wherein The second MAC frame includes one or more special user information fields, and the target bits are carried in the one or more special user information fields.

14. The method according to claim 13, wherein The second MAC frame includes a general information field, and the general information field includes third information, and the third information is used to indicate the number of the one or more special user information fields.

15. The method according to claim 13 or 14, characterized in that, The second MAC frame is a trigger frame.

16. The method according to claim 11, wherein The second MAC frame is a data frame, a control frame, or a management frame.

17. The method according to any one of claims 11 to 16, characterized in that, Before the first STA sends the first PPDU to the second STA, the method further includes: The first STA receives a third MAC frame sent by the second STA, and the third MAC frame contains other bits of the bits occupied by the first parameter except the target bits.

18. The method according to claim 17, wherein The third MAC frame is a beacon frame; or both the third MAC frame and the second MAC frame are carried in the second PPDU.

19. The method according to any one of claims 10 to 18, characterized in that, The target bits include M least significant bits among the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

20. The method according to claim 10, characterized in that, The second PPDU includes a SIGNAL SIG field, and the target bits are carried in the SIG field.

21. The method according to claim 20, wherein The user-specific field of the SIG field includes one or more special user fields, and the target information is carried in the one or more special user fields.

22. The method according to claim 21, wherein, The SIG field includes a common field, and the common field includes fourth information for indicating the number of the one or more special user fields.

23. The method according to claim 22, wherein The common field includes an ignore field, and the fourth information is carried in the ignore field.

24. The method according to any one of claims 20 to 23, characterized in that, Before the first STA sends a first PPDU to a second STA, the method further includes: The first STA receives a fourth MAC frame sent by the second STA, and the fourth MAC frame includes other bits among the bits occupied by the first parameter except the target bits.

25. The method according to claim 24, wherein The fourth MAC frame is a beacon frame.

26. The method according to claim 24 or 25, characterized in that, The target bits include M least significant bits among the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

27. The method according to any one of claims 1 to 26, characterized in that, The second STA is an access point.

28. A wireless communication method, characterized in that, Including: A second station STA receives a first physical protocol data unit PPDU sent by a first STA, and the first PPDU includes first information and second information; Wherein, the first information is used to preempt the transmission opportunity TXOP of the second STA and / or indicate that the first STA includes low-latency data to be transmitted; The second information is used to determine the legitimacy of the first STA.

29. The method according to claim 28, wherein The second information is generated based on a group key or a pairwise key.

30. The method according to claim 30, wherein The group key includes one or more of the following: group temporal key GTK, integrity group temporal key IGTK, beacon integrity group temporal key BIGTK, and control group temporal key CGTK.

31. The method according to any one of claims 28 to 30, characterized in that, The first PPDU occupies part or all of the working bandwidth of the first STA.

32. The method according to any one of claims 28 to 31, characterized in that, The first PPDU is used to carry a first media access control MAC frame, and the second information is the message integrity code MIC in the first MAC frame.

33. The method according to claim 32, wherein The first MAC frame includes a first frame control sequence FCS field, and the field corresponding to the MIC is before or after the first FCS field.

34. The method according to claim 33, wherein The field corresponding to the MIC is after the first FCS field, and the first MAC frame further includes a second FCS field, and the second FCS field is after the field corresponding to the MIC.

35. The method according to any one of claims 28 to 31, characterized in that, The second information is the secure long training field LTF in the first PPDU.

36. The method according to any one of claims 28 to 35, characterized in that, The second information is generated based on a first parameter; wherein, the second information is MIC and the first parameter is a packet sequence number, or the second information is a secure LTF and the first parameter is a sequence number.

37. The method according to claim 36, wherein, Before the second STA receives the first PPDU sent by the first STA, the method further includes: The second STA sends a second PPDU to the first STA, and the second PPDU includes target bits, and the target bits are part or all of the bits occupied by the first parameter.

38. The method according to claim 37, characterized in that, The second PPDU is used to carry a second MAC frame, and the second MAC frame contains the target bit.

39. The method according to claim 38, wherein The second MAC frame includes an aggregation control field, and the target bit is carried in the aggregation control field.

40. The method according to claim 38, wherein The second MAC frame includes one or more special user information fields, and the target bit is carried in the one or more special user information fields.

41. The method according to claim 40, characterized in that, The second MAC frame includes a general information field, and the general information field includes third information for indicating the number of the one or more special user information fields.

42. The method according to claim 40 or 41, characterized in that, The second MAC frame is a trigger frame.

43. The method according to claim 38, wherein The second MAC frame is a data frame, a control frame, or a management frame.

44. The method according to any one of claims 38 to 43, characterized in that, Before the second STA receives a first PPDU sent by a first STA, the method further includes: The second STA sends a third MAC frame to the second STA, and the third MAC frame contains other bits of the bits occupied by the first parameter except the target bit.

45. The method according to claim 44, characterized in that, The third MAC frame is a beacon frame; or, both the third MAC frame and the second MAC frame are carried in the second PPDU.

46. The method according to any one of claims 37 to 45, characterized in that, The target bit includes M least significant bits of the bits occupied by the first parameter, and M is a positive integer greater than or equal to 1.

47. The method according to claim 37, wherein, The second PPDU includes a signal SIG field, and the target bit is carried in the SIG field.

48. The method according to claim 47, wherein The user-specific field of the SIG field includes one or more special user fields, and the target information is carried in the one or more special user fields.

49. The method according to claim 48, wherein The SIG field includes a general field, and the general field includes fourth information for indicating the number of the one or more special user fields.

50. The method according to claim 49, characterized in that, The general field includes an ignored field, and the fourth information is carried in the ignored field.

51. The method according to any one of claims 47 to 50, characterized in that, Before the second STA receives a first PPDU sent by a first STA, the method further includes: The second STA sends a fourth MAC frame to the first STA, and the fourth MAC frame contains other bits of the bits occupied by the first parameter except the target bit.

52. The method according to claim 51, wherein, The fourth MAC frame is a beacon frame.

53. The method according to claim 51 or 52, characterized in that, The target bit includes M least significant bits of the bits occupied by the first parameter, and M is a positive integer greater than or equal to 1.

54. The method according to any one of claims 28 to 53, characterized in that, The second STA is an access point.

55. A communication device, characterized in that, The communication device is a first station STA, and the communication device includes: A first communication module for sending a first physical protocol data unit PPDU to a second STA, where the first PPDU includes first information and second information; Wherein, the first information is used to preempt the transmission opportunity TXOP of the second STA and / or indicate that the first STA includes low-latency data to be transmitted; the second information is used to determine the legitimacy of the first STA.

56. The communication device according to claim 55, wherein, The second information is generated based on a group key or a pairwise key.

57. The communication device according to claim 56, wherein, The group key includes one or more of the following: group temporary key GTK, integrity group temporary key IGTK, beacon integrity group temporary key BIGTK, and control group temporary key CGTK.

58. The communication device according to any one of claims 55 to 57, characterized in that, The first PPDU occupies part or all of the working bandwidth of the first STA.

59. The communication device according to any one of claims 55 to 58, characterized in that, The first PPDU is used to carry a first Media Access Control (MAC) frame, and the second information is a Message Integrity Code (MIC) in the first MAC frame.

60. The communication device according to claim 59, wherein, The first MAC frame includes a first Frame Check Sequence (FCS) field, and the field corresponding to the MIC is located before or after the first FCS field.

61. The communication device according to claim 60, characterized in that, The field corresponding to the MIC is located after the first FCS field, and the first MAC frame further includes a second FCS field, which is located after the field corresponding to the MIC.

62. The communication device according to any one of claims 55 to 58, characterized in that, The second information is a Secure Long Training Field (LTF) in the first PPDU.

63. The communication device according to any one of claims 55 to 62, characterized in that, The second information is generated based on a first parameter; wherein, when the second information is the MIC, the first parameter is a packet sequence number, or when the second information is the secure LTF, the first parameter is a sequence number.

64. The communication device according to claim 63, characterized in that, The communication device further includes: A second communication module, configured to receive a second PPDU sent by the second STA before the first STA sends the first PPDU to the second STA. The second PPDU includes target bits, and the target bits are part or all of the bits occupied by the first parameter.

65. The communication device according to claim 64, characterized in that, The second PPDU is used to carry a second MAC frame, and the second MAC frame contains the target bits.

66. The communication device according to claim 65, characterized in that, The second MAC frame includes an aggregation control field, and the target bits are carried in the aggregation control field.

67. The communication device according to claim 65, characterized in that, The second MAC frame includes one or more special user information fields, and the target bits are carried in the one or more special user information fields.

68. The communication device according to claim 67, wherein The second MAC frame includes a general information field, and the general information field includes third information for indicating the number of the one or more special user information fields.

69. The communication device according to claim 67 or 68, characterized in that, The second MAC frame is a trigger frame.

70. The communication device according to claim 65, wherein, The second MAC frame is a data frame, a control frame, or a management frame.

71. The communication device according to any one of claims 65 to 70, characterized in that, The communication device further includes: A third communication module, configured to receive a third MAC frame sent by the second STA before the first STA sends the first PPDU to the second STA. The third MAC frame contains other bits of the bits occupied by the first parameter except the target bits.

72. The communication device according to claim 71, wherein The third MAC frame is a beacon frame; or both the third MAC frame and the second MAC frame are carried in the second PPDU.

73. The communication device according to any one of claims 64 to 72, characterized in that, The target bits include the M least significant bits of the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

74. The communication device according to claim 64, wherein The second PPDU includes a Signal (SIG) field, and the target bits are carried in the SIG field.

75. The communication device according to claim 74, wherein The user-specific field of the SIG field includes one or more special user fields, and the target information is carried in the one or more special user fields.

76. The communication device according to claim 75, wherein, The SIG field includes a general field, and the general field includes fourth information for indicating the number of the one or more special user fields.

77. The communication device according to claim 76, characterized in that, The general field includes an ignore field, and the fourth information is carried in the ignore field.

78. The communication device according to any one of claims 74 to 77, characterized in that, The communication device further includes: A fourth communication module, configured to receive a fourth MAC frame sent by the second STA before the first STA sends a first PPDU to the second STA, where the fourth MAC frame includes other bits except the target bit among the bits occupied by the first parameter.

79. The communication device according to claim 78, characterized in that, The fourth MAC frame is a beacon frame.

80. The communication device according to claim 78 or 79, characterized in that, The target bit includes M least significant bits among the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

81. The communication device according to any one of claims 55 to 80, characterized in that, The second STA is an access point.

82. A communication device, characterized in that, The communication device is a second station STA, and the communication device includes: A first communication module, configured to receive a first physical protocol data unit PPDU sent by the first STA, where the first PPDU includes first information and second information; Wherein, the first information is used to preempt the transmission opportunity TXOP of the second STA and / or indicate that the first STA includes low-latency data to be transmitted; the second information is used to determine the legitimacy of the first STA.

83. The communication device according to claim 82, characterized in that, The second information is generated based on a group key or a pairwise key.

84. The communication device according to claim 83, characterized in that, The group key includes one or more of the following: group temporary key GTK, integrity group temporary key IGTK, beacon integrity group temporary key BIGTK, and control group temporary key CGTK.

85. The communication device according to any one of claims 82 to 84, characterized in that, The first PPDU occupies part or all of the working bandwidth of the first STA.

86. The communication device according to any one of claims 82 to 85, characterized in that, The first PPDU is used to carry a first media access control MAC frame, and the second information is a message integrity code MIC in the first MAC frame.

87. The communication device according to claim 86, characterized in that, The first MAC frame includes a first frame control sequence FCS field, and the field corresponding to the MIC is located before or after the first FCS field.

88. The communication device according to claim 87, characterized in that, The field corresponding to the MIC is located after the first FCS field, and the first MAC frame further includes a second FCS field, and the second FCS field is located after the field corresponding to the MIC.

89. The communication device according to any one of claims 82 to 85, characterized in that, The second information is a secure long training field LTF in the first PPDU.

90. The communication device according to any one of claims 82 to 89, characterized in that, The second information is generated based on a first parameter; wherein, the second information is MIC, and the first parameter is a packet sequence number, or the second information is a secure LTF, and the first parameter is a sequence number.

91. The communication device according to claim 90, characterized in that, The communication device further includes: A second communication module, configured to send a second PPDU to the first STA before the second STA receives the first PPDU sent by the first STA, where the second PPDU includes a target bit, and the target bit is part or all of the bits occupied by the first parameter.

92. The communication device according to claim 91, wherein The second PPDU is used to carry a second MAC frame, and the second MAC frame includes the target bit.

93. The communication device according to claim 92, characterized in that, The second MAC frame includes an aggregation control field, and the target bit is carried in the aggregation control field.

94. The communication device according to claim 92, wherein, The second MAC frame includes one or more special user information fields, and the target bit is carried in the one or more special user information fields.

95. The communication device according to claim 94, characterized in that, The second MAC frame includes a general information field, and the general information field includes third information, and the third information is used to indicate the number of the one or more special user information fields.

96. The communication device according to claim 94 or 95, characterized in that, The second MAC frame is a trigger frame.

97. The communication device according to claim 92, wherein The second MAC frame is a data frame, a control frame, or a management frame.

98. The communication device according to any one of claims 92 to 97, characterized in that, The communication device further includes: A third communication module, configured to send a third MAC frame to the second STA before the second STA receives a first PPDU sent by a first STA, where the third MAC frame includes other bits of the bits occupied by the first parameter except the target bit.

99. The communication device according to claim 98, characterized in that, The third MAC frame is a beacon frame; or, both the third MAC frame and the second MAC frame are carried in the second PPDU.

100. The communication device according to any one of claims 91 to 99, characterized in that, The target bit includes M least significant bits of the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

101. The communication device according to claim 98, characterized in that, The second PPDU includes a signal SIG field, and the target bit is carried in the SIG field.

102. The communication device according to claim 101, characterized in that, The user-specific field of the SIG field includes one or more special user fields, and the target information is carried in the one or more special user fields.

103. The communication device according to claim 102, characterized in that, The SIG field includes a common field, and the common field includes fourth information for indicating the number of the one or more special user fields.

104. The communication device according to claim 103, wherein The common field includes an ignored field, and the fourth information is carried in the ignored field.

105. The communication device according to any one of claims 101 to 104, characterized in that, The communication device further includes: A fourth communication module, configured to send a fourth MAC frame to the first STA before the second STA receives a first PPDU sent by the first STA, where the fourth MAC frame includes other bits of the bits occupied by the first parameter except the target bit.

106. The communication device according to claim 105, characterized in that, The fourth MAC frame is a beacon frame.

107. The communication device according to claim 105 or 106, characterized in that, The target bit includes M least significant bits of the bits occupied by the first parameter, where M is a positive integer greater than or equal to 1.

108. The communication device according to any one of claims 82 to 107, characterized in that, The second STA is an access point.

109. A communication device, characterized in that, It includes a memory and a processor, where the memory is used to store a program, and the processor is used to call the program in the memory so that the communication device executes the method according to any one of claims 1-27 or 28-54.

110. A device, characterized in that, It includes a processor, configured to call a program from a memory so that the device executes the method according to any one of claims 1-27 or 28-54.

111. A chip, characterized in that, It includes a processor, configured to call a program from a memory so that a device installed with the chip executes the method according to any one of claims 1-27 or 28-54.

112. A computer-readable storage medium, characterized in that, A program is stored thereon, and the program causes a computer to execute the method according to any one of claims 1-27 or 28-54.

113. A computer program product, characterized in that, It includes a program, and the program causes a computer to execute the method according to any one of claims 1-27 or 28-54.

114. A computer program, characterized in that, The computer program causes a computer to execute the method according to any one of claims 1-27 or 28-54.

Images