Communication system with header and acknowledgement integrity protection

Abstract

The invention relates to a communication system with header and acknowledgement integrity protection. A communication system is provided in which an access point (AP) communicates with a station (STA). The AP and STA may transmit an integrity protection frame. The AP and STA may perform an integrity check on the integrity protection frame. The AP and STA may transmit an integrity protection block acknowledgement (BA) frame in response to receiving the integrity protection frame. The AP and STA may perform an integrity check on the integrity protection BA frame. Padding may be inserted into the integrity protection frame and / or BA frame to accommodate processing delays associated with generating and verifying message integrity checks (MICs) in the frame and / or BA frame. An integrity check may be performed on a corresponding BA frame before, after, or before and after transmission of the frame.

Description

[0001] This application claims priority to U.S. Patent Application No. 19 / 012,627, filed January 7, 2025, and U.S. Provisional Patent Application No. 63 / 561,087, filed March 4, 2024, which are hereby incorporated by reference in their entirety. Technical Field

[0002] The present disclosure relates generally to wireless communications, including wireless communications by electronic devices. Background Art

[0003] The present invention relates to a communication system and method for transmitting wireless data between nodes of a communication network. The nodes may include user equipment devices, wireless access points, wireless base stations, or other electronic devices.

[0004] Ensuring that a communication system exhibits adequate performance levels can be challenging. If care is not taken, wireless data sent by a first device may not be properly received at a second device. Furthermore, when wireless data is transmitted between a first device and a second device, the wireless data may be susceptible to security risks such as man-in-the-middle (MITM) attacks. Summary of the Invention

[0005] A communication system is provided in which an access point (AP) communicates with a station (STA). The AP and STA may transmit integrity-protected frames. The AP and STA may perform integrity checks on the integrity-protected frames. The AP and STA may send integrity-protected block acknowledgement (BA) frames in response to receiving the integrity-protected frames. The AP and STA may perform integrity checks on the integrity-protected BA frames. Padding may be inserted into the integrity-protected frames and / or BA frames to accommodate processing delays associated with generating and verifying a message integrity check (MIC) in the frames and / or BA frames. The integrity check may be performed on the frames before, after, or both before and after the corresponding BA frames are transmitted.

[0006] One aspect of the present disclosure provides a method for operating a first electronic device to wirelessly communicate with a second electronic device. The method may include transmitting an integrity-protected frame using one or more antennas for reception by the second electronic device. The integrity-protected frame may include: a preamble; a medium access control (MAC) header; a delimiter located between the preamble and the MAC header; a message integrity check (MIC) field based on the MAC header; a data payload, the MAC header being located between the data payload and the delimiter; and a padding field configured to accommodate processing delays associated with generating or verifying the MIC field.

[0007] One aspect of the present disclosure provides a method for operating a first electronic device to wirelessly communicate with a second electronic device. The method may include receiving a frame using one or more antennas. The method may include sending an integrity-protected block acknowledgment (BA) frame using one or more antennas for reception by the second electronic device. The integrity-protected BA frame may include: a preamble; a block acknowledgment (ACK) for a medium access control protocol data unit (MPDU) in the frame; a message integrity check (MIC) field based on the block ACK, the block ACK being located between the MIC field and the preamble in the integrity-protected BA frame; and a padding field configured to accommodate processing delays associated with generating or verifying the MIC field.

[0008] One aspect of the present disclosure provides a method for operating a first electronic device to wirelessly communicate with a second electronic device. The method may include receiving a frame using one or more antennas. The method may include sending a block acknowledgement (BA) frame using the one or more antennas for reception by the second electronic device, wherein the BA frame includes a block acknowledgement (ACK) for a media access control protocol data unit (MPDU) in the frame. The method may include using one or more processors to attempt to verify the integrity of a media access control (MAC) header of an MPDU in the frame before sending an integrity-protected BA frame.

[0009] One aspect of the present disclosure provides a method for operating a first electronic device to wirelessly communicate with a second electronic device. The method may include using one or more antennas to receive a frame. The method may include using one or more antennas to send a block acknowledgment (BA) frame for reception by the second electronic device, wherein the BA frame includes a block acknowledgment (ACK) for a medium access control protocol data unit (MPDU) in the frame. The method may include, after integrity protecting the BA frame, using one or more processors to calculate a message integrity check (MIC) value based on at least some of the MPDUs in the MPDU. The method may include using one or more antennas to send a block acknowledgment request (BAR) frame when the calculated MIC value does not match the corresponding MIC field included in the frame, wherein the BAR frame identifies the MPDU. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a diagram of an example wireless communication system in accordance with some embodiments.

[0011] Figure 2 is a diagram of an exemplary wireless station (STA) according to some embodiments.

[0012] Figure 3 is a schematic diagram of an illustrative wireless access point (AP) according to some embodiments.

[0013] Figure 4is a diagram of an illustrative wireless communication system including a first electronic device communicating with a second electronic device via a wireless communication link according to some embodiments.

[0014] Figure 5 is a timing diagram of an exemplary integrity-protected frame and a corresponding integrity-protected block acknowledgement (BA) frame that may be transmitted between a first electronic device and a second electronic device according to some embodiments.

[0015] Figure 6 is a flowchart of illustrative operations involved in integrity protection and integrity checking of wireless data transmitted between a first electronic device and a second electronic device according to some embodiments.

[0016] 7A to 7D is a timing diagram illustrating how padding may be provided at different locations to an example integrity protection frame, according to some embodiments.

[0017] Figure 8 is a timing diagram illustrating how padding between different medium access control protocol data units (MPDUs) may be provided to an example integrity-protected physical protocol data unit (PPDU) frame according to some embodiments.

[0018] Figure 9A and Figure 9B is a timing diagram illustrating how padding may be provided at different locations to an example integrity protection frame, according to some embodiments.

[0019] Figure 10 is a flow diagram of illustrative operations involved in using a receiver to perform an integrity check on a received frame after sending a corresponding BA frame, according to some embodiments.

[0020] Figure 11 is a flow diagram of illustrative operations involved in using a receiver to perform integrity checks on received frames before and after sending corresponding BA frames, in accordance with some embodiments.

[0021] Figure 12 is a flow diagram of illustrative operations involved in using a receiver to perform an integrity check on a received frame before sending a corresponding BA frame, according to some embodiments.

[0022] Figure 13 is a diagram illustrating an example signaling scheme between a multi-layer multi-device (MLMD) AP and MLMD STAs according to some embodiments.

[0023] Figure 14 is a diagram illustrating how a header message integrity check (MIC) may be placed at different locations within an example integrity-protected frame, according to some embodiments.

[0024] Figure 15 is a diagram illustrating how an example integrity-protected frame may include a combined MIC field that integrity protects both the header and the data payload of the integrity-protected frame, according to some embodiments.

[0025] Figure 16 is a diagram of an exemplary integrity-protected multi-STA BA frame with a configurable AID11 field, according to some embodiments.

[0026] Figure 17 A table is shown outlining different exemplary AID11 fields that may be included in an integrity protected multi-STA BA frame according to some embodiments.

[0027] Figure 18 is a diagram of two exemplary integrity protection frames including time synchronization function (TSF) information for requesting a corresponding BA frame, according to some embodiments.

[0028] Figure 19 is a diagram illustrating how data frames and BA frames may be communicated between an exemplary multi-link device (MLD) transmitter and an exemplary MLD receiver according to some embodiments.

[0029] Figure 20 is a timing diagram illustrating how an exemplary first device and second device may use silent reorder buffer updates at the second device to mitigate BA off-synchronization according to some embodiments.

[0030] Figure 21 is a timing diagram illustrating how an exemplary first device and second device may use a transmit buffer update delay at the first device to mitigate BA desynchronization according to some embodiments.

[0031] Figure 22 is a diagram showing how reorder buffer status information may be included in the BA Control field of an example integrity-protected multi-STA BA frame according to some embodiments.

[0032] Figure 23 A table showing an overview of different exemplary AID11 fields that may be included in an integrity-protected multi-STA BA frame having a BA Control field with reorder buffer status information, according to some embodiments. DETAILED DESCRIPTION

[0033] Figure 1An example of a wireless communication system 108 (also sometimes referred to herein as a wireless communication network 108, communication network 108, network 108, or system 108) is shown. Figure 1 This represents one possibility among many, and the features of the present disclosure may be implemented by any of a variety of systems as desired. For example, the embodiments described herein may be implemented in any type of wireless device. The wireless embodiment described below is an example embodiment.

[0034] like Figure 1 As shown, an exemplary wireless communication system 108 includes an access point (AP) 104 that communicates with one or more wireless devices 106 (e.g., a first wireless device 106A, a second wireless device 106B, etc.) via a transmission medium. Wireless devices 106A and 106B may be user devices (e.g., user equipment (UE) devices), such as stations (STAs), non-AP STAs, or wireless local area network (WLAN) devices. Wireless devices 106 are sometimes referred to herein as STAs 106.

[0035] STA 106 may be a device with wireless network connectivity, such as a mobile (e.g., cellular) phone, a handheld device, a wearable device (e.g., a wristwatch device, a pendant device, a ringing device, a head-mounted device such as a virtual, mixed and / or augmented reality headset, goggles, helmet or glasses, etc.), a computer (e.g., a desktop computer, a laptop computer, a computer monitor containing an embedded computer, etc.), a tablet computer, a media player, headphones, one or two wireless earbuds, a television, a gaming device or console, a navigation device, an embedded system (such as a system in which electronic equipment with a display is installed in a kiosk or car), a wireless Internet-connected voice-controlled speaker, a home entertainment device, a remote control device, a game controller, a user input device, a peripheral device or accessory, an electronic stylus or pen, an unmanned aerial vehicle (UAV), an unmanned aerial controller (UAC), an automobile, computing equipment integrated into a vehicle or kiosk, equipment that implements the functionality of two or more of these devices, or virtually any type of wireless device.

[0036] STA 106 may include a processor (processing element) configured to execute program instructions stored in a memory. STA 106 may perform any of the method embodiments described herein by executing such stored instructions. Alternatively or in addition, STA 106 may include a programmable hardware element, such as a field programmable gate array (FPGA), an integrated circuit, and / or any of various other possible hardware components configured to (e.g., individually or in combination) perform any of the method embodiments described herein or any portion of any of the method embodiments described herein.

[0037] The wireless communication system 108 may include one or more wireless access points (APs), such as AP 102. AP 102 may be a standalone AP or an enterprise AP and may include hardware that enables wireless communication with STAs 106, such as STA 106A and STA 106B. AP 102 may also be equipped to communicate with a network 100 (e.g., a WLAN, an enterprise network, and / or another communication network connected to the Internet, among various possible networks). Thus, AP 102 may facilitate communication between STA devices 106 and / or between STA devices 106 and network 100. The AP 102 may be configured to provide communications over one or more wireless technologies, such as any of 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ad, 802.11ax, 802.11ay, 802.11be, 802.11bn, and / or other 802.11 versions, or cellular protocols such as 5G or LTE, including in unlicensed bands (LAA).

[0038] The network 100 may include any desired number of network nodes, terminals, and / or end hosts communicatively coupled together using communication paths including wired links and / or wireless links. A wired link may include a cable (e.g., an Ethernet cable, an optical fiber or other optical cable that uses light to transmit signals, a telephone cable, a radio frequency cable such as a coaxial cable, or other transmission line). A wireless link may include a short-range wireless communication link operating within a few inches, a few feet, or tens of feet, a medium-range wireless communication link operating within a few hundred feet, a few thousand feet, a few miles, or tens of miles, and / or a long-range wireless communication link operating within a few hundred or thousands of miles.

[0039] The nodes of network 100 may be organized into one or more relay networks, mesh networks, local area networks (LANs), wireless local area networks (WLANs), ring networks (e.g., optical rings), cloud networks, virtual / logical networks, the Internet (e.g., communicatively coupled to each other via the Internet), combinations thereof, and / or using any other desired network topology. The network nodes, terminals, and / or end hosts of network 100 may include network switches, network routers, optical add / drop multiplexers, other multiplexers, repeaters, modems, portals, gateways, servers, network cards (line cards), wireless access points, wireless base stations, and / or any other desired network components. The network nodes in network 100 may include physical components such as electronic devices, servers, computers, network cabinets, line cards, user equipment, etc., and / or may include virtual components that are logically defined in software and distributed across two or more underlying physical devices (above them) (e.g., in a cloud network configuration).

[0040] The communication area (or coverage area) of AP 102 (or AP 104) may be referred to as a basic service area (BSA) or a cell. AP 102 (or AP 104) and STA 106 may be configured to communicate over a transmission medium using any of a variety of radio access technologies (RATs) or wireless communication technologies, such as Wi-Fi, LTE, LTE-Advanced (LTE-A), 5G NR, ultra-wideband (UWB), etc. A given RAT may, for example, specify a physical method for implementing a corresponding communication protocol (e.g., a WLAN protocol, a wireless personal area network (WPAN) protocol, a cellular telephone protocol such as a 3G protocol, a 4G (LTE) protocol, a 5G (NR) protocol, etc., a UWB protocol, a satellite communication protocol, a satellite navigation protocol, a device-to-device (D2D) protocol, etc.).

[0041] Thus, AP 102, AP 104, and other similar access points (not shown) operating according to one or more wireless communication technologies can be arranged into a network that can provide continuous or nearly continuous overlapping service to STAs 106A and 106B and similar devices within a geographic area, for example, via one or more communication technologies. For example, a STA can roam directly from one AP to another, or can transition between APs and cellular network cells.

[0042] Note that, at least in some cases, STA 106 may be capable of communicating using any of a variety of wireless communication technologies. For example, STA 106 may be configured to communicate using one or more of Wi-Fi, LTE, LTE-A, 5G NR, Bluetooth, UWB, one or more satellite systems, and the like. Other combinations of wireless communication technologies (including more than two wireless communication technologies) are also possible. Similarly, in some cases, STA 106 may be configured to communicate using only a single wireless communication technology.

[0043] like Figure 1 As shown, the exemplary wireless communication system 108 may also include an AP 104 that communicates with a wireless device 106B via a transmission medium. AP 104 also provides communication connectivity to network 100. Thus, according to some embodiments, a wireless device may be able to connect to one or both of AP 102 (or a cellular base station (BS)) and AP 104 (or another access point) to access network 100. For example, a STA may roam from AP 102 to AP 104 based on one or more factors such as coverage, interference, and capabilities. Note that AP 104 may also allow access to networks different from those allowed by AP 102 (e.g., an enterprise Wi-Fi network, a home Wi-Fi network, etc.).

[0044] In some implementations, the STAs 106 (e.g., STAs 106A and 106B) may include handheld devices such as smartphones or tablets, wearable devices such as smartwatches or smart glasses, and / or may include any of various types of devices with wireless communication capabilities. For example, one or more of the STAs 106A and / or 106B may be wireless devices intended for stationary or nomadic deployments, such as appliances, measurement devices, control devices, and the like.

[0045] STA 106B may also be configured to communicate with STA 106A. For example, STA 106A and STA 106B may be capable of performing direct device-to-device (D2D) communication. In some embodiments, such direct communication between STAs may also be referred to as, or alternatively referred to as, peer-to-peer (P2P) communication. Direct communication may be supported by AP 102 (e.g., AP 102 may facilitate discovery and various possible forms of assistance), or may be performed in a manner not supported by AP 102. According to various embodiments, such P2P communication may be performed using any of 3GPP-based D2D communication technologies, Wi-Fi-based P2P communication technologies, UWB, Bluetooth (BT), and / or various other direct communication technologies.

