Securing control frames in wireless networks

Abstract

An embodiment is a method performed by a wireless device to secure a control frame. The method includes generating the control frame, wherein the control frame includes a key ID field that appears before at least one field included in a body of the control frame and a message integrity check (MIC) field that appears 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 an integrity of the control frame. The method further includes transmitting the control frame.

Description

SPECIFICATIONSECURING CONTROL FRAMES IN WIRELESS NETWORKSCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 556,849 filed February 22, 2024, which is hereby incorporated by reference.TECHNICAL FIELD

[0002] The present disclosure generally relates to wireless communications, and more specifically, relates to securing control frames in wireless networks.BACKGROUND

[0003] Institute of Electrical and Electronics Engineers (IEEE) 802.11 is a set of standards for implementing wireless local area network communication in various frequencies, including but not limited to the 2.4 gigahertz (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.1 In, 802.1 lac, and 802.1 lax (also known as “Wi-Fi 6”). These standards specify the modulation techniques, channel bandwidths, and other technical aspects that facilitate interoperability between devices from various manufacturers. IEEE 802.11 has played an important role in the widespread adoption of wireless networking in homes, offices, and public spaces, enabling users to connect their devices to the internet and each other without the need for wired connections.

[0004] IEEE 802.1 Ibe, also known as “Wi-Fi 7”, is the next generation of the IEEE 802.11 family of standards for wireless local area networks. Currently under development, 802.1 Ibe aims to significantly improve upon the capabilities of its predecessor, 802.1 lax / Wi-Fi 6, by offering even higher data rates, lower latency, and increased reliability. The standard is expected to leverage advanced technologies such as multi-link operation (MLO), which allows devices to simultaneously use multiple frequency bands and channels for enhanced performance and reliability. Additionally, 802.1 Ibe will introduce 4096-QAM (Quadrature Amplitude Modulation), enabling higher data rates by encoding more bits per symbol. The standard will also feature improved medium access control (MAC) efficiency, enhanced power savingcapabilities, and better support for high-density environments. With these advancements, 802.1 Ibe is expected to deliver theoretical maximum data rates 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.1 Ibe standard is projected to be finalized by the end of 2024, paving the way for the next generation of Wi-Fi devices and networks.

[0005] An access point (AP) may transmit a trigger frame to non-AP stations (STAs) to solicit a simultaneous uplink transmission from the STAs. The trigger frame may include resource allocation information for the STAs that are to participate in the uplink transmission. A STA that receives a trigger frame and that has been allocated resources may respond to the trigger frame by transmitting a trigger-based physical layer protocol data unit (TB PPDU) to the AP following a short interframe space (SIFS) interval after receiving the trigger frame. Since the AP can use a trigger frame to control the behavior of multiple STAs, it is important to secure the trigger frame. For example, it is important for STAs that receive the trigger frame to be able to check the integrity of the trigger frame. However, existing wireless networking standards do not provide a mechanism to secure trigger frames.

[0006] Existing wireless networking standards use the broadcast integrity protocol (BIP) to secure group addressed management frames. With BIP, a management message integrity check (MIC) element that carries security materials needed to perform an integrity check is added to the end of the frame body field. The security materials may include a key ID, packet number (PN), and a message integrity check (MIC) authentication value.

[0007] One way to secure a trigger frame would be to apply BIP to the trigger frame. For example, an authentication value can be generated for the parts of the trigger frame that need to be secured and the authentication value may be added to the end of the trigger frame together with other security materials that are needed to check the integrity of the trigger frame (e.g., key ID and packet number). However, such an approach is not suitable for trigger frames because the BIP integrity check process may take too long for the STA to transmit the TB PPDU in the requisite time (e.g., the TB PPDU needs to be transmitted a SIFS interval after receiving the trigger frame). Therefore, there is a need for a way to minimize / reduce the time delay of checking the integrity of a trigger frame to allow STAs that receive the trigger frame to be able to transmit the TB PPDU in requisite time.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The disclosure will be more fully understood from the detailed description provided below and the accompanying drawings that depict various embodiments of the disclosure. However, these drawings should not be interpreted as limiting the disclosure to the specific embodiments shown; they are provided for explanation and understanding only.

[0009] Figure 1 illustrates an example of a wireless local area network (WLAN) with a basic service set (BSS) that includes multiple wireless devices, in accordance with some embodiments of the present disclosure.

[0010] Figure 2 is a schematic diagram of a wireless device, in accordance with some embodiments of the present disclosure.

[0011] Figure 3 A illustrates components of a wireless device configured to transmit data, in accordance with some embodiments of the present disclosure.

[0012] Figure 3B illustrates components of a wireless device configured to receive data, in accordance with some embodiments of the present disclosure.

[0013] Figure 4 illustrates interframe space (IFS) relationships, in accordance with some embodiments of the present disclosure.

[0014] Figure 5 illustrates a Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA)-based frame transmission procedure, in accordance with some embodiments of the present disclosure.

[0015] Figure 6 illustrates maximum physical layer (PHY) rates for Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards, in accordance with some embodiments of the present disclosure.

[0016] Figure 7 provides a detailed description of fields in Extremely High Throughput (EHT) Physical Protocol Data Unit (PPDU) frames, including their purposes and characteristics, in accordance with some embodiments of the present disclosure.

[0017] Figure 8 illustrates an example of multi-user (MU) transmission in Orthogonal Frequency-Division Multiple Access (OFDMA), in accordance with some embodiments of the present disclosure.

[0018] Figure 9 illustrates an example of an access point sending a trigger frame to multiple associated stations and receiving Uplink Orthogonal Frequency-Division Multiple Access Trigger-Based Physical Protocol Data Units (UL OFDMA TB PPDUs) in response, in accordance with some embodiments of the present disclosure.

[0019] Figure 10 is a diagram showing a format of a media access control protocol data unit (MPDU) with a non-encrypted frame body field, according to some embodiments.

[0020] Figure 11 is a diagram showing a format of an MPDU with an encrypted frame body field, according to some embodiments.

[0021] Figure 12 is a diagram showing a way to generate additional authentication data (AAD), according to some embodiments.

[0022] Figure 13 is a diagram showing a format of a frame control field, according to some embodiments.

[0023] Figure 14 is a diagram showing a format of a sequence control field, according to some embodiments.

[0024] Figure 15 is a diagram showing a format of a management frame, according to some embodiments.

[0025] Figure 16 is a diagram showing a format of a management MIC element, according to some embodiments.

[0026] Figure 17 is a diagram showing a way to generate additional authentication data (AAD) in broadcast integrity protocol (BIP), according to some embodiments.

[0027] Figure 18 is a diagram showing a format of a trigger frame, according to some embodiments.

[0028] Figure 19 is a diagram showing a format of a user info field, according to some embodiments.

[0029] Figure 20 is a diagram showing a format of a special user info field, according to some embodiments.

[0030] Figure 21 is a diagram showing a format of AAD that can be used for securing a trigger frame, according to some embodiments.

[0031] Figure 22 is a diagram showing a format of a secured trigger frame, according to some embodiments.

[0032] Figure 23 is a diagram showing a format of key ID user info fields, according to some embodiments.

[0033] Figure 24 is a diagram showing a format of message integrity check (MIC) user info fields when the length of the authentication value is 64 bits, according to some embodiments.

[0034] Figure 25 is a diagram showing a format of MIC user info fields when the length of the authentication value is 128 bits, according to some embodiments.

[0035] Figure 26 is a flow diagram of a method for securing a control frame, according to some embodiments.

[0036] Figure 27 is a flow diagram of a method for checking an integrity of a control frame, according to some embodiments.DETAILED DESCRIPTION

[0037] The present disclosure generally relates to wireless communications, and more specifically, relates to securing control frames (e.g., trigger frames) in wireless networks.

[0038] Broadcast integrity protocol (BIP) may be used to secure group addressed management frames. The security materials needed in BIP to perform an integrity check are key ID, packet number (PN), and a message integrity check (MIC) authentication value (which may be referred to herein simply as “authentication value”). In BIP, these security materials are carried in a management MIC element that is added to the end of the frame body field.

[0039] As mentioned above, existing wireless networking standards do not provide a mechanism to secure trigger frames. One way to secure trigger frames would be to apply BIP to trigger frames. However, with trigger frames, the recipient needs to be able to perform the integrity check quickly because the recipient has to transmit a trigger-based physical layer protocol data unit (TB PPDU) following a short interframe space (SIFS) interval after receiving the trigger frame. The recipient needs to obtain the key ID to obtain the cipher key needed to generate and check the authentication value. Also, the recipient needs to obtain the PN to begin generating the authentication value. As such, if the key ID and PN appear towards the end of the trigger frame, as done in BIP, the generation of the authentication value can only begin after the entire trigger frame has been received or almost all of the trigger frame has been received. In this case, the recipient may not be able to perform the integrity check quickly enough to be able to transmit the TB PPDU in the requisite time (e.g., after a SIFS interval following reception of the trigger frame). To address this problem, techniques are described herein that allow the recipient to be able to begin the integrity check process early in the trigger frame reception process so that the recipient can complete the integrity check in time to be able to transmit the TB PPDU in the requisite time. The techniques described herein achieve this by providing the key ID and PN towards the beginning of the trigger frame, which allows the recipient to be able to start the security engine and start the integrity check process early (e.g., identify the key early), while the trigger frame is still being received. While the techniques are primarily described herein in the context of securing trigger frames, a similar approach may be used to secure other types of control frames, and particularly control frames that require an immediate response from the recipient.

[0040] Techniques are described herein for securing a control frame. According to some embodiments, a transmitting wireless device may generate a control frame. The control frame may include a key ID field that appears before at least one field included in a body of the control frame. The key ID field may carry a key ID and a PN. Also, the control frame may include aMIC field that appears after the at least one field. The MIC field may carry an authentication value that can be used for checking an integrity of the control frame. The transmitting wireless device may then transmit the control frame.

