Control frame security protection in wireless networks

Abstract

An embodiment is a method performed by a wireless device for securing a control frame. The method includes generating a control frame, wherein the control frame includes a Key ID field and a Message Integrity Check (MIC) field, the Key ID field appearing before at least one field included in a body of the control frame, the MIC field appearing after the at least one field, wherein the Key ID field carries a Key ID and a packet number, wherein the MIC field carries an authentication value for checking integrity of the control frame. The method further includes transmitting the control frame.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 556,849, filed February 22, 2024, which is incorporated herein by reference. Technical Field

[0003] This disclosure relates generally to wireless communications, and more specifically to the security protection of control frames in wireless networks. Background Technology

[0004] The Institute of Electrical and Electronics Engineers (IEEE) 802.11 is a set of standards for enabling wireless local area network (WLAN) communication at various frequencies, including but not limited to the 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz bands. These standards define the protocols that enable Wi-Fi devices to communicate with each other. The IEEE 802.11 family of standards has evolved over time to accommodate higher data rates, improved security, and better performance in different environments. Some of the most widely used standards include 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, and 802.11ax (also known as “Wi-Fi 6”). These standards specify modulation techniques, channel bandwidth, and other technical aspects that facilitate interoperability between devices from different manufacturers. IEEE 802.11 has played a significant role in the widespread adoption of wireless networking in homes, offices, and public places, enabling users to connect their devices to the internet and to each other without a wired connection.

[0005] IEEE 802.11be (also known as "Wi-Fi 7") is the next-generation standard of the IEEE 802.11 family of standards for wireless local area networks. Currently under development, 802.11be aims to significantly improve upon its predecessor, 802.11ax / Wi-Fi 6, by providing even higher data rates, lower latency, and greater reliability. The standard is expected to leverage advanced technologies such as Multi-Link Operation (MLO), which allows devices to use multiple frequency bands and channels simultaneously to enhance performance and reliability. Furthermore, 802.11be will introduce 4096-QAM (Quadrature Amplitude Modulation), achieving higher data rates by encoding more bits per symbol. The standard will also feature improved Media Access Control (MAC) efficiency, enhanced energy efficiency, and better support for high-density environments. With these advancements, 802.11be is expected to offer a theoretical maximum data rate of up to 46 gigabits per second (Gbps), making it suitable for bandwidth-intensive applications such as virtual and augmented reality, 8K video streaming, and high-performance gaming. The IEEE 802.11be standard is expected to be finalized by the end of 2024, paving the way for next-generation Wi-Fi devices and networks.

[0006] An access point (AP) can send a trigger frame to a non-AP station (STA) to request simultaneous uplink transmission from that STA. The trigger frame can include resource allocation information for STAs participating in the uplink transmission. A STA that receives the trigger frame and has been allocated resources can respond by sending a trigger-based physical layer protocol data unit (TB PPDU) to the AP after a short inter-frame interval (SIFS) following the receipt of the trigger frame. Since the AP can use trigger frames to control the behavior of multiple STAs, it is important to secure these trigger frames. For example, it is important that the STA receiving the trigger frame can verify its integrity. However, existing wireless networking standards do not provide mechanisms for securing trigger frames.

[0007] Existing wireless networking standards use the Broadcast Integrity Protocol (BIP) to secure group-addressed management frames. BIP adds a Management Message Integrity Verification (MIC) element, carrying the security material required to perform integrity checks, to the end of the frame body field. The security material may include a key ID, a packet number (PN), and a Message Integrity Verification (MIC) authentication value.

[0008] One way to secure trigger frames is to apply BIP (Block Integrity Verification) to them. For example, an authentication value can be generated for the portion of the trigger frame that needs security protection, and this authentication value, along with other security material required to verify the integrity of the trigger frame (e.g., key ID and block number), can be appended to the end of the trigger frame. However, this approach is not suitable for trigger frames because the BIP integrity verification process can be too time-consuming, preventing the STA from sending the TBPPDU within the required timeframe (e.g., if a TBPPDU needs to be sent after a SIFS interval following the receipt of the trigger frame). Therefore, a method is needed to minimize / reduce the time delay in verifying the integrity of trigger frames so that the STA receiving the trigger frame can send the TBPPDU within the required timeframe. Attached Figure Description

[0009] This disclosure will be more fully understood from the detailed description provided below and the accompanying drawings depicting various embodiments of the present disclosure. However, these drawings should not be construed as limiting the disclosure to the specific embodiments shown; they are provided for illustration and understanding only.

[0010] Figure 1 Examples of wireless local area networks (WLANs) having a basic set of services (BSS) including multiple wireless devices are shown according to some embodiments of the present disclosure.

[0011] Figure 2 This is a schematic diagram of a wireless device according to some embodiments of the present disclosure.

[0012] Figure 3A Components of a wireless device configured to transmit data according to some embodiments of the present disclosure are shown.

[0013] Figure 3B Components of a wireless device configured to receive data according to some embodiments of the present disclosure are shown.

[0014] Figure 4 Inter-frame spacing (IFS) relationships according to some embodiments of this disclosure are shown.

[0015] Figure 5 A frame transmission process based on Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) according to some embodiments of this disclosure is illustrated.

[0016] Figure 6 The maximum physical layer (PHY) rate of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard is shown according to some embodiments of this disclosure.

[0017] Figure 7Detailed descriptions of fields in Extremely High Throughput (EHT) Physical Layer Protocol Data Unit (PPDU) frames according to some embodiments of this disclosure are provided, including the purpose and characteristics of the fields.

[0018] Figure 8 Examples of multi-user (MU) transmission in orthogonal frequency division multiple access (OFDMA) according to some embodiments of the present disclosure are shown.

[0019] Figure 9 An example is shown whereby an access point according to some embodiments of the present disclosure sends a trigger frame to a plurality of associated stations and receives an uplink orthogonal frequency division multiple access trigger-based physical layer protocol data unit (UL OFDMA TB PPDU) in response.

[0020] Figure 10 This is a schematic diagram illustrating the format of a Media Access Control Protocol Data Unit (MPDU) with an unencrypted frame body field according to some embodiments.

[0021] Figure 11 This is a schematic diagram illustrating the format of an MPDU with an encrypted frame body field according to some embodiments.

[0022] Figure 12 This is a schematic diagram illustrating how Additional Authentication Data (AAD) is generated according to some embodiments.

[0023] Figure 13 This is a schematic diagram illustrating the format of a frame control field according to some embodiments.

[0024] Figure 14 This is a schematic diagram illustrating the format of a sequence control field according to some embodiments.

[0025] Figure 15 This is a schematic diagram illustrating the format of a management frame according to some embodiments.

[0026] Figure 16 This is a schematic diagram illustrating the format of a management MIC element according to some embodiments.

[0027] Figure 17 This is a schematic diagram illustrating how Additional Authentication Data (AAD) is generated in the Broadcast Integrity Protocol (BIP) according to some embodiments.

[0028] Figure 18 This is a schematic diagram illustrating the format of a trigger frame according to some embodiments.

[0029] Figure 19 This is a schematic diagram illustrating the format of a user information field according to some embodiments.

[0030] Figure 20This is a schematic diagram illustrating the format of a special user information field according to some embodiments.

[0031] Figure 21 This is a schematic diagram illustrating the format of an AAD that can be used to securely protect trigger frames according to some embodiments.

[0032] Figure 22 This is a schematic diagram illustrating the format of a protected trigger frame according to some embodiments.

[0033] Figure 23 This is a schematic diagram illustrating the format of a key ID user information field according to some embodiments.

[0034] Figure 24 This is a schematic diagram illustrating the format of the Message Integrity Verification (MIC) user information field when the length of the authentication value is 64 bits, according to some embodiments.

[0035] Figure 25 This is a schematic diagram illustrating the format of the MIC user information field when the length of the authentication value is 128 bits, according to some embodiments.

[0036] Figure 26 This is a flowchart of a method for security protection of control frames according to some embodiments.

[0037] Figure 27 This is a flowchart of a method for verifying the integrity of control frames according to some embodiments. Detailed Implementation

[0038] This disclosure relates generally to wireless communications, and more specifically to the security protection of control frames (e.g., trigger frames) in wireless networks.

[0039] The Broadcast Integrity Protocol (BIP) can be used to secure group-addressed management frames. The security materials required for integrity checks in BIP are a key ID, a packet number (PN), and a Message Integrity Verification (MIC) authentication value (which may also be referred to as the "authentication value" in this document). In BIP, these security materials are carried in a management MIC element appended to the end of the frame body field.

[0040] As mentioned above, existing wireless networking standards do not provide a mechanism for securing trigger frames. One way to secure trigger frames is to apply BIP (Block Integrity Check) to them. However, for trigger frames, the receiver needs to be able to perform integrity checks quickly because it must send a trigger-based Physical Layer Protocol Data Unit (TB PPDU) after receiving the trigger frame, through a Short Interframe Space (SIFS). The receiver needs to obtain a key ID to obtain the cryptographic key required to generate and verify the authentication value. Furthermore, the receiver needs to obtain a PN (Proof Node) to begin generating the authentication value. Therefore, if, as in BIP, the key ID and PN appear near the end of the trigger frame, authentication value generation can only begin after the entire or nearly all of the trigger frame has been received. In this case, the receiver may not be able to perform integrity checks quickly enough to send the TB PPDU within the required timeframe (e.g., after one SIFS interval after receiving the trigger frame). To address this issue, this paper describes a technique that enables the receiver to begin the integrity check process early in the trigger frame reception process, allowing the receiver to complete the integrity check in a timely manner to send the TB PPDU within the required timeframe. The technique described in this paper achieves this by providing the key ID and PN near the beginning of the trigger frame. This allows the receiver to initiate the security engine and begin the integrity verification process (e.g., identify the key early) while still receiving the trigger frame. Although this paper primarily describes the technique in the context of securing trigger frames, similar approaches can be used to secure other types of control frames, particularly those requiring an immediate response from the receiver.

[0041] This document describes techniques for securing control frames. According to some embodiments, a transmitting wireless device can generate a control frame. The control frame may include a key ID field preceding at least one field included in the body of the control frame. The key ID field may carry a key ID and a PN. Furthermore, the control frame may include a MIC field following at least one field. The MIC field may carry an authentication value that can be used to verify the integrity of the control frame. The transmitting wireless device can then transmit the control frame.

[0042] The receiving wireless device can receive control frames. It can extract the key ID and PN from the key ID field of the control frame and begin the integrity verification process. Subsequently, the receiving wireless device can extract the authentication value from the MIC field of the control frame. Then, the receiving wireless device can use the key ID, PN, and authentication value to verify the integrity of the control frame. If the integrity verification is successful, the receiving wireless device can send a response frame to the sending wireless device.

[0043] In one embodiment, the control frame is a trigger frame. In this case, at least one field may include user information (also referred to as the "user information" field). The key ID field may include two key ID user information fields. The key ID user information fields may have a similar format to the user information fields to ensure compatibility with legacy wireless devices implementing previous wireless networking standards. The MIC field may include three or five MIC user information fields. The MIC user information fields may have a similar format to the user information fields to ensure compatibility with legacy wireless devices implementing previous wireless networking standards.

[0044] The techniques described herein can provide one or more advantages. For example, the techniques described herein can provide security for control frames. The receiver of a control frame can be able to initiate the integrity verification process of the control frame earlier (e.g., while still receiving the control frame), which allows the receiver to respond to the control frame immediately within the required time (e.g., after a SIFS interval following the receipt of the control frame). Although some advantages are mentioned herein, those skilled in the art will understand from this disclosure that the techniques described herein can have other advantages.

[0045] For illustrative purposes, this document describes various embodiments within the context of wireless networks based on the IEEE 802.11 standard and using its terminology and concepts. Those skilled in the art will understand that the embodiments disclosed herein can be modified / adapted for use with other types of wireless networks.