[0046] STA 106 may include one or more devices or integrated circuits for facilitating wireless communication, potentially including a WLAN (e.g., Wi-Fi) modem, a cellular modem, and / or one or more other wireless modems. The wireless modem may include one or more processors (processor elements) and various hardware components as described herein. STA 106 may perform any of the method embodiments described herein (or any portion thereof) by executing instructions on one or more programmable processors. Alternatively or in addition, the one or more processors may be one or more programmable hardware elements, such as an FPGA (field programmable gate array) or other circuitry configured to perform any of the method embodiments described herein or any portion of any of the method embodiments described herein. The wireless modems described herein may be used for a STA as defined herein, a wireless device as defined herein, or a communication device as defined herein. The wireless modems described herein may also be used for an AP, a base station, a picocell, a femtocell, or other similar network-side devices.

[0047] STA 106 may include one or more antennas for communicating using one or more wireless communication protocols or radio access technologies. In some embodiments, STA 106 may be configured to communicate using a single shared radio. The shared radio may be coupled to a single antenna, or may be coupled to multiple antennas (e.g., for multiple-input and multiple-output (MIMO)) for performing wireless communications. Alternatively, STA 106 may include two or more radios, each of which may be configured to communicate via a respective wireless link. Other configurations are also possible.

[0048] Figure 2 FIG. 1 is a block diagram of one possible STA device, such as STA 106. STA 106 is sometimes referred to herein as UE 106, UE device 106, or device 106. STA 106 may also be referred to herein as non-AP STA 106 or non-AP device 106. Figure 2 As shown, STA 106 may include wireless circuitry such as wireless communication circuitry 230 , a subsystem such as system on chip (SOC) 200 , a display such as display 260 , and one or more interfaces such as connector interface (I / F) 220 .

[0049] SOC 200 may include one or more components configured for various purposes. Figure 2As shown, the SOC 200 may include one or more processors 202 and display circuitry 204. The processor 202 may execute program instructions for the STA 106. The display circuitry 204 may perform graphics processing and may provide display signals to a display 260. The display 260 may be a touch-sensitive display, a force-sensitive display, or a display without touch or force sensitivity. For example, the display 260 may include one or more arrays of display pixels that emit light containing an image.

[0050] The SOC 200 may also include sensor circuits, such as motion sensing circuitry 270. The motion sensing circuitry 270 may detect motion of the STA 106 using, for example, a gyroscope, an accelerometer, an inertial measurement unit (IMU), a compass, and / or any of a variety of other motion sensing components. The processor 202 may also be coupled to a memory management unit (MMU) 240, which may be configured to receive addresses from the processor 202 and may translate these addresses into locations in a memory or other storage circuit (e.g., the memory 206, read-only memory (ROM) 250, flash (NAND) memory 210, etc.). The MMU 240 may be configured to perform memory protection and page table translation or setup. In some embodiments, the MMU 240 may be included as part of the processor 202.

[0051] The SOC 200 may be coupled to various other circuits in the STA 106. For example, the SOC 200 may be coupled to various types of memory (e.g., flash memory 210), a connector interface 220 (e.g., for coupling to a computer system, a docking station, a charging station, etc.), a display 260, and wireless communication circuitry 230 (e.g., for performing wireless communications under LTE, LTE-A, 5G NR, Bluetooth, Wi-Fi, NFC, GPS, UWB, etc.).

[0052] STA 106 may include at least one antenna 235. If desired, STA 106 may include multiple antennas 235, such as at least a first antenna 235A and a second antenna 235B. STA 106 may use antennas 235 to perform wireless communications with access points, base stations, and / or other devices. For example, STA 106 may use antennas 235A and 235B to perform communications with access points, base stations, and / or other devices. Figure 1 As described above, in some embodiments, the STA 106 may be configured to communicate wirelessly using a variety of wireless communication standards or radio access technologies (RATs).

[0053] The wireless communication circuitry 230 may include one or more modems, such as a WLAN (e.g., Wi-Fi) modem 232, a cellular modem 234, and a Bluetooth modem 236. If desired, the wireless communication circuitry 230 may include additional modems for handling other RATs or wireless communication technologies. The STA 106 may use the WLAN modem 232 (sometimes referred to herein as a Wi-Fi modem 232) to perform communication with one or more external devices (e.g., Figure 1 The STA 106 may use the Bluetooth modem 236 to perform Bluetooth or other WPAN communications with one or more external devices (e.g., another STA 106). The STA 106 may use the cellular modem 234 to perform cellular communications with one or more wireless base stations according to one or more cellular communication technologies (e.g., according to one or more 3GPP specifications).

[0054] As described herein, the STA 106 may include hardware components and software components for implementing embodiments of the present disclosure. For example, one or more components of the wireless communication circuitry 230 (e.g., Wi-Fi modem 232, cellular modem 234, BT modem 236) of the STA 106 may be configured to implement part or all of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium), one or more processors configured as FPGAs (field programmable gate arrays), and / or processors using dedicated hardware components that may include ASICs (application-specific integrated circuits). The STA 106 may include a support structure, such as a housing. The housing may include conductive and / or dielectric housing walls, layers, and / or other structures.

[0055] If desired, the STA 106 may include additional input-output devices (not shown for clarity). The input-output devices may be used to allow data to be supplied to the STA 106 and to allow data to be provided from the STA 106 to external devices. The input-output devices may include a user interface device, a data port device (interface 220), a touch sensor, a display (e.g., display 260), a light-emitting component such as a display without touch sensor capabilities, buttons (mechanical, capacitive, optical, etc.), a scroll wheel, a touchpad, a keypad, a keyboard, a microphone, a camera, buttons, a speaker, a status indicator, an audio jack and other audio port components, a digital data port device, a motion sensor (accelerometer, gyroscope, and / or compass to detect motion), a capacitive sensor, a proximity sensor, a magnetic sensor, a force sensor (e.g., a force sensor coupled to a display to detect pressure applied to the display), a temperature sensor, etc. In some configurations, keyboards, headsets, displays, pointing devices such as touchpads, mice, and joysticks, and other input-output devices may be coupled to the STA 106 using wired or wireless connections (e.g., some of the input-output devices may be peripheral devices coupled to a main processing unit or other portion of the STA 106 via a wired or wireless link).

[0056] Figure 3 is such as AP 104 (or equivalently, Figure 1 In some cases (e.g., in the context of 802.11 communications), AP 104 may also be referred to as a station (STA), and may be more specifically referred to as an AP STA. Note that Figure 3 The AP of is only one example of a possible access point. As shown, the AP 104 may include one or more processors 304 that may execute program instructions for the AP 104. The processor 304 may also be coupled to an MMU 340, which may be configured to receive addresses from the processor 304 and translate those addresses into locations in memory (e.g., memory 360 and ROM 350), or into other memory circuits, circuits, or devices.

[0057] The AP 104 may include at least one network port 370. The network port 370 may be configured to couple to a network and provide access to the network (e.g., Figure 1The network port 370 (or an additional network port) may also or alternatively be configured to couple to a cellular network (e.g., a core network (CN) of a cellular service provider). The core network may provide mobility-related services and / or other services to multiple UE devices (e.g., STA 106). In some cases, the network port 370 may be coupled to a telephone network via the core network, and / or the core network may provide a telephone network (e.g., between other UE devices served by the cellular service provider).

[0058] AP 104 may include one or more radios 330A-330N, each of which may be coupled to a corresponding communication chain 332 and at least one antenna 334, and possibly to multiple antennas (e.g., first radio 330A is coupled to antenna 334A via communication chain 332A, Nth radio 330N is coupled to antenna 334N via communication chain 332N, and so on). Radio 330 may be configured to operate as a wireless transceiver for communicating with STA 106 via communication chain 332 and antenna 334. Antennas 334A-334N communicate with their respective radios 330A-330N via communication chains 332A-332N. Communication chain 332 may be a receive chain, a transmit chain, or may include both a transmit chain and a receive chain. Radios 330A-330N may be configured to communicate according to various wireless communication standards, including, but not limited to, LTE, LTE-A, 5G NR, 6G, UWB, WLAN (Wi-Fi), WPAN (BT), and the like. If desired, the AP 104 can be configured to operate over multiple wireless links using one or more radios 330A-330N, with each radio configured to operate over a respective wireless link.

[0059] The AP 104 may be configured to communicate wirelessly using one or more wireless communication standards. In some cases, the AP 104 may include multiple radio components that enable network entities to communicate according to multiple wireless communication technologies. For example, as one possibility, the AP 104 may include an LTE or 5G radio for communicating according to LTE or 5G NR and a Wi-Fi radio for communicating according to Wi-Fi. In this case, the AP 104 may be able to operate as both a cellular base station and a Wi-Fi access point. As another possibility, the AP 104 may include a multimode radio component capable of communicating according to any of a plurality of wireless communication technologies (e.g., NR and Wi-Fi, NR and LTE, etc.). As another possibility, the AP 104 may be configured to function exclusively as a Wi-Fi access point, for example, without cellular communication capabilities.

[0060] As further described herein, the AP 104 may include hardware and software components for implementing or supporting the features described herein. The processor 304 of the AP 104 may be configured to implement or support implementation of some or all of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium) to operate multiple wireless links using multiple corresponding radio components. Alternatively, the processor 304 may be configured as a programmable hardware element, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit), or a combination thereof. Alternatively (or in addition), the processor 304 of the AP 104, together with one or more other components 330, 332, 334, 340, 350, 360, 370, may be configured to implement or support implementation of some or all of the features described herein.

[0061] The radio 330 on the AP 104 may use antenna 334 ( Figure 3 ) and the wireless communication circuitry 230 on the STA 106 may use the antenna 235 ( Figure 2 ) to transmit and / or receive radio frequency signals within different frequency bands (sometimes referred to herein as communication bands or simply “frequency bands”) at radio frequencies. The frequency bands processed by the AP 104 and the STA 106 may include satellite communication bands (e.g., C-band, S-band, L-band, X-band, W-band, V-band, K-band, K-band, etc.). a Frequency band, K u frequency bands, etc.); Wireless Local Area Network (WLAN) frequency bands (e.g., (IEEE 802.11) or other WLAN communication bands) such as the 2.4 GHz WLAN band (e.g., 2400 MHz to 2480 MHz), the 5 GHz WLAN band (e.g., 5180 MHz to 5825 MHz), 6E band (e.g., 5925 MHz to 7125 MHz) and / or other frequency bands (e.g., 1875 MHz to 5160 MHz); Wireless Personal Area Network (WPAN) bands such as 2.4 GHz frequency bands or other WPAN communication bands, cellular telephone bands (e.g., bands from about 600 MHz to about 5 GHz, 3G bands, 4G LTE bands, 5G new radio frequency range 1 (FR1) bands below 10 GHz, 5G new radio frequency range 2 (FR2) bands between 20 GHz and 60 GHz, 6G bands, etc.), other centimeter or millimeter wave bands between 10 GHz and 300 GHz; near field communication (NFC) bands (e.g., 13.56 MHz); satellite navigation bands (e.g., GPS bands from 1565 MHz to 1610 MHz, Global Navigation Satellite System (GLONASS) bands, BeiDou Satellite Navigation System (BDS) bands, etc.); ultra-wideband (UWB) bands operating under the IEEE 802.15.4 protocol and / or other ultra-wideband communication protocols; communication bands under the 3GPP wireless communication standard family; communication bands under the IEEE 802.XX standard family; and / or any other desired frequency bands of interest.

[0062] Any desired antenna structure may be used to form antenna 334 ( Figure 3 ) and antenna 235( Figure 2 ). For example, the antenna may include an antenna having a resonant element formed by a loop antenna structure, a patch antenna structure, an inverted-F antenna structure, a slot antenna structure, a planar inverted-F antenna structure, a helical antenna structure, a monopole antenna, a dipole antenna, a hybrid of these designs, or the like. If desired, one or more antennas may include an antenna resonant element formed by a conductive portion of the device housing (e.g., a peripheral conductive housing structure extending around the periphery of the display on STA 106). Filter circuits, switching circuits, impedance matching circuits, and / or other antenna tuning components may be adjusted to adjust the frequency response and wireless performance of the antenna over time. If desired, multiple antennas may be implemented as phased array antennas (e.g., where each antenna forms a radiator or antenna element of a phased array antenna (sometimes also referred to as a phased antenna array)). In these cases, the phased array antenna can transmit RF signals within a signal beam. The phase and / or amplitude of each radiator in the phased array antenna can be adjusted so that the RF signals of each radiator interfere constructively and destructively to guide or direct the signal beam in a specific pointing direction (e.g., the direction of peak signal gain). The signal beam may be adjusted or steered over time.

[0063] The wireless communication circuit 230 may use the antenna 235 ( Figure 2 ) to transmit radio frequency signals. Radio component 330 may use antenna 334 ( Figure 3) to transmit radio frequency signals. As used herein, the term "transmitting radio frequency signals" means the sending and / or receiving of radio frequency signals (e.g., for performing unidirectional and / or bidirectional wireless communication with external wireless communication equipment). As used herein, the term "transmitting wireless data" means the sending and / or receiving of wireless data (e.g., as performed by a corresponding radio frequency signal). An antenna can transmit radio frequency signals by radiating the radio frequency signals into free space (or radiating into free space through an intervening device structure such as a dielectric cover layer). Additionally or alternatively, an antenna can receive radio frequency signals from free space (or through an intervening device structure such as a dielectric cover layer). The transmission and reception of radio frequency signals by an antenna each involves the excitation or resonance of antenna currents on an antenna resonating element in the antenna by radio frequency signals within the operating frequency band of the antenna.