[0041] A receiving wireless device may receive the control frame. The receiving wireless device may extract the key ID and the PN from the key ID field of the control frame, and start the integrity check process. The receiving wireless device may then extract the authentication value from the MIC field of the control frame. The receiving wireless device may then check the integrity of the control frame using the key ID, PN, and the authentication value. If the integrity check is successful, the receiving wireless device may transmit a response frame to the transmitting wireless device.

[0042] In an embodiment, the control frame is a trigger frame. In such case, the at least one field may include a user information (also referred to as a “user info” field). The key ID field may include two key ID user information fields. The key ID user information fields may have a similar format as a user information field to ensure compatibility with legacy wireless devices that implement 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 as a user information field to ensure compatibility with legacy wireless devices that implement previous wireless networking standards.

[0043] The techniques described herein may provide one or more advantages. For example, the techniques described herein may provide security for control frames. The recipient of the control frame may be able to start the integrity check process for the control frame early (e.g., while still receiving the control frame), which may allow the recipient to provide an immediate response to the control frame in the requisite time (e.g., after a SIFS interval following reception of the control frame). While certain advantages are mentioned here, one having ordinary skill in the relevant art will appreciate that the techniques described herein may have other advantages in view of the present disclosure.

[0044] For purposes of illustration, various embodiments are described herein in the context of wireless networks that are based on IEEE 802.11 standards and using terminology and concepts thereof. Those skilled in the art will appreciate that the embodiments disclosed herein can be modified / adapted for use in other types of wireless networks.

[0045] In the following detailed description, only certain embodiments of the present invention have been shown and described, simply by way of illustration. As those skilled in the art would realize, the described embodiments may be modified in different ways, all without departing from the spirit or scope of the present invention. Accordingly, the drawings anddescription are to be regarded as illustrative in nature and not restrictive. Like reference numerals designate like elements throughout the specification.

[0046] Figure 1 shows a wireless local area network (WLAN) 100 with a basic service set (BSS) 102 that includes a plurality of wireless devices 104 (sometimes referred to as WLAN devices 104). Each of the wireless devices 104 may include a medium access control (MAC) layer and a physical (PHY) layer according to an IEEE (Institute of Electrical and Electronics Engineers) standard 802.11, including one or more of the amendments(e.g., 802.1 la / b / g / n / p / ac / ax / bd / be). In one embodiment, the MAC layer of a wireless device 104 may initiate 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 a corresponding frame. Similarly, a PHY layer of a receiving wireless device may generate an RXVECTOR, which includes parameters of a received frame and is passed to a MAC layer for processing.

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

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

[0049] 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 thememory 232, which may include a non-transitory computer / machine readable medium having software (e.g., computer / machine programing instructions) and data stored therein.

[0050] In an 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 may implement a first plurality of functions of the MAC layer by executing MAC software, which may be included in the software stored in the storage device 232. The MAC hardware processing unit 216 may implement a second plurality of functions of the MAC layer in specialpurpose hardware. However, the MAC processor 212 is not limited thereto. For example, the MAC processor 212 may be configured to perform the first and second plurality of functions entirely in software or entirely in hardware according to an implementation.

[0051] The PHY processor 222 includes a transmitting (TX) signal processing unit (SPU) 224 and a receiving (RX) SPU 226. The PHY processor 222 implements a plurality of functions of the PHY layer. These functions may be performed in software, hardware, or a combination thereof according to an implementation.

[0052] Functions performed by the transmitting SPU 224 may include one or more of Forward Error Correction (FEC) encoding, stream parsing into one or more spatial streams, diversity encoding of the spatial streams into a plurality of space-time streams, spatial mapping of the space-time streams to transmit chains, inverse Fourier Transform (iFT) computation, Cyclic Prefix (CP) insertion to create a Guard Interval (GI), and the like. Functions performed by the receiving SPU 226 may include inverses of the functions performed by the transmitting SPU 224, such as GI removal, Fourier Transform computation, and the like.

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

[0054] The antenna unit 250 includes one or more antennas. When Multiple-Input Multiple- Output (MIMO) or Multi-User MIMO (MU-MIMO) is used, the antenna unit 250 may include a plurality of antennas. In an embodiment, the antennas in the antenna unit 250 may operate as a beam-formed antenna array. In an embodiment, the antennas in the antenna unit 250 may be directional antennas, which may be fixed or steerable.

[0055] The input interfaces 234 receive information from a user, and the output interfaces 236 output information to the user. The input interfaces 234 may include one or more of a keyboard,keypad, mouse, touchscreen, microphone, and the like. The output interfaces 236 may include one or more of a display device, touch screen, speaker, and the like.

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

[0057] As described herein, a wide variety of electronic devices, circuits, firmware, software, and combinations thereof may be used to implement the functions of the components of the WLAN device 104. Furthermore, the WLAN device 104 may include other components, such as application processors, storage interfaces, clock generator circuits, power supply circuits, and the like, which have been omitted in the interest of brevity.

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

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

[0060] The encoder 300 receives and encodes input data. In an embodiment, the encoder 300 includes a forward error correction (FEC) encoder. The FEC encoder may include a binary convolution code (BCC) encoder followed by a puncturing device. The FEC encoder may include a low-density parity-check (LDPC) encoder.

[0061] The TxSP 324 may further include a scrambler for scrambling the input data before the encoding is performed by the encoder 300 to reduce the probability of long sequences of 0s or Is. When the encoder 300 performs the BCC encoding, the TxSP 324 may further include an encoder parser for demultiplexing the scrambled bits among a plurality of BCC encoders. If LDPC encoding is used in the encoder, the TxSP 324 may not use the encoder parser.

[0062] The interleaver 302 interleaves the bits of each stream output from the encoder 300 to change an order of bits therein. The interleaver 302 may apply the interleaving only when the encoder 300 performs BCC encoding and otherwise may output the stream output from the encoder 300 without changing the order of the bits therein.

[0063] The mapper 304 maps the sequence of bits output from the interleaver 302 to constellation points. If the encoder 300 performed LDPC encoding, the mapper 304 may also perform LDPC tone mapping in addition to constellation mapping.

[0064] When the TxSP 324 performs a MIMO or MU-MIMO transmission, the TxSP 324 may include a plurality of interleavers 302 and a plurality of mappers 304 according to a number of spatial streams (NSS) of the transmission. The TxSP 324 may further include a stream parser for dividing the output of the encoder 300 into blocks and may respectively send the blocks to different interleavers 302 or mappers 304. The TxSP 324 may further include a space-time block code (STBC) encoder for spreading the constellation points from the spatial streams into a number of space-time streams (NSTS) and a spatial mapper for mapping the space-time streams to transmit chains. The spatial mapper may use direct mapping, spatial expansion, or beamforming.

[0065] The IFT 306 converts a block of the constellation points output from the mapper 304 (or, when MIMO or MU-MIMO is performed, the spatial mapper) to a time domain block (i.e., a symbol) by using an inverse discrete Fourier transform (IDFT) or an inverse fast Fourier transform (IFFT). If the STBC encoder and the spatial mapper are used, the IFT 306 may be provided for each transmit chain.

[0066] When the TxSP 324 performs a MIMO or MU-MIMO transmission, the TxSP 324 may insert cyclic shift diversities (CSDs) to prevent unintentional beamforming. The TxSP 324 may perform the insertion of the CSD before or after the IFT 306. The CSD may be specified per transmit chain or may be specified per space-time stream. Alternatively, the CSD may be applied as a part of the spatial mapper.

[0067] When the TxSP 324 performs a MIMO or MU-MIMO transmission, some blocks before the spatial mapper may be provided for each user.

[0068] The GI inserter 308 prepends a GI to each symbol produced by the IFT 306. Each GI may include a Cyclic Prefix (CP) corresponding to a repeated portion of the end of the symbol that the GI precedes. The TxSP 324 may optionally perform windowing to smooth edges of each symbol after inserting the GI.

[0069] The RF transmitter 342 converts the symbols into an RF signal and transmits the RF signal via the antenna 352. When the TxSP 324 performs a MIMO or MU-MIMO transmission, the GI inserter 308 and the RF transmitter 342 may be provided for each transmit chain.

[0070] Figure 3B illustrates components of a WLAN device 104 configured to receive data according to an embodiment, including a Receiver (Rx) SPU (RxSP) 326, an RF receiver 344, and an antenna 354. In an embodiment, the RxSP 326, RF receiver 344, and antenna 354 maycorrespond to the receiving SPU 226, the RF receiver 244, and an antenna of the antenna unit 250 of Figure 2, respectively.

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

[0072] The RF receiver 344 receives an RF signal via the antenna 354 and converts the RF signal into symbols. The GI remover 318 removes the GI from each of the symbols. When the received transmission is a MIMO or MU-MIMO transmission, the RF receiver 344 and the GI remover 318 may be provided for each receive chain.

[0073] The FT 316 converts each symbol (that is, each time domain block) into a frequency domain block of constellation points by using a discrete Fourier transform (DFT) or a fast Fourier transform (FFT). The FT 316 may be provided for each receive chain.

[0074] When the received transmission is the MIMO or MU-MIMO transmission, the RxSP 326 may include a spatial demapper for converting the respective outputs of the FTs 316 of the receiver chains to constellation points of a plurality of space-time streams, and an STBC decoder for despreading the constellation points from the space-time streams into one or more spatial streams.

[0075] The demapper 314 demaps the constellation points output from the FT 316 or the STBC decoder to bit streams. If the received transmission was encoded using LDPC encoding, the demapper 314 may further perform LDPC tone demapping before performing the constellation demapping.