[0046] In the following detailed description, certain embodiments of the invention are shown and described by way of illustration only. Those skilled in the art will recognize that the described embodiments can be modified in different ways without departing from the spirit or scope of the invention. Therefore, the drawings and descriptions should be considered illustrative in nature and not restrictive. Throughout the specification, the same reference numerals denote the same elements.

[0047] Figure 1A wireless local area network (WLAN) 100 with a basic service set (BSS) 102 is illustrated, which includes multiple wireless devices 104 (sometimes referred to as WLAN devices 104). Each wireless device 104 may include a media access control (MAC) layer and a physical (PHY) layer according to the Institute of Electrical and Electronics Engineers (IEEE) standard 802.11 (including one or more revisions, such as 802.11a / b / g / n / p / ac / ax / bd / be). In one embodiment, the MAC layer of wireless device 104 may initiate the transmission of a frame to another wireless device 104 by passing a PHY-TXSTART.request (TXVECTOR) to the PHY layer. The TXVECTOR provides parameters for generating and / or transmitting the corresponding frame. Similarly, the PHY layer of a receiving wireless device may generate an RXVECTOR, which includes parameters of the received frame and is passed to the MAC layer for processing.

[0048] Multiple wireless devices 104 may include wireless device 104A as an access point (sometimes referred to as an AP station or AP STA) and other wireless devices 104B1-104B4 as non-AP stations (sometimes referred to as non-AP STAs). Alternatively, in an ad-hoc networking environment, all of the multiple wireless devices 104 may be non-AP STAs. Generally, AP STAs (e.g., wireless device 104A) and non-AP STAs (e.g., wireless devices 104B1-104B4) may be collectively referred to as STAs. However, for ease of description, unless the context otherwise indicates, non-AP STAs may be referred to simply as STAs. Although four non-AP STAs (e.g., wireless devices 104B1-104B4) are shown, WLAN 100 may include any number of non-AP STAs (e.g., one or more wireless devices 104B).

[0049] Figure 2 A schematic block diagram of a wireless device 104 according to an embodiment is shown. Wireless device 104 may be wireless device 104A (i.e., an access point (AP) of WLAN 100) or... Figure 1 The wireless device 104 includes any one of the wireless devices 104B1-104B4. Wireless device 104 includes a baseband processor 210, a radio frequency (RF) transceiver 240, an antenna unit 250, a storage device (e.g., a memory device) 232, one or more input interfaces 234, and one or more output interfaces 236. The baseband processor 210, storage device 232, input interfaces 234, output interfaces 236, and RF transceiver 240 can communicate with each other via a bus 260.

[0050] The baseband processor 210 performs baseband signal processing and includes a MAC processor 212 and a PHY processor 222. The baseband processor 210 may utilize a memory 232, which may include a non-transitory computer / machine-readable medium on which software (e.g., computer / machine programming instructions) and data are stored.

[0051] In this embodiment, the MAC processor 212 includes a MAC software processing unit 214 and a MAC hardware processing unit 216. The MAC software processing unit 214 can implement a first plurality of functions of the MAC layer by executing MAC software, which may include software stored in the storage device 232. The MAC hardware processing unit 216 can implement a second plurality of functions of the MAC layer in dedicated hardware. However, the MAC processor 212 is not limited thereto. For example, depending on the specific implementation, the MAC processor 212 may be configured to perform the first plurality of functions and the second plurality of functions entirely in software or entirely in hardware.

[0052] PHY processor 222 includes a transmit (TX) signal processing unit (SPU) 224 and a receive (RX) SPU 226. PHY processor 222 implements multiple functions of the PHY layer. Depending on the specific implementation, these functions may be executed in software, hardware, or a combination thereof.

[0053] The functions performed by the transmitting SPU 224 may include one or more of the following: forward error correction (FEC) coding, parsing a stream into one or more spatial streams, diversity coding a spatial stream into multiple space-time streams, spatial mapping of space-time streams to a transmission chain, inverse Fourier transform (iFT) calculation, inserting a cyclic prefix (CP) to create a guard interval (GI), etc. The functions performed by the receiving SPU 226 may include the inverse functions performed by the transmitting SPU 224, such as GI removal, Fourier transform calculation, etc.

[0054] RF transceiver 240 includes an RF transmitter 242 and an RF receiver 244. RF transceiver 240 is configured to transmit first information received from baseband processor 210 to WLAN 100 (e.g., to another WLAN device 104 of WLAN 100), and to provide second information received from WLAN 100 (e.g., second information received from another WLAN device 104 of WLAN 100) to baseband processor 210.

[0055] Antenna element 250 includes one or more antennas. When using multiple-input multiple-output (MIMO) or multi-user MIMO (MU-MIMO), antenna element 250 may include multiple antennas. In an embodiment, the antennas in antenna element 250 may operate as a beamforming antenna array. In an embodiment, the antennas in antenna element 250 may be fixed or steerable directional antennas.

[0056] Input interface 234 receives information from the user, and output interface 236 outputs information to the user. Input interface 234 may include one or more of the following: keyboard, keypad, mouse, touchscreen, microphone, etc. Output interface 236 may include one or more of the following: display device, touchscreen, speaker, etc.

[0057] As described herein, many functions of the WLAN device 104 can be implemented in hardware or software. Which functions are implemented in software and which are implemented in hardware will vary depending on the constraints imposed on the design. Constraints may include one or more of the following: design cost, manufacturing cost, time to market, power consumption, available semiconductor technology, etc.

[0058] As described herein, the functions of the components of WLAN device 104 can be implemented using a wide variety of electronic devices, circuits, firmware, software, and combinations thereof. Furthermore, WLAN device 104 may include other components such as application processors, storage interfaces, clock generator circuits, power supply circuits, etc., which are omitted for brevity.

[0059] Figure 3A Components of a WLAN device 104 configured to transmit data according to an embodiment are shown, including a transmit (Tx) SPU (TxSP) 324, an RF transmitter 342, and an antenna 352. In the embodiment, the TxSP 324, RF transmitter 342, and antenna 352 correspond to... Figure 2 The antenna of the transmitting SPU 224, RF transmitter 242 and antenna unit 250.

[0060] The TxSP 324 includes an encoder 300, an interleaver 302, a mapper 304, an inverse Fourier transform (IFT) 306, and a guard interval (GI) inserter 308.

[0061] Encoder 300 receives and encodes input data. In an embodiment, encoder 300 includes a forward error correction (FEC) encoder. The FEC encoder may include a binary convolutional code (BCC) encoder that is connected to a subsequent punching device. The FEC encoder may include a low-density parity check (LDPC) encoder.

[0062] The TxSP 324 may also include a scrambler to scramble the input data before the encoder 300 performs encoding, reducing the probability of long sequences of 0s or 1s. When the encoder 300 performs BCC encoding, the TxSP 324 may also include an encoder parser to demultiplex the scrambled bits among multiple BCC encoders. If the encoder uses LDPC encoding, the TxSP 324 may not need an encoder parser.

[0063] Interleaver 302 interleaves the bits of each stream output from encoder 300 to change the order of the bits. Interleaver 302 may apply interleaving only when encoder 300 performs BCC encoding, and in other cases, it may output the stream from encoder 300 without changing the order of the bits.

[0064] Mapper 304 maps the bit sequence output from interleaver 302 to constellation points. If encoder 300 performs LDPC encoding, mapper 304 can also perform LDPC tone mapping in addition to constellation mapping.

[0065] When the TxSP 324 performs MIMO or MU-MIMO transmission, it can include multiple interleavers 302 and multiple mappers 304 depending on the number of spatial streams (NSS) being transmitted. The TxSP 324 may also include a stream resolver, which divides the output of the encoder 300 into blocks and can send the blocks to different interleavers 302 or mappers 304 respectively. The TxSP 324 may also include a Space-Time Block Code (STBC) encoder and a spatial mapper. The STBC encoder expands constellation points from the spatial streams into several space-time streams (NSTS), and the spatial mapper maps the space-time streams to the transmission chain. The spatial mapper can use direct mapping, spatial spreading, or beamforming.

[0066] IFT 306 converts the constellation point blocks output from mapper 304 (or, in the case of MIMO or MU-MIMO, from the spatial mapper) into temporal blocks (i.e., symbols) using either the inverse discrete Fourier transform (IDFT) or the inverse fast Fourier transform (IFFT). If an STBC encoder and a spatial mapper are used, IFT 306 can be set for each transmit chain.

[0067] When the TxSP 324 performs MIMO or MU-MIMO transmissions, it can insert cyclic shift diversity (CSD) to prevent unintended beamforming. The TxSP 324 can insert CSD before or after IFT 306. CSD can be specified per transmit chain or per space-time stream. Alternatively, CSD can be applied as part of the spatial mapper.

[0068] When the TxSP 324 performs MIMO or MU-MIMO transmissions, it can provide some blocks before the space mapper for each user.

[0069] The GI inserter 308 adds a GI before each symbol generated by the IFT 306. Each GI may include a cyclic prefix (CP) corresponding to a repeating portion at the end of the symbol to which the GI is placed. The TxSP 324 may optionally perform windowing after inserting the GI to smooth the edges of each symbol.

[0070] RF transmitter 342 converts symbols into RF signals and transmits the RF signals via antenna 352. When TxSP 324 performs MIMO or MU-MIMO transmission, GI inserter 308 and RF transmitter 342 can be set for each transmission chain.

[0071] Figure 3B Components of a WLAN device 104 configured to receive data according to an embodiment are shown, including a receiver (Rx) SPU (RxSP) 326, an RF receiver 344, and an antenna 354. In the embodiment, the RxSP 326, RF receiver 344, and antenna 354 may correspond to... Figure 2 The antenna of the receiving SPU 226, RF receiver 244 and antenna unit 250.

[0072] The RxSP 326 includes a GI remover 318, a Fourier transform (FT) 316, a demapper 314, a deinterleaver 312, and a decoder 310.

[0073] RF receiver 344 receives RF signals via antenna 354 and converts the RF signals into symbols. GI remover 318 removes GIs from each symbol. When the received transmission is a MIMO or MU-MIMO transmission, RF receiver 344 and GI remover 318 can be configured for each receive chain.

[0074] FT 316 converts each symbol (i.e., each time-domain block) into a frequency-domain block of constellation points using either the Discrete Fourier Transform (DFT) or the Fast Fourier Transform (FFT). FT 316 can be configured for each receiver chain.

[0075] When the received transmission is a MIMO or MU-MIMO transmission, the RxSP 326 may include a spatial demapper and an STBC decoder. The spatial demapper is used to convert the corresponding output of the FT 316 of the receive chain into constellation points of multiple space-time streams, and the STBC decoder is used to de-expand the constellation points from the space-time streams into one or more spatial streams.

[0076] Demapper 314 demaps the constellation points output from the FT 316 or STBC decoder into a bitstream. If the received transmission is encoded using LDPC encoding, demapper 314 can also perform LDPC tone modulation mapping before performing constellation demapping.

[0077] Deinterleaving unit 312 deinterleaves bits of each stream output from demapping unit 314. Deinterleaving unit 312 may perform deinterleaving only if the received transmission is encoded using BCC encoding, and in other cases, it may output the stream from demapping unit 314 without performing deinterleaving.

[0078] When the received transmission is a MIMO or MU-MIMO transmission, the RxSP 326 can use multiple demappers 314 and multiple deinterleavers 312 corresponding to the number of spatial streams transmitted. In this case, the RxSP 326 may also include a stream deparser for merging the streams output from the deinterleavers 312.

[0079] Decoder 310 decodes the stream output from deinterleaver 312 or stream deparser. In an embodiment, decoder 310 includes an FEC decoder. The FEC decoder may include a BCC decoder or an LDPC decoder.