[0064] The wireless communication circuit 230 may be coupled to the antenna 235 ( Figure 2 ). Radio component 330 may be coupled to antenna 334 ( Figure 3 Communication link 332 ( Figure 3 ) may be provided on an RF transmission line between the antenna 334 and the radio 330. The RF transmission line may include a coaxial cable, a microstrip transmission line, a stripline transmission line, an edge-coupled microstrip transmission line, an edge-coupled stripline transmission line, a transmission line formed by a combination of these types of transmission lines, or the like. If desired, the RF transmission line may be integrated into a rigid and / or flexible printed circuit board. If desired, one or more of the RF lines may be shared between radio components or modems. If desired, an RF front end (RFFE) module may be inserted on one or more RF transmission lines (e.g., on Figure 3 within the communication link 332 or within Figure 2 The RF front-end module may include a substrate, integrated circuit, chip, or package separate from the radio component or modem, and may include filter circuits, switching circuits, amplifier circuits, impedance matching circuits, RF coupling circuits, and / or any other desired RF circuitry for operating on RF signals transmitted through the RF transmission line.

[0065] Processor 202 ( Figure 2 ) and processor 304 ( Figure 3 ) may each include one or more processors, such as a microprocessor, a microcontroller, a digital signal processor, a host processor, a baseband processing circuit (e.g., one or more baseband processors or baseband processor integrated circuits), an application specific integrated circuit (ASIC), an FPGA, a central processing unit (CPU), a graphics processing unit (GPU), etc. If necessary, the radio component 330 ( Figure 3) and / or wireless communication circuitry 230 may also include one or more processors. The baseband circuitry in STA 106 and / or AP 104 may, for example, access corresponding storage circuitry (e.g., Figure 2 Memory 206 or Figure 3 The communication protocol stack on the memory 360) is used to: perform user plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer and / or PDU layer; and / or perform control plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer and / or non-access layer.

[0066] AP 104 (or Figure 1 The AP 104 (or AP 102) may communicate with the STA 106 via a corresponding wireless communication link. Radio frequency signals may be wirelessly transmitted between radio components and antennas on the AP 104 and the STA 106 to support the wireless communication link. The radio frequency signals may include wireless data modulated onto one or more carrier waves of the radio frequency signals (e.g., modulated by a transmitter in the radio component 330 of the AP 104 or a transmitter in a modem on the wireless communication circuitry 230 of the STA 106). The wireless data may be organized, modulated onto the radio frequency signals, and demodulated from the radio frequency signals (e.g., by a receiver in the radio component 330 of the AP 104 or a receiver in the modem on the wireless communication circuitry 230 of the STA 106) according to a corresponding communication protocol or standard (e.g., an IEEE 802.11 protocol or standard). The radio frequency signals may be transmitted in one or more frequency bands associated with the communication protocol.

[0067] This document describes a specific implementation in which AP 104 and STA 106 communicate according to the IEEE 802.11 protocol or standard as an example. Under the 802.11 protocol, wireless data is organized into a series of frames or frame streams (e.g., media access control (MAC) frames) carried by radio frequency signals. Frames, sometimes also referred to as packets, may include management frames, control frames, data frames, beacon frames, association frames, authentication frames, acknowledgment (ACK) frames, block ACK frames, and / or other types of frames. Each frame may include a frame header, a body (e.g., following the header), and a trailer (e.g., following the body). The header may include, for example, source address information identifying the sender of the frame, destination address information identifying some or all of the intended recipients of the frame, routing information, identifier information identifying one or more aspects of some or all of the frame (e.g., information identifying the type of frame), control information, etc. The body may include, for example, a data payload (e.g., a payload of voice data, video data, web browsing data, application data, etc.). The trailer may include check information that helps authenticate the frame to the recipient. As an example, the check information may include a frame check sequence (FCS) or a cyclic redundancy check (CRC) field.

[0068] Under the bidirectional communication link between the AP 104 and the STA 106, frames are transmitted from the AP 104 to the STA 106 and from the STA 106 to the AP 104. The STA 106 may send one or more ACK frames or block ACK frames to the AP 104 to acknowledge successful receipt of the one or more frames sent by the AP 104. The AP 104 may send one or more ACK frames or block ACK frames to the STA 106 to acknowledge successful receipt of the one or more frames sent by the AP 104.

[0069] When a first device (e.g., AP 104 or STA 106) transmits wireless data to a second device (e.g., STA 106 or AP 104) via a medium, care should be taken to ensure that the second device correctly receives the wireless data transmitted by the first device. In addition, care should be taken to prevent an unauthorized third device (e.g., a so-called man-in-the-middle (MITM) attacker) from receiving the wireless data transmitted by the first device, to prevent the third device from relaying the wireless data or transmitting modified or additional wireless data to the second device (e.g., in order to deceive the second device into believing that the third device is actually the first device), and / or to prevent the third device from deceiving the second device into transmitting additional wireless data to the third device instead of the first device.

[0070] To help alleviate these problems, the first device may perform integrity protection on one or more fields of a frame of wireless data sent by the first device to a second device (e.g., an intended recipient). The second device may receive the integrity-protected frame from the first device. After receiving the integrity-protected frame, the second device may perform an integrity check (sometimes also referred to herein as integrity verification or validation) to verify the integrity of the received integrity-protected frame. Verifying the integrity of the received integrity-protected frame may allow the second device to verify that it has correctly received all the information in the integrity-protected frame sent by the first device, and / or verify that it has received the frame from the first device and not an unauthorized third (e.g., MITM) device. The second device may also perform integrity protection on one or more fields of a frame of wireless data that it sends to the second device. The first device may then perform an integrity check on the integrity-protected frame sent by the second device.

[0071] Figure 4 FIG. 1 is a diagram illustrating how a first device and a second device in a wireless communication system 108 can transmit wireless data to each other. Figure 4 As shown, the wireless communication system 108 may include at least a first device 400A (e.g., Figure 1 STA 106 or AP 102 / 104 and a second device 400B (eg, Figure 1Devices 400A and 400B can communicate wireless data with each other via wireless communication link 404. An embodiment of implementing and maintaining wireless communication link 404 using the IEEE 802.11 protocol (e.g., 802.11bn or other versions of the 802.11 protocol) is described herein as an example.

[0072] Device 400A may perform integrity protection on wireless data and may send the integrity-protected wireless data to device 400B via wireless communication link 404. The integrity-protected wireless data may include one or more frames (e.g., data frames). Device 400B may perform an integrity check to verify the data from the integrity-protected frames received from device 400A. Device 400B may send an acknowledgment message, such as a block acknowledgment (BA) frame, to device 400A via wireless communication link 404 for the received integrity-protected frames. If necessary, device 400B may perform integrity protection on the BA frames, and device 400A may perform an integrity check to verify the integrity-protected BA frames received from device 400B. In this example, device 400A functions as a transmitting (TX) device and device 400B functions as a receiving (RX) device. This is illustrative, and at other times, device 400B may function as a TX device and device 400A may function as a RX device. The integrity check may help prevent a third device, such as device 402 (e.g., a MITM device), from interfering with wireless communication link 404.

[0073] A transmitting device may utilize a transmit (TX) buffer and a temporary buffer to transmit data to a receiving device, which then receives and processes the data in the temporary buffer and reordering buffer. For example, when device 400A acts as a transmitting device, device 400A uses TX buffer 406 and temporary buffer 408 to process transmitted data. When device 400B acts as a receiving device, device 400B uses temporary buffer 410 and reordering buffer 412 to process received data. Device 400B may also include a TX buffer for transmitting data. Device 400A may also include a reordering buffer for receiving data.

[0074] Figure 5 5 is a timing diagram illustrating an exemplary frame 500 of integrity-protected wireless data sent by device 400A to device 400B and a corresponding integrity-protected BA frame 502 sent by device 400B to device 400A in response to frame 500. Figure 5As shown, a frame 500 (e.g., a data frame) includes several fields (e.g., as specified by the corresponding IEEE 802.11 protocol). The fields of frame 500 may include a preamble (e.g., one or more preamble fields) such as preamble 506, followed by a delimiter field such as aggregate medium access control protocol data unit (A-MPDU) delimiter 508 (sometimes also referred to herein as MPDU delimiter 508), followed by a header such as MAC header 510, followed by a MAC header (HDR) message integrity check (MIC) field such as HDR MIC 512, followed by a payload field such as medium access control protocol data unit (MPDU) field 514. MPDU field 514 may also include a MIC for the payload within MPDU field 514 (for clarity, the MIC field is not shown in FIG. 1 ). Figure 5 not shown).

[0075] For clarity, Figure 5 The simplest case is shown, in which frame 500 includes only a single MPDU. If desired, frame 500 may be a physical protocol data unit (PPDU) frame including multiple MPDUs. Each MPDU may be preceded by a corresponding MPDU delimiter (e.g., A-MPDU delimiter 508) in the PPDU frame. In these embodiments, A-MPDU delimiter 508, MAC header 510, HDR MIC 512, and MPDU field 514 may form a single A-MPDU subframe 530 (delimiter 508, MAC header 510, HDR MIC 512, and MPDU field 514 are sometimes referred to herein as A-MPDU subframe 530 or simply subframe 530). A PPDU frame may include a series of multiple A-MPDU subframes. Each MPDU in a frame may have a corresponding sequence number (SN) that identifies the temporal position or order of the MPDU within the frame. The MAC header of each subframe may identify the SN of its corresponding MPDU as well as other header information.

[0076] Preamble 506 may include a PHY layer preamble and / or other preamble information for frame 500. A-MPDU delimiter 508 may define the location and length of its corresponding MPDU field 514 within frame 500 (e.g., within an aggregate frame in implementations where frame 500 is a PPDU frame). MAC header 510 includes MAC header information for MPDU field 514. For example, MAC header 510 may include a Header Group Number (HDR PN) field. The HDR PN field may contain a unique value, a random number, used for detecting MAC header replay and integrity protection. HDR MIC 512 includes integrity protection check information for MAC header 510. For example, HDR MIC 512 may be generated by inputting some or all of MAC header 510 into a cryptographic function, such as a hash function (e.g., HDR MIC 512 may be a hash value or other cryptographic function output generated based on the contents of MAC header 510). MPDU field 514 may include any desired payload data for frame 500. The MPDU field 514 may also include an additional MIC (not shown) generated by inputting some or all of the data payload of the MPDU field 514 into a cryptographic function such as a hash function. Figure 5 Although not shown, frame 500 may also include a final (trailer) field following its last MPDU that includes a frame check sequence (FCS). The FCS may be a checksum or another value calculated based on all the data in frame 500 (e.g., the FCS may be the output of a hash function, a checksum function, or other cryptographic function that takes all the data in frame 500 as its input).

[0077] In response to receipt of frame 500, device 400B ( Figure 4 ) may generate and send a BA frame 502. Device 400B may send the BA frame 502 after a period of time, such as a short interframe space (SIFS) 504, has passed since the end of the frame 500 or the MPDU field 514 (e.g., as specified by the IEEE 802.11 protocol). SIFS 504 may, for example, provide time for device 400B to process the frame 500 and respond with an ACK frame, such as BA frame 502. Device 400B may send the BA frame 502 using a predetermined or preconfigured duration, modulation and coding scheme (MCS), and number of spatial streams (NSS).

[0078] like Figure 5As shown, BA frame 502 includes several fields (e.g., as specified by the corresponding IEEE 802.11 protocol). BA frame 502 may include a preamble such as preamble 516, a block acknowledgement (ACK) message field such as block acknowledgement (ACK) 518, and a message integrity check field such as MIC 520. Preamble 516 may include a PHY layer preamble and / or other preamble information for BA frame 502. Block ACK 518 may include information confirming to device 400A that device 400B has successfully received the corresponding MPDU field 514 in frame 500. In implementations where frame 500 includes a single MPDU field 514, BA frame 502 may also sometimes be referred to simply as an ACK frame. In implementations where frame 500 includes multiple MPDU fields 514 (e.g., when frame 500 is a PPDU frame), block ACK 518 may confirm that multiple MPDUs from frame 500 were successfully received at device 400B.

[0079] MIC 520 includes integrity protection check information for block ACK 518. MIC 520 may be generated, for example, by inputting some or all of block ACK 518 into a cryptographic function such as a hash function (e.g., MIC 520 may be a hash value or other cryptographic function output generated based on the contents of block ACK 518). Device 400A is sometimes also referred to herein as a transmitting or transmitter (TX) device of frame 500 and / or a receiver or receiver (RX) device of BA frame 502. Device 400B is sometimes also referred to herein as a TX device of BA frame 502 and / or an RX device of frame 500.

[0080] Figure 6 is Figure 4 Transmitted between devices 400A and 400B Figure 5 Flowchart of exemplary operations involved in the BA frame 500 and the BA frame 502. Figure 6At operation 600, device 400A may generate an integrity-protected frame, such as frame 500. For example, device 400A may integrity-protect the frame by generating a corresponding HDR MIC 512 based on the MAC header 510 of each MPDU field 514 in frame 500. Device 400A may then include HDR MIC 512 in frame 500. Device 400A may also integrity-protect the frame by generating an additional MIC for the data payload of each MPDU field 514 and inserting the additional MIC into or adjacent to each MPDU field. If necessary, device 400A may combine the HDR MIC with the corresponding additional MIC for a given MPDU field to generate a combined MIC that is inserted into the frame. Device 400A may also generate an FCS based on the content of frame 500 and may include the FCS in frame 500 (e.g., in a trailer field of frame 500). If necessary, device 400A may insert one or more padding fields into the frame to help accommodate processing delays.

[0081] At operation 602, device 400A may transmit frame 500 to device 400B.

[0082] At operation 604, device 400B may begin receiving frame 500 from device 400A. Device 400B may perform an integrity check on the received frame 500 (e.g., may verify its integrity). This may also sometimes be referred to herein as checking the integrity of frame 500, checking integrity protection of frame 500, verifying the integrity of frame 500, verifying integrity protection of frame 500, checking the integrity of frame 500, or checking integrity protection of frame 500. If desired, the integrity check may include a replay detection operation. Replay detection may be performed to ensure that the HDR PN value increases over time (e.g., by comparing the HDR PN value to a previous HDR PN value and determining whether the newer HDR PN value is greater than the previous HDR PN value). The integrity check may further include operating, calculating, or generating an HDR MIC for each MAC header 510 in the received frame (e.g., using the same hash function or cryptographic function as used by the device 400A to generate the HDR MIC 512, with the corresponding MAC header 510 as input to the function) and comparing the calculated HDR MIC with the HDR MIC 512 included in the frame 500. If desired, this may further include operating, calculating, or generating an additional MIC for the data payload in each MPDU field 514 of the received frame and comparing the calculated additional MIC with the corresponding additional MIC of the MPDU field 514 as included in the frame 500. If desired, the device 400B may further generate an FCS for the received frame 500 and may compare the generated FCS with the FCS included in the frame 500. If / when each of the calculated HDR MICs matches the corresponding HDR MIC 512 included in the frame 500 and / or each of the calculated additional MICs matches the corresponding additional MIC in the frame 500, the device 400B successfully verifies / checks the integrity of the received frame 500 (e.g., the integrity check is successful). If one of the calculated HDR MICs does not match the corresponding HDR MIC 512 included in the frame 500 and / or one of the calculated additional MICs does not match the corresponding additional MIC included in the frame 500, the device 400B does not verify the integrity of the received frame 500 (e.g., the integrity check is unsuccessful / fails, the frame is identified as invalid or unverified, etc.). When the integrity check is successful or unsuccessful, the device 400B may take appropriate action.

[0083] At operation 606, the device 400B may generate an integrity-protected BA frame, such as the BA frame 502. The device 400B may integrity-protect the BA frame by generating a MIC 520 based on the block ACK 518 and including the MIC 520 in the BA frame 502. If desired, the device 400B may insert one or more padding fields into the BA frame to help accommodate processing delays.

[0084] At operation 608 , device 400B may send the integrity-protected BA frame to device 400A. If desired, device 400B may perform operations 606 and / or 608 before or concurrently with operation 604 .

[0085] At operation 610, device 400A may begin receiving a BA frame 502 from device 400B. Device 400A may perform an integrity check on (e.g., may verify the integrity of) the received BA frame 502. This may also sometimes be referred to herein as checking the integrity of the BA frame 502, checking the integrity protection of the BA frame 502, verifying the integrity of the BA frame 502, verifying the integrity of the BA frame 502, checking the integrity of the BA frame 502, or checking the integrity protection of the BA frame 502. This may include operating, calculating, or generating a MIC for the block ACK 518 in the received BA frame (e.g., using the same hash function or cryptographic function as used by device 400B to generate the MIC 520, with the corresponding block ACK 518 as input to the function) and comparing the generated MIC with the MIC 520 included in the BA frame 502. The integrity check may also optionally include requesting frame authentication, as described in more detail below. If / when the generated MIC matches the MIC 520 included in the BA frame 502, the device 400A successfully verifies / checks the integrity of the received BA frame 502 (e.g., the integrity check is successful). If the generated MIC does not match the MIC 520 included in the BA frame 502, the device 400A does not verify the integrity of the received frame 500 (e.g., the integrity check is unsuccessful). When the integrity check is successful or unsuccessful, the device 400A may take appropriate action. The process may then loop back to operation 600 via path 612 as the device 400A continues to send wireless data to the device 400B. If desired, the device 400A may perform operation 600 after or concurrently with a subsequent iteration of operation 600.

[0086] In this way, the frame 500 and the BA frame 502 ( Figure 5 ) to help protect against Figure 4402, and can help optimize wireless communication between devices 400A and 400B. MAC header integrity protection (e.g., HDR MIC 512 in frame 500) can, for example, help ensure that an attacker (e.g., device 402) cannot change the MAC header integrity of STA 106 ( Figure 1 ) to receive PPDUs with excess bandwidth (BW) or NSS (e.g., via Operational Mode Indication (OMI) A-Control) and / or may help ensure that an attacker cannot cause the AP 102 / 104 ( Figure 1 ) believes that the STA 106 is incorrectly in power save or active mode, which may otherwise result in frame loss or lack of frame transmission (e.g., via the STA's power management field). On the other hand, BA frame integrity protection (e.g., MIC 520 in BA frame 502) can help ensure that the SNs of devices 400A and 400B are synchronized. For example, if device 400B expects an SN that is too high, device 400B may discard received frames with a smaller SN. In addition, if device 400B has a hole in its reordering buffer, device 400B may not be able to correctly forward received frames to its corresponding software application or network 100 ( Figure 1 ), which may cause sending delays.

[0087] Consider Figure 4 FIG2 is an example of a MITM attack performed by device 402. In this example, device 402 intercepts frame 500 sent by device 400A (e.g., a frame with MPDUs with sequence numbers (SN) 1, 2, 3, and 4), modifies data from frame 500 (e.g., a frame with only MPDUs with sequence numbers 1 and 2, but not sequence numbers 3 and 4, from data sent by device 400A), and then sends the modified data to device 400B. Device 400A does not receive a BA frame. Integrity protection and checking can help mitigate this type of attack.

[0088] Performing integrity checks on frame 500 and BA frame 502 may also require processing delays by devices 400A and 400B. Figure 5 , the device 400A may need a period of time 522 to generate (e.g., calculate, compute, etc.) the HDR MIC 512 for the MAC header 510 (e.g., at Figure 6 As another example, device 400B may require a period of time 526 after receiving the end of MAC header 510 to verify HDR MIC 512 (e.g., Figure 6 As another example, device 400B may require time period 524 to generate (e.g., calculate, compute, etc.) MIC 520 for block ACK 518 (e.g., at operation 604). Figure 6As another example, device 400A may require a period of time 528 to verify MIC 520 after receiving the end of MIC 520 (e.g., Figure 6 610).

[0089] If desired, frame 500 and / or BA frame 502 may include one or more padding fields that help accommodate these processing delays. 7A to 7D Four examples of padding fields that device 400A may include in frame 500 are shown. Figure 7A As shown in the first example of FIG, device 400A may generate a frame 500 including a padding field such as padding (PAD) 700 between the A-MPDU delimiter 508 and the MAC header 510. In general, padding 700 may include any desired sequence of one or more padding bits. As an example, padding 700 may include one or more repetitions of the A-MPDU delimiter 508 (e.g., two or more copies of the A-MPDU delimiter 508 may be present between the preamble 506 and the MAC header 510).

[0090] For example, Figure 7B As shown, the padding 700 may be located between the MAC header 510 and the HDR MIC 512 in the frame 500. Figure 7C As shown, padding 700 may be inserted between the HDR MIC 512 and the MPDU field 514 in the frame 500. In another example, as shown in FIG. Figure 7D As shown, padding 700 may be appended to the MPDU field 514 and / or the end of the frame 500 . 7A to 7C The padding 700 of the preamble 506 may include any desired sequence of one or more padding bits or symbols (e.g., orthogonal frequency division multiplexing (OFDM) symbols, each of which has a 4us duration, a 12us duration, or another duration specified by the communication protocol). If desired, in some cases, the padding 700 may be appended to the beginning of the preamble 506 (e.g., at position 702). If desired, the frame 500 may be 7A to 7D Padding 700 is included at two or more of the illustrated locations. By way of example, the padding 700 can include one or more repetitions of the A-MPDU delimiter 508, repetitions of one or more other fields of the frame 500, blank or empty fields, fields or sequences of bits or symbols defined by a communication protocol as intended or reserved for padding, etc. For example, the padding 700 can allow more time for the device 400A to generate the HDR MIC 512 for the MAC header 510 when generating and transmitting the frame 500 and / or for the device 400B to verify the HDR MIC 512 in the received frame 500.

[0091] Figure 85 is a diagram showing an example in which a frame 500 is a PPDU frame having a plurality of MPDUs. Figure 8 As shown, the frame 500 may include a set of MPDU fields 800. Each MPDU field 800 may include Figure 5 The corresponding MPDU field 514 of the corresponding subframe can be used with different corresponding subframes (e.g., Figure 5 If desired, each MPDU field 800 may also include a field before the corresponding MPDU field 514. Figure 5 One or more of the other fields 506, 508, 510 and 512.

[0092] Each MPDU field 800 has a corresponding SN that specifies the order of the MPDU fields within the frame 500. Figure 8 In the example shown in FIG. 5 , the frame 500 has four MPDU fields 800, including a first MPDU field 800-0 with SN=A, a second MPDU field 800-1 with SN=A+1, a third MPDU field 800-2 with SN=A+2, and a fourth MPDU field 800-3 with SN=A+3. MPDU fields 800-0 through 800-3 may also have corresponding increasing HDR PN values. This is exemplary, and in general, the frame 500 may have any desired number of MPDU fields 800.

[0093] The frame 500 may include padding 700 before and / or after each MPDU field 800. If desired, the frame 500 may have different padding 700 having different characteristics and / or including different padding bits and / or symbols at different locations within the frame. For example, there may be a first set of padding fields 700A and a second set of padding fields 700B in the frame 500. The padding field 700A may, for example, appear before and after each MPDU field 800 in the frame 500, except for the last MPDU field 800 in the frame 500 (e.g., MPDU field 800-3). The padding field 700B may appear after the last MPDU field 800 in the frame 500 (e.g., MPDU field 800-3). Figure 8 In the example shown in FIG5 , there is a single padding field 700A before the MPDU field 800-0, a set of ten padding fields 700A between the MPDU fields 800-0 and 800-1 and between the MPDU fields 800-1 and 800-2, six padding fields 700A between the MPDU fields 800-2 and 800-3, and six padding fields 700B after the MPDU field 800-3. This is illustrative, and in general, the frame 500 may include any desired number of padding fields 700A and 700B.

[0094] In some implementations, each padding field 700A may include repeated A-MPDU delimiters 508 ( Figure 5 ) (e.g., the padding field 700A can be a copy of the same MPDU delimiter). The repeated A-MPDU delimiter can be, for example, a zero-length A-MPDU subframe whose end-of-frame (EOF) bit is set to 0. In some implementations, each padding field 700B can include an EOF padding bit (e.g., a zero-length A-MPDU subframe whose EOF bit is set to 1). There can be enough padding fields 700B (e.g., the EOF bits in the frame 500) to meet the minimum EOF padding duration 804 for the frame 500. The padding field 700A can help ensure that the minimum MPDU start interval 802 exists between the beginning of each MPDU field 800 in the frame 500 and the beginning of a subsequent MPDU field 800 in the frame 500. The device 400A can adjust or reconfigure the number of padding fields 700A and / or 700B to allow more or less time for the device 400A to generate the frame 500 and / or for the device 400B to perform an integrity check on the frame 500.

[0095] The minimum MPDU start interval 802 indicates the time during which device 400A can transmit an MPDU field 800, regardless of the size of the MPDU field. Additional padding fields 700A (e.g., A-MPDU subframe header, MPDU delimiter, etc.) can be added to ensure that the next MPDU field 800 begins only after the minimum MPDU start interval 802. If an MPDU transmission takes longer than the minimum MPDU start interval 802, device 400A can forgo including the padding field because padding is not needed. For example, the added time from padding fields 700A and 700B can be in symbols.

[0096] The minimum EOF pad duration 804 is the amount of time that padding is sent at the end of or after the frame 500. The EOF pad duration (e.g., the number of padding fields 700B) may increase the number of symbols that need to be sent at the end of or after the data frame. The receiver (e.g., device 400B) may use this time to perform integrity checks on the data frame. The receiver may also use this time to create an integrity-protected BA frame 502 ( Figure 5 ).

[0097] Figure 9A and Figure 9B The device 400B can be used in Figure 5 Two examples of padding fields included in the BA frame 502 of FIG. Figure 9AAs shown in the example of FIG, device 400B may generate a BA frame 502 that includes a padding field such as padding 900 located between preamble 516 and block ACK 518. In this example, padding 900 may include padding 900 and Figure 8 The padding field 700A may be similar to the padding (e.g., one or more repeated MPDU delimiters), or may include other padding. Figure 9B As shown, padding 900 may be inserted between the block ACK 518 and the MIC 520. If desired, padding similar to padding 900 may also be included within the block ACK 518 (e.g., as an additional per-association identifier (AID) field). If desired, the BA frame 502 may include padding 900 at two or more of these locations. In general, padding 900 may include padding similar to padding 900. Figure 8 The receiver may also include padding similar to the padding field 700A (e.g., repeated MPDU delimiters), one or more AID traffic identifier (TID) information fields not used by any STA 106, or other padding bits or symbols. If desired, the receiver may help configure the device for transmitting the frame 500 ( Figure 8 ) to allow the receiver enough time to calculate and generate the BA frame.

[0098] Device 400B may send a BA frame 502 to a receiver of the BA frame (eg, device 400A). BA frame 502 may have a minimum duration 902. Minimum duration 902 plus minimum EOF fill duration 804 ( Figure 8 ) may signal to the AP a minimum duration for a BA frame that the receiver should consider received. This duration may be exceeded if the BA frame includes a relatively large per-AID field. If the AP triggers an uplink (UL) BA frame by transmitting a corresponding trigger frame, the UL reserved unit duration of the BA frame may be at least the minimum duration 902 plus the minimum EOF fill duration 804 ( Figure 8 For example, the minimum duration 902 may be replaced with the minimum EOF fill time. In this case, all the extra time is allocated to the frame 500. If necessary, additional fill time may be added after the end of the MIC 520 in the BA frame 502 (e.g., as Figure 9B The sender (eg, device 400A) uses this time to verify the integrity of the BA frame 502 and to check whether to continue data transmission.

[0099] Padding 700 may be added to frame 500 and / or padding 900 may be added to BA frame 502 (e.g., before block ACK 518, after block ACK 518, and / or within block ACK 518 as additional per-AID fields) to accommodate integrity protection and integrity check processing delays. When padding 700 is added to the end of frame 500 (e.g., see Figure 7D and Figure 8 ), the padding duration is configured in the association, and the padding is present in all transmitted A-MPDUs. This may require additional setup signaling. Because the padding is always present, this type of padding always involves additional overhead. On the other hand, when padding 900 is added to the BA frame 502, the BA frame transmitter (e.g., device 400B) may add the padding as a per-association identifier (AID) padding field if / when the calculation of the MIC 520 requires additional time. For example, padding 900 may be one or more AID TID information fields that are not used by any STA 106. This implementation does not require any signaling overhead to establish, and the transmitted BA frame can simply apply the padding when needed.

[0100] Consider an example in which device 400A performs a transmit opportunity (TXOP) continuation after receiving a BA frame 502. In these cases, device 400A does not necessarily know whether the real (intended) receiver (e.g., device 400B) has received the frame 500 it transmitted until device 400A has verified the integrity of the corresponding BA frame 502 sent by device 400B. In this case, device 400A can verify the integrity of the BA frame 502 before or after continuing the TXOP by sending additional frames 500 to device 400B (e.g., as shown in FIG. 2 ). Figure 9B As shown, there is padding 900 at the end of the BA frame).

[0101] In an implementation where device 400A begins sending additional frames 500 regardless of whether device 400A has verified the integrity of BA frame 502, device 400A estimates the duration of the next PPDU without ensuring that these frames are received by the intended receiver. Figure 4 If a BA frame 502 is sent by device 400B (device 400B), the next PPDU duration may be incorrectly allocated, resulting in communication errors. By adding padding 900 to BA frame 502, device 400B can allow device 400A more time to verify (check) the integrity of BA frame 502. By verifying the integrity of BA frame 502, device 400A knows that the transmitted frame 500 was received by the true (intended) receiver (device 400B) and the number of MPDUs received by the true receiver. On the other hand, padding 900 increases the transmission overhead of device 400B.

[0102] The header in frame 500 may include a corresponding header (HDR) packet number (PN) (HDR PN), a time synchronization function (TSF) component (e.g., specifying the time when the corresponding preamble starts to be transmitted), and an HDR MIC (e.g., Figure 5 HDR MIC 512). The HDR PN may include a unique counter value that increments by one for each integrity protection header sent by device 400A. Device 400B may use several protection mechanisms to prevent the reception of false data from a MITM (e.g., device 402) and the transmission of a BA frame in response to the reception of false data. For example, device 400B may perform an address and FCS check. If frame 500 is correctly addressed to device 400B and the FCS calculated at device 400B in response to the received frame 500 matches the FCS field of the received frame 500, device 400B may transmit BA frame 502. Additionally or alternatively, device 400B may check the header PN and, if the MPDU is not replayed, may transmit BA frame 502. Additionally or alternatively, device 400B may check the header TSF and HDR PN and, if the TSF is within a predetermined time period (e.g., approximately 256 μs) and the HDR PN increment counter value, together with the TSF (if present), has a value greater than a previously received value of a correctly integrity-protected frame, may transmit BA frame 502. Additionally or alternatively, device 400B may calculate an HDR MIC and, if the calculated HDR MIC matches the header MIC included in frame 500, may transmit BA frame 502. Additionally or alternatively, device 400B may calculate a MIC for the data payload in frame 500 and, if the calculated MIC matches the MIC of the data payload included in frame 500, may transmit BA frame 502. The integrity check at device 400B may be performed before or after device 400B transmits BA frame 502, and may have different implications for how devices 400A and 400B process transmitted and received data.

[0103] Generally speaking, when device 400B transmits BA frame 502 regardless of the MAC header integrity check on frame 500, no additional padding is required for the A-MPDU. Device 400B may transmit the BA frame when MAC headers A1 and A2 match and device 400B has correctly received at least one MPDU (e.g., the FCS matches). On the other hand, when device 400B transmits BA frame 502 only when / when the MAC header integrity is verified, additional padding may be required to accommodate the MAC header integrity check (sometimes referred to herein as a MAC header integrity verification). Device 400B may transmit the BA frame when MAC headers A1 and A2 match and device 400B receives at least one MPDU, successfully verifies the integrity protection of its MAC header, and successfully verifies that it has correctly received the MPDU (e.g., the FCS matches).

[0104] Buffers on device 400A and device 400B (e.g., Figure 4 Buffers 406-412 of the device 400A may be adapted to handle the transmission, reception, and verification of frames 500 and BA frames 502. For example, when device 400A has data to send to device 400B, device 400A may select one or more MPDUs to send to device 400B. Device 400A may aggregate the MPDUs into frame 500 (e.g., in Figure 4 TX buffer 406 and / or temporary buffer 408 of the device 400A. The device 400A may perform integrity protection on the MPDU and / or frame. For example, the device 400A may perform integrity protection on the MAC header 510 of the MPDU field 514 in the frame 500 by generating a corresponding HDR MIC 512 and inserting the HDR MIC 512 into the frame 500. The device 400A may also encrypt the data payload of the MPDU and / or may generate and insert an additional MIC into the data payload of the MPDU.

[0105] The device 400B may receive the frame 500 and may store the frame 500 in the temporary buffer 410. The device 400B may perform an integrity check on the MPDU stored in the temporary buffer 410. For example, the device 400B may only acknowledge the MPDU (e.g., in the corresponding BA frame 502) when the received MPDU has all of the following: (a) matching MAC headers A1 and A2, (b) MAC header numbers (MHN) in increasing order, and (c) a payload with a correct FCS. The device 400B may update the reorder buffer 412 ( Figure 4) to include only valid (e.g., integrity-checked) MPDUs or frames 500 from the temporary buffer 410. For example, the device 400B may verify the integrity of the MPDUs in the temporary buffer 410 by performing one or more of the following: (i) verifying the integrity of the MAC header of each MPDU in the temporary buffer 410 (e.g., by calculating an HDR MIC from the MAC header and comparing it with the corresponding HDR MIC 512 received in the frame 500 and stored in the temporary buffer), (ii) decrypting the data payload of each MPDU and performing an integrity check on the decrypted data payload, and (iii) checking whether the reorder buffer 412 already contains the PN of the corresponding frame 500. The device 400A may update its TX buffer 406 based on the integrity-checked BA frame 502 received from the device 400B. Figure 4 Device 400A may receive BA frame 502, for example, from device 400B, and may store the BA frame in temporary buffer 408 ( Figure 4 ). Device 400A may then verify the integrity of the BA frame in temporary buffer 408 (e.g., may check whether the bitmap of the BA frame matches the MPDU currently being transmitted in temporary buffer 408). If both conditions are met, device 400A may update its TX buffer 406 based on the now verified (integrity-checked) BA frame 502.

[0106] Figures 10 to 12 is a flow chart of illustrative operations that may be performed by device 400B to perform an integrity check on a frame 500 sent by device 400A before or after device 400B sends a corresponding BA frame 502 to device 400A. Figure 6 Operations 604 and 606 are performed simultaneously Figures 10 to 12 operation.

[0107] Figure 10 is a frame 500 in which the device 400B checks the MAC header MIC (e.g., Figure 5 Flowchart of operations that can be performed by device 400B in a specific implementation of HDR BA 512) and corresponding FCS.

[0108] At operation 1000, device 400B may detect (eg, may receive and begin attempting to decode / demodulate) a frame 500 sent by device 400A. Frame 500 includes at least one MPDU field 514 ( Figure 5 ). A given MPDU field 514 from the frame 500 may be performed Figure 10 In the case where the frame 500 includes multiple MPDU fields 514 (e.g., for example, Figure 8The MPDU field 800 in a single PPDU as shown may be repeated for each MPDU in the received frame. Figure 10 The device 400B can be in the temporary buffer 410 ( Figure 4 ) temporarily stores the MPDU for further processing.

[0109] At operation 1002, device 400B may check, verify, check, identify, and / or otherwise determine whether device 400B is the intended recipient of the MPDU field 514 from frame 500. This may include, for example, determining whether the AID and destination address of the MPDU stored on a temporary buffer (e.g., as identified by one or more header fields of the MPDU) are associated with device 400B or another recipient device. If / when device 400B is not the intended recipient of the MPDU (e.g., when the AID and / or address do not match), processing may proceed to operation 1006 via path 1004.

[0110] At operation 1006, device 400B may discard (delete) the MPDU from the temporary buffer, and processing may loop back from operation 1006 to operation 1002 to process additional MPDUs of the detected frame 500. Alternatively, processing may loop back from operation 1006 to operation 1000 to process additional frames 500 received from device 400A. If / when device 400B is the intended recipient of the MPDU (e.g., when the AID and address match), processing may proceed from operation 1002 to operation 1010 via path 1008.

[0111] At operation 1010 (e.g., in response to device 400B being the intended recipient of the MPDU), device 400B may check, verify, and / or check the MAC header number (MHN) and TSF of the MPDU stored at the temporary buffer. The MHN and TSF may be, for example, obtained from the MAC header 510 ( Figure 5) to be identified or included therein. Device 400B may check the MHN and TSF by, for example, determining whether the MHN is a duplicate MHN and whether the TSF falls within a predetermined range. If / when the MHN is not a duplicate MHN, device 400B may determine or identify the MHN as valid, and if / when the TSF is within a predetermined time range, may determine the TSF is valid. On the other hand, if / when the MHN is a duplicate MHN, device 400B may determine or identify the MHN as invalid, and if / when the TSF is outside the predetermined time range, may determine the TSF is invalid. If / when one or both of the MHN and TSF are invalid, processing proceeds to operation 1006 via path 1020, and the MPDU may be discarded. If / when the MHN and TSF are valid, processing proceeds from operation 1010 to operation 1016 via path 1014.

[0112] At operation 1016 (e.g., in response to the device, the MPDU having a valid MHN and TSF), device 400B checks, verifies, and / or checks the payload FCS of the MPDU stored in the temporary buffer. This may include calculating an FCS based on the payload of the MPDU and comparing the calculated FCS to the FCS field of the MPDU. When the calculated FCS matches the FCS identified by the FCS field of the MPDU, device 400B may determine or identify the FCS as valid. When the calculated FCS does not match the FCS identified by the FCS field of the MPDU, device 400B may determine or identify the FCS as invalid. If / when the FCS is invalid, processing proceeds to operation 1006 via path 1018, and the MPDU may be discarded. If / when the FCS is valid, processing proceeds from operation 1016 to operation 1022 via path 1020.

[0113] At operation 1022 (eg, in response to the MPDU having a valid FCS), the device 400B may prepare (generate) a block ACK 518 ( Figure 5 ), the block ACK including and / or otherwise identifying the corresponding MPDU received in frame 500 (e.g., the MPDU examined at operations 1008-1016). Device 400B may send the BA frame 502 to device 400A.

[0114] At operation 1024 (eg, after transmission of the BA frame 502), the device 400B may detect the MAC header 510 ( Figure 5 This may include checking, verifying and / or checking the HDR MIC 512 of the MPDU and checking, verifying and / or checking the MIC field of the data payload of the MPDU.

[0115] The device 400B may calculate a header MIC based on the MAC header 510 of the MPDU (e.g., by applying the same hash function or cryptographic function to the MAC header 510 as applied by the device 400A when generating the HDR MIC 512) and verify the HDR MIC 512 by comparing the calculated header MIC with the HDR MIC 512 of the MPDU included in the received frame 500 (e.g., the device 400B may determine that the HDR 512 is valid when the calculated header MIC matches the HDR MIC 512 included with the MPDU, and may determine that the HDR MIC 512 is invalid when the calculated header MIC does not match the HDR MIC 512 included with the MPDU).

[0116] Device 400B may verify the MIC field of the data payload by calculating a MIC based on the data payload of the MPDU (e.g., by applying the same hash function or cryptographic function to the data payload as applied by device 400A when generating the MPDU) and comparing the calculated MIC with the MIC for the data payload included with the MPDU in the detected frame 500 (e.g., device 400B may determine that the MIC for the data payload is valid when the calculated MIC matches the MIC for the data payload included with the MPDU, and may determine that the MIC for the data payload is invalid when the calculated MIC does not match the MIC for the data payload included with the MPDU).

[0117] If / when device 400B determines that HDR MIC 512 is invalid, the MIC for the data payload is invalid, or device 400B cannot recover or decrypt the data payload, processing may proceed to operation 1006 via path 1026. If / when device 400B determines that HDR MIC 512 is valid, the MIC for the data payload is valid, and device 400B is able to recover or decrypt the data payload, processing proceeds to operation 1030 via path 1028.

[0118] At operation 1030, the device 400B may reorder the MPDUs from the detected frame 500. This may include transferring the MPDUs from the temporary buffer 410 to the reorder buffer 412 ( Figure 4 The reordering buffer 412 may reorder the stored MPDUs (eg, in the correct time order identified by the SNs of the MPDUs transferred from the temporary buffer 410 to the reordering buffer 412).

[0119] At operation 1032, the reorder buffer 412 ( Figure 4 ) may deliver the MPDUs stored on the reorder buffer 412 to one or more software applications running on the device 400B for further processing (e.g., the device 400B may pass the stored MPDUs up the protocol stack to an application processor on the device 400B).

[0120] wherein the device 400B sends the BA frame 502 before checking the MIC and HDR MIC 512 of the data payload for the MAC header 510 in the MPDU stored at the temporary buffer 410. Figure 10 The example of is illustrative and non-limiting. If desired, the device 400B may check the HDR MIC 512 for the MAC header 510 of the MPDU before sending the BA frame 502.

[0121] Figure 11 is a flow diagram of illustrative operations that may be performed by device 400B in an implementation in which device 400B performs an integrity check on the MAC header 510 of the MPDU before sending the BA frame 502. Figure 11 Operations 1100-1116 are respectively related to Figure 10 Therefore, for the sake of brevity, the operations 1000-1016 are omitted. Figure 11 Description of operations 1100-1116.

[0122] At operation 1122 (e.g., before the BA frame 502 is transmitted and the responding device 400B determines that the FCS payload is valid), the device 400B may verify the HDR BA 512 by calculating a header MIC based on the MAC header 510 of the MPDU stored on the temporary buffer and by comparing the calculated header MIC with the HDR MIC 512 included with the MPDU in the detected frame 500. The device 400B may determine that the HDR MIC 512 is valid when the calculated header MIC matches the HDR MIC 512 included with the MPDU, and may determine that the HDR MIC 512 is invalid when the calculated header MIC does not match the HDR MIC 512 included with the MPDU.

[0123] If / when device 400B determines that HDR MIC 512 is invalid, processing may proceed to operation 1106 via path 1119. If / when device 400B determines that HDR MIC 512 is valid, processing may proceed to operation 1124 via path 1123. At operation 1124 (e.g., in response to the MPDU having a valid HDR MIC 512), device 400B may prepare (generate) a block ACK 518 ( Figure 5 ), the block ACK including and / or otherwise identifying the corresponding MPDU received in frame 500 (e.g., the MPDU examined at operations 1102-1122). Device 400B may send the BA frame 502 to device 400A.

[0124] At operation 1126 (e.g., after transmission of the BA frame), the device 400B may verify the MIC field of the data payload of the MPDU by calculating a MIC based on the data payload of the MPDU and comparing the calculated MIC with the MIC for the data payload included with the MPDU in the detected frame 500. The device 400B may determine that the MIC for the data payload is valid when the calculated MIC matches the MIC for the data payload included with the MPDU, and may determine that the MIC for the data payload is invalid when the calculated MIC does not match the MIC for the data payload included with the MPDU.

[0125] If / when device 400B determines that the MIC for the data payload is invalid, processing may proceed to operation 1106 via path 1128. If / when device 400B determines that the MIC for the data payload is valid, device 400B may recover or decrypt the data payload, and processing may proceed to operation 1130 via path 1129. Figure 11 Operations 1130 and 1132 are respectively related to Figure 10 Operations 1030 and 1032 are the same. Therefore, for the sake of brevity, descriptions of operations 1130 and 1132 are omitted.

[0126] If desired, the device 400B may check both the HDR MIC 512 for the MAC header 510 of the MPDU and the MIC for the data payload of the MPDU before sending the BA frame 502 . Figure 12 is a flow diagram of illustrative operations that may be performed by device 400B in an implementation in which device 400B performs an integrity check on both the MAC header 510 and the data payload of the MPDU before sending the BA frame 502. Figure 12 Operations 1200-1216 are respectively related to Figure 10 Therefore, for the sake of brevity, the operations 1000-1016 are omitted. Figure 12 Description of operations 1200-1216.

[0127] At operation 1222 (e.g., before the BA frame 502 is transmitted and the responding device 400B determines that the FCS payload is valid), the device 400B may verify the HDR BA 512 by calculating a header MIC based on the MAC header 510 of the MPDU stored on the temporary buffer and by comparing the calculated header MIC with the HDR MIC 512 included with the MPDU in the detected frame 500. The device 400B may determine that the HDR MIC 512 is valid when the calculated header MIC matches the HDR MIC 512 included with the MPDU, and may determine that the HDR MIC 512 is invalid when the calculated header MIC does not match the HDR MIC 512 included with the MPDU.

[0128] If / when the device 400B determines that the HDR MIC 512 is invalid, processing may proceed to operation 1206 via path 1219. If / when the device 400B determines that the HDR MIC 512 is valid, processing may proceed to operation 1224 via path 1223. At operation 1224 (e.g., in response to the MPDU having a valid HDR MIC 512), the device 400B may verify the MIC field of the data payload of the MPDU by calculating a MIC based on the data payload of the MPDU and by comparing the calculated MIC with the MIC for the data payload included with the MPDU in the detected frame 500. The device 400B may determine that the MIC for the data payload is valid when the calculated MIC matches the MIC for the data payload included with the MPDU, and may determine that the MIC for the data payload is invalid when the calculated MIC does not match the MIC for the data payload included with the MPDU. If desired, operation 1222 may be performed concurrently with operation 1224 (eg, in a single combined integrity check step with operation 1224 ) or before operation 1224 .

[0129] If / when device 400B determines that the MIC for the data payload is invalid, processing may proceed to operation 1206 via path 1226. If / when device 400B determines that the MIC for the data payload is valid, device 400B may recover or decrypt the data payload, and processing may proceed to operation 1230 via path 1228. At operation 1230 (e.g., in response to the MPDU having both a valid HDR MIC 512 and a valid data payload MIC), device 400B may prepare (generate) a block ACK 518 ( Figure 5), the block ACK including and / or otherwise identifying the corresponding MPDU received in frame 500 (e.g., the MPDU examined at operations 1202-1224). Device 400B may send the BA frame 502 to device 400A. Figure 12 Operations 1232 and 1234 are respectively Figure 10 Operations 1030 and 1032 are the same. Therefore, for the sake of brevity, descriptions of operations 1232 and 1234 are omitted.

[0130] Device 400A is generally unaware of when device 400B discards a frame or MPDU after transmission of BA frame 502 (e.g., as Figure 11 Path 1128 or Figure 10 If desired, portions of the MAC header (e.g., the Power Management (PM) field, the End of Service Period (EOSP) field, the High Throughput (HT) Control field, and / or the Mobility Domain (MD) bit) may be included in the MAC header. Figures 10 to 12 integrity protected and integrity checked during one or more checks and / or in separate operations.

[0131] Figures 10 to 12The examples are illustrative and non-limiting. In general, device 400B may implement other integrity checking procedures. Under any of these schemes, when the FCS, header PN, TSF, MAC header, and data payload have been verified for a given MPDU, device 400B may pass the MAC header and data payload of the MPDU to its reordering buffer and may send the BA frame 502 to device 400A with or without integrity protection and / or integrity checking of the BA frame by device 400A. When the FCS, header PN, TSF, and MAC header are valid but the payload MIC is invalid, neither the payload nor the MAC header is passed to the reordering buffer, but device 400B may still send the BA frame 502 to device 400A with or without integrity protection and / or integrity checking of the BA frame by device 400A. Alternatively, in these cases, when the HDR MIC of the MAC header is valid (e.g., when the header MIC is checked before the payload MIC is checked), device 400B may pass the MAC header to the reordering buffer. When the FCS, header PN, and TSF are valid but the MAC header is invalid, the payload and MAC header are not passed to the reordering buffer regardless of whether the data payload MIC is valid. Device 400B may still send BA frame 502 to device 400A without an integrity check, but without performing an integrity check. When the FCS, header PN, or TSF is invalid, regardless of the MAC header integrity or the data payload integrity, the payload and MAC header are not passed to the reordering buffer, and device 400B does not send BA frame 502 to device 400A.

[0132] Consider an example in which device 400B sends an integrity-protected BA frame 502 to device 400A in response to a frame 500 having at least a first MPDU with SN=1, a second MPDU with SN=2, and a power management field of zero (e.g., PowerManagement=0). Frame 500 may request a corresponding BA frame 502 (e.g., the BA frame 502 sent by device 400B is the requested BA frame). In some examples, the BA frame 502 may be received by device 402 ( Figure 4) (e.g., a MITM attacker) rather than being received at device 400A. In these cases, after a predetermined period of time has passed without receiving a BA frame corresponding to frame 500 at device 400A, device 400A may resend frame 500, but with the power management field being one (e.g., PowerManagement=1). Device 402 may then intercept the resent frame. In response to intercepting the resent frame, device 402 may transmit (replay) the BA frame 502 received from device 400B to device 400A. The replayed BA frame represents an unsecure MITM transmission and interference in the communication between devices 400A and 400B. When device 400A confirms that the received BA frame 502 is valid (e.g., when Figure 6 ), the device 400A may perform an integrity check on the received BA frame 502 and may pass the received BA frame out of its temporary buffer.

[0133] In these situations, device 400A can utilize several mechanisms to avoid being tricked into believing that the BA frame replayed by device 402 was actually sent by device 400B. First, device 400A can check whether the address and FCS of the received BA frame match the BA frame requested by frame 500. Second, device 400A can check the PN of the received BA frame to ensure that the received BA frame is not a replayed BA frame from a MITM device. Third, BA frame 502 can include information identifying the TSF of the corresponding request MPDU sent by device 400A. Device 400A can perform a TSF check on the received BA frame. This can involve verifying that the received BA frame is only sent within a predetermined time period (e.g., 256 μs) of the TSF of the corresponding request frame 500. If the TSF of the received BA frame is outside (after) the predetermined time period, device 400A can discard the received BA frame. For another example, the device 400A may verify the received BA frame only if the hash / TSF of the request frame matches the received BA frame (e.g., with the TSF / ID of the request frame appended to avoid sending a BA frame in response to a fake frame). Fourth, the device 400A may verify the MIC 520 of the received BA frame ( Figure 5 ) (e.g., assuming that device 402 cannot modify the contents of the BA). If the received BA frame has an invalid MIC 520, device 400A may discard the BA frame. Device 400A may perform one or more of these integrity checks on the received BA frame 502 before or after starting to send its next frame 500 (e.g., Figure 6 610).

[0134] The data frame integrity check operation performed by device 400B (e.g., Figures 10 and 11 ) can be controlled by the wireless communication link 404 ( Figure 4 ) is specified by the communication protocol of the device 400A. The BA frame integrity check operation performed by the device 400A may also be specified by the communication protocol (e.g., the IEEE 802.11 protocol). The device 400A may perform an integrity check on the received BA frame before or after the TXOP continues (e.g., subsequent PPDU transmission). The communication protocol may also define an integrity check mode for the BA frame 502. This may include STA signaling for uplink (UL) transmissions, and AP signaling for downlink (DL) transmissions: (1) Minimum MPDU start time (e.g., Figure 8 The shortest MPDU start interval 802), (2) the minimum EOF padding value (e.g., Figure 8 The shortest EOF filling duration 804), (3) the shortest BA duration (e.g., Figure 9A 902), and / or (4) minimum BA filling (e.g., Figure 9A and Figure 9B Information identifying one or more of these values ​​may be communicated (signaled) between devices 400A and 400B (e.g., in a MAC header 510 or another field of frame 500 and / or in a header, preamble, or other field of a BA frame 502). This signaling may be at the link level, the multi-link device (MLD) level, or the multi-layer multi-domain (MLMD) level.

[0135] Figure 13 13 is a diagram illustrating an exemplary signaling scheme between an AP and a STA when the AP is part of an MLMD AP 1300 and when the STA is part of an MLMD STA (physical device) 1302. Figure 13 As shown, AP (e.g., Figure 1 The AP 102 or 104) can communicate with the corresponding STA (e.g., Figure 1 Multiple APs may be logically grouped together to form corresponding MLD-level (physical) devices. MLMD AP 1300 is a virtual device and may include multiple MLD-level devices. The AP of a given MLD-level device communicates with a group of corresponding STAs that are logically grouped together at the MLD level. MLMD STA 1302 may include multiple groups of STAs that are grouped together at the MLD level. A given AP may form Figure 4 One of the devices 400A or 400B communicates with a STA forming the other of the devices 400A or 400B.

[0136] An MLMD STA can be implemented with different radios capable of operating at different frequencies. For example, one radio may operate in the 2.4 GHz band, a second radio in the 5 GHz band, and a third in the 6 GHz band. These radios may have different capabilities for four parameters to configure the additional time required to calculate or verify the integrity of data frames or BA frames. MLMD level configuration can assign band-specific values ​​to the four signaled values. In this configuration, each link in a specific band inherits the four signaled band-specific values.

[0137] As an example, each AP or STA (UL or DL) can configure different values ​​for four signaled values ​​(minimum MPDU start time, minimum EOF padding value, minimum BA duration, and minimum BA padding). These values ​​can be signaled in a linked manner using a Multilink (ML) element or an ML Link Reconfiguration Add or Modify frame. As another example, an AP and a group of STAs grouped together at the MLD level (UL and DL) can configure four signaled values. In this example, these values ​​can remain the same at the MLD AP level. These values ​​can be (re)signaled using an ML element or in an ML Link Reconfiguration Add or Modify frame. As another example, an AP and an MLMD STA 1302 can configure four signaled values. In this example, the values ​​remain the same within the MLMD AP 1300. These values ​​can be (re)signaled using an ML element. A STA or AP can optionally perform header and data payload MIC integrity checks before BA frame transmission, even if this is not required (e.g., a protocol-defined integrity check mode may be the minimum requirement).

[0138] Wherein the HDR MIC 512 is located between the MAC header 510 and the payload of the frame 500 (eg, the MPDU field 514). Figure 5 The examples are intended to be illustrative rather than limiting. Figure 14 HDR MIC 512 is shown in frame 500 ( Figure 5 ) are two examples of other possible locations. Figure 14 Frame 500A shows an example in which the HDR MIC 512 is placed between different fields of the MAC header 510 (eg, between the header (HDR) PN field and the Galois Counter Mode Protection (GCMP) HDR field). Figure 14Frame 500B shows another example in which the HDR MIC 512 is placed after the data payload 1402 in the frame 500 (e.g., after the payload MIC for the data payload 1402). For example, the HDR MIC 512 can be an eight-octet field having a total of 64 bits.

[0139] A frame 500 (eg, frame 500A and frame 500B) may include a data payload MIC 1404 appended to the end of its data payload 1402 (eg, where the payload and payload MIC form a Figure 5 14). Payload MIC 1404 may be calculated based on data payload 1402. Alternatively, HDR MIC 512 may be calculated based on fields of MAC header 510 (e.g., fields of MAC header 510 that do not include HDR MIC 512). Portion 1400 of frames 500A and 500B may be integrity-protected by HDR MIC 512. Data payload 1402 may be integrity-protected by payload MIC 1404. The remainder of frames 500A and 500B may not have integrity protection.

[0140] Device 400A may separately and independently generate / calculate the HDR MIC and the payload MIC while generating frame 500. Device 400B may separately verify the HDR MIC and the payload MIC. Device 400B may perform an integrity check on header MIC 512 (e.g., Figure 10 Operation 1024, Figure 11 Operation 1122 or Figure 12 1222 of the example) and performs an integrity check on the payload MIC 1404 (e.g., at Figure 10 Operation 1024, Figure 11 Operation 1126 or Figure 12 1224).

[0141] If desired, both the payload MIC 1404 (eg, integrity protection for the data payload 1402) and the HDRMIC 512 may be combined into a single combined MIC field. Figure 15 14 shows an example of how the frame 500 may include a single MIC that combines the integrity protection of the HDR MIC 512 with the integrity protection of the payload MIC 1404. Figure 15As shown, frame 500 includes a combined MIC field, such as combined MIC 1500. Device 400A may generate combined MIC 1500 based on MAC header 510 and data payload 1402. Device 400A may generate HDR MIC 512 (e.g., based on MAC header 510) (e.g., by inputting MAC header 510 into a hash function) Figure 14 ), a payload MIC 1404 may be generated based on the data payload 1402 (e.g., by inputting the data payload 1402 into a hash function) and by combining the HDR MIC 512 with the payload MIC 1404 (e.g., using an XOR function that outputs the value of the HDR MIC 512 as an exclusive-OR (XOR) with the payload MIC 1404). Figure 14 ). Thus, the combined MIC 1500 may also sometimes be referred to herein as an XOR MIC 1500 or an XOR 1500 of the payload MIC 1404 and the HDR MIC 512. In this implementation, the device 400B may verify the integrity of both the data payload 1402 and the MAC header 510 simultaneously (e.g., in Figure 10 After the BA frame shown is sent or as Figure 12 15. Before the BA frame is transmitted as shown). Retransmission of a frame may result in a different XOR value in XOR MIC 1500 because the MAC header is updated upon retransmission.

[0142] In some implementations, the AP may send a multi-STA BA frame (e.g., in the STA 106) carrying a BA bitmap to a single STA 106 (pair protection) or to multiple STAs 106 (broadcast protection). Figure 6 (e.g., processing operation 608 of FIG. 2 ) A multi-STA BA frame may include one or more AID fields. The AID field may be used to identify the STA that signals which BA bitmap on the BA frame. Figure 16 An example of an illustrative multi-STA BA frame 1600 is shown.

[0143] like Figure 16 As shown, the multi-STA BA frame 1600 may include a frame control field, a duration / ID field, an address field, a BA control field 1610, a per-AID field list 1602, and an FCS field. The per-AID field list 1602 may be formed, for example, Figure 5The block ACK 518 may include an AID TID information field, a block ACK starting sequence control field 1606, and a block ACK bitmap 1608. The AID TID information field 1604 may include an AID11 field associated with the block ACK bitmap 1608, an ACK type field associated with the block ACK bitmap 1608, and a TID field associated with the block ACK bitmap 1608. The block ACK starting sequence control field 1606 may include a fragment number field and a starting SN field.

[0144] The fragment number field may specify the size of the bitmap (eg, 64 bits, 32 bits, etc.) The AID11 field may be used to identify various information such as HDR PN, request frame TSF, and HDR MIC 512 requesting the frame 500 of the multi-STA BA frame 1600 . Figure 17 Table 1700 is shown outlining different exemplary AID11 fields that may be included in the AID TID information field 1604 of a multi-STA BA frame 1600. The first column of table 1700 lists the different AID11 fields, the second column lists the contents of the corresponding AID11 fields, and the third column lists the corresponding AID11 fields and the meaning of their contents. If desired, the BA control field 1610 (sometimes also referred to as the BAR control field 1610, e.g., a two-bit field) may be followed by a variable-length BAR information field. If desired, the variable-length BAR information field may be followed by a control MIC field (e.g., similar to the header MIC described herein, which may be included in, represented by, or identified by table 1602, or its alternative table 1601), followed by a variable-length padding field, followed by a four-bit FCS field. In this implementation, frame 1600 need not be a multi-STA BA frame (e.g., frame 1600 may be any desired BAR frame in BlockAckReq format). The BA control field 1610 (sometimes also referred to herein as the BAR control field 1610) may include, for example, a one-bit reserved field, followed by a four-bit BAR type field, followed by a one-bit protected control field, followed by a one-bit key ID field, followed by a five-bit reserved field, followed by a four-bit TID_INFO field. For another example, the BA control field 1610 may include a two-bit reserved field after the key ID field, followed by a one-bit no memory retention field, followed by a one-bit memory configuration tag field, followed by a one-bit management Ack field, followed by a four-bit TID_INFO field.

[0145] exist Figure 17 In the example of , the first AID11 field W is defined as including padding (eg, Figure 9A and Figure 9B This may allow device 400B additional time to calculate MIC 520 ( Figure 5 ). This field may be protected by a MIC (e.g., provided as an input to a hash function when generating the MIC 520). A second AID11 field (e.g., AID11 field "10") may be defined to include a BA bitmap for a first STA 106 (STA1) operating under a first version of the communication protocol (e.g., the IEEE 802.11bn protocol). A third AID11 field (e.g., AID11 field "11") may be defined to include a BA bitmap for a second STA 106 (STA2) operating under the first version of the communication protocol.

[0146] The fourth AID11 field X may be defined to include or identify the HDR PN of the corresponding request frame 500 and / or include or identify a hash (e.g., a hash identifier) ​​and / or TSF (e.g., including two octets for the HDR PN and six octets for the TSF of the request frame) of the corresponding request frame 500. The fifth AID11 field Y may be defined to include or identify the MIC protection and / or checksum of the corresponding frame 500 up to that point (e.g., the MIC BA for STAs operating under the first version of the communication protocol, such as Figure 5 MIC 520).

[0147] The sixth AID11 field (e.g., AID11 field "12") may be defined to include a BA bitmap for a third STA 106 (STA3) operating under a second version of the communication protocol that is older than the first version of the communication protocol (e.g., a legacy version of the communication protocol). The seventh AID11 field (e.g., AID11 field "13") may be defined to include a BA bitmap for a fourth STA 106 (STA4) operating under the second version of the communication protocol. These fields may include a BA bitmap for a legacy STA without MIC protection. The eighth AID11 field Z may be defined to include padding (e.g., Figure 9A and Figure 9B Fill 900 in). Figure 17 The examples are illustrative and non-limiting, and in general, any desired AID11 field may be designated for any desired purpose.

[0148] Figure 18Two additional examples of frames 500 that may be sent by device 400A as request frames for a BA frame 502 sent by device 400B are shown. Frame 500C is an example in which frame 500 is a block acknowledgement request (BAR) frame 500C. As shown in BAR frame 500C, information identifying the TSF of frame 500C may be inserted into HDR PN field 1800 within MAC header 510 (e.g., before a payload, which may include a variable-length control payload). The same TSF may be present in all HDR PN values. Frame 500D is another example in which frame 500 is a data or management frame. As shown in data or management frame 500D, information identifying the TSF of frame 500D may be inserted into HDR PN field 1800 within MAC header 510. This may be followed by HDR MIC field 512, data payload 1402, payload MIC 1404, and so on.

[0149] Information identifying the TSF of frame 500C may be inserted into the HDR PN field 1700 in any desired manner. As an example, the HDR PN field 1800 may include a first value (e.g., one or more HDR_Number bits) followed by a second value (e.g., one or more bits) identifying the TSF. For example, the first value may be identified using the first octet and a portion of the second octet (e.g., the most significant bits of the second octet). The second value identifying the TSF may be stored in the remainder of the second octet (e.g., the least significant bits). For example, the first value may be increased by one (e.g., up to 2 bits) for each integrity protection. 10 = PN of 1,024 MPDUs, corresponding to the maximum BA window size). TSF can be set to the TSF corresponding to the PPDU transmission time. TSF can range from, for example, 2 4 us=16us minimum TSF (time) value to such as ~2 10 = Maximum TSFT (time) value of 1,008 us. For example, a receiver may discard received frames that have a TSF difference greater than + / - 256 us compared to its internal TSF value. In a Nonce implementation, the HDR PN field 1800 may be padded with four octets of the TSF so that the Nonce is 6 octets if needed. As another example, the HDR PN field 1800 may include a universal number. In the Nonce, the HDR PN field 1800 is padded with two octets or all ones so that the length of the Nonce is six octets. This alternative allows for replay of frames and does not require TSF synchronization.

[0150] Additionally or alternatively, the frame 500 may be identified as a request frame by computing a hash on the request frame. In these implementations, the device 400A may use frame control, duration, retry, preamble, and address (e.g., constant values ​​that are not dependent on receive operation) to identify the frame 500 as a request frame. This typically does not require a TSF-based random number, but may require the collection of a large amount of data. Alternatively, the device 400A may use frame control, duration, retry, preamble, address, and minimum received sequence number (SN) and HDR PN value techniques to identify the frame 500 as a request frame. This information is based on the BA frame content and may increase processing time and complexity.

[0151] Consider a scenario where the AP and STA have established a target wake time (TWT) service period (SP) and where an attacker (e.g. Figure 4 In this example, device 402 receives a frame sent by the AP but interferes with the STA, preventing it from receiving frames. In the next TWT SP, the attacker can reply with a frame that prematurely terminates the TWT SP. The STA may be confused and not receive any frames in the TWT SP. The attacker can prevent the buffer status information from being sent and resend the old buffer status information at a later time. This may result in incorrect allocation to the STA. This attack scenario leads to two new protections for sending frames.

[0152] First, MIC protection of the MPDU header, MPDU data payload, and BA frame can be used to prevent modification and false frames. MIC protection generally provides poor protection against replay of unreceived frames. If MIC protection is performed before the BA frame is sent, the BA protection can also increase latency. Second, TSF can be used to prevent replay of old data and BA frames. Replay protection may be irrelevant for MAC header information because the header information may change over time. However, TSF-based protection can prevent attackers from replaying MPDUs. The BA frame may include replay protection that ensures that the BA frame 502 is sent as a response to the corresponding request frame 500. BA frame replay protection is particularly relevant when the data receiver performs an integrity check after the BA frame is sent.

[0153] Figure 19 19 shows an example in which the MLD transmitter 1900 transmits the frame 500 to the MLD receiver 1902, and the MLD receiver 1902 transmits the BA frame 502 to the MLD transmitter 1900. The MLD transmitter 1900 may include a group of STAs including STA A1, STA A2, and STA A3 (e.g., AP STAs or non-AP STAs). The MLD receiver 1902 may include a group of STAs including STA B1, STA B2, and STA B3 (e.g., non-AP STAs or AP STAs).

[0154] like Figure 19 As shown, the MLD transmitter 1900 controls the sequence number of the MPDUs sent to the MLD receiver 1902 (e.g., the MLD transmitter 1900 can control SN assignment, PN assignment, single TX window assignment, and ML TX / Re-TX management). The transmitter 1900 has a transmit buffer 1904 that stores all frames in transmission (see, e.g., Figure 4 The frames currently being transmitted are stored in a STA-specific buffer (see, e.g., Figure 4 The MLD receiver 1902 receives the frame 500, temporarily stores information from the frame in scoreboards for different STAs, and then provides the information from the scoreboards to a single reordering buffer that performs duplicate detection, PN checking, etc.

[0155] MLD receiver 1902 can acknowledge all received frames 500 but has no control over MPDUs being transmitted. If stateless BA is assumed, for each MPDU acknowledged in a BA frame, the BA bitmap can signal that the MPDU was received (e.g., using a value of "1"), or that the MPDU was not received or is unknown to the receiver (e.g., using a value of "0"). When BA frames are integrity-protected, MLD transmitter 1900 is required to perform an integrity check on the BA frame before updating its transmit buffer. This eliminates attacks using fake BA frames.

[0156] Consider another example in which device 400B checks both the HDR MIC and the payload MIC of the received frame 500 after sending the BA frame 502. If not careful, this can create a BA desynchronization problem. In this example, device 400B may end up discarding the received frame after sending the corresponding BA frame 502. This may create a hole in the reordering buffer on device 400B. The data is not forwarded to its corresponding application until the hole is filled or the BA window moves forward. However, the BA frame signals to device 400A that the transmission of frame 500 is acceptable to device 400B. Device 400A can then erase the frame from its transmit buffer and be unaware that device 400B is waiting for the frame to be retransmitted.

[0157] In a first example, this BA desynchronization issue can be addressed using silent reordering buffer updates at device 400B. In this example, device 400B may detect that the payload MIC or header MIC of the received frame 500 fails for the MPDU in the received frame after sending the corresponding BA frame. However, device 400B may include internal logic that checks when to forward the MPDU to its reordering buffer. Device 400B may, for example, check whether device 400A will have enough time to resend the MPDU. For example, device 400B may check whether device 400A has processed the sent SN value and whether it has transmitted a larger SN than the one already received. If this internal condition is met, device 400B may silently forward the MPDU to its reordering buffer. This may result in the loss of the MPDU with invalid integrity after sending the BA frame.

[0158] exist Figure 20 An example of this type of solution is shown in the timing diagram of Figure 20 In the example shown in FIG4 , device 400A transmits MPDUs with SNs = 11 and 12 at time T1. Device 400B may store the previously received and integrity-checked MPDU with SN = 13 in its reordering buffer, but has not yet performed an integrity check on the received MPDUs with SNs = 11 and 12, and thus has not yet been passed to the reordering buffer. Device 400B transmits a BA frame 502 acknowledging the MPDUs with SNs = 11 and 12 at time T2, even though the MPDUs with SNs = 11 and 12 have not yet been integrity-checked.

[0159] At time T3, device 400B has completed the calculation that the received MPDUs with SN = 11 and 12 have failed the integrity check. Device 400B may then discard the invalid MPDUs with SN = 11 and 12. However, because device 400B has already sent BA frames for the MPDUs with SN = 11 and 12, device 400A mistakenly believes that device 400B has received the MPDUs with SN = 11 and 12, causing device 400A to delete the MPDUs with SN = 11 and 12 from its transmit buffer.

[0160] Device 400A may then send the next MPDU with SN=14 to device 400B. Device 400B receives the MPDU with SN=14, sends a corresponding BA frame for the MPDU with SN=14 to device 400A, and then determines at time T4 that the MPDU with SN=14 has passed the integrity check. Upon passing the integrity check, device 400B places the MPDU with SN=14 into the reordering buffer (e.g., in the correct sequential order after the MPDU with SN=13). Internal logic on device 400B may silently forward the MPDU with SN=14 to the reordering buffer while ignoring the discarded MPDUs with SN=11 and 12, thereby causing the loss of these MPDUs but resynchronizing device 400B to device 400A (e.g., resolving the BA desynchronization issue).

[0161] For example, Figure 21 As shown in the timing diagram of , the delay to the send buffer can be used to solve the BA out-of-sync problem. Figure 21 As shown, instead of waiting for device 400A to send the next MPDU in the sequence after the MPDUs with SN=11 and 12 fail the MIC check at time T3, device 400B may instead send an integrity-protected BAR frame to device 400A identifying the discarded MPDUs with SN=11 and 12. This signaling of discarded MPDUs or frames is also referred to as reordering buffer status signaling. The BAR frame may signal or identify a hole in the reordering buffer on device 400B (e.g., caused by a MIC check failure or a hole that results in a delay in forwarding low-latency frames to the corresponding application).

[0162] At time TB, device 400A may send a BA frame in response to the BAR frame received from device 400B. The transmitter may apply a transmit buffer update delay (e.g., "TransmissionBufferUpdateDelay"). This delay may allow device 400A sufficient time to resend the MPDUs with SNs = 11 and 12. Device 400B may send a BA frame in response to the retransmission of the MPDUs with SNs = 11 and 12, and may then determine that the retransmitted MPDUs have valid integrity. Device 400A may then send the next MPDU with SN = 14 to device 400B.

[0163] For another example, if necessary, the device 400B may send a multi-STA frame 1600 ( Figure 16 ) to signal to device 400A that its reorder buffer is missing an MPDU sent by device 400A (e.g., at Figure 21 In this example, the multi-STA BA frame 1600 ( Figure 16) may include information identifying the status of the reorder buffer 412 on the device 400B.

[0164] Figure 22 16 shows one example of information that may be stored in the BA control field 1610 of the multi-STA BA frame 1600 to signal the reorder buffer status of the device 400B to the device 400A. Figure 22 As shown, the BA control field 1610 may include information about the status of its reorder buffer 412, such as a reorder buffer status field 2200. The reorder buffer status field 2200 may include one or more bits. The reorder buffer status field 2200 may be a first value (e.g., a bit set to "1") for indicating to the device 400A that the multi-STA BA frame 1600 includes one or more ReorderBufferStatus per AID fields. The reorder buffer status 2200 may be a second value (e.g., a bit set to "0") for indicating to the device 400A that the multi-STA BA frame 1600 does not include any ReorderBufferStatus per AID fields. If desired, a new AID field (e.g., an AID11 field) may be defined to signal the start of the ReorderBufferStatus.

[0165] Figure 23 An overview is shown that may be included in a multi-STA BA frame 1600 (e.g., Figure 22 Table 2300 of additional exemplary AID11 fields in the AID TID information field 1604 of a multi-STA BA frame 1600 shown with the reorder buffer status 2200 in its BA control field 1610. Figure 23 In the example of FIG4 , AID11 field A is reserved to identify the state of the reordering buffer 412 on the device 400B. AID11 field B can be defined to include a reordering bitmap for a corresponding STA (e.g., STA2) operating under a first version of the communication protocol (e.g., IEEE 802.11bn). The bitmap identifies the MPDUs discarded by the device 400A after the transmission of the BA frame 502 (e.g., Figure 21 If necessary, the AID11 field (eg, AID11 field "100") may be defined to include a BA bitmap for a legacy STA (eg, STA3) without MIC protection. Figure 23 The examples are illustrative and non-limiting, and in general, any desired AID11 field may be designated for any desired purpose.

[0166] In this example, the transmitter (e.g., device 400A) controls retransmissions and selects appropriate actions after receiving the reordering buffer status (e.g., in the multi-STA BA frame 1600) from device 400B. Then, in the best case, the transmitter can retransmit the failed MPDU. In the default case, the transmitter can move the reordering buffer forward. This can resynchronize the transmitter and receiver block ACKs, allow the blocked data in the reordering buffer to be moved to the corresponding application at the receiver (e.g., device 400B), and retransmit the leaky / lost frame in a TCP resend or another higher-layer resend mechanism. As the BA window becomes larger (e.g., supporting up to 1024 MPDUs), leaks may block frames for longer and longer periods of time, resulting in higher transmission delays.

[0167] As used herein, the term "simultaneously" refers to at least partially overlapping in time. In other words, if at least some of the first event occurs simultaneously with at least some of the second event (e.g., if at least some of the first event occurs during at least some of the second event, occurs at the same time as at least some of the second event, or occurs when at least some of the second event occurs), the first event and the second event are referred to herein as "simultaneous" with each other. If the first event and the second event are synchronous (e.g., if the entire duration of the first event overlaps in time with the entire duration of the second event), the first event and the second event can be simultaneous, but if the first event and the second event are asynchronous (e.g., if the first event starts before or after the second event starts, if the first event ends before or after the second event ends, or if the first event and the second event partially do not overlap in time), the first event and the second event can also be simultaneous. As used herein, the term "while" is synonymous with "concurrently." The term "when" also implies at least some concurrency (eg, event A occurs "when" event B occurs) means that at least some of event A occurs concurrently with at least some of event B).

[0168] STA 106 and AP 102 / 104 ( Figure 1 ) may collect and / or use personally identifiable information. It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly stated to users.

[0169] Combined with the above Figures 1 to 23The methods and operations described may be performed by components of the STA and / or AP using software, firmware, and / or hardware (e.g., dedicated circuitry or hardware). The software code for performing these operations may be stored on a non-transitory computer-readable storage medium (e.g., a tangible computer-readable storage medium) that is stored on one or more of the components of the STA and / or AP. The software code may sometimes be referred to as software, data, instructions, program instructions, or code. The non-transitory computer-readable storage medium may include a drive, non-volatile memory such as non-volatile random access memory (NVRAM), a removable flash drive or other removable media, other types of random access memory, and the like. The software stored on the non-transitory computer-readable storage medium may be executed by processing circuitry on one or more of the components of the STA and / or AP. The processing circuitry may include a microprocessor, a central processing unit (CPU), an application-specific integrated circuit having a processing circuit, or other processing circuitry.

[0170] For one or more aspects, at least one of the components shown in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods described in the following embodiments section. For example, circuits associated with the electronic device, authentication server, one or more processors, and the like described above in conjunction with one or more of the preceding figures may be configured to operate according to one or more of the embodiments shown in the following embodiments section.

[0171] Example

[0172] In the following sections, additional exemplary aspects are provided.

[0173] Embodiment 1 includes a method of operating a first electronic device to wirelessly communicate with a second electronic device, the method comprising: using one or more antennas to send an integrity-protected frame for reception by the second electronic device, wherein the integrity-protected frame comprises: a preamble; a medium access control (MAC) header; a delimiter located between the preamble and the MAC header; a message integrity check (MIC) field based on the MAC header; a data payload, the MAC header being located between the data payload and the delimiter; and a padding field, the padding field being configured to accommodate processing delays associated with generating or verifying the MIC field.

[0174] Embodiment 2 includes the method of embodiment 1 or some other embodiment or combination of embodiments herein, wherein the padding field is located between the delimiter and the MAC header in the integrity protected frame.

[0175] Embodiment 3 includes the method of any one of embodiments 1 or 2 or some other embodiment or combination of embodiments herein, wherein the padding field includes a copy of the delimiter.

[0176] Embodiment 4 includes the method of any one of embodiments 1 to 3 or some other embodiment or combination of embodiments herein, wherein the delimiter comprises an aggregated MAC protocol data unit (A-MPDU) associated with the data payload.

[0177] Embodiment 5 includes the method of any one of embodiments 1 to 4 or some other embodiment or combination of embodiments herein, wherein the padding field is located between the MAC header and the MIC field in the integrity protected frame.

[0178] Embodiment 6 includes the method of any one of embodiments 1 to 5 or some other embodiment or combination of embodiments herein, wherein the padding field is located between the MIC field and the data payload of the integrity protection frame.

[0179] Embodiment 7 includes the method of any one of embodiments 1 to 6 or some other embodiment or combination of embodiments herein, wherein the padding field is appended to the end of the data payload.

[0180] Embodiment 8 includes a method according to any one of embodiments 1 to 7 or some other embodiment or combination of embodiments herein, wherein the integrity-protected frame further comprises: a first MAC protocol data unit (MPDU) field, the first MAC protocol data unit (MPDU) field comprising the data payload; a second MPDU field, the second MPDU field comprising an appended data payload; a first group of padding fields, the first group of padding fields comprising the padding fields, the padding fields in the first group comprising a copy of the delimiter; and a second group of padding fields, the second group of padding fields being appended to the end of the second MPDU, the padding fields in the second group comprising an end-of-frame (EOF) bit.

[0181] Embodiment 9 includes a method according to any one of embodiments 1 to 8 or some other embodiment or combination of embodiments herein, the method further comprising: receiving an integrity protection block confirmation (BA) frame from the second electronic device using the one or more antennas; and verifying the additional MIC field of the BA frame using one or more processors.

[0182] Embodiment 10 includes a method according to any one of embodiments 1 to 9 or some other embodiment or combination of embodiments herein, wherein the MAC header includes a packet number (PN) field, and wherein the PN field identifies a first time synchronization function (TSF) of the integrity protection frame.

[0183] Embodiment 11 includes a method according to any one of embodiments 1 to 10 or some other embodiment or combination of embodiments herein, wherein the BA frame identifies a second TSF, the method further comprising discarding the BA frame when the second TSF is after a predetermined time range from the first TSF.

[0184] Embodiment 12 includes a method as in any one of embodiments 1 to 11 or some other embodiment or combination of embodiments herein, wherein the BA frame includes a hash identifier associated with the integrity protected frame.

[0185] Embodiment 13 includes a method according to any one of embodiments 1 to 12 or some other embodiment or combination of embodiments herein, wherein the integrity protection frame further includes: an additional MIC field based on the data payload, and the data payload is located between the additional MIC field and the MAC header in the integrity protection frame.

[0186] Embodiment 14 includes a method according to any one of embodiments 1 to 13 or some other embodiment or combination of embodiments herein, wherein the MIC field is located between the data payload and the packet number (PN) field of the MAC header in the integrity protection frame.

[0187] Embodiment 15 includes the method of any one of embodiments 1 to 14 or some other embodiment or combination of embodiments herein, wherein the additional MIC field is located between the MIC field and the data payload in the integrity protected frame.

[0188] Embodiment 16 includes a method according to any one of embodiments 1 to 15 or some other embodiment or combination of embodiments herein, the method further comprising: using one or more processors to generate a first MIC value based on the MAC header; using the one or more processors to generate a second MIC value based on the data payload; and using the one or more processors to generate the MIC field by performing an exclusive OR (XOR) operation on the first MIC value and the second MIC value, wherein the data payload is located between the MIC field and the MAC header in the integrity protection frame.

[0189] Embodiment 17 includes a method of operating a first electronic device to wirelessly communicate with a second electronic device, the method comprising: receiving a frame using one or more antennas; and sending an integrity-protected block acknowledgment (BA) frame using the one or more antennas for reception by the second electronic device, wherein the integrity-protected BA frame comprises: a preamble; a block acknowledgment (ACK) for a medium access control protocol data unit (MPDU) in the frame; a message integrity check (MIC) field based on the block ACK, the block ACK being located between the MIC field and the preamble in the integrity-protected BA frame; and a padding field, the padding field being configured to accommodate processing delays associated with generating or verifying the MIC field.

[0190] Embodiment 18 includes the method of embodiment 17 or some other embodiment or combination of embodiments herein, wherein the padding field is located between the block ACK and the MIC field in the integrity-protected BA frame.

[0191] Embodiment 19 includes the method of any one of embodiments 17, 18, or some other embodiment or combination of embodiments herein, wherein the padding field is located between the block ACK and the preamble in the integrity-protected BA frame.

[0192] Embodiment 20 includes a method according to any one of embodiments 17 to 19 or some other embodiment or combination of embodiments herein, wherein the padding field includes an association identifier (AID) traffic identifier (TID) information field that is not associated with any station (STA) communicating with the first electronic device and the second electronic device.

[0193] Embodiment 21 includes a method according to any one of embodiments 17 to 20 or some other embodiment or combination of embodiments herein, wherein the integrity-protected BA frame includes a block ACK bitmap, and the padding field includes an association identifier 11 (AID11) field associated with the block ACK bitmap.

[0194] Embodiment 22 includes a method according to any one of embodiments 17 to 21 or some other embodiment or combination of embodiments herein, wherein the integrity-protected BA frame includes a BA control field, and the BA control field includes one or more bits identifying the status of a reordering buffer on the first electronic device.

[0195] Embodiment 23 includes a method according to any one of embodiments 17 to 22 or some other embodiment or combination of embodiments herein, wherein the integrity-protected BA frame includes an association identifier 11 (AID11) field identifying one or more MPDUs discarded from the reordering buffer on the first electronic device.

[0196] Embodiment 24 includes a method of operating a first electronic device to wirelessly communicate with a second electronic device, the method comprising: receiving a frame using one or more antennas; sending a block acknowledgment (BA) frame using the one or more antennas for reception by the second electronic device, wherein the BA frame includes a block acknowledgment (ACK) for a media access control protocol data unit (MPDU) in the frame; and using one or more processors to attempt to verify the integrity of a media access control (MAC) header of the MPDU in the frame before sending the integrity-protected BA frame.

[0197] Embodiment 25 includes a method according to embodiment 24 or some other embodiment or combination of embodiments herein, further comprising: using the one or more processors to attempt to verify the integrity of the data payload of the MPDU in the frame after sending the integrity-protected BA frame.

[0198] Embodiment 26 includes a method according to any one of embodiments 24, 25 or some other embodiment or combination of embodiments herein, the method further comprising: using the one or more processors to attempt to verify the integrity of the data payload of the MPDU in the frame before sending the integrity-protected BA frame.

[0199] Embodiment 27 includes a method of operating a first electronic device to wirelessly communicate with a second electronic device, the method comprising: receiving a frame using one or more antennas; sending a block acknowledgment (BA) frame using the one or more antennas for reception by the second electronic device, wherein the BA frame includes a block acknowledgment (ACK) for a media access control protocol data unit (MPDU) in the frame; calculating a message integrity check (MIC) value based on at least some of the MPDUs using one or more processors after the integrity protection of the BA frame; and when the calculated MIC value does not match a corresponding MIC field included in the frame, sending a block acknowledgment request (BAR) frame using the one or more antennas, wherein the BAR frame identifies the MPDU.

[0200] Example 28 may include an apparatus comprising means for performing one or more elements of the method according to or related to any one of Examples 1 to 27 or a combination thereof, or any other method or process described herein.

[0201] Embodiment 29 may include one or more non-transitory computer-readable media, which include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described in or related to any one of Embodiments 1 to 27 or a combination thereof, or any other method or process described herein.

[0202] Embodiment 30 may include an apparatus comprising logic components, modules, or circuits for performing one or more elements of the method described in accordance with or related to any one of embodiments 1 to 27 or a combination thereof, or any other method or process described herein.

[0203] Example 31 may include methods, techniques, or processes as described in or related to any one of Examples 1 to 27, or a combination thereof, or portions or components thereof.

[0204] Embodiment 32 may include a device comprising: one or more processors and one or more non-transitory computer-readable storage media, wherein the one or more non-transitory computer-readable storage media include instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or portion thereof, as described in or related to any one of Embodiments 1 to 27 or a combination thereof.

[0205] Embodiment 33 may include signals according to or in connection with any one of embodiments 1 to 27 or a combination thereof, or portions or components thereof.

[0206] Embodiment 34 may include a datagram, information element, packet, frame, segment, PDU or message, or a portion or component thereof, as described or related to any one of embodiments 1 to 27 or a combination thereof, or otherwise described in this disclosure.

[0207] Embodiment 35 may include a signal encoded with data as described in, related to, or in combination with any one of Embodiments 1 to 26, or portions or components thereof, or as otherwise described in this disclosure.

[0208] Embodiment 36 may include a signal encoded with a datagram, IE, packet, frame, segment, PDU or message, or a portion or component thereof, as described or related to any one of embodiments 1 to 26 or a combination thereof, or otherwise described in this disclosure.

[0209] Embodiment 37 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process, or portion thereof, according to or related to any one of embodiments 1 to 27 or a combination thereof.

[0210] Embodiment 38 may include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique, or process, or portion thereof, as described in or related to any one of embodiments 1 to 27 or a combination thereof.

[0211] Embodiment 39 may include signals in a wireless network as shown and described herein.

[0212] Embodiment 40 may include a method of communicating in a wireless network as shown and described herein.

[0213] Embodiment 41 may include a system for providing wireless communications as shown and described herein.

[0214] Embodiment 42 may include an apparatus for providing wireless communications as shown and described herein.

[0215] According to one embodiment, a method of operating a first electronic device to wirelessly communicate with a second electronic device is provided, the method comprising sending an integrity-protected frame using one or more antennas for reception by the second electronic device, wherein the integrity-protected frame comprises: a preamble; a medium access control (MAC) header; a delimiter located between the preamble and the MAC header; a message integrity check (MIC) field based on the MAC header; a data payload, the MAC header being located between the data payload and the delimiter; and a padding field configured to accommodate processing delays associated with generating or verifying the MIC field.

[0216] According to another embodiment, a padding field is optionally located between the delimiter and the MAC header in the integrity protected frame.

[0217] According to another embodiment, the padding field optionally includes a copy of the delimiter, and the delimiter optionally includes an aggregated MAC protocol data unit (A-MPDU) associated with the data payload.

[0218] According to another embodiment, a padding field is optionally located between the MAC header and the MIC field in the integrity protected frame.

[0219] According to another embodiment, a padding field is optionally located between the MIC field and the data payload of the integrity protected frame.

[0220] According to another embodiment, a padding field is optionally appended to the end of the data payload.

[0221] According to another embodiment, the integrity protected frame optionally includes a first MAC protocol data unit (MPDU) field, the first MAC protocol data unit (MPDU) field including a data payload; a second MPDU field, the second MPDU field including an appended data payload; a first group of padding fields, the first group of padding fields including padding fields, the padding fields in the first group including a copy of a delimiter; and a second group of padding fields, the second group of padding fields being appended to the end of the second MPDU, the padding fields in the second group including an end-of-frame (EOF) bit.

[0222] According to another embodiment, the method optionally includes: receiving a block acknowledgement (BA) frame from the second electronic device using one or more antennas; and verifying an additional MIC field of the BA frame using one or more processors.

[0223] According to another embodiment, the MAC header optionally includes a packet number (PN) field, and the PN field identifies a first time synchronization function (TSF) of the integrity protection frame, and the BA frame identifies a second TSF, and the method optionally includes discarding the BA frame when the second TSF is after a predetermined time range from the first TSF.

[0224] According to another embodiment, the BA frame optionally includes a hash identifier associated with the integrity protected frame.

[0225] According to another embodiment, the integrity protected frame optionally includes an additional MIC field based on the data payload, which is located between the additional MIC field and the MAC header in the integrity protected frame.

[0226] According to another embodiment, the MIC field is optionally located between the data payload and the packet number (PN) field of the MAC header in the integrity protected frame.

[0227] According to another embodiment, an additional MIC field is optionally located between the MIC field and the data payload in the integrity protected frame.

[0228] According to another embodiment, the method optionally includes: generating, using one or more processors, a first MIC value based on a MAC header; generating, using one or more processors, a second MIC value based on a data payload; and generating, using one or more processors, a MIC field by performing an exclusive OR (XOR) operation on the first MIC value and the second MIC value, wherein the data payload is located between the MIC field and the MAC header in the integrity protected frame.

[0229] According to one embodiment, a method of operating a first electronic device to wirelessly communicate with a second electronic device is provided, the method comprising: receiving a frame using one or more antennas; and sending an integrity-protected block acknowledgment (BA) frame using the one or more antennas for reception by the second electronic device, the integrity-protected BA frame comprising: a preamble; a block acknowledgment (ACK) for a medium access control protocol data unit (MPDU) in the frame; a message integrity check (MIC) field based on the block ACK, the block ACK being located between the MIC field and the preamble in the integrity-protected BA frame; and a padding field configured to accommodate processing delays associated with generating or verifying the MIC field.

[0230] According to another embodiment, a padding field is optionally located between the end of the MIC field and the beginning of the frequency checksum field of the integrity protected BA frame.

[0231] According to another embodiment, a padding field is optionally located between the Block ACK and MIC fields in the integrity protected BA frame.

[0232] According to one embodiment, a method of operating a first electronic device to wirelessly communicate with a second electronic device is provided, the method comprising: receiving a frame using one or more antennas; sending a block acknowledgment (BA) frame using the one or more antennas for reception by the second electronic device, the BA frame comprising a block acknowledgment (ACK) for a media access control protocol data unit (MPDU) in the frame; and using one or more processors to attempt to verify the integrity of a media access control (MAC) header of the MPDU in the frame before sending the integrity-protected BA frame.

[0233] According to another embodiment, the method optionally includes employing one or more processors to attempt to verify the integrity of a data payload of an MPDU in the frame after sending the integrity-protected BA frame.

[0234] According to another embodiment, the method optionally includes employing one or more processors to attempt to verify the integrity of a data payload of an MPDU in the frame prior to sending the integrity-protected BA frame.

[0235] Unless explicitly stated otherwise, any of the above embodiments may be combined with any other embodiment (or combination of embodiments).The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the various aspects to the precise forms disclosed.

Claims

1. A method of operating a first electronic device to wirelessly communicate with a second electronic device, the method comprising: The integrity protection frame is transmitted using one or more antennas for reception by the second electronic device, wherein the integrity protection frame includes Preamble, Medium Access Control (MAC) header, a delimiter between the preamble and the MAC header, Based on the Message Integrity Check (MIC) field of the MAC header, a data payload, the MAC header being located between the data payload and the delimiter, and A padding field is configured to accommodate processing delays associated with generating or validating the MIC field. 2 . The method of claim 1 , wherein the padding field is located between the delimiter and the MAC header in the integrity protection frame.

3. The method of claim 2, wherein the padding field comprises a copy of the delimiter, and wherein the delimiter comprises an aggregated MAC protocol data unit (A-MPDU) associated with the data payload. 4 . The method of claim 1 , wherein the padding field is located between the MAC header and the MIC field in the integrity protection frame. 5 . The method of claim 1 , wherein the padding field is located between the MIC field and the data payload of the integrity protection frame. The method of claim 1 , wherein the padding field is appended to the end of the data payload.

7. The method of claim 1 , wherein the integrity protection frame further comprises: a first MAC protocol data unit (MPDU) field, the first MPDU field including the data payload; a second MPDU field comprising an additional data payload; a first group of padding fields, the first group of padding fields comprising the padding fields, the padding fields in the first group comprising copies of the delimiter; and A second group of padding fields is appended to the end of the second MPDU, the padding fields in the second group including an end-of-frame (EOF) bit.

8. The method according to claim 1, further comprising: receiving a block acknowledgement (BA) frame from the second electronic device using the one or more antennas; as well as One or more processors are used to validate the appended MIC field of the BA frame.

9. The method of claim 8, wherein the MAC header includes a packet number (PN) field, and wherein the PN field identifies a first time synchronization function (TSF) of the integrity protection frame, and wherein the BA frame identifies a second TSF, the method further comprising: When the second TSF is after a predetermined time range from the first TSF, the BA frame is discarded.

10. The method of claim 8, wherein the BA frame includes a hash identifier associated with the integrity-protected frame.

11. The method of claim 1 , wherein the integrity protection frame further comprises: Based on the additional MIC field of the data payload, the data payload is located between the additional MIC field and the MAC header in the integrity protection frame.

12. The method of claim 11, wherein the MIC field is located between the data payload and a packet number (PN) field of the MAC header in the integrity-protected frame.

13. The method of claim 11, wherein the additional MIC field is located between the MIC field and the data payload in the integrity protection frame.

14. The method according to claim 1, further comprising: generating, using one or more processors, a first MIC value based on the MAC header; generating, using the one or more processors, a second MIC value based on the data payload; as well as The MIC field is generated using the one or more processors by performing an exclusive OR (XOR) operation on the first MIC value and the second MIC value, the data payload being located between the MIC field and the MAC header in the integrity-protected frame.

15. A method of operating a first electronic device to wirelessly communicate with a second electronic device, the method comprising: receiving frames using one or more antennas; as well as An integrity-protected block acknowledgement (BA) frame is transmitted using the one or more antennas for reception by the second electronic device, wherein the integrity-protected BA frame includes Preamble, a block acknowledgement (ACK) for a medium access control protocol data unit (MPDU) in the frame, Based on a message integrity check (MIC) field of the block ACK, the block ACK being located between the MIC field and the preamble in the integrity-protected BA frame, and A padding field is configured to accommodate processing delays associated with generating or validating the MIC field.

16. The method of claim 15, wherein the padding field is located between the end of the MIC field and the beginning of a frequency checksum field of the integrity-protected BA frame.

17. The method of claim 15, wherein the padding field is located between the block ACK and the MIC field in the integrity-protected BA frame.

18. A method of operating a first electronic device to wirelessly communicate with a second electronic device, the method comprising: receiving frames using one or more antennas; transmitting a block acknowledgement (BA) frame for reception by the second electronic device using the one or more antennas, wherein the BA frame includes a block acknowledgement (ACK) for a medium access control protocol data unit (MPDU) in the frame; as well as One or more processors are employed to attempt to verify the integrity of a medium access control (MAC) header of the MPDU in the frame prior to sending the integrity-protected BA frame.

19. The method according to claim 18, further comprising: The one or more processors are employed to attempt to verify the integrity of a data payload of the MPDU in the frame after sending the integrity-protected BA frame.

20. The method according to claim 18, further comprising: The one or more processors are employed to attempt to verify the integrity of a data payload of the MPDU in the frame prior to sending the integrity-protected BA frame.

Images