[0076] The deinterleaver 312 deinterleaves the bits of each stream output from the demapper 314. The deinterleaver 312 may perform the deinterleaving only when the received transmission was encoded using BCC encoding, and otherwise may output the stream output by the demapper 314 without performing deinterleaving.

[0077] When the received transmission is the MIMO or MU-MIMO transmission, the RxSP 326 may use a plurality of demappers 314 and a plurality of deinterleavers 312 corresponding to the number of spatial streams of the transmission. In this case, the RxSP 326 may further include a stream deparser for combining the streams output from the deinterleavers 312.

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

[0079] The RxSP 326 may further include a descrambler for descrambling the decoded data. When the decoder 310 performs BCC decoding, the RxSP 326 may further include an encoderdeparser for multiplexing the data decoded by a plurality of BCC decoders. When the decoder 310 performs the LDPC decoding, the RxSP 326 may not use the encoder deparser.

[0080] Before making a transmission, wireless devices such as wireless device 104 will assess the availability of the wireless medium using Clear Channel Assessment (CCA). If the medium is occupied, CCA may determine that it is busy, while if the medium is available, CCA determines that it is idle.

[0081] The PHY entity for IEEE 802.11 is based on Orthogonal Frequency Division Multiplexing (OFDM) or Orthogonal Frequency Division Multiple Access (OFDMA). In either OFDM or OFDMA Physical (PHY) layers, a STA (e.g., a wireless device 104) is capable of transmitting and receiving Physical Layer (PHY) Protocol Data Units (PPDUs) (also referred to as PLCP (Physical Layer Convergence Procedure) Protocol Data Units) that are compliant with the mandatory PHY specifications. A 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 having a maximum number of space-time streams (STS) per user and employing up to a predetermined total number of STSs. A PHY entity may provide support for 10 Megahertz (MHz), 20 MHz, 40 MHz, 80 MHz, 160 MHz, 240 MHz, and 320 MHz contiguous channel widths and support for an 80+80, 80+160 MHz, and 160+160 MHz non-contiguous channel width. Each channel includes a plurality of subcarriers, which may also be referred to as tones. A PHY entity may define signaling fields denoted as Legacy Signal (L-SIG), Signal A (SIG-A), and Signal B (SIG-B), and the like within a PPDU by which some necessary information about PHY Service Data Unit (PSDU) attributes are communicated. The descriptions below, for sake of completeness and brevity, refer to OFDM-based 802.11 technology. Unless otherwise indicated, a station refers to a non-AP STA.

[0082] Figure 4 illustrates Inter-Frame Space (IFS) relationships. In particular, Figure 4 illustrates a Short IFS (SIFS), a Point Coordination Function (PCF) IFS (PIFS), a Distributed Coordination Function (DCF) IFS (DIFS), and an Arbitration IFSs corresponding to an Access Category (AC) ‘i’ (AIFS[i]). Figure 4 also illustrates a slot time and a data frame is used for transmission of data forwarded to a higher layer. As shown, a WLAN device 104 transmits the data frame after performing backoff if a DIFS has elapsed during which the medium has been idle.

[0083] A management frame may be used for exchanging management information, which is not forwarded to the higher layer. Subtype frames of the management frame include a beacon frame, an association request / response frame, a probe request / response frame, and an authentication request / response frame.

[0084] A control frame may be used for controlling access to the medium. Subtype frames of the control frame include a request to send (RTS) frame, a clear to send (CTS) frame, and an acknowledgement (ACK) frame.

[0085] When the control frame is not a response frame of another frame, the WLAN device 104 transmits the control frame after performing backoff if a DIFS has elapsed during which the medium has been idle. When the control frame is the response frame of another frame, the WLAN device 104 transmits the control frame after a SIFS has elapsed without performing backoff or checking whether the medium is idle.

[0086] A WLAN device 104 that supports Quality of Service (QoS) functionality (that is, a QoS STA) may transmit the frame after performing backoff if an AIFS for an associated access category (AC) (i.e., AIFS[AC]) has elapsed. When transmitted by the QoS STA, any of the data frame, the management frame, and the control frame, which is not the response frame, may use the AIFS [AC] of the AC of the transmitted frame.

[0087] A WLAN device 104 may perform a backoff procedure when the WLAN device 104 that is ready to transfer a frame finds the medium busy. The backoff procedure includes determining a random backoff time composed of N backoff slots, where each backoff slot has a duration equal to a slot time and N being an integer number greater than or equal to zero. The backoff time may be determined according to a length of a Contention Window (CW). In an embodiment, the backoff time may be determined according to an AC of the frame. All backoff slots occur following a DIFS or Extended IFS (EIFS) period during which the medium is determined to be idle for the duration of the period.

[0088] When the WLAN device 104 detects no medium activity for the duration of a particular backoff slot, the backoff procedure shall decrement the backoff time by the slot time. When the WLAN device 104 determines that the medium is busy during a backoff slot, the backoff procedure is suspended until the medium is again determined to be idle for the duration of a DIFS or EIFS period. The WLAN device 104 may perform transmission or retransmission of the frame when the backoff timer reaches zero.

[0089] The backoff procedure operates so that when multiple WLAN devices 104 are deferring and execute the backoff procedure, each WLAN device 104 may select a backoff time using a random function and the WLAN device 104 that selects the smallest backoff time may win the contention, reducing the probability of a collision.

[0090] Figure 5 illustrates a Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) based frame transmission procedure for avoiding collision between frames in a channel according to an embodiment. Figure 5 shows a first station STA1 transmitting data, a secondstation STA2 receiving the data, and a third station STA3 that may be located in an area where a frame transmitted from the STA1 can be received, a frame transmitted from the second station STA2 can be received, or both can be received. The stations STA1, STA2, and STA3 may be WLAN devices 104 of Figure 1.

[0091] The station STA1 may determine whether the channel is busy by carrier sensing. The station STA1 may determine channel occupation / status based on an energy level in the channel or an autocorrelation of signals in the channel, or may determine the channel occupation by using a network allocation vector (NAV) timer.

[0092] After determining that the channel is not used by other devices (that is, that the channel is IDLE) during a DIFS (and performing backoff if required), the station STA1 may transmit a Request-To-Send (RTS) frame to the station STA2. Upon receiving the RTS frame, after a SIFS the station STA2 may transmit a Clear-To-Send (CTS) frame as a response to the RTS frame. If Dual-CTS is enabled and the station STA2 is an AP, the AP may 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 the HT format).

[0093] When the station STA3 receives the RTS frame, it may set a NAV timer of the station STA3 for a transmission duration of subsequently transmitted frames (for example, a duration of SIFS + CTS frame duration + SIFS + data frame duration + SIFS + ACK frame duration) using duration information included in the RTS frame. When the station STA3 receives the CTS frame, it may set the NAV timer of the station STA3 for a transmission duration of subsequently transmitted frames using duration information included in the CTS frame. Upon receiving a new frame before the NAV timer expires, the station STA3 may update the NAV timer of the station STA3 by using duration information included in the new frame. The station STA3 does not attempt to access the channel until the NAV timer expires.

[0094] When the station STA1 receives the CTS frame from the station STA2, it may transmit a data frame to the station STA2 after a SIFS period elapses from a time when the CTS frame has been completely received. Upon successfully receiving the data frame, the station STA2 may transmit an ACK frame as a response to the data frame after a SIFS period elapses.

[0095] When the NAV timer expires, the third station STA3 may determine whether the channel is busy using the carrier sensing. Upon determining that the channel is not used by other devices during a DIFS period after the NAV timer has expired, the station STA3 may attempt to access the channel after a contention window elapses according to a backoff process.

[0096] When Dual-CTS is enabled, a station that has obtained a transmission opportunity (TXOP) and that has no data to transmit may transmit a CF-End frame to cut short the TXOP.An AP receiving a CF-End frame having a Basic Service Set Identifier (BSSID) of the AP as a destination address may respond by transmitting 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. A station receiving a CF-End frame resets its NAV timer to 0 at the end of the PPDU containing the CF-End frame. Figure 5 shows the station STA2 transmitting an ACK frame to acknowledge the successful reception of a frame by the recipient.

[0097] The IEEE 802.1 Ibn (Ultra High Reliability, UHR) working group has been established to address the growing demand for higher peak throughput and reliability in Wi-Fi. As shown in Figure 6, the peak PHY rate has significantly increased from IEEE 802.1 lb to IEEE 802.1 Ibe (Wi-Fi 7), with the latter focusing on further improving peak throughput. The UHR study group aims to enhance the tail of the latency distribution and jitter to support applications that require low latency, such as video-over- WLAN, gaming, AR, and VR. It is noted that various characteristics of UHR (e.g., max PHY rate, PHY rate enhancement, bandwidth / number of spatial streams, and operating bands) are still to be determined.

[0098] The focus of IEEE 802.1 Ibe is primarily on WLAN indoor and outdoor operation with stationary and pedestrian speeds in the 2.4, 5, and 6 GHz frequency bands. In addition to peak PHY rate, different candidate features are under discussion. These candidate features include (1) a 320MHz bandwidth and a more efficient utilization of a non-contiguous spectrum, (2) multi -band / multi-channel aggregation and operation, (3) 16 spatial streams and Multiple Input Multiple Output (MIMO) protocol enhancements, (4) multi-Access Point (AP) Coordination (e.g., coordinated and joint transmission), (5) an enhanced link adaptation and retransmission protocol (e.g., Hybrid Automatic Repeat Request (HARQ)), and (6) adaptation to regulatory rules specific to a 6 GHz spectrum.