[0080] RxSP 326 may also include a descrambler for descrambling the decoded data. When decoder 310 performs BCC decoding, RxSP 326 may also include an encoder de-parser for multiplexing data decoded by multiple BCC decoders. When decoder 310 performs LDPC decoding, RxSP 326 may not use an encoder de-parser.

[0081] Before transmission, a wireless device, such as wireless device 104, will use idle channel assessment (CCA) to evaluate the availability of the wireless medium. If the medium is occupied, CCA can determine that the medium is busy; if the medium is available, CCA can determine that the medium is idle.

[0082] The PHY entities used in IEEE 802.11 are based on Orthogonal Frequency Division Multiplexing (OFDM) or Orthogonal Frequency Division Multiple Access (OFDMA). In the OFDM or OFDMA physical (PHY) layer, a STA (e.g., wireless device 104) is capable of transmitting and receiving Physical Layer (PHY) Protocol Data Units (PPDUs) conforming to the mandatory PHY specification (also known as PLCP (Physical Layer Convergence Process) Protocol Data Units). The PHY specification defines a set of modulation and coding schemes (MCS) and a maximum number of spatial streams. Some PHY entities define downlink (DL) and uplink (UL) multi-user (MU) transmissions with a maximum number of space-time streams (STS) per user and employing up to a predetermined total number of STSs. The PHY entity can support continuous channel bandwidths of 10 MHz, 20 MHz, 40 MHz, 80 MHz, 160 MHz, 240 MHz, and 320 MHz, and discontinuous channel bandwidths of 80+80 MHz, 80+160 MHz, and 160+160 MHz. Each channel includes multiple subcarriers, which may also be referred to as tones. The PHY entity can define signaling fields within the PPDU, represented as conventional signals (L-SIG), signal A (SIG-A), and signal B (SIG-B), etc., through which necessary information about the attributes of the PHY Service Data Unit (PSDU) is conveyed. For the sake of completeness and brevity, the following description refers to OFDM-based 802.11 technology. Unless otherwise indicated, "station" refers to a non-AP STA.

[0083] Figure 4 The inter-frame spacing (IFS) relationship is shown. Specifically, Figure 4 The following are shown: Short IFS (SIFS), Point Coordination Function (PCF) IFS (PIFS), Distributed Coordination Function (DCF) IFS (DIFS), and Arbitration IFS (AIFS[i]) corresponding to Access Class (AC) "i". Figure 4 The time slot duration is also shown, and the data frame is used to transmit data forwarded to higher layers. As shown, if the DIFS has elapsed during the period when the medium remains idle, the WLAN device 104 sends a data frame after performing a backoff.

[0084] Management frames can be used to exchange management information that is not forwarded to higher levels. Subtypes of management frames include beacon frames, association request / response frames, probe request / response frames, and authentication request / response frames.

[0085] Control frames can be used to control access to the medium. Subtypes of control frames include Request to Send (RTS) frames, Clear to Send (CTS) frames, and Acknowledge (ACK) frames.

[0086] When the control frame is not a response frame to another frame, if the DIFS has passed while the medium remains idle, the WLAN device 104 sends the control frame after performing backoff. When the control frame is a response frame to another frame, the WLAN device 104 sends the control frame after the SIFS has passed without performing backoff or checking if the medium is idle.

[0087] If the AIFS of the associated Access Class (AC) (i.e., AIFS[AC]) has passed, the WLAN device 104 (i.e., QoS STA) that supports Quality of Service (QoS) can send a frame after performing backoff. When sent by the QoS STA, any of the data frames, management frames, and control frames that are not response frames may use the AIFS[AC] of the AC of the frame being sent.

[0088] When a WLAN device 104 preparing to transmit a frame detects that the medium is busy, the WLAN device 104 can perform a backoff procedure. The backoff procedure includes determining a random backoff time consisting of N backoff slots, where the duration of each backoff slot is equal to the slot time, and N is an integer greater than or equal to zero. The backoff time can be determined based on the length of the contention window (CW). In an embodiment, the backoff time can be determined based on the frame's AC (Acceptance Time). All backoff slots occur after a DIFS (Distributed Incoming Window) or Extended IFS (EIFS) period, during which the medium is determined to be idle.

[0089] When WLAN device 104 does not detect media activity for the duration of a specific backoff slot, the backoff process should reduce the backoff time by one slot duration. When WLAN device 104 determines that the media is busy during the backoff slot, it suspends the backoff process until the media is again determined to be idle for the duration of the DIFS or EIFS period. When the backoff timer reaches zero, WLAN device 104 can perform frame transmission or retransmission.

[0090] The backoff process allows each WLAN device 104 to select a backoff time using a random function when multiple WLAN devices 104 are delaying access and performing the backoff process. The WLAN device 104 that selects the shortest backoff time wins the competition, thereby reducing the probability of collision.

[0091] Figure 5 A frame transmission process based on Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) for avoiding collisions between frames in a channel is illustrated according to an embodiment. Figure 5The diagram illustrates a first station STA1 transmitting data, a second station STA2 receiving data, and a third station STA3. The third station STA3 can be located in an area capable of receiving frames transmitted by STA1, frames transmitted by STA2, or both. Stations STA1, STA2, and STA3 can be... Figure 1 WLAN device 104.

[0092] Station STA1 can determine whether the channel is busy by carrier sensing. Station STA1 can determine channel occupancy / state based on the energy level in the channel or the autocorrelation of the signal in the channel, or it can determine channel occupancy by using a network allocation vector (NAV) timer.

[0093] After determining that other devices have not used the channel during DIFS (i.e., the channel is idle) (and backoff is performed if necessary), station STA1 can send a Request to Send (RTS) frame to station STA2. Upon receiving the RTS frame, station STA2 can send a Clear to Send (CTS) frame after SIFS as a response to the RTS frame. If dual CTS is enabled and station STA2 is an AP, the AP can send two CTS frames in response to the RTS frame (e.g., a first CTS frame in a non-high throughput format and a second CTS frame in an HT format).

[0094] When STA3 receives an RTS frame, it can use the duration information included in the RTS frame to set its NAV timer to the transmission duration of the subsequently transmitted frame (e.g., SIFS + CTS frame duration + SIFS + data frame duration + SIFS + ACK frame duration). When STA3 receives a CTS frame, it can use the duration information included in the CTS frame to set its NAV timer to the transmission duration of the subsequently transmitted frame. If a new frame is received before the NAV timer expires, STA3 can use the duration information included in the new frame to update its NAV timer. STA3 does not attempt to access the channel before the NAV timer expires.

[0095] When STA1 receives a CTS frame from STA2, STA1 may send a data frame to STA2 after one SIFS period has elapsed since the CTS frame was fully received. After successfully receiving the data frame, STA2 may send an ACK frame as a response to the data frame after one SIFS period has elapsed.

[0096] When the NAV timer expires, the third station STA3 can use carrier sensing to determine if the channel is busy. If it is determined that no other device is using the channel during the DIFS period after the NAV timer expires, station STA3 can attempt to access the channel after the contention window has passed, according to the backoff procedure.

[0097] When dual CTS is enabled, a station that has secured a Transmission Opportunity (TXOP) and has no data to transmit can send a CF-End frame to prematurely terminate the TXOP. An AP receiving a CF-End frame with its Basic Service Set Identifier (BSSID) as the destination address can respond by sending two more CF-End frames: a first CF-End frame using Space-Time Block Coding (STBC) and a second CF-End frame using non-STBC. The station receiving the CF-End frame resets its NAV timer to 0 at the end of the PPDU containing the CF-End frame. Figure 5 The example shows that station STA2 sends an ACK frame to confirm that the receiver has successfully received the frame.

[0098] The IEEE 802.11bn (Ultra-High Reliability, UHR) working group has been formed to address the growing demand for higher peak throughput and reliability in Wi-Fi. Figure 6 As shown, peak PHY rates have significantly improved from IEEE 802.11b to IEEE 802.11be (Wi-Fi 7), with the latter focusing on further increasing peak throughput. The UHR research group aims to enhance latency distribution and jitter tails to support applications requiring low latency, such as WLAN video transmission, gaming, AR, and VR. It should be noted that various characteristics of UHR, such as maximum PHY rate, PHY rate enhancement, bandwidth / number of spatial streams, and operating frequency band, remain to be determined.

[0099] IEEE 802.11be focuses primarily on indoor and outdoor WLAN operation at stationary and pedestrian speeds in the 2.4 GHz, 5 GHz, and 6 GHz bands. In addition to peak PHY rates, various candidate features are being discussed. These candidate features include: (1) 320 MHz bandwidth and more efficient use of discontinuous spectrum; (2) multi-band / multi-channel aggregation and operation; (3) 16 spatial streams and enhanced multiple-input multiple-output (MIMO) protocols; (4) multi-access point (AP) coordination (e.g., coordinated and joint transmission); (5) enhanced link adaptation and retransmission protocols (e.g., Hybrid Automatic Repeat Request (HARQ)); and (6) adaptation to regulatory rules specific to the 6 GHz spectrum.

[0100] The focus of IEEE 802.11bn (UHR) is still under discussion, with candidate features including: MLO enhancements (e.g., in terms of improving throughput / reliability and reducing latency); latency and reliability improvements (e.g., for multi-AP coordination to support low-latency services); bandwidth expansion (e.g., expansion to 240 MHz, 480 MHz, 640 MHz); aggregated PPDUs (A-PPDUs); enhanced multi-link single-radio (eMLSR) extensions for APs; roaming improvements; and power-saving solutions for extending battery life. Some features, such as increased bandwidth and spatial stream count, are solutions that have proven effective and feasible in previous projects focused on increasing link throughput.

[0101] For the IEEE 802.11be operating bands (e.g., 2.4 / 5 / 6 GHz), additional unlicensed spectrum exceeding 1 GHz may be available due to consideration of using the 6 GHz band (5.925 GHz–7.125 GHz) for unlicensed use. This would enable APs and STAs to become tri-band devices. Data transmission speeds greater than 160 MHz (e.g., 320 MHz or 640 MHz) can be considered to increase the maximum PHY rate. For example, 320 MHz or 160+160 MHz data could be transmitted in the 6 GHz band. Alternatively, 160+160 MHz data could be transmitted across both the 5 GHz and 6 GHz bands.

[0102] During wireless communication, the transmitting station (STA) creates a Physical Layer Protocol Data Unit (PPDU) frame and sends it to the receiving STA. Subsequently, the receiving STA receives, detects, and processes the PPDU.

[0103] Ultra-High Throughput (EHT) PPDU frames contain several components. EHT PPDU frames include a legacy section, which includes fields such as the Legacy Short Training Field (L-STF), Legacy Long Training Field (L-LTF), Legacy Signal Field (L-SIG), and Repeated Legacy Signal Field (RL-SIG). These fields are used to maintain compatibility with older Wi-Fi standards.

[0104] In addition to the traditional components, EHT PPDU frames also include a Universal Signaling Field (U-SIG), an EHT Signaling Field (EHT-SIG), an EHT Short Training Field (EHT-STF), and an EHT Long Training Field (EHT-LTF). These fields are dedicated to the EHT standard and are used for various purposes, such as signaling, synchronization, and channel estimation.

[0105] Figure 7 Provides a more detailed description of each field in the EHT PPDU frame, including its purpose and characteristics.

[0106] The frame structure for Ultra-High Reliability (UHR) PPDUs is currently undefined and will be determined through further discussions within relevant working groups or research groups. This indicates that the specific details of UHR PPDUs are still under development and will be finalized based on the results of future discussions.

[0107] The distributed nature of channel access networks such as IEEE 802.11 WLANs makes carrier sense mechanisms helpful in ensuring collision-free operation. Each station (STA) uses its physical carrier sense to detect transmissions from other STAs. However, in some situations, a STA may fail to detect every transmission. For example, when one STA is located far from another STA, it may perceive the medium as idle and begin sending frames, leading to a collision. To mitigate this hidden node problem, Network Allocation Vector (NAV) is introduced.