[0099] The focus of IEEE 802.1 Ibn (UHR) is still under discussion, with candidate features including MLO enhancements (e.g., in terms of increased throughput / reliability and decreased latency), latency and reliability improvements (e.g., multi-AP coordination to support low latency traffic), bandwidth expansion (e.g., to 240, 480, 640 MHz), aggregated PPDU (A- PPDU), enhanced multi-link single-radio (eMLSR) extensions to AP, roaming improvements, and power-saving schemes for prolonging battery life.

[0100] Some features, such as increasing the bandwidth and the number of spatial streams, are solutions that have been proven to be effective in previous projects focused on increasing link throughput and on which feasibility demonstration is achievable.

[0101] With respect to operational bands (e.g., 2.4 / 5 / 6 GHz) for IEEE 802.1 Ibe, more than 1 GHz of additional unlicensed spectrum is likely to be available because the 6 GHz band (5.925- 7.125 GHz) is being considered for unlicensed use. This would allow APs and STAs to become tri -band devices. Larger than 160MHz data transmissions (e.g., 320 MHz or 640 MHz) could be considered to increase the maximum PHY rate. For example, 320 MHz or 160+160MHz data could be transmitted in the 6 GHz band. For example, 160+160 MHz data could be transmitted across the 5 and 6 GHz bands.

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

[0103] The Extremely High Throughput (EHT) PPDU frame encompasses several components. It includes a legacy part, which comprises 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 legacy part, the EHT PPDU frame also contains the Universal Signal Field (U-SIG), EHT Signal Field (EHT-SIG), EHT Short Training Field (EHT-STF), and EHT Long Training Field (EHT-LTF). These fields are specific 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 their purposes and characteristics.

[0106] Regarding the Ultra High Reliability (UHR) PPDU, its frame structure is currently undefined and will be determined through further discussions within the relevant working group or study group. This indicates that the specifics of the UHR PPDU are still under development and will be finalized based on the outcomes of future deliberations.

[0107] The distributed nature of channel access networks, such as IEEE 802.11 WLANs, makes the carrier sense mechanism useful for ensuring collision-free operation. Each station (STA) uses its physical carrier sense to detect transmissions from other STAs. However, in certain situations, it may not be possible for a STA to detect every transmission. For instance, when one STA is located far away from another STA, it might perceive the medium as idle and start transmitting a frame, leading to collisions. To mitigate this hidden node problem, the network allocation vector (NAV) has been introduced.

[0108] As the IEEE 802.11 standard continues to evolve, it now includes scenarios where multiple users can simultaneously transmit or receive data within a basic service set (BSS), such as uplink (UL) and downlink (DL) multi-user (MU) transmissions in a cascaded manner. In these cases, the existing carrier sense and NAV mechanisms may not be sufficient, andmodifications or newly defined mechanisms may be required to facilitate efficient and collision- free operation.

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

[0110] Figure 8 illustrates an example of multi-user (MU) transmission in Orthogonal Frequency-Division Multiple Access (OFDMA), in accordance with some embodiments of the present disclosure.

[0111] In the IEEE 802.1 lax and 802.1 Ibe specifications, the trigger frame plays a useful role in facilitating uplink multi-user (MU) transmissions. The purpose of the trigger frame is to allocate resources and solicit one or more Trigger-based (TB) Physical Layer Protocol Data Unit (PPDU) transmissions from the associated stations (STAs).

[0112] The trigger frame contains information required by the responding STAs to send their Uplink TB PPDUs. This information includes the Trigger type, which specifies the type of TB PPDU expected, and the Uplink Length (UL Length), which indicates the duration of the uplink transmission.

[0113] Figure 9 illustrates an example scenario where an access point (AP) operating in an 80MHz bandwidth environment sends a Trigger frame to multiple associated STAs. Upon receiving the Trigger frame, the STAs respond by sending their respective Uplink Orthogonal Frequency Division Multiple Access (UL OFDMA) TB PPDUs, utilizing the allocated resources within the specified 80 MHz bandwidth.

[0114] After successfully receiving the UL OFDMA TB PPDUs, the AP acknowledges the STAs by sending an acknowledgement frame. This acknowledgement can be in the form of an 80MHz width multi-STA Block Acknowledgement (Block Ack) or a Block Acknowledgement with a Direct Feedback (DF) OFDMA method. The multi-STA Block Ack allows the AP to acknowledge multiple STAs simultaneously, while the Block Ack with DF OFDMA enables the AP to provide feedback to the STAs using the same OFDMA technique employed in the uplink transmission.

[0115] The trigger frame is a useful component in enabling efficient uplink MU transmissions in IEEE 802.1 lax and 802.1 Ibe networks, by allocating resources and coordinating the uplink transmissions from multiple STAs within the same bandwidth.

[0116] Wireless network systems can rely on retransmission of media access control (MAC) protocol data units (MPDUs) when the transmitter (TX) does not receive an acknowledgement from the receiver (RX) or MPDUs are not successfully decoded by the receiver. Using an automatic repeat request (ARQ) approach, the receiver discards the last failed MPDU before receiving the newly retransmitted MPDU. With requirements of enhanced reliability and reduced latency, the wireless network system can evolve toward a hybrid ARQ (HARQ) approach.

[0117] There are two methods of HARQ processing. In a first type of HARQ scheme, also referred to as chase combining (CC) HARQ (CC-HARQ) scheme, signals to be retransmitted are the same as the signals that previously failed because all subpackets to be retransmitted use the same puncturing pattern. The puncturing is needed to remove some of the parity bits after encoding using an error-correction code. The reason why the same puncturing pattern is used with CC-HARQ is to generate a coded data sequence with forward error correction (FEC) and to make the receiver use a maximum-ratio combining (MRC) to combine the received, retransmitted bits with the same bits from the previous transmission. For example, information sequences are transmitted in packets with a fixed length. At a receiver, error correction and detection are carried out over the whole packet. However, the ARQ scheme may be inefficient in the presence of burst errors. To solve this more efficiently, subpackets are used. In subpacket transmissions, only those subpackets that include errors need to be retransmitted.

[0118] Since the receiver uses both the current and the previously received subpackets for decoding data, the error probability in decoding decreases as the number of used subpackets increases. The decoding process passes a cyclic redundancy check (CRC) and ends when the entire packet is decoded without error or the maximum number of subpackets is reached. In particular, this scheme operates on a stop-and-wait protocol such that if the receiver can decode the packet, it sends an acknowledgement (ACK) to the transmitter. When the transmitter receives an ACK successfully, it terminates the HARQ transmission of the packet. If the receiver cannot decode the packet, it sends a negative acknowledgement (NAK) to the transmitter and the transmitter performs the retransmission process.

[0119] In a second type of HARQ scheme, also referred to as an incremental redundancy (IR) HARQ (IR-HARQ) scheme, different puncturing patterns are used for each subpacket such that the signal changes for each retransmitted subpacket in comparison to the originally transmittedsubpacket. IR-HARQ alternatively uses two puncturing patterns for odd numbered and even numbered transmissions, respectively. The redundancy scheme of IR-HARQ improves the log likelihood ratio (LLR) of parity bit(s) in order to combine information sent across different transmissions due to requests and lowers the code rate as the additional subpacket is used. This results in a lower error rate of the subpacket in comparison to CC-HARQ. The puncturing pattern used in IR-HARQ is indicated by a subpacket identity (SPID) indication. The SPID of the first subpacket may always be set to 0 and all the systematic bits and the punctured parity bits are transmitted in the first subpacket. Self-decoding is possible when the receiving signal- to-noise ratio (SNR) environment is good (i.e., a high SNR). In some embodiments, subpackets with corresponding SPIDs to be transmitted are in increasing order of SPID but can be exchanged / switched except for the first SPID.

[0120] AP coordination has been considered as a potential technology to improve WLAN system throughput in the IEEE 802.1 Ibe standard and is still being discussed in the IEEE 802.1 Ibn (UHR) standard. To support various AP coordination schemes, such as coordinated beamforming, OFDMA, TDMA, spatial reuse, and joint transmission, a predefined mechanism for APs is necessary.

[0121] In the context of coordinated TDMA (C-TDMA), the AP that obtains a transmit opportunity (TXOP) is referred to as the sharing AP. This AP initiates the AP coordination schemes to determine the AP candidate set by sending a frame, such as a Beacon frame or probe response frame, which includes information about the AP coordination scheme capabilities. The AP that participates in the AP coordination schemes after receiving the frame from the sharing AP is called the shared AP. The sharing AP is also known as the master AP or coordinating AP, while the shared AP is referred to as the slave AP or coordinated AP.

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

[0123] Coordinated Beamforming (C-BF): Multiple APs transmit on the same frequency resource by coordinating and forming spatial nulls, allowing for simultaneous transmission from multiple APs.

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

[0125] Joint Transmission (JTX): Multiple APs transmit jointly to a given user simultaneously by sharing data between the APs.

[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 the cooperation between multiple APs.

[0128] Existing wireless networking standards (e.g., IEEE 802.11 wireless networking standards) provide security features for MPDU / frame transmission and reception. Data frames may be encrypted / decrypted and checked for integrity using temporal key integrity protocol (TKIP), counter mode with cipher block chaining message authentication code protocol (CCMP), or Galois / counter mode protocol (GCMP). Group addressed management frames may be checked for integrity using broadcast / multicast integrity protocol (BIP).

[0129] CCMP and GCMP are widely used security protocols for encrypting / decrypting frames and checking the integrity of frames. CCMP is based on the advanced encryption standard (AES) algorithm and the cipher block chaining message authentication code (CBC- MAC) technique. GCMP is also based on the AES algorithm but uses the Galois message authentication code (GMAC) technique. Both CCMP and GCMP have two variants, depending on the length of the encryption key: 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. With these security protocols, certain fields of the MAC header of a frame are used to generate a message integrity check (MIC) authentication value (also referred to simply as “authentication value”). This authentication value is then transmitted in a MIC field that appears after the encrypted frame body field of the frame. The recipient of the frame can check the integrity of the MAC header using the authentication value.

[0130] Figure 10 is a diagram showing a format of a standard (non-encrypted) MPDU, according to some embodiments.

[0131] As shown in the diagram, the 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. The duration / ID field 1014 may carry information regarding the remaining time for consecutive frame exchanges or an association identifier (AID) depending on the type and subtype of the MPDU. The address fields (e.g., address 1 field 1016, address 2 field 1018, address 3 field 1020, and / or address 4 field 1024) may carry the address of the transmitter and receiver of the MPDU, as well as any intermediate wireless devices that are involved in thetransmission. The frame body field 1030 may carry the payload of the MPDU, which may vary depending on the type and subtype of the MPDU. The FCS field 1040 may carry a 32-bit cyclic redundancy check (CRC) value, which can be used to check the integrity and validity of the MAC header 1010 and the frame body field 1030. In general, CRC provides simple data integrity, whereas MIC provides cryptographic integrity.

[0132] Figure 11 is a diagram showing a format of an MPDU with an encrypted frame body field, according to some embodiments.

[0133] As shown in the diagram, 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 a 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), a key ID octet 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 key ID octet field 1118 may include a reserved field 1120 (5 bits), an extended initialization vector (IV) field 1122 (1 bits), and a key ID field 1124 (2 bits).

[0134] Both CCMP and GCMP require additional information to be transmitted in the MPDU. The CCMP / GCMP header 1140 and the MIC field 1160 may be added to the MPDU to accommodate this additional information. The CCMP / GCMP header 1140 may carry security materials that are needed for decrypting the encrypted frame body field 1150 such as the packet number (PN) and the key ID. The extended initialization vector field 1122 may carry a bit that is fixed to 1. The MIC field 1160 may carry an authentication value that can be used for checking 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 that is to be included in the frame body field 1150 of the MPDU and then to insert the encrypted data / payload in the frame body field 1150. The second operation is to generate an authentication value that can be used for checking the encryption and decryption processes and to insert the authentication value in the MIC field 1160. The length of the authentication value may be eight (8) bytes for CCMP-128 and sixteen (16) bytes for CCMP-256, GCMP-128, and GCMP -256. The length of the MIC field 1160 may vary depending on the length of the authentication value.

[0136] Figure 12 is a diagram showing a way to generate additional authentication data (AAD), according to some embodiments.

[0137] Both CCMP and GCMP may generate an authentication value for a MPDU based on additional authentication data (AAD) for the MPDU. The AAD for a MPDU may be generated based on concatenating certain fields included in the MPDU and masking certain (sub)fields / bits included in the concatenated fields. The procedure for generating the AAD is the same for both CCMP and GCMP.

[0138] For example, as shown in the diagram, the AAD may be generated by concatenating a frame control (FC) field 1202 (2 bytes), an Al (address 1) field 1204 (6 bytes), an A2 (address 2) field 1206 (6 bytes), an A3 (address 3) field 1208 (6 bytes), a sequence control (SC) field 1210 (2 bytes), an A4 (address 4) field 1212 (0 or 6 bytes), and a QoS control (QC) field 1214 (0 or 2 bytes), in that order. It should be noted that not all MPDUs have an A4 field 1212 and QoS control field 1214, and any fields that are absent from the MAC header may be excluded from the AAD. As such, the length of the AAD may vary depending on the presence or absence of such fields. The possible lengths of AAD are 22, 24, 28, or 30 bytes.

[0139] The Al (address 1) field 1204, A2 (address 2) field 1206, A3 (address 3) field 1208, and A4 (address 4) field 1212 may be used in the AAD without modification. However, the FC field 1202, SC field 1210, and QoS control field 1214 may be modified by deleting / masking some fi elds / bits therein.

[0140] Figure 13 is a diagram showing a format of a frame control field, according to some embodiments.

[0141] The frame control (FC) field may include fields for carrying information regarding the format and function of the MPDU. As shown in the diagram, the frame control field may include a protocol version field 1302 (2 bits), a type field 1304 (2 bits), a subtype field 1306 (4 bits), a to distribution system (DS) field 1308 (1 bit), a from DS field 1310 (1 bit), a more fragments field 1312 (1 bits), a retry field 1314 (1 bits), a power management field 1316 (1 bits), a more data field 1318 (1 bits), a protected frame field 1320 (1 bits), and a plus high throughput control (+HTC) field 1322 (1 bits). The bit positions of the fields may be as shown in the diagram.

[0142] When generating AAD, some of these fields may be modified by masking certain bits to 0. For example, bits 4, 5, and 6 of the subtype field 1306 in a data frame are masked to 0. Also, the retry field 1314, which indicates whether the MPDU is a retransmission, is masked to 0. Also, the power management field 1316, which indicates the power-saving mode of the transmitter, is masked to 0. Also, the more data field 1318, which indicates whether there are more MPDUs buffered for transmission, is masked to 0. Finally, the +HTC field 1322, whichindicates the presence of a high throughput control (HTC) field, is masked to 0 in the case that a data frame has a QoS control field.

[0143] Figure 14 is a diagram showing a format of a sequence control field, according to some embodiments.

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

[0145] The QoS control field includes fields for carrying information about the quality of service and the aggregation of the MPDU. When generating AAD, the masking rules applied to the QoS control field may vary depending on whether the MPDU belongs to a non-directional multi-gigabit (non-DMG) basic service set (BSS) or a directional multi -gigabit (DMG) BSS. If the MPDU belongs to a non-DMG BSS and both the transmitter and the receiver have the signaling and payload protected (SPP) aggregated MAC service data unit (A-MSDU) capable field set to a value of 1, indicating that they support single MPDU protection for an A-MSDU, then all fields included in the QoS control field except the traffic identifier (TID) field and the A-MSDU present field are masked to 0. If the MPDU belongs to a non-DMG BSS and either the transmitter or the receiver does not have the SPP A-MSDU capable field set to a value of 1, then all fields included in the QoS control field except the TID field are masked to 0. If the MPDU belongs to a DMG BSS, then all fields included in the QoS control field except the TID field, the A-MSDU present field, and the A-MSDU type field are masked to 0.

[0146] CCMP and GCMP are security protocols that enable concurrent encryption / decry ption and integrity checks for data frames. BIP is a security protocol that enables integrity checks for group addressed management frames. BIP does not encrypt the data / payload of group addressed management frames, but provides a way to check its integrity.

[0147] Figure 15 is a diagram showing a format of a management frame, according to some embodiments.

[0148] As shown in the diagram, the management frame may include a MAC header 1510, a frame body field 1530, and a 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 further include a HT control field 1524 (0 to 4bytes). The presence of the HT control field 1524 may be indicated by a value caried in a +HTC field (not shown) included in the frame control field 1512.

[0149] Figure 16 is a diagram showing a format of a management MIC element, according to some embodiments.

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

[0151] As shown in the diagram, the 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 temporal key packet number (IPN) or beacon integrity group temporal key packet number (BIPN)) field 1608 (6 bytes), and a MIC field 1610 (8 or 16 bytes). The element ID field 1602 may carry a unique value indicating the element type. In a management MIC element, the element ID field 1602 may carry a value of 76. The length field 1604 may carry an indication of the length of the management MIC element excluding the element ID field 1602 and the length field 1604. The MIC field 1610 may vary in length depending on the encryption algorithm being used. For example, the MIC field 1610 may have a length of 8 bytes or 16 bytes. Consequently, the length field 1604 of the management MIC element may carry a value of 16 or 24.

[0152] The key ID field 1606 may carry the identifier for the key that is used for performing an integrity check. When the sender generates the authentication value, it conveys the ID of the key that was used in the key ID field 1606. Upon receiving this information, the recipient may generate its own authentication value using the specified key and check whether it matches the authentication value carried in the MIC field 1610. In the key ID field 1606, the lower 12 bits of the 2-byte (16 bits) representation may carry the actual key ID, while the remaining 4 bits may be reserved. Although the 12 bits of the key ID field 1606 can accommodate values from 0 to 4095, in practice, only one of the values 4, 5, 6, or 7 is used. In the context of BIP, a key may be an integrity group temporal key (IGTK) or a beacon integrity group temporal key (BIGTK). The key ID for IGTK may be either 4 or 5, while the key ID for BIGTK may be 6 or 7. Consequently, transmitting the key ID may only require three (3) bits.

[0153] The IPN / BIPN field 1608 may carry the IGTK packet number (IPN) or the BIGTK packet number (BIPN). The packet number may be used to generate the authentication value during the execution of encryption algorithms. The process for generating the authentication value may involve segmenting the original message into blocks of 128 bits and sequentially inputting the blocks into an algorithm. A counter may also be input into the algorithm during this process. The counter may increase by one for each block. Also, the packet number may beinput into the algorithm along with the counter. Importantly, the packet number should vary for each frame.

[0154] To apply BIP, the management MIC element may be added to the end of the frame body field of the management frame. During this process, the element ID field 1602, the length field 1604, the key ID field 1606, and the IPN / BIPN field 1608 may be filled with their respective values, while the MIC field 1610 may temporarily be filled with zeros. Then, the authentication value may be generated using one of the following algorithms: BIP-CMAC-128, BIP-CMAC-256, BIP-GMAC-128, or BIP-GMAC-256. These algorithms may target the frame body field and may be the same / similar algorithm as the one used for generating the authentication value in CCMP-128, CCMP-256, GCMP-128, or GCMP-256. The generated authentication value may be inserted into the MIC field 1610 (e.g., and overwrite the zeroes previously carried in the MIC field 1610) of the management MIC element.