[0108] As the IEEE 802.11 standard has evolved, it now includes scenarios where multiple users can simultaneously send or receive data within a Basic Service Set (BSS), such as cascaded uplink (UL) and downlink (DL) multi-user (MU) transmissions. In these cases, existing carrier sense and NAV mechanisms may be insufficient, and modified or newly defined mechanisms may be necessary to facilitate efficient and conflict-free operation.

[0109] For the purposes of this disclosure, MU transmission refers to a situation in which multiple frames are simultaneously transmitted to or from multiple STAs using different resources. Examples of such resources include different frequency resources in Orthogonal Frequency Division Multiple Access (OFDMA) transmissions and different spatial streams in Multi-User Multiple-Input Multiple-Output (MU-MIMO) transmissions. Therefore, downlink OFDMA (DL-OFDMA), downlink MU-MIMO (DL-MU-MIMO), uplink OFDMA (UL-OFDMA), uplink MU-MIMO (UL-MU-MIMO), and OFDMA combined with MU-MIMO are all considered examples of MU transmissions.

[0110] Figure 8 Examples of multi-user (MU) transmission in orthogonal frequency division multiple access (OFDMA) according to some embodiments of the present disclosure are shown.

[0111] In the IEEE 802.11ax and IEEE 802.11be specifications, trigger frames play a useful role in facilitating uplink multi-user (MU) transmissions. The purpose of a trigger frame is to allocate resources and request the transmission of one or more trigger-based (TB) physical layer protocol data units (PPDUs) from an associated station (STA).

[0112] The trigger frame contains the information required for the STA to send its uplink TB PPDU. This information includes the trigger type and the uplink length (UL length). The trigger type specifies the type of the expected TB PPDU, and the uplink length indicates the duration of the uplink transmission.

[0113] Figure 9 An exemplary scenario is illustrated below: An access point (AP) operating in an 80 MHz bandwidth environment sends a trigger frame to multiple associated STAs. Upon receiving the trigger frame, the STAs respond by sending their corresponding uplink orthogonal frequency division multiple access (UL OFDMA) TB PPDU using the resources allocated within the specified 80 MHz bandwidth.

[0114] After successfully receiving the UL OFDMA TB PPDU, the AP acknowledges the STA by sending an acknowledgment frame. This acknowledgment can take the form of multi-STA block acknowledgment (Block Ack) with an 80 MHz bandwidth, or it can take the form of block acknowledgment with Direct Feedback (DF) OFDMA. Multi-STA block acknowledgment allows the AP to acknowledge multiple STAs simultaneously, while block acknowledgment with DF OFDMA allows the AP to provide feedback to the STA using the same OFDMA technology used in the uplink transmission.

[0115] Trigger frames are a useful component for achieving efficient uplink MU transmission in IEEE 802.11ax and IEEE 802.11be networks by allocating resources and coordinating uplink transmissions of multiple STAs within the same bandwidth.

[0116] When the transmitter (TX) fails to receive an acknowledgment from the receiver (RX) or the receiver fails to decode a Media Access Control (MAC) Protocol Data Unit (MPDU), a wireless network system can rely on MPDU retransmission. Using Automatic Repeat Request (ARQ), the receiver discards the previously failed MPDU before receiving a new retransmitted MPDU. With increasing demands for enhanced reliability and reduced latency, wireless network systems can evolve towards Hybrid ARQ (HARQ).

[0117] There are two HARQ processing methods. In the first type of HARQ scheme, also known as chase-and-comb (CC) HARQ (CC-HARQ), the signal to be retransmitted is the same as the previously failed signal because all sub-packets to be retransmitted use the same puncturing pattern. Punching is necessary to remove some parity bits after encoding with error correction codes. The reason CC-HARQ uses the same puncturing pattern is to generate an encoded data sequence with forward error correction (FEC) and to allow the receiver to use maximum ratio combining (MRC) to combine the received retransmitted bits with the same bits from the previous transmission. For example, information sequences are sent in packets of fixed length. At the receiver, error correction and detection are performed on the entire packet. However, ARQ schemes can be inefficient in the presence of burst errors. To address this problem more efficiently, sub-packets are used. In sub-packet transmission, only those sub-packets containing the errors need to be retransmitted.

[0118] Because the receiver uses both currently received and previously received sub-packets to decode data, the probability of errors during decoding decreases as the number of sub-packets used increases. The decoding process performs Cyclic Redundancy Check (CRC) and terminates when the entire packet is decoded without errors or when the maximum number of sub-packets is reached. Specifically, the scheme operates based on a stop-and-wait protocol, such that if the receiver can decode the packet, it sends an acknowledgment (ACK) to the transmitter. When the transmitter successfully receives the ACK, it terminates the HARQ transmission of the packet. If the receiver cannot decode the packet, it sends a negative acknowledgment (NAK) to the transmitter, and the transmitter performs a retransmission.

[0119] In the second type of HARQ scheme, also known as Incremental Redundancy (IR) HARQ (IR-HARQ), a different puncturing pattern is used for each sub-packet, such that the signal of each retransmitted sub-packet changes compared to the originally transmitted sub-packet. IR-HARQ alternates between two puncturing patterns, one for odd-numbered transmissions and one for even-numbered transmissions. The redundancy scheme of IR-HARQ improves the log-likelihood ratio (LLR) of the parity bits to combine information sent across different transmissions due to requests, and reduces the code rate as additional sub-packets are used. This results in a lower sub-packet error rate compared to CC-HARQ. The puncturing pattern used in IR-HARQ is indicated by a Sub-packet Identifier (SPID). The SPID of the first sub-packet can always be set to 0, and all system bits and punctured parity bits are transmitted in the first sub-packet. Self-decoding is possible when the received signal-to-noise ratio (SNR) environment is good (i.e., high SNR). In some embodiments, the sub-packets to be sent with corresponding SPIDs are arranged in ascending order of SPIDs, but may be swapped / switched except for the first SPID.

[0120] AP coordination has been identified as a potential technology for improving WLAN system throughput in the IEEE 802.11be standard and is still under discussion in the IEEE 802.11bn (UHR) standard. To support various AP coordination schemes, such as coordinated beamforming, OFDMA, TDMA, spatial multiplexing, and joint transmission, predefined mechanisms for APs are required.