[0155] Figure 17 is a diagram showing a way to generate AAD in BIP, according to some embodiments.

[0156] BIP-CMAC and BIP-GMAC take AAD as an input. The procedure for generating AAD is the same for both BIP-CMAC and BIP-GMAC. AAD may be generated by concatenating certain fields of the MAC header. For example, as shown in the diagram, AAD may be generated by concatenating the frame control field 1702 (2 bytes), the address 1 (Al) field 1704 (6 bytes), the address 2 (A2) field 1706 (6 bytes), and the address 3 (A3) field 1708 (6 bytes). In this case, the length of AAD may be 20 bytes.

[0157] Figure 18 is a diagram showing a format of a trigger frame, according to some embodiments.

[0158] The trigger frame is a type of a control frame that was introduced as part of the IEEE 802.1 lax wireless networking standard. An AP may transmit a trigger frame to solicit simultaneous uplink transmission from multiple non-AP STAs. As shown in the diagram, the trigger frame may include a frame control field 1802 (2 bytes), a duration field 1804 (2 bytes), a RA field 1806 (6 bytes), and a TA field 1810 (6 bytes), which form the MAC header. The trigger frame may further include a common info field 1812 (8 or more bytes) and a user info list field 1814 (variable length), which form the frame body. The common info field 1812 may carry information intended for all non-AP STAs that receive the trigger frame. The user info list field may include zero or more user info fields, with each user info field carrying information intended for a particular non-AP STA. The trigger frame may further include a padding field 1816 (variable length) and a FCS field 1818 (4 bytes).

[0159] Figure 19 is a diagram showing a format of a user info field, according to some embodiments.

[0160] As shown in the diagram, the user info field includes an AID 12 field 1902 (12 bits), a resource unit (RU) allocation field 1904 (8 bits), an uplink forward error correction (UL FEC) coding type field 1906 (1 bit), an uplink high-efficiency modulation and coding scheme (UL HE-MCS) field 1908 (4 bits), an uplink dual carrier modulation (UL DCM) field 1910 (1 bit), a spatial stream (SS) allocation random access resource unit (RA-RU) information field 1912 (6 bits), a UL target receive power field 1914 (7 bits), a reserved field 1916 (1 bit), and a trigger dependent user info field 1918 (variable length).

[0161] The AID 12 field 1902 may indicate the particular STA that the information carried in the user info field is intended for. A STA that receives a trigger frame may identify which user info field is intended for itself based on the value carried in the AID12 field 1902. If the value carried in the AID12 field 1902 of a user info field is 0, the information included in the user info field may be information regarding a random access resource unit (RA-RU) allocated to all associated STAs. If the value carried in the AID12 field 1902 of the user info field is between 1 and 2007, the value may be an association identifier (AID) value for the intended recipient of the user info field. If the value carried in the AID12 field 1902 of the user info field is 2045, the information carried in the user info field may be information regarding a RA-RU allocated to unassociated STAs. If the value carried in the AID12 field 1902 of the user info field is 2046, the information included in the user info field may be information regarding an unallocated RU. If the value carried in the AID12 field 1902 of the user info field is 4095, it may indicate that the padding field 1816 starts. Other values for the AID12 field 1902 may be reserved and not used. The remaining 28 bits of the user info field (the bits excluding the AID 12 field 1902) may carry information regarding the corresponding RU. This information may include information regarding RU allocation, UL FEC coding type, UL HE-MCS, UL DCM, SS Allocation / RA-RU information, and UL target receive power. The trigger dependent user info field 1918 may be optional (it may be present or not present depending on the type of the trigger frame). The type of the trigger frame may be indicated in the trigger type field included in the common info field.

[0162] Figure 20 is a diagram showing a format of a special user info field, according to some embodiments.

[0163] After the trigger frame was introduced as part of the IEEE 802.1 lax wireless networking standard, it became necessary to transmit additional information besides the information carried in the common info field to all STAs receiving the trigger frame. A specialuser info field was added to the IEEE 802.1 Ibe wireless networking standard to provide such information through a user info field.

[0164] As shown in the diagram, the special user info field may include an AID 12 field 2002 (12 bits), a PHY version identifier field 2004 (3 bits), a UL bandwidth extension field 2006 (2 bits), an EHT spatial reuse 1 field 2008 (4 bits), an EHT spatial reuse 2 field 2010 (4 bits), a U- SIG disregard and validate field 2012 (12 bits), a reserved field 2014 (3 bits), and a trigger dependent user info field 2016 (variable length).

[0165] The AID 12 field 2002 included in the special user info field may carry a fixed value of 2007. The remaining 28 bits may carry additional information that the AP provides to non- AP STAs such as information regarding PHY version identifier, UL bandwidth extension, EHT spatial reuse, and U-SIG disregard and validate. The special user info field may appear immediately after the common info field (i.e., be the first user info field amongst all of the user info fields).

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

[0167] However, BIP cannot be applied to a trigger frame as-is to secure the trigger frame. As mentioned above, the AAD used in BIP is generated by concatenating the frame control field, the address 1 field, the address 2 field, and the address 3 field. However, since the trigger frame only has two address fields in its MAC header, a different AAD is needed compared to the one used in BIP.

[0168] Figure 21 is a diagram showing a format of AAD that can be used for securing a trigger frame, according to some embodiments.

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

[0170] When BIP is applied to a trigger frame, there is an issue related to timing delay. The recipient of the trigger frame needs to know the key ID to know which key to use for generating the authentication value. Also, the recipient of the trigger frame needs to know the PN to be able to generate the authentication value. However, with BIP, the key ID and PN appeartowards the end of the frame. If the key ID and PN appear towards the end of the trigger frame, the recipient has to wait until after it has received most of the trigger frame before it can start generating the authentication value, which makes it difficult for the recipient to provide an immediate response to the trigger frame in the requisite time.

[0171] Likewise, when BIP is applied to a group addressed management frame, the authentication value can only be generated after almost all of the frame has been received, and it takes some non-negligible time to generate the authentication value and check whether it matches the authentication value carried in the management MIC element of the group addressed management frame. However, the time delay is not a significant issue in the case of the group addressed management frame because there is no need for the recipient to provide an immediate response to the group addressed management frame.

[0172] The time delay issue arises because the key ID and PN appear towards the end of the trigger frame. When applying security protocols such as TKIP, CCMP, or GCMP 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. As such, upon receiving the TKIP / CCMP / GCMP header, the recipient can promptly identify the cipher key and can execute the decryption and integrity check process while receiving the frame body field.

[0173] Techniques are described herein that allow the integrity check process of a trigger frame to start earlier and thus allow the recipient to provide an immediate response to the trigger frame (e.g., transmit a TB PPDU) within the requisite time (e.g., a SIFS interval after reception of the trigger frame).

[0174] Figure 22 is a diagram showing a format of a secured trigger frame, according to some embodiments.

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

[0176] The format of the secured trigger frame is similar to the format of a conventional trigger frame but includes the key ID user info field 2212 and the MIC user info field 2216. The key ID user info field 2212 may carry a key ID and PN. The MIC user info field 2216 may carry a MIC authentication value. Notably, the key ID user info field 2212 appears before the user info list field 2214 (and after the common info field 2210 in this example), which allowsthe recipient to start the integrity check process for the trigger frame early (e.g., identify the key early). If the special user info field exists, the key ID user info field 2212 may be placed before the special user info field. Also, the MIC user info field 2216 may appear after the user info list field 2214.

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

[0178] Figure 23 is a diagram showing a format of key ID user info fields, according to some embodiments.

[0179] As mentioned above, the key ID user info field 2212 may carry the key ID and PN. The length of the key ID is 3 bits and the length of the PN is 48 bits. As such, the total length of data that needs to be conveyed exceeds the 28 bits of data that can be carried in the 40-bit key ID user info field (excluding the AID12 field). Thus, multiple key ID user info fields may be used to carry the key ID and PN. In an embodiment, as shown in the diagram, two key ID user info fields are used to carry the key ID and PN.

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

[0181] The key info sequence field may be used for indicating the sequence of the key ID user info fields. In the example shown in the diagram, the key info sequence field 2304 included in the first key ID user info field carries a value of 0 and the key info sequence field 2314 included in the second key ID user info field carries a value of 1. The first packet number field 2310 and the second packet number field 2316 may collectively carry the PN.

[0182] When the value carried in a key info sequence field is 0, the subsequent one bit (e.g., bit B 14) may be reserved. For the remaining bits, three bits may be used for the key ID field 2308 to carry the key ID and the remaining 22 bits may be used for the first packet number field 2310 to carry the first 22 bits (out of 48 total bits) of the PN.

[0183] When the value carried in a key info sequence field is 1, the remaining 26 bits may be used for the second packet number field 2316 to carry the remaining 26 bits of the PN. In an embodiment, the values of 2 and 3 are not used in the key info sequence field.

[0184] Figure 24 is a diagram showing a format of MIC user info fields when the length of the authentication value is 64 bits, according to some embodiments.

[0185] As mentioned above, the MIC user info field 2216 may be used for carrying an authentication value. The length of the authentication value may depend on the encryption algorithm being used. If BIP-CMAC-128 is being used, the length of the authentication value may be 64 bits. If BIP-CMAC-256, BIP-GMAC-128, or BIP-GMAC-256 are being used, the length of the authentication value may be 128 bits. Either way, the length of the authentication value exceeds the 28 bits of data that can be carried in the 40-bit MIC user info field (excluding the AID 12 field). Thus, multiple MIC user info fields may be used to carry the authentication value. In an embodiment, as will be described in further detail herein, if the length of the authentication value is 64 bits, three MIC user info fields are used to carry the authentication value. In an embodiment, as will be described in further detail herein, if the length of the authentication value is 128 bits, five MIC user info fields are used to carry the authentication value.

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

[0187] A MIC info sequence field may have a length of 2 bits or 3 bits. When the first two bits of a MIC info sequence field are ‘00’, ‘OF, or ‘ 10’ in binary, the length of the MIC info sequence field may be 2 bits, and the authentication value may be conveyed in the next 26 bits. When the first 2 bits of the MIC info sequence field are ‘ 11’ in binary, the length of the MIC info sequence field may be 3 bits, and thus the next bit may also be included in the MIC infosequence field. Thus, in such case, the MIC info sequence field may carry a value of ‘ 110’ or ‘ 111’ in binary, and the authentication value may be conveyed in the next 25 bits.

[0188] When the value carried in the MIC info sequence field is ‘00’ in binary, the remaining 26 bits may be used for the MIC1 field 2406, which may carry the first 26 bits of the authentication value. When the value carried in the MIC info sequence field is ‘01’ in binary, the remaining 26 bits may be used for the MIC2 field 2412, which may carry the next 26 bits of the authentication value. When the value carried in the MIC info sequence field is ‘ 10’ in binary, there may be two cases depending on the length of the authentication value. If the length of the authentication value is 64 bits, there are 12 bits of the authentication value still remaining to convey after the MIC1 field 2406 and the MIC2 field 2412. Thus, if the value carried in the MIC info sequence field is ‘ 10’ in binary and the length of the authentication value is 64 bits (e.g., BIP-CMAC-128 is being used), the 12 bits following the MIC info sequence field may be used for the MIC3 field 2418, which may carry the remaining 12 bits of the authentication value. The remaining 14 bits may be reserved.

[0189] Figure 25 is a diagram showing a format of MIC user info fields when the length of the authentication value is 128 bits, according to some embodiments.

[0190] If the length of the authentication value is 128 bits, five MIC user info fields may be used to carry the authentication value. For example, MIC user info fields #1 and #2 shown in Figure 24 and MIC user info fields #3, #4, and #5 shown in Figure 25 may be used.

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

[0192] If the value carried in the MIC info sequence field is ‘ 10’ in binary and the length of the authentication value is 128 bits (e.g., BIP-CMAC-256, BIP-GMAC-128, or BIP-GMAC-256 is being used), the remaining 26 bits may be used for the MIC3 field 2506, which may carry the next 26 bits of the authentication value.

[0193] When the value carried in the MIC info sequence field is ‘ 110’ in binary, the remaining 25 bits may be used for the MIC4 field 2512, which may carry the next 25 bits of the authentication value. When the value carried in the MIC info sequence field is ‘ 111’ in binary,the remaining 25 bits may be used for the MIC5 field 2518, which may carry the remaining 25 bits of the authentication value.

[0194] Existing IEEE 802.11 wireless networking standards do not secure trigger frames, which is problematic because trigger frames are used for controlling the behavior of multiple STAs. The techniques described herein may secure trigger frames and fill this void in the existing wireless networking standards. The techniques described herein may place the key ID and PN towards the front of the trigger frame to allow the recipient of the trigger frame to start the integrity check process early, which allows the recipient to provide an immediate response to the trigger frame in a timely manner.

[0195] If the key ID user info field and the MIC user info field are configured in the manner described herein above, two key ID user info fields and either three or five MIC user info fields may be added to the trigger frame. These additional user info fields may secure the trigger frame by allowing the recipient to check the integrity of the trigger frame.

[0196] However, simply appending an additional field that carries the key ID, PN, and MIC authentication value to the end of a trigger frame may unduly delay the integrity check process, making it difficult for the recipient to provide an immediate response to the trigger frame (e.g., transmit a TB PPDU after a SIFS interval). The techniques described herein solve this problem by placing the key ID and PN earlier in the trigger frame (e.g., in front of the user info list field). Also, the authentication value may be placed after the user info list field. This allows the recipient to start the integrity check process early, resulting in reduced delay, which allows the recipient to provide an immediate response to the trigger frame in a timely manner.

[0197] As mentioned above, while the techniques are primarily described herein in the context of securing trigger frames, a similar approach may be used to secure other types of control frames, and particularly control frames that require an immediate response from the recipient.

[0198] Turning now to Figure 26, a method 2600 will be described for securing a control frame, in accordance with an example embodiment. The method 2600 may be performed by a wireless device (e.g., wireless device 104).

[0199] Additionally, although shown in a particular order, in some embodiments the operations of the method 2600 (and the other method(s) shown in the other figure(s)) may be performed in a different order. For example, although the operations of the method 2600 are shown in a sequential order, some of the operations may be performed in partially or entirely overlapping time periods.

[0200] At operation 2605, the wireless device generates the control frame, wherein the control frame includes a key ID field that appears before at least one field included in a body of the control frame and a MIC field that appears 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 an integrity of the control frame.

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

[0202] In an embodiment, as shown in block 2610, the key ID field includes a first key ID user information field and a second key ID user information field. In an embodiment, as shown in block 2615, the first key ID user information field includes a first association identifier field, a first key information sequence field, an inner 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 inner key ID field carries the key ID, wherein the first packet number field and the second packet number field collectively carry the packet number. In an 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 an embodiment, the inner key ID field has a length of 3 bits, the first packet number field has a length of 22 bits, and the second packet number field has a length of 26 bits. In an embodiment, the first association identifier field and the second association identifier field each carry a value of 4093.

[0203] In an embodiment, as shown in block 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 further include a fourth MIC user information field and a fifth MIC user information field). In an embodiment, as shown in block 2625, each MIC user information field includes an association identifier field, a MIC information sequence field, and an inner MIC field, wherein the inner MIC fields collectively carry the authentication value. For example, the first MIC user information field may include a first association identifier field, a first MIC information sequence field, and a first inner MIC field, the second MIC user information field may include a second association identifier field, a second MIC information sequence field, and a second inner MIC field, and the third MIC user information field may include a third association identifier field, a third MIC information sequence field, and a third inner MIC field. In an embodiment, the first MIC information sequence field carries a value of binary ‘00’, the second MIC information sequence field carries a value of binary ‘OF, and the third MIC information sequence field carries a value of binary ‘ 10’. In an embodiment, the first inner MIC field has a length of 26 bits, the second inner MIC field has a length of 26 bits, and the thirdinner MIC field has a length of 12 bits. In an embodiment, the first association identifier field, the second association identifier field, and the third association identifier field each carry a value of 4094.

[0204] In an embodiment where the MIC field includes the fourth MIC user information field and the fifth MIC user information field (in addition to the first MIC user information field, the second MIC user information field, and the third MIC user information field), the fourth MIC user information field may include a fourth association identifier field, a fourth MIC information sequence field, and a fourth inner MIC field and the fifth MIC user information field may include a fifth association identifier field, a fifth MIC information sequence field, and a fifth inner MIC field. In an embodiment, the first MIC information sequence field may carry a value of binary ‘00’, the second MIC information sequence field may carry a value of binary ‘OF, the third MIC information sequence field may carry a value of binary ‘ 10’, the fourth MIC information sequence field may carry a value of binary ‘ 110’, and the fifth MIC information sequence field may carry a value of binary ‘ 111’. In an embodiment, the first inner MIC field has a length of 26 bits, the second inner MIC field has a length of 26 bits, the third inner MIC field has a length of 26 bits, the fourth inner MIC field has a length of 25 bits, and the fifth inner MIC field has a length of 25 bits. In an embodiment, the first association identifier field, the second association identifier field, the third association identifier field, the fourth association identifier field, and the fifth association identifier field each carry a value of 4094.

[0205] In an embodiment, the wireless device generates AAD based on concatenating a frame control field, a first address field, and a second address field included in the control frame and generates the authentication value based on the AAD. In an embodiment where the control frame is a trigger frame, the authentication value may be further generated based on a user information list field included in the trigger frame.

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

[0207] An embodiment is a wireless device that is configured to perform method 2600. For example, the wireless device may include circuitry operable to generate the control frame, wherein the control frame includes a key ID field that appears before at least one field included in a body of the control frame and a MIC field that appears 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 an integrity of the control frame. The wireless device may further include a wireless transmitter operable to transmit the control frame.

[0208] Turning now to Figure 27, a method 2700 will be described for checking an integrity of a control frame, in accordance with an example embodiment. The method 2700 may be performed by a wireless device (e.g., wireless device 104).

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

[0210] At operation 2710, the wireless device extracts a key ID and a packet number from the key ID field. In an embodiment (e.g., where 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 an 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 inner 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 inner key ID field and the packet number is extracted from the first packet number field and the second packet number field. In an 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 an embodiment, the inner key ID field has a length of 3 bits, the first packet number field has a length of 22 bits, and the second packet number field has a length of 26 bits. In an embodiment, the first association identifier field and the second association identifier field each carry a value of 4093. The wireless device may start the integrity check process using the key ID and / or the packet number before it completely receives the payload of the control frame.

[0211] At operation 2725, the wireless device extracts an authentication value from the MIC field. In an embodiment (e.g., where the control frame is a trigger frame), as shown in block 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 further include a fourth MIC user information field and a fifth MIC user information field). In an embodiment, as shown in block 2735, each MIC user information field includes an association identifier field, a MIC information sequence field, and an inner MIC field, wherein the authentication value is extracted from the inner MIC fields. For example, the first MIC user information field may include a first association identifier field, a first MIC information sequence field, and a first inner MIC field, the second MIC user information field may include a second associationidentifier field, a second MIC information sequence field, and a second inner MIC field, and the third MIC user information field may include a third association identifier field, a third MIC information sequence field, and a third inner MIC field. In an embodiment, the first MIC information sequence field carries a value of binary ‘00’, the second MIC information sequence field carries a value of binary ‘OF, and the third MIC information sequence field carries a value of binary ‘ 10’ . In an embodiment, the first inner MIC field has a length of 26 bits, the second inner MIC field has a length of 26 bits, and the third inner MIC field has a length of 12 bits. In an embodiment, the first association identifier field, the second association identifier field, and the third association identifier field each carry a value of 4094.