[0121] In a coordinated TDMA (C-TDMA) scenario, the AP that obtains a transmission opportunity (TXOP) is called the sharing AP. This AP initiates an AP coordination scheme by sending frames such as beacon frames or probe response frames (containing information about the AP's coordination scheme capabilities) to determine the AP candidate set. APs that participate in the AP coordination scheme after receiving frames from the sharing AP are called the shared APs. The sharing AP is also called the master AP or coordinating AP, while the shared APs are called slave APs or coordinated APs.

[0122] The operation of various AP coordination schemes has been discussed in the IEEE 802.11be and UHR standards:

[0123] Coordinated beamforming (C-BF): Multiple access points (APs) transmit on the same frequency resources by coordinating and forming spatial nulls, thereby allowing simultaneous transmission from multiple APs.

[0124] Coordinated OFDMA (C-OFDMA): APs transmit on orthogonal frequency resources by coordinating and allocating spectrum, thereby achieving more efficient spectrum utilization.

[0125] Joint transmission (JTX): Multiple access points (APs) simultaneously send data to a given user by sharing data among themselves.

[0126] Coordinated Spatial Reuse (C-SR): Multiple APs or STAs adjust their transmit power to reduce interference between APs.

[0127] By implementing these AP coordination schemes, WLAN systems can improve their overall throughput and efficiency by leveraging cooperation among multiple APs.

[0128] Existing wireless networking standards (e.g., the IEEE 802.11 wireless networking standard) provide security features for the transmission and reception of MPDU / frames. Data frames can be encrypted / decrypted and their integrity verified using Time-Limited Key Integrity Protocol (TKIP), Counter Mode and Message Authentication Code with Cipher Block Chaining Protocol (CCMP) or Galois / Counter Mode Protocol (GCMP). Group-addressed management frames can be verified for integrity using Broadcast / Multicast Integrity Protocol (BIP).

[0129] CCMP and GCMP are widely used security protocols for encrypting / decrypting and verifying the integrity of frames. CCMP is based on the Advanced Encryption Standard (AES) algorithm and Cipher Block Chaining Message Authentication Code (CBC-MAC) technology. GCMP is also based on the AES algorithm, but uses Galois Message Authentication Code (GMAC) technology. Depending on the encryption key length, both CCMP and GCMP have two variants: CCMP-128 and CCMP-256 use 128-bit and 256-bit keys respectively, and GCMP-128 and GCMP-256 also use 128-bit and 256-bit keys respectively. Using these security protocols, a Message Integrity Check (MIC) authentication value (also simply called the "authentication value") is generated using certain fields of the frame's MAC header. This authentication value is then sent in the MIC field, which appears after the encrypted frame body field of the frame. The receiver of the frame can use the authentication value to verify the integrity of the MAC header.

[0130] Figure 10 This is a schematic diagram illustrating the format of a standard (unencrypted) MPDU according to some embodiments.

[0131] As shown in the figure, an MPDU may include a MAC header 1010, a frame body field 1030, and a Frame Check Sequence (FCS) field 1040. The MAC header 1010 may include a frame control field 1012 (2 bytes), a duration / ID field 1014 (2 bytes), an address 1 field 1016 (6 bytes), an address 2 field 1018 (0 or 6 bytes), an address 3 field 1020 (0 or 6 bytes), a sequence control field 1022 (0 or 2 bytes), an address 4 field 1024 (0 or 6 bytes), a quality of service (QoS) control field 1026 (0 or 2 bytes), and a high throughput (HT) control field 1028 (0 or 4 bytes). The frame control field 1012 may carry general information about the MPDU, such as its type and subtype. Depending on the MPDU type and subtype, the duration / ID field 1014 may carry information about the remaining time for continuous frame switching or an association identifier (AID). The address fields (e.g., address 1 field 1016, address 2 field 1018, address 3 field 1020, and / or address 4 field 1024) can carry the addresses of the transmitter and receiver of the MPDU, as well as the addresses of any intermediate wireless devices involved in the transmission. The frame body field 1030 can carry the payload of the MPDU, which can vary depending on the type and subtype of the MPDU. The FCS field 1040 can carry a 32-bit Cyclic Redundancy Check (CRC) value, which can be used to verify the integrity and validity of the MAC header 1010 and the frame body field 1030. Generally, CRC provides simple data integrity, while MIC provides cryptographic integrity.

[0132] Figure 11 This is a schematic diagram illustrating the format of an MPDU having an encrypted frame body field according to some embodiments.

[0133] As shown in the figure, the MPDU may include a MAC header 1110, a CCMP / GCMP header 1140 (8 bytes), a (encrypted) frame body field 1150, a MIC field 1160 (8 or 16 bytes), and an FCS field 1170. The CCMP / GCMP header 1140 may include a packet number 0 (PN0) field 1112 (1 byte), a PN1 field 1114 (1 byte), a reserved (RSVD) field 1116 (1 byte), an octet key ID field 1118 (1 byte), a PN2 field 1126 (1 byte), a PN3 field 1128 (1 byte), a PN4 field 1130 (1 byte), and a PN5 field 1132 (1 byte). The octet key ID field 1118 may include a reserved field 1120 (5 bits), an extended initialization vector (IV) field 1122 (1 bit), and a key ID field 1124 (2 bits).

[0134] Both CCMP and GCMP require additional information to be sent in the MPDU. This additional information can be added to the MPDU along with the CCMP / GCMP header 1140 and the MIC field 1160. The CCMP / GCMP header 1140 can carry security material required to decrypt the encrypted frame body field 1150, such as the block number (PN) and key ID. The extended initialization vector field 1122 can carry a bit fixed to 1. The MIC field 1160 can carry an authentication value that can be used to verify the encryption and decryption processes.

[0135] Both CCMP and GCMP involve two operations to ensure the integrity and accuracy of the encryption and decryption processes. The first operation is to encrypt the data / payload to be included in the frame body field 1150 of the MPDU, and then insert the encrypted data / payload into the frame body field 1150. The second operation is to generate an authentication value that can be used to verify the encryption and decryption processes, and insert the authentication value into the MIC field 1160. For CCMP-128, the authentication value can be eight (8) bytes long; for CCMP-256, GCMP-128, and GCMP-256, the authentication value can be sixteen (16) bytes long. The length of the MIC field 1160 can vary depending on the length of the authentication value.

[0136] Figure 12 This is a schematic diagram illustrating how Additional Authentication Data (AAD) is generated according to some embodiments.

[0137] Both CCMP and GCMP can generate the authentication value of an MPDU based on its Additional Authentication Data (AAD). The AAD of an MPDU can be generated by concatenating certain fields included in the MPDU and masking certain (sub)fields / bits included in the concatenated fields. The process of generating the AAD is the same for both CCMP and GCMP.

[0138] For example, as shown in the figure, an AAD can be generated by concatenating the following fields in sequence: Frame Control (FC) field 1202 (2 bytes), A1 (address 1) field 1204 (6 bytes), A2 (address 2) field 1206 (6 bytes), A3 (address 3) field 1208 (6 bytes), Serial Control (SC) field 1210 (2 bytes), A4 (address 4) field 1212 (0 or 6 bytes), and QoS Control (QC) field 1214 (0 or 2 bytes). It should be noted that not all MPDUs have A4 field 1212 and QoS Control field 1214, and any fields not present in the MAC header can be excluded from the AAD. Therefore, the length of the AAD can vary depending on the presence or absence of these fields. Possible lengths for an AAD are 22 bytes, 24 bytes, 28 bytes, or 30 bytes.

[0139] Fields A1 (Address 1) 1204, A2 (Address 2) 1206, A3 (Address 3) 1208, and A4 (Address 4) 1212 can be used in AAD without modification. However, these fields can be modified by deleting / masking some fields / bits in FC field 1202, SC field 1210, and QoS control field 1214.

[0140] Figure 13 This is a schematic diagram illustrating the format of a frame control field according to some embodiments.

[0141] The Frame Control (FC) field may include fields that carry information about the format and function of the MPDU. As shown in the figure, the FC field may include a protocol version field 1302 (2 bits), a type field 1304 (2 bits), a subtype field 1306 (4 bits), a to Distributed System (DS) field 1308 (1 bit), a from DS field 1310 (1 bit), a more fragmented field 1312 (1 bit), a retry field 1314 (1 bit), a power management field 1316 (1 bit), a more data field 1318 (1 bit), a protected frame field 1320 (1 bit), and a +HTC (High Throughput Control) field 1322 (1 bit). The bit positions of the fields can be as shown in the figure.

[0142] When generating the AAD, some fields can be modified by masking certain bits to 0. For example, bits 4, 5, and 6 of the subtype field 1306 in the data frame are masked to 0. Additionally, the retry field 1314, indicating whether an MPDU is a retransmission, is masked to 0. Furthermore, the power management field 1316, indicating the transmitter's power-saving mode, is masked to 0. Additionally, the more data field 1318, indicating whether more MPDUs are buffered for transmission, is masked to 0. Finally, in the case of a data frame with a QoS control field, the +HTC field 1322, indicating the presence of a High Throughput Control (HTC) field, is masked to 0.

[0143] Figure 14 This is a schematic diagram illustrating the format of a sequence control field according to some embodiments.

[0144] The Sequence Control (SC) field may include fields that carry information about the order and fragmentation of the MPDU. As shown in the figure, the Sequence Control field may include a fragment number field 1402 (4 bits) and a sequence number field 1404 (12 bits). When generating the AAD, the sequence number field 1404, which indicates the position of the MPDU in the MPDU sequence, is masked to 0. The bit positions of the fields can be as shown in the figure.

[0145] The QoS control field includes fields that carry information about the aggregation of MPDUs and Quality of Service (QoS). When generating the AAD, the masking rules applied to the QoS control field can vary depending on whether the MPDU belongs to a non-DMG Basic Service Set (BSS) or a DMG BSS. If the MPDU belongs to a non-DMG BSS, and both the transmitter and receiver's Signaling and Payload Protected (SPP) Aggregated MAC Service Data Unit (A-MSDU) capability fields are set to 1, indicating support for single MPDU protection of the A-MSDU, then all fields in the QoS control field except the Service Identifier (TID) field and the A-MSDU Presence field are masked to 0. If the MPDU belongs to a non-DMG BSS, and neither the transmitter nor the receiver's SPP A-MSDU capability field is set to 1, then all fields in the QoS control field except the TID field are masked to 0. If the MPDU belongs to the DMG BSS, then all fields in the QoS control field except for the TID field, the A-MSDU presence field, and the A-MSDU type field are masked to 0.

[0146] CCMP and GCMP are security protocols that enable parallel encryption / decryption and integrity verification of data frames. BIP is a security protocol that performs integrity verification on group-addressed management frames. BIP does not encrypt the data / payload of group-addressed management frames; instead, it provides a way to verify their integrity.

[0147] Figure 15 This is a schematic diagram illustrating the format of a management frame according to some embodiments.

[0148] As shown in the figure, the management frame may include a MAC header 1510, a frame body field 1530, and an FCS field 1540. The MAC header 1510 may include a frame control field 1512 (2 bytes), a duration field 1514 (2 bytes), an address 1 field 1516 (6 bytes), an address 2 field 1518 (6 bytes), an address 3 field 1520 (6 bytes), and a sequence control field 1522 (2 bytes). The MAC header 1510 may also include an HT control field 1524 (0 to 4 bytes). The presence of the HT control field 1524 can be indicated by the value carried in the +HTC field (not shown) included in the frame control field 1512.

[0149] Figure 16 This is a schematic diagram illustrating the format of a management MIC element according to some embodiments.

[0150] To apply BIP to group-addressed management frames, the management MIC element can be added to the end of the frame body field of the management frame.

[0151] As shown in the figure, a management MIC element may include an element ID field 1602 (1 byte), a length field 1604 (1 byte), a key ID field 1606 (2 bytes), an IPN / BIPN (Integrity Group Temporary Key Block Number (IPN) or Beacon Integrity Group Temporary Key Block Number (BIPN)) field 1608 (6 bytes), and a MIC field 1610 (8 or 16 bytes). The element ID field 1602 can carry a unique value indicating the element type. In a management MIC element, the element ID field 1602 can carry the value 76. The length field 1604 can carry an indication of the length of the management MIC element, excluding the element ID field 1602 and the length field 1604. The length of the MIC field 1610 can vary depending on the encryption algorithm used. For example, the length of the MIC field 1610 can be 8 bytes or 16 bytes. Therefore, the length field 1604 of a management MIC element can carry the value 16 or 24.

[0152] The Key ID field 1606 can carry an identifier for the key used to perform integrity verification. When the sender generates an authentication value, it communicates the ID of the key used in the Key ID field 1606. Upon receiving this information, the receiver can use the specified key to generate its own authentication value and verify that the authentication value matches the authentication value carried in the MIC field 1610. In the Key ID field 1606, the lower 12 bits, represented by 2 bytes (16 bits), can carry the actual key ID, while the remaining 4 bits can be reserved. Although the 12 bits of the Key ID field 1606 can hold values ​​from 0 to 4095, in practice, only one of the values ​​4, 5, 6, or 7 is used. In the context of BIP, the key can be an Integrity Group Temporary Key (IGTK) or a Beacon Integrity Group Temporary Key (BIGTK). The key ID of an IGTK can be 4 or 5, while the key ID of a BIGTK can be 6 or 7. Therefore, sending the key ID may only require three (3) bits.

[0153] The IPN / BIPN field 1608 can carry either an IGTK Block Number (IPN) or a BIGTK Block Number (BIPN). During the execution of the encryption algorithm, the block number can be used to generate an authentication value. The process of generating the authentication value may involve dividing the original message into 128-bit blocks and sequentially feeding these blocks into the algorithm. A counter can also be fed into the algorithm during this process. For each block, the counter can be incremented by one. Furthermore, the block number can be fed into the algorithm along with the counter. Importantly, the block number should vary for each frame.

[0154] To apply BIP, a management MIC element can be appended to the end of the frame body field of the management frame. During this process, the element ID field 1602, length field 1604, key ID field 1606, and IPN / BIPN field 1608 can be filled with the appropriate values, while the MIC field 1610 can be temporarily filled with zeros. Subsequently, an authentication value can be generated using one of the following algorithms: BIP-CMAC-128, BIP-CMAC-256, BIP-GMAC-128, or BIP-GMAC-256. These algorithms can operate on the frame body field and can be the same as / similar to the algorithms used to generate authentication values ​​in CCMP-128, CCMP-256, GCMP-128, or GCMP-256. The generated authentication value can be inserted into the MIC field 1610 of the management MIC element (e.g., overwriting any zeros previously carried in the MIC field 1610).

[0155] Figure 17 This is a schematic diagram illustrating how an AAD is generated in a BIP according to some embodiments.

[0156] BIP-CMAC and BIP-GMAC take the AAD as input. The process of generating the AAD is the same for both BIP-CMAC and BIP-GMAC. The AAD can be generated by concatenating certain fields of the MAC header. For example, as shown in the figure, the AAD can be generated by concatenating the Frame Control field 1702 (2 bytes), Address 1 (A1) field 1704 (6 bytes), Address 2 (A2) field 1706 (6 bytes), and Address 3 (A3) field 1708 (6 bytes). In this case, the AAD length can be 20 bytes.

[0157] Figure 18 This is a schematic diagram illustrating the format of a trigger frame according to some embodiments.

[0158] A trigger frame is a control frame introduced as part of the IEEE 802.11ax wireless networking standard. An Access Point (AP) can send a trigger frame to request simultaneous uplink transmissions from multiple non-AP STAs. As shown in the figure, a trigger frame may include a Frame Control field 1802 (2 bytes), a Duration field 1804 (2 bytes), an RA field 1806 (6 bytes), and a TA field 1810 (6 bytes) forming the MAC header. The trigger frame may also include a Common Information field 1812 (8 bytes or more) and a User Information List field 1814 (variable length) forming the frame body. The Common Information field 1812 may carry information intended for all non-AP STAs receiving the trigger frame. The User Information List field may include zero or more User Information fields, each carrying information intended for a specific non-AP STA. The trigger frame may also include a Padding field 1816 (variable length) and an FCS field 1818 (4 bytes).

[0159] Figure 19 This is a schematic diagram illustrating the format of a user information field according to some embodiments.

[0160] As shown in the figure, the user information fields include AID12 field 1902 (12 bits), Resource Unit (RU) allocation field 1904 (8 bits), Uplink Forward Error Correction (UL FEC) coding type field 1906 (1 bit), Uplink High Efficiency Modulation and Coding Scheme (UL HE-MCS) field 1908 (4 bits), Uplink Dual Carrier Modulation (UL DCM) field 1910 (1 bit), Spatial Stream (SS) Allocation / Random Access Resource Unit (RA-RU) information field 1912 (6 bits), UL Target Received Power field 1914 (7 bits), Reserved field 1916 (1 bit), and Trigger-related User Information field 1918 (variable length).

[0161] The AID12 field 1902 can indicate the specific STA to which the information carried in the User Information field is addressed. The STA receiving the trigger frame can identify which User Information field is for it based on the value carried in the AID12 field 1902. If the value carried in the AID12 field 1902 of the User Information field is 0, the information included in the User Information field can be information about Random Access Resource Units (RA-RUs) allocated to all associated STAs. If the value carried in the AID12 field 1902 of the User Information field is between 1 and 2007, the value can be the Association Identifier (AID) value of the expected recipient of the User Information field. If the value carried in the AID12 field 1902 of the User Information field is 2045, the information carried in the User Information field can be information about RA-RUs allocated to unassigned STAs. If the value carried in the AID12 field 1902 of the User Information field is 2046, the information included in the User Information field can be information about unassigned RUs. If the value carried in the AID12 field 1902 of the User Information field is 4095, this value can indicate the start of padding field 1816. Other values ​​in the AID12 field 1902 can be reserved and not used. The remaining 28 bits of the User Information field (excluding the bits of the AID12 field 1902) can carry information about the corresponding RU. This information may include information about RU allocation, UL FEC coding type, UL HE-MCS, UL DCM, SS allocation / RA-RU information, and UL target received power. The trigger-related User Information field 1918 can be optional (it may or may not exist, depending on the type of trigger frame). The type of trigger frame can be indicated in the trigger type field included in the public information field.

[0162] Figure 20 This is a schematic diagram illustrating the format of a special user information field according to some embodiments.

[0163] After the trigger frame was introduced as part of the IEEE 802.11ax wireless networking standard, additional information beyond that carried in the common information field needed to be sent to all STAs receiving the trigger frame. The IEEE 802.11be wireless networking standard added a special user information field to provide this information.

[0164] As shown in the figure, special user information fields may include AID12 field 2002 (12 bits), PHY version identifier field 2004 (3 bits), UL bandwidth extension field 2006 (2 bits), EHT space multiplexing 1 field 2008 (4 bits), EHT space multiplexing 2 field 2010 (4 bits), U-SIG ignore and verify field 2012 (12 bits), reserved field 2014 (3 bits), and trigger-related user information field 2016 (variable length).

[0165] The AID12 field 2002 included in the Special User Information field can carry a fixed value of 2007. The remaining 28 bits can carry additional information provided by the AP to non-AP STAs, such as information about the PHY version identifier, UL bandwidth extension, EHT space multiplexing, and U-SIG ignoring and verification. The Special User Information field can appear immediately after the common information field (i.e., as the first user information field among all user information fields).

[0166] One way to secure trigger frames is to apply existing security protocols provided in wireless networking standards. BIP, used to secure management frames for group addressing, can be considered a good candidate for securing trigger frames as well. For example, a field / element similar to the management MIC element can be added after the user information field included in the trigger frame to convey the key ID, PN, and authentication value. The authentication value can be generated based on both the public information field and the user information list field, or only the user information list field.

[0167] However, BIP cannot be applied to trigger frames as is for security protection. As mentioned above, the AAD used in BIP is generated by concatenating the frame control field, address 1 field, address 2 field, and address 3 field. However, since the MAC header of the trigger frame only has two address fields, a different AAD is required compared to the AAD used in BIP.

[0168] Figure 21 This is a schematic diagram illustrating the format of an AAD that can be used to securely protect trigger frames according to some embodiments.

[0169] As shown in the figure, an AAD can be generated by concatenating the frame control field 2102 (2 bytes), the address 1 (A1) field 2104 (6 bytes), and the address 2 (A2) field 2106 (6 bytes). In this case, the total length of the AAD is 14 bytes.

[0170] When BIP is applied to trigger frames, there are issues related to timing delays. The receiver of the trigger frame needs to know the key ID to determine which key to use to generate the authentication value. Additionally, the receiver needs to know the PN to generate the authentication value. However, with BIP, the key ID and PN appear near the end of the frame. If the key ID and PN appear near the end of the trigger frame, the receiver must wait until it has received most of the trigger frame before it can begin generating the authentication value, making it difficult for the receiver to respond to the trigger frame immediately within the required timeframe.

[0171] Similarly, when BIP is applied to group-addressed management frames, the authentication value can only be generated after almost the entire frame has been received, and the generation of the authentication value and verification of its match with the authentication value carried in the management MIC element of the group-addressed management frame require a non-negligible amount of time. However, in the case of group-addressed management frames, time delay is not a significant problem because the receiver does not need to respond immediately to the group-addressed management frame.

[0172] The time delay issue arises because the key ID and PN appear near the end of the trigger frame. When security protocols such as TKIP, CCMP, or GCMP are applied to data frames, the TKIP / CCMP / GCMP header carrying the key ID and PN is inserted between the MAC header and the frame body field. Therefore, upon receiving the TKIP / CCMP / GCMP header, the receiver can quickly identify the cryptographic key and perform decryption and integrity checks simultaneously with receiving the frame body field.

[0173] This article describes a technique that enables the integrity verification process of the trigger frame to begin earlier, thereby allowing the receiver to respond to the trigger frame immediately (e.g., send a TBPPDU) within the required time (e.g., the SIFS interval after receiving the trigger frame).

[0174] Figure 22 This is a schematic diagram illustrating the format of a protected trigger frame according to some embodiments.

[0175] As shown in the figure, the protected trigger frame includes a frame control field 2202 (2 bytes), a duration field 2204 (2 bytes), an RA field 2206 (6 bytes), a TA field 2208 (6 bytes), a public information field 2210 (8 bytes or more), a key ID user information field 2212 (also referred to as the key ID user information field in this document), a user information list field 2214 (variable length), a MIC user information field 2216 (also referred to as the MIC user information field in this document), a padding field 2218 (variable length), and an FCS field 2220 (4 bytes).

[0176] The format of the protected trigger frame is similar to that of a conventional trigger frame, but it includes a Key ID user information field 2212 and a MIC user information field 2216. The Key ID user information field 2212 can carry the Key ID and PN. The MIC user information field 2216 can carry the MIC authentication value. Notably, the Key ID user information field 2212 appears before the user information list field 2214 (and in this example after the public information field 2210), allowing the receiver to begin the integrity verification process of the trigger frame earlier (e.g., to identify the key earlier). If a special user information field exists, the Key ID user information field 2212 can be placed before the special user information field. Furthermore, the MIC user information field 2216 can appear after the user information list field 2214.

[0177] The Key ID user information field 2212 and the MIC user information field 2216 can follow the general format of user information fields to ensure compatibility with STAs implementing existing wireless networking standards. For example, the first 12 bits can be used as the AID12 field, while the remaining 28 bits can be used to convey security material. In this respect, the Key ID user information field 2212 and the MIC user information field 2216 can be similar to special user information fields. The AID12 field of the Key ID user information field 2212 and the MIC user information field 2216 can carry one of a reserved AID or an infrequently used AID. For example, the AID12 field included in the Key ID user information field 2212 can carry the value 4093 (to indicate that the field is a Key ID user information field), and the AID12 field included in the MIC user information field 2216 can carry the value 4094 (to indicate that the field is a MIC user information field).

[0178] Figure 23 This is a schematic diagram illustrating the format of a key ID user information field according to some embodiments.

[0179] As described above, the Key ID user information field 2212 can carry both the Key ID and the PN. The Key ID is 3 bits long, and the PN is 48 bits long. Therefore, the total length of the data to be conveyed exceeds 40 bits, while the Key ID user information field can carry 28 bits of data (excluding the AID12 field). Therefore, multiple Key ID user information fields can be used to carry both the Key ID and the PN. In one embodiment, as shown, two Key ID user information fields are used to carry both the Key ID and the PN.

[0180] As shown in the figure, the first key ID user information field (key ID user information field #1) may include an AID12 field 2302 (12 bits), a key information sequence field 2304 (2 bits), a reserved field 2306 (1 bit), a key ID field 2308 (3 bits), and a first block number (PN1) field 2310 (22 bits). The second key ID user information field (key ID user information field #2) may include an AID12 field 2312 (12 bits), a key information sequence field 2314 (2 bits), and a second block number (PN2) field 2316 (26 bits).

[0181] The key information sequence field can be used to indicate the order of the key ID user information fields. In the example shown in the figure, the key information sequence field 2304 included in the first key ID user information field carries a value of 0, and the key information sequence field 2314 included in the second key ID user information field carries a value of 1. The first block number field 2310 and the second block number field 2316 can jointly carry PN.

[0182] When the value carried in the key information sequence field is 0, the next bit (e.g., bit B14) can be reserved. For the remaining bits, three bits can be used in the key ID field 2308 to carry the key ID, and the remaining 22 bits can be used in the first block number field 2310 to carry the first 22 bits of PN (the first 22 bits out of a total of 48 bits).

[0183] When the value carried in the key information sequence field is 1, the remaining 26 bits can be used in the second block number field 2316 to carry the remaining 26 bits of PN. In one embodiment, the values ​​2 and 3 are not used in the key information sequence field.

[0184] Figure 24 This is a schematic diagram illustrating the format of the MIC user information field when the length of the authentication value is 64 bits, according to some embodiments.

[0185] As described above, the MIC user information field 2216 can be used to carry the authentication value. The length of the authentication value can depend on the encryption algorithm used. If BIP-CMAC-128 is used, the authentication value can be 64 bits long. If BIP-CMAC-256, BIP-GMAC-128, or BIP-GMAC-256 is used, the authentication value can be 128 bits long. In either case, the length of the authentication value exceeds the 28 bits of data (excluding the AID12 field) that a 40-bit MIC user information field can carry. Therefore, multiple MIC user information fields can be used to carry the authentication value. In one embodiment, as will be described in further detail herein, if the authentication value is 64 bits long, three MIC user information fields are used to carry the authentication value. In one embodiment, as will be described in further detail herein, if the authentication value is 128 bits long, five MIC user information fields are used to carry the authentication value.

[0186] As shown in the figure, the first MIC user information field (MIC user information field #1) may include AID12 field 2402 (12 bits), MIC information sequence field 2404 (2 bits), and first MIC (MIC1) field 2406 (26 bits). The second MIC user information field (MIC user information field #2) may include AID12 field 2408 (12 bits), MIC information sequence field 2410 (2 bits), and second MIC (MIC2) field 2412 (26 bits). The third MIC user information field (MIC user information field #3) may include AID12 field 2414 (12 bits), MIC information sequence field 2416 (2 bits), third MIC (MIC3) field 2418 (12 bits), and reserved field 2420 (14 bits).

[0187] The MIC (Matchmaking Message Sequence) field can be 2 bits or 3 bits long. When the first two bits of the MIC field are binary "00", "01", or "10", the MIC field can be 2 bits long, and the authentication value can be conveyed in the following 26 bits. When the first two bits of the MIC field are binary "11", the MIC field can be 3 bits long, and therefore, the next bit can also be included in the MIC field. Thus, in this case, the MIC field can carry the binary value "110" or "111", and the authentication value can be conveyed in the following 25 bits.

[0188] When the MIC information sequence field carries a value of binary "00", the remaining 26 bits can be used for MIC1 field 2406, which carries the first 26 bits of the authentication value. When the MIC information sequence field carries a value of binary "01", the remaining 26 bits can be used for MIC2 field 2412, which carries the subsequent 26 bits of the authentication value. When the MIC information sequence field carries a value of binary "10", there are two possibilities depending on the length of the authentication value. If the authentication value is 64 bits long, there are still 12 bits of the authentication value to be conveyed after MIC1 field 2406 and MIC2 field 2412. Therefore, if the MIC information sequence field carries a value of binary "10" and the authentication value is 64 bits long (e.g., using BIP-CMAC-128), the 12 bits after the MIC information sequence field can be used for MIC3 field 2418, which carries the remaining 12 bits of the authentication value. The remaining 14 bits can be reserved.

[0189] Figure 25 This is a schematic diagram illustrating the format of the MIC user information field when the length of the authentication value is 128 bits, according to some embodiments.

[0190] If the authentication value is 128 bits long, it can be carried using five MIC user information fields. For example, it can be used... Figure 24 The MIC user information fields #1 and #2 shown are as follows: Figure 25 The MIC user information fields #3, #4, and #5 are shown below.

[0191] As shown in the figure, the third MIC user information field (MIC user information field #3) may include AID12 field 2502 (12 bits), MIC information sequence field 2504 (2 bits), and third MIC (MIC3) field 2506 (26 bits). The fourth MIC user information field (MIC user information field #4) may include AID12 field 2508 (12 bits), MIC information sequence field 2510 (3 bits), and fourth MIC (MIC4) field 2512 (25 bits). The fifth MIC user information field (MIC user information field #5) may include AID12 field 2514 (12 bits), MIC information sequence field 2516 (3 bits), and fifth MIC (MIC5) field 2518 (25 bits).

[0192] If the value carried in the MIC information sequence field is binary "10" and the length of the authentication value is 128 bits (e.g., using BIP-CMAC-256, BIP-GMAC-128, or BIP-GMAC-256), then the remaining 26 bits can be used for the MIC3 field 2506, which can carry the subsequent 26 bits of the authentication value.

[0193] When the value carried in the MIC information sequence field is binary "110", the remaining 25 bits can be used for MIC4 field 2512, which can carry the subsequent 25 bits of the authentication value. When the value carried in the MIC information sequence field is binary "111", the remaining 25 bits can be used for MIC5 field 2518, which can carry the remaining 25 bits of the authentication value.

[0194] The existing IEEE 802.11 wireless networking standard lacks security protection for trigger frames, which is problematic because trigger frames control the behavior of multiple STAs. The technique described in this paper provides security protection for trigger frames and fills this gap in the existing wireless networking standard. This technique places the key ID and PN near the beginning of the trigger frame, enabling the receiver to initiate the integrity verification process earlier and respond promptly to the trigger frame.

[0195] If the Key ID user information field and the MIC user information field are configured as described above, two Key ID user information fields and three or five MIC user information fields can be added to the trigger frame. These additional user information fields can secure the trigger frame by enabling the receiver to verify its integrity.

[0196] However, simply appending the additional fields carrying the key ID, PN, and MIC authentication values ​​to the end of the trigger frame can unduly delay the integrity verification process, making it difficult for the receiver to respond immediately to the trigger frame (e.g., sending a TB PPDU after the SIFS interval). The technique described herein addresses this problem by placing the key ID and PN earlier in the trigger frame (e.g., before the user information list field). Furthermore, the authentication value can be placed after the user information list field. This allows the receiver to initiate the integrity verification process earlier, thereby reducing latency and enabling the receiver to respond to the trigger frame promptly.

[0197] As stated above, although this paper primarily describes the technique in the context of securing trigger frames, similar approaches can be used to secure other types of control frames, especially those requiring an immediate response from the receiver.

[0198] Turn now Figure 26 The present invention will describe a method 2600 for security protection of control frames according to an exemplary embodiment. Method 2600 may be performed by a wireless device (e.g., wireless device 104).

[0199] Furthermore, although shown in a specific order, in some embodiments, the operations of method 2600 (and the operations of other methods shown in the figures) may be performed in a different order. For example, although the operations of method 2600 are shown to be performed sequentially, some operations may be performed in partially overlapping or completely overlapping time periods.

[0200] At operation 2605, the wireless device generates a control frame, wherein the control frame includes a key ID field preceding at least one field included in the body of the control frame and a MIC field following at least one field, wherein the key ID field carries a key ID and a packet number, and wherein the MIC field carries an authentication value used to verify the integrity of the control frame.

[0201] In one embodiment, the control frame is a trigger frame.

[0202] In one embodiment, as shown in box 2610, the key ID field includes a first key ID user information field and a second key ID user information field. In another embodiment, as shown in box 2615, the first key ID user information field includes a first association identifier field, a first key information sequence field, an internal key ID field, and a first group number field; and the second key ID user information field includes a second association identifier field, a second key information sequence field, and a second group number field. The internal key ID field carries the key ID, and the first and second group number fields jointly carry the group number. In one embodiment, the first key information sequence field carries the value 0, and the second key information sequence field carries the value 1. In one embodiment, the internal key ID field has a length of 3 bits, the first group number field has a length of 22 bits, and the second group number field has a length of 26 bits. In one embodiment, the first association identifier field and the second association identifier field each carry the value 4093.

[0203] In one embodiment, as shown in box 2620, the MIC field includes a first MIC user information field, a second MIC user information field, and a third MIC user information field (the MIC field may also include a fourth MIC user information field and a fifth MIC user information field). In one embodiment, as shown in box 2625, each MIC user information field includes an associated identifier field, a MIC information sequence field, and an internal MIC field, wherein the internal MIC field collectively carries the authentication value. For example, the first MIC user information field may include a first associated identifier field, a first MIC information sequence field, and a first internal MIC field; the second MIC user information field may include a second associated identifier field, a second MIC information sequence field, and a second internal MIC field; and the third MIC user information field may include a third associated identifier field, a third MIC information sequence field, and a third internal MIC field. In one embodiment, the first MIC information sequence field carries the binary value "00", the second MIC information sequence field carries the binary value "01", and the third MIC information sequence field carries the binary value "10". In one embodiment, the length of the first internal MIC field is 26 bits, the length of the second internal MIC field is 26 bits, and the length of the third internal MIC field is 12 bits. In one embodiment, the first associated identifier field, the second associated identifier field, and the third associated identifier field each carry the value 4094.

[0204] In an embodiment where the MIC fields (in addition to the first, second, and third MIC user information fields) also include a fourth and a fifth MIC user information field, the fourth MIC user information field may include a fourth associated identifier field, a fourth MIC information sequence field, and a fourth internal MIC field, and the fifth MIC user information field may include a fifth associated identifier field, a fifth MIC information sequence field, and a fifth internal MIC field. In one embodiment, the first MIC information sequence field may carry the binary value "00", the second MIC information sequence field may carry the binary value "01", the third MIC information sequence field may carry the binary value "10", the fourth MIC information sequence field may carry the binary value "110", and the fifth MIC information sequence field may carry the binary value "111". In one embodiment, the length of the first, second, and third internal MIC fields is 26 bits, the length of the fourth internal MIC field is 25 bits, and the length of the fifth internal MIC field is 25 bits. In one embodiment, the first, second, third, fourth, and fifth associated identifier fields each carry the value 4094.

[0205] In one embodiment, the wireless device generates an Authentication Advisory (AAD) based on the frame control field, first address field, and second address field included in the concatenation control frame, and generates an authentication value based on the AAD. In embodiments where the control frame is a trigger frame, the authentication value can also be generated based on the user information list field included in the trigger frame.

[0206] At operation 2630, the wireless device sends a control frame.

[0207] One embodiment is a wireless device configured to perform method 2600. For example, the wireless device may include circuitry operable to generate control frames, wherein the control frames include a key ID field preceding at least one field included in the body of the control frame and a MIC field following at least one field, wherein the key ID field carries a key ID and a packet number, and wherein the MIC field carries an authentication value used to verify the integrity of the control frame. The wireless device may also include a wireless transmitter operable to transmit the control frames.

[0208] Turn now Figure 27 The present invention will describe a method 2700 for verifying the integrity of a control frame according to an exemplary embodiment. Method 2700 may be performed by a wireless device (e.g., wireless device 104).

[0209] At operation 2705, the wireless device receives a control frame, wherein the control frame includes a key ID field preceding at least one field included in the body of the control frame and a MIC field following at least one field. In one embodiment, the control frame is a trigger frame. In such an embodiment, at least one field may include a user information list field.

[0210] At operation 2710, the wireless device extracts the key ID and packet number from the key ID field. In one embodiment (e.g., when the control frame is a trigger frame), as shown in block 2715, the key ID field includes a first key ID user information field and a second key ID user information field. In one embodiment, as shown in block 2720, the first key ID user information field includes a first association identifier field, a first key information sequence field, an internal key ID field, and a first packet number field, and the second key ID user information field includes a second association identifier field, a second key information sequence field, and a second packet number field, wherein the key ID is extracted from the internal key ID field, and the packet number is extracted from the first and second packet number fields. In one embodiment, the first key information sequence field carries a value of 0, and the second key information sequence field carries a value of 1. In one embodiment, the length of the internal key ID field is 3 bits, the length of the first packet number field is 22 bits, and the length of the second packet number field is 26 bits. In one embodiment, the first association identifier field and the second association identifier field each carry a value of 4093. The wireless device may begin the integrity verification process using the key ID and / or the packet number before fully receiving the payload of the control frame.

[0211] At operation 2725, the wireless device extracts the authentication value from the MIC field. In one embodiment (e.g., when the control frame is a trigger frame), as shown in box 2730, the MIC field includes a first MIC user information field, a second MIC user information field, and a third MIC user information field (the MIC field may also include a fourth MIC user information field and a fifth MIC user information field). In one embodiment, as shown in box 2735, each MIC user information field includes an associated identifier field, a MIC information sequence field, and an internal MIC field, wherein the authentication value is extracted from the internal MIC field. For example, the first MIC user information field may include a first associated identifier field, a first MIC information sequence field, and a first internal MIC field; the second MIC user information field may include a second associated identifier field, a second MIC information sequence field, and a second internal MIC field; and the third MIC user information field may include a third associated identifier field, a third MIC information sequence field, and a third internal MIC field. In one embodiment, the first MIC information sequence field carries the binary value "00", the second MIC information sequence field carries the binary value "01", and the third MIC information sequence field carries the binary value "10". In one embodiment, the first internal MIC field has a length of 26 bits, the second internal MIC field has a length of 26 bits, and the third internal MIC field has a length of 12 bits. In one embodiment, the first associated identifier field, the second associated identifier field, and the third associated identifier field each carry a value of 4094.

[0212] In an embodiment where the MIC fields (in addition to the first, second, and third MIC user information fields) also include a fourth and a fifth MIC user information field, the fourth MIC user information field may include a fourth associated identifier field, a fourth MIC information sequence field, and a fourth internal MIC field, and the fifth MIC user information field may include a fifth associated identifier field, a fifth MIC information sequence field, and a fifth internal MIC field. In one embodiment, the first MIC information sequence field carries the binary value "00", the second MIC information sequence field carries the binary value "01", the third MIC information sequence field carries the binary value "10", the fourth MIC information sequence field carries the binary value "110", and the fifth MIC information sequence field carries the binary value "111". In one embodiment, the length of the first internal MIC field is 26 bits, the length of the second internal MIC field is 26 bits, the length of the third internal MIC field is 26 bits, the length of the fourth internal MIC field is 25 bits, and the length of the fifth internal MIC field is 25 bits. In one embodiment, the first, second, third, fourth, and fifth associated identifier fields each carry the value 4094.

[0213] At operation 2740, the wireless device uses the key ID, packet number, and authentication value to verify the integrity of the control frame. If the integrity verification is successful, the wireless device can accept the control frame and process it further. Otherwise, if the integrity verification fails, the wireless device can reject the control frame.

[0214] One embodiment is a wireless device configured to perform method 2700. For example, the wireless device may include a wireless receiver operable to receive a control frame, wherein the control frame includes a key ID field preceding at least one field included in the body of the control frame and a MIC field following at least one field. The wireless device may also include circuitry operable to extract a key ID and a packet number from the key ID field, extract an authentication value from the MIC field, and use the key ID, packet number, and authentication value to verify the integrity of the control frame.

[0215] While many of the solutions and techniques provided herein have been described with reference to WLAN systems, it should be understood that these solutions and techniques are also applicable to other network environments, such as cellular telecommunications networks, wired networks, etc. In some embodiments, the solutions and techniques provided herein may be an article of manufacture or may be embodied in an article of manufacture, in which instructions for programming one or more data processing components (collectively referred to herein as “processors” or “processing units”) to perform the operations described herein are stored on a non-transitory machine-readable medium (e.g., microelectronic memory). In other embodiments, some of these operations may be performed by specific hardware components that include hard-wired logic (e.g., dedicated digital filter modules and state machines). Alternatively, these operations may be performed by any combination of programmed data processing components and fixed hard-wired circuit components.

[0216] In some cases, an embodiment may be an apparatus (e.g., an AP STA, a non-AP STA, or another network or computing device) that includes one or more hardware and software logical structures for performing one or more of the operations described herein. For example, as described herein, the apparatus may include a memory unit storing instructions executable by a hardware processor mounted in the apparatus. The apparatus may also include one or more other hardware or software elements, including a network interface, a display device, etc.

[0217] Some parts of the foregoing specific embodiments have been presented in the form of algorithms and symbolic representations of operations on data bits in computer memory. These algorithmic descriptions and representations are the most effective way for those skilled in the art of data processing to communicate the essence of their work to others skilled in the art. Algorithms, as described herein and in general, are considered to be self-consistent sequences of operations that produce desired results. An operation is an operation that requires physical manipulation of physical quantities. Usually, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Sometimes, mainly for reasons of common usage, it has proven convenient to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc.

[0218] However, it should be remembered that all these terms and similar terms should be associated with appropriate physical quantities and are merely convenient labels applied to those quantities. This disclosure may relate to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities in the registers and memories of the computer system to make it other data similarly represented as physical quantities in the memory or registers or other such information storage systems of the computer system.

[0219] This disclosure also relates to means for performing the operations described herein. Such means may be specifically constructed for an intended purpose or may include a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. For example, a computer system or other data processing system may implement the computer-implemented methods described herein in response to its processor executing a computer program (e.g., a sequence of instructions) contained in memory or other non-transitory machine-readable storage medium. Such computer programs may be stored in computer-readable storage media, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards or optical cards, or any type of medium suitable for storing electronic instructions, each of which is coupled to a computer system bus.

[0220] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used with the programs taught herein, or it may prove convenient to construct more specialized devices to perform the methods. The structures of various such systems will be presented as illustrated in the following description. Furthermore, this disclosure is not described with reference to any particular programming language. It should be understood that the teachings of this disclosure as described herein can be implemented using various programming languages.

[0221] This disclosure may be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, the instructions being used to program a computer system (or other electronic device) to perform processes according to this disclosure. Machine-readable media include any mechanism for storing information in a machine-readable (e.g., computer-readable) form. In some embodiments, machine-readable (e.g., computer-readable) media include machine-readable (e.g., computer-readable) storage media, such as read-only memory (“ROM”), random access memory (“RAM”), disk storage media, optical storage media, flash memory components, etc.

[0222] In the foregoing description, embodiments of the present disclosure have been described with reference to specific exemplary embodiments. It is obvious that various modifications can be made thereto without departing from the broader spirit and scope of the embodiments of the present disclosure set forth in the following claims. Therefore, the description and drawings should be considered illustrative rather than restrictive.

Claims

1. A method for security protection of control frames, performed by a wireless device, the method comprising: Generate the control frame, wherein the control frame includes a key ID field and a message integrity verification (MIC) field, the key ID field appearing before at least one field included in the body of the control frame, and the MIC field appearing after the at least one field, wherein the key ID field carries a key ID and a group number, and wherein the MIC field carries an authentication value used to verify the integrity of the control frame; and Send the control frame.

2. The method according to claim 1, wherein, The control frame is a trigger frame, and the at least one field includes a user information list field, wherein the key ID field includes a first key ID user information field and a second key ID user information field.

3. The method according to claim 2, wherein, The first key ID user information field includes a first association identifier field, a first key information sequence field, an internal key ID field, and a first group number field. The second key ID user information field includes a second association identifier field, a second key information sequence field, and a second group number field. The internal key ID field carries the key ID. The first group number field and the second group number field together carry the group number.

4. The method according to claim 3, wherein, The first key information sequence field carries a value of 0, and the second key information sequence field carries a value of 1.

5. The method according to claim 3, wherein, The internal key ID field is 3 bits long, the first group number field is 22 bits long, and the second group number field is 26 bits long.

6. The method according to claim 3, wherein, The first association identifier field and the second association identifier field each carry the value 4093.

7. The method according to claim 1, wherein, The control frame is a trigger frame, and the at least one field includes a user information list field, wherein the MIC field includes a first MIC user information field, a second MIC user information field, and a third MIC user information field.

8. The method according to claim 7, wherein, The first MIC user information field includes a first associated identifier field, a first MIC information sequence field, and a first internal MIC field. The second MIC user information field includes a second associated identifier field, a second MIC information sequence field, and a second internal MIC field. The third MIC user information field includes a third associated identifier field, a third MIC information sequence field, and a third internal MIC field. The first internal MIC field, the second internal MIC field, and the third internal MIC field together carry the authentication value.

9. The method according to claim 8, wherein, The first MIC information sequence field carries the binary value "00", the second MIC information sequence field carries the binary value "01", and the third MIC information sequence field carries the binary value "10".

10. The method according to claim 8, wherein, The first internal MIC field has a length of 26 bits, the second internal MIC field has a length of 26 bits, and the third internal MIC field has a length of 12 bits.

11. The method according to claim 8, wherein, The first associated identifier field, the second associated identifier field, and the third associated identifier field each carry the value 4094.

12. The method according to claim 7, wherein, The MIC field also includes a fourth MIC user information field and a fifth MIC user information field.

13. The method according to claim 12, wherein, The first MIC user information field includes a first associated identifier field, a first MIC information sequence field, and a first internal MIC field. The second MIC user information field includes a second associated identifier field, a second MIC information sequence field, and a second internal MIC field. The third MIC user information field includes a third associated identifier field, a third MIC information sequence field, and a third internal MIC field. The fourth MIC user information field includes a fourth associated identifier field, a fourth MIC information sequence field, and a fourth internal MIC field. The fifth MIC user information field includes a fifth associated identifier field, a fifth MIC information sequence field, and a fifth internal MIC field. The first internal MIC field, the second internal MIC field, the third internal MIC field, the fourth internal MIC field, and the fifth internal MIC field together carry the authentication value.

14. The method according to claim 13, wherein, The first MIC information sequence field carries the binary value "00", the second MIC information sequence field carries the binary value "01", the third MIC information sequence field carries the binary value "10", the fourth MIC information sequence field carries the binary value "110", and the fifth MIC information sequence field carries the binary value "111".

15. The method according to claim 13, wherein, The first internal MIC field has a length of 26 bits, the second internal MIC field has a length of 26 bits, the third internal MIC field has a length of 26 bits, the fourth internal MIC field has a length of 25 bits, and the fifth internal MIC field has a length of 25 bits.

16. The method according to claim 13, wherein, The first associated identifier field, the second associated identifier field, the third associated identifier field, the fourth associated identifier field, and the fifth associated identifier field each carry the value 4094.

17. The method according to claim 1, further comprising: Additional authentication data (AAD) is generated based on the frame control field, the first address field, and the second address field included in the concatenated control frame. and The authentication value is generated based on the AAD.

18. The method according to claim 17, wherein, The control frame is a trigger frame, and the authentication value is generated based on the user information list field included in the trigger frame.

19. A method for verifying the integrity of a control frame, the method comprising: The control frame is received, wherein the control frame includes a key ID field and a message integrity verification (MIC) field, the key ID field appears before at least one field included in the body of the control frame, and the MIC field appears after the at least one field; Extract the key ID and group number from the key ID field; Extract the authentication value from the MIC field; and The integrity of the control frame is verified using the key ID, the group number, and the authentication value.

20. The method according to claim 19, wherein, The control frame is a trigger frame, and the at least one field includes a user information list field, wherein the key ID field includes a first key ID user information field and a second key ID user information field.

21. The method according to claim 20, wherein, The first key ID user information field includes a first association identifier field, a first key information sequence field, an internal key ID field, and a first group number field. The second key ID user information field includes a second association identifier field, a second key information sequence field, and a second group number field. The key ID is extracted from the internal key ID field, and the group number is extracted from the first group number field and the second group number field.

22. The method according to claim 21, wherein, The first key information sequence field carries a value of 0, and the second key information sequence field carries a value of 1.

23. The method according to claim 21, wherein, The internal key ID field is 3 bits long, the first group number field is 22 bits long, and the second group number field is 26 bits long.

24. The method according to claim 21, wherein, The first association identifier field and the second association identifier field each carry the value 4093.

25. The method according to claim 19, wherein, The control frame is a trigger frame, and the at least one field includes a user information list field, wherein the MIC field includes a first MIC user information field, a second MIC user information field, and a third MIC user information field.

26. The method of claim 25, wherein, The first MIC user information field includes a first associated identifier field, a first MIC information sequence field, and a first internal MIC field. The second MIC user information field includes a second associated identifier field, a second MIC information sequence field, and a second internal MIC field. The third MIC user information field includes a third associated identifier field, a third MIC information sequence field, and a third internal MIC field. The authentication value is extracted from the first internal MIC field, the second internal MIC field, and the third internal MIC field.

27. The method according to claim 26, wherein, The first MIC information sequence field carries the binary value "00", the second MIC information sequence field carries the binary value "01", and the third MIC information sequence field carries the binary value "10".

28. The method according to claim 26, wherein, The first internal MIC field has a length of 26 bits, the second internal MIC field has a length of 26 bits, and the third internal MIC field has a length of 12 bits.

29. The method according to claim 26, wherein, The first associated identifier field, the second associated identifier field, and the third associated identifier field each carry the value 4094.

30. The method according to claim 25, wherein, The MIC field also includes a fourth MIC user information field and a fifth MIC user information field.

31. The method according to claim 30, wherein, The first MIC user information field includes a first associated identifier field, a first MIC information sequence field, and a first internal MIC field. The second MIC user information field includes a second associated identifier field, a second MIC information sequence field, and a second internal MIC field. The third MIC user information field includes a third associated identifier field, a third MIC information sequence field, and a third internal MIC field. The fourth MIC user information field includes a fourth associated identifier field, a fourth MIC information sequence field, and a fourth internal MIC field. The fifth MIC user information field includes a fifth associated identifier field, a fifth MIC information sequence field, and a fifth internal MIC field. The authentication value is extracted from the first internal MIC field, the second internal MIC field, the third internal MIC field, the fourth internal MIC field, and the fifth internal MIC field.

32. The method according to claim 31, wherein, The first MIC information sequence field carries the binary value "00", the second MIC information sequence field carries the binary value "01", the third MIC information sequence field carries the binary value "10", the fourth MIC information sequence field carries the binary value "110", and the fifth MIC information sequence field carries the binary value "111".

33. The method according to claim 31, wherein, The first internal MIC field has a length of 26 bits, the second internal MIC field has a length of 26 bits, the third internal MIC field has a length of 26 bits, the fourth internal MIC field has a length of 25 bits, and the fifth internal MIC field has a length of 25 bits.

34. The method according to claim 31, wherein, The first associated identifier field, the second associated identifier field, the third associated identifier field, the fourth associated identifier field, and the fifth associated identifier field each carry the value 4094.

35. A wireless device configured to securely protect control frames, the wireless device comprising: A circuit operable to generate the control frame, wherein the control frame includes a key ID field and a message integrity verification (MIC) field, the key ID field appearing before at least one field included in the body of the control frame, and the MIC field appearing after the at least one field, wherein the key ID field carries a key ID and a block number, and wherein the MIC field carries an authentication value for verifying the integrity of the control frame; and A wireless transmitter, operable to transmit the control frame.

36. A wireless device configured to verify the integrity of control frames, the wireless device comprising: A wireless receiver operable to receive the control frame, wherein the control frame includes a key ID field and a message integrity check (MIC) field, the key ID field appearing before at least one field included in the body of the control frame, and the MIC field appearing after the at least one field; and A circuit operable to extract a key ID and a group number from the key ID field, extract an authentication value from the MIC field, and use the key ID, the group number, and the authentication value to verify the integrity of the control frame.

Images