[0212] In an embodiment where the MIC field includes the fourth MIC user information field and the fifth MIC user information field (in addition to the first MIC user information field, the second MIC user information field, and the third MIC user information field), the fourth MIC user information field may include a fourth association identifier field, a fourth MIC information sequence field, and a fourth inner MIC field and the fifth MIC user information field may include a fifth association identifier field, a fifth MIC information sequence field, and a fifth inner MIC field. In an embodiment, the first MIC information sequence field carries a value of binary ‘00’, the second MIC information sequence field carries a value of binary ‘OF, the third MIC information sequence field carries a value of binary ‘ 10’, the fourth MIC information sequence field carries a value of binary ‘ 110’, and the fifth MIC information sequence field carries a value of binary ‘ 111’. In an embodiment, the first inner MIC field has a length of 26 bits, the second inner MIC field has a length of 26 bits, the third inner MIC field has a length of 26 bits, the fourth inner MIC field has a length of 25 bits, and the fifth inner MIC field has a length of 25 bits. In an embodiment, the first association identifier field, the second association identifier field, the third association identifier field, the fourth association identifier field, and the fifth association identifier field each carry a value of 4094.

[0213] At operation 2740, the wireless device checks the integrity of the control frame using the key ID, the packet number, and the authentication value. If the integrity check is successful, the wireless device may accept the control frame and further process the control frame. Otherwise, if the integrity check fails, the wireless device may reject the control frame.

[0214] An embodiment is a wireless device that is configured to perform method 2700. For example, the wireless device may include a wireless receiver operable to receive the control frame, wherein the control frame includes a key ID field that appears before at least one field included in a body of the control frame and a MIC field that appears after the at least one field. The wireless device may further include circuitry operable to extract a key ID and a packetnumber from the key ID field, extract an authentication value from the MIC field, and check the integrity of the control frame using the key ID, the packet number, and the authentication value.

[0215] Although many of the solutions and techniques provided herein have been described with reference to a WLAN system, it should be understood that these solutions and techniques are also applicable to other network environments, such as cellular telecommunication networks, wired networks, etc. In some embodiments, the solutions and techniques provided herein may be or may be embodied in an article of manufacture in which a non-transitory machine-readable medium (such as microelectronic memory) has stored thereon instructions which program one or more data processing components (generically referred to here as a “processor” or “processing unit”) to perform the operations described herein. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines). Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired 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 logic structures for performing one or more of the operations described herein. For example, as described herein, an apparatus may include a memory unit, which stores instructions that may be executed by a hardware processor installed 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 portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consi stent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0218] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure can refer to the action and processes of a computersystem, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage systems.

[0219] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus can be specially constructed for the intended purposes, or it can include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. For example, a computer system or other data processing system may carry out the computer-implemented methods described herein in response to its processor executing a computer program (e.g., a sequence of instructions) contained in a memory or other non- transitory machine-readable storage medium. Such a computer program can be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

[0220] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems can be used with programs in accordance with the teachings herein, or it can prove convenient to construct a more specialized apparatus to perform the method. The structure for a variety of these systems will appear as set forth in the description below. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the disclosure as described herein.

[0221] The present disclosure can be provided as a computer program product, or software, that can include a machine-readable medium having stored thereon instructions, which can be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium such as a read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory components, etc.

[0222] In the foregoing specification, embodiments of the disclosure have been described with reference to specific example embodiments thereof. It will be evident that various modifications can be made thereto without departing from the broader spirit and scope ofembodiments of the disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

CLAIMSWhat is claimed is:

1. A method performed by a wireless device to secure a control frame, the method comprising: generating the control frame, wherein the control frame includes a key ID field that appears before at least one field included in a body of the control frame and a message integrity check (MIC) field that appears 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 an integrity of the control frame; and transmitting the control frame.

2. The method of 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 of claim 2, wherein the first key ID user information field includes a first association identifier field, a first key information sequence field, an inner key ID field, and a first packet number field, wherein 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 inner key ID field carries the key ID, wherein the first packet number field and the second packet number field collectively carry the packet number.

4. The method of 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 of claim 3, wherein the inner key ID field has a length of 3 bits, the first packet number field has a length of 22 bits, and the second packet number field has a length of 26 bits.

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

7. The method of 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 of claim 7, wherein the first MIC user information field includes a first association identifier field, a first MIC information sequence field, and a first inner MIC field, wherein the second MIC user information field includes a second association identifier field, a second MIC information sequence field, and a second inner MIC field, wherein the third MIC user information field includes a third association identifier field, a third MIC information sequence field, and a third inner MIC field, wherein the first inner MIC field, the second inner MIC field, and the third inner MIC field collectively carry the authentication value.

9. The method of claim 8, wherein the first MIC information sequence field carries a value of binary ‘00’, the second MIC information sequence field carries a value of binary ‘OF, and the third MIC information sequence field carries a value of binary ‘ 10’.

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

11. The method of claim 8, wherein the first association identifier field, the second association identifier field, and the third association identifier field each carry a value of 4094.

12. The method of claim 7, wherein the MIC field further includes a fourth MIC user information field and a fifth MIC user information field.

13. The method of claim 12, wherein the first MIC user information field includes a first association identifier field, a first MIC information sequence field, and a first inner MIC field, wherein the second MIC user information field includes a second association identifier field, a second MIC information sequence field, and a second inner MIC field, wherein the third MIC user information field includes a third association identifier field, a third MIC information sequence field, and a third inner MIC field, wherein the fourth MIC user information field includes a fourth association identifier field, a fourth MIC information sequence field, and a fourth inner MIC field, wherein the fifth MIC user information field includes a fifth association identifier field, a fifth MIC information sequence field, and a fifth inner MIC field, wherein the first inner MIC field, the second inner MIC field, the third inner MIC field, the fourth inner MIC field, and the fifth inner MIC field collectively carry the authentication value.

14. The method of claim 13, wherein the first MIC information sequence field carries a value of binary ‘00’, the second MIC information sequence field carries a value of binary ‘OF, the third MIC information sequence field carries a value of binary ‘ 10’, the fourth MIC informationsequence field carries a value of binary ‘ 110’, and the fifth MIC information sequence field carries a value of binary ‘ 111’.

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

16. The method of claim 13, wherein the first association identifier field, the second association identifier field, the third association identifier field, the fourth association identifier field, and the fifth association identifier field each carry a value of 4094.

17. The method of claim 1, further comprising: generating additional authentication data (AAD) based on concatenating a frame control field, a first address field, and a second address field included in the control frame; and generating the authentication value based on the AAD.

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

19. A method for checking an integrity of a control frame, the method comprising: receiving the control frame, wherein the control frame includes a key ID field that appears before at least one field included in a body of the control frame and a message integrity check (MIC) field that appears after the at least one field; extracting a key ID and a packet number from the key ID field; extracting an authentication value from the MIC field; and checking the integrity of the control frame using the key ID, the packet number, and the authentication value.

20. The method of 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 of claim 20, wherein the first key ID user information field includes a first association identifier field, a first key information sequence field, an inner key ID field, and afirst packet number field, wherein 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 inner key ID field and the packet number is extracted from the first packet number field and the second packet number field.

22. The method of 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 of claim 21, wherein the inner key ID field has a length of 3 bits, the first packet number field has a length of 22 bits, and the second packet number field has a length of 26 bits.

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

25. The method of 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 association identifier field, a first MIC information sequence field, and a first inner MIC field, wherein the second MIC user information field includes a second association identifier field, a second MIC information sequence field, and a second inner MIC field, wherein the third MIC user information field includes a third association identifier field, a third MIC information sequence field, and a third inner MIC field, wherein the authentication value is extracted from the first inner MIC field, the second inner MIC field, and the third inner MIC field.

27. The method of claim 26, wherein the first MIC information sequence field carries a value of binary ‘00’, the second MIC information sequence field carries a value of binary ‘OF, and the third MIC information sequence field carries a value of binary ‘ 10’.

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

29. The method of claim 26, wherein the first association identifier field, the second association identifier field, and the third association identifier field each carry a value of 4094.

30. The method of claim 25, wherein the MIC field further includes a fourth MIC user information field and a fifth MIC user information field.

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

32. The method of claim 31, wherein the first MIC information sequence field carries a value of binary ‘00’, the second MIC information sequence field carries a value of binary ‘OF, the third MIC information sequence field carries a value of binary ‘ 10’, the fourth MIC information sequence field carries a value of binary ‘ 110’, and the fifth MIC information sequence field carries a value of binary ‘ 111’.

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

34. The method of claim 31, wherein the first association identifier field, the second association identifier field, the third association identifier field, the fourth association identifier field, and the fifth association identifier field each carry a value of 4094.

35. A wireless device configured to secure a control frame, the wireless device comprising: circuitry operable to generate the control frame, wherein the control frame includes a keyID field that appears before at least one field included in a body of the control frame and a message integrity check (MIC) field that appears after the at least one field, wherein the key ID field carries a key ID and a packet number, whereinthe MIC field carries an authentication value for checking an integrity of the control frame; and a wireless transmitter operable to transmit the control frame.

36. A wireless device configured to check an integrity of a control frame, the wireless device comprising: a wireless receiver operable to receive the control frame, wherein the control frame includes a key ID field that appears before at least one field included in a body of the control frame and a message integrity check (MIC) field that appears after the at least one field; and 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 check the integrity of the control frame using the key ID, the packet number, and the authentication value.

Images