CN117730486A - Changing the rate at which MIMO transmissions are derived from a wireless communication device - Google Patents

Changing the rate at which MIMO transmissions are derived from a wireless communication device Download PDF

Info

Publication number
CN117730486A
CN117730486A CN202280051905.4A CN202280051905A CN117730486A CN 117730486 A CN117730486 A CN 117730486A CN 202280051905 A CN202280051905 A CN 202280051905A CN 117730486 A CN117730486 A CN 117730486A
Authority
CN
China
Prior art keywords
wireless communication
network
communication device
rate
messages
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202280051905.4A
Other languages
Chinese (zh)
Inventor
C·贝格
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cognitive Systems Corp
Original Assignee
Cognitive Systems Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/328,479 external-priority patent/US11570712B2/en
Application filed by Cognitive Systems Corp filed Critical Cognitive Systems Corp
Publication of CN117730486A publication Critical patent/CN117730486A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B7/00Radio transmission systems, i.e. using radiation field
    • H04B7/02Diversity systems; Multi-antenna system, i.e. transmission or reception using multiple antennas
    • H04B7/04Diversity systems; Multi-antenna system, i.e. transmission or reception using multiple antennas using two or more spaced independent antennas
    • H04B7/0413MIMO systems
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01SRADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S13/00Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
    • G01S13/003Bistatic radar systems; Multistatic radar systems
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01SRADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S7/00Details of systems according to groups G01S13/00, G01S15/00, G01S17/00
    • G01S7/003Transmission of data between radar, sonar or lidar systems and remote stations
    • G01S7/006Transmission of data between radar, sonar or lidar systems and remote stations using shared front-end circuitry, e.g. antennas
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02Power saving arrangements
    • H04W52/0209Power saving arrangements in terminal devices
    • H04W52/0212Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02Power saving arrangements
    • H04W52/0209Power saving arrangements in terminal devices
    • H04W52/0225Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0229Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a wanted signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02Power saving arrangements
    • H04W52/0209Power saving arrangements in terminal devices
    • H04W52/0261Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
    • H04W52/0274Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof
    • H04W52/028Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof switching on or off only a part of the equipment circuit blocks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

In a general aspect, a rate at which MIMO transmissions are derived from a wireless communication device is changed. The first wireless communication device may be configured to wirelessly transmit the first set of messages to the second wireless communication device at a first transmission rate. The first wireless communication device may also be configured to receive MIMO transmissions from the second wireless communication device. The first wireless communication apparatus may be further configured to: generating first channel information based on respective training fields in each first MIMO transmission; determining a rate at which first channel information is generated; changing the first transmission rate to a second, different transmission rate based on the rate at which the first channel information is generated; and wirelessly transmitting the second set of messages to the second wireless communication device at a second transmission rate.

Description

Changing the rate at which MIMO transmissions are derived from a wireless communication device
Cross Reference to Related Applications
The present application claims priority from U.S. patent application Ser. No. 17/328,479, entitled "Varying a Rate of Eliciting MIMO Transmission from Wireless Communication Devices," filed on even 24, 5, 2021, the contents of which are incorporated herein by reference.
Background
The following description relates to varying the rate at which multiple input/multiple output (MIMO) transmissions are directed from a wireless communication device, such as for wireless motion detection.
Motion detection systems have been used to detect movement of objects in, for example, a room or an outdoor area. In some example motion detection systems, infrared or optical sensors are used to detect movement of an object in the field of view of the sensor. Motion detection systems have been used in security systems, automation control systems, and other types of systems.
Drawings
Fig. 1 is a diagram illustrating an example wireless communication system.
Fig. 2A-2B are diagrams illustrating example wireless signals communicated between wireless communication devices.
FIG. 2C is a diagram of an example wireless sensing system operating to detect motion in a space.
Fig. 3 is a diagram illustrating an example PHY frame.
Fig. 4 is a diagram illustrating an example PHY frame.
Fig. 5 is a diagram illustrating an example multiple-input multiple-output (MIMO) radio configuration.
Fig. 6 is a diagram showing an example spectrum of a wireless signal.
Fig. 7 is a diagram showing an example representation of the Open Systems Interconnection (OSI) model.
Fig. 8 is a diagram illustrating example message components of three layers of a typical OSI model.
FIG. 9 is a flow chart illustrating an example process of locating upper level logical addresses.
Fig. 10 is a state machine diagram illustrating an example process of deriving a MIMO transmission from a wireless communication device.
Fig. 11A shows a flowchart representing an example process of setting ICMP ping.
Fig. 11B shows a flowchart representing an example process of stopping ICMP ping.
Fig. 11C shows a flowchart representing an example process of ICMP ping.
Fig. 12A shows a flowchart representing an example process of setting TCP Ping.
Fig. 12B shows a flowchart representing an example process of performing TCP Ping.
Fig. 13 shows a flowchart representing an example process of setting ARP Ping.
Fig. 14 shows a flow chart representing an example method of deriving a MIMO transmission from a wireless communication device.
Fig. 15 is a block diagram illustrating an example wireless communication device.
Fig. 16 illustrates an example message exchange in an association process between a client device and an access point device.
Fig. 17 illustrates an example Traffic Indication Map (TIM) element.
Fig. 18 shows an example MAC header with a frame control field.
Fig. 19 shows an example format of a power save poll message.
Fig. 20 illustrates an example control loop that may be used to vary the rate of outgoing transmissions.
Fig. 21 illustrates a flow chart representative of an example method of varying a rate at which MIMO transmissions are derived from a wireless communication device.
Detailed Description
In some aspects described herein, a wireless sensing system may process wireless signals (e.g., radio frequency signals) transmitted through a space between wireless communication devices for wireless sensing applications. An example wireless sensing application includes detecting motion, which may include one or more of: detecting motion of an object in a space, motion tracking, localization of motion in a space, respiratory detection, respiratory monitoring, presence detection, gesture recognition, human detection (e.g., mobile and stationary human detection), human tracking, fall detection, velocity estimation, intrusion detection, walking detection, step counting, respiratory rate detection, sleep mode detection, apnea estimation, gesture change detection, activity recognition, gait rate classification, gesture decoding, sign language recognition, hand tracking, heart rate estimation, respiratory rate estimation, room occupancy detection, human dynamics monitoring, and other types of motion detection applications. Other examples of wireless sensing applications include object recognition, speech recognition, keystroke detection and recognition, tamper detection, touch detection, attack detection, user authentication, driver fatigue detection, traffic monitoring, smoke detection, school violence detection, human counting, metal detection, human recognition, bicycle positioning, human queue estimation, wi-Fi imaging, and other types of wireless sensing applications. For example, the wireless sensing system may operate as a motion detection system to detect the presence and location of motion based on Wi-Fi signals or other types of wireless signals.
Examples described herein may be useful for home monitoring. In some instances, home monitoring using the wireless sensing systems described herein may provide several advantages including full home coverage through the wall and in darkness, careful detection without cameras, higher accuracy and reduced false alarms (e.g., as compared to sensors that do not use Wi-Fi signal sensing sensors in environments), and adjustable sensitivity. By layering Wi-Fi motion detection capabilities into routers and gateways, a robust motion detection system may be provided.
The examples described herein may also be useful for health monitoring. Caregivers want to know that their relatives are safe, while elderly and special-demand people want to maintain their independence at home with dignity. In some examples, health monitoring using the wireless sensing systems described herein may provide a solution that uses wireless signals to detect motion without using cameras or violating privacy, generates alerts when abnormal activity is detected, tracks sleep patterns, and generates preventive health data. For example, caregivers may monitor sports, visits from healthcare professionals, abnormal behavior such as bed time to flat time periods, and the like. Furthermore, movement is unobtrusively monitored without the need for a wearable device, and the wireless sensing system described herein provides a more economical and convenient alternative to auxiliary living facilities and other safety and health monitoring tools.
The examples described herein may also be useful for setting up smart homes. In some examples, the wireless sensing system described herein uses predictive analysis and Artificial Intelligence (AI) to learn movement patterns and trigger smart home functions accordingly. Examples of smart home functions that may be triggered include adjusting a thermostat when a person passes through a front door, turning other smart devices on or off based on preferences, automatically adjusting lighting, adjusting an HVAC system based on the current occupant, and so forth.
In some examples, aspects of the systems and techniques described herein provide technical improvements and advantages over existing methods. In some wireless network environments, some wireless communication devices may not automatically send MIMO transmissions in response to some PHY layer or MAC layer messages. The PHY layer (also referred to as the physical layer) may refer to layer 1 of the Open System Interconnection (OSI) model, and the MAC layer (also referred to as the data link layer) may refer to layer 2 of the OSI model. In aspects of the described systems and techniques, messages initiated by protocols in higher layers (e.g., layers 1 and 2 above the OSI model) may be used to elicit MIMO transmissions from a wireless communication device. For example, a network layer message (e.g., ICMP Ping, ARP Ping, or modified versions of these and other network layer processes) and a transport layer message (e.g., TCP Ping or modified versions of these and other transport layer processes) may be used to cause one or more wireless communication devices to send a wireless transmission that includes a MIMO training field.
The MIMO training field contains signals with higher frequency resolution, a greater number of subcarrier frequencies, and a higher frequency bandwidth than the legacy training field in the PHY frame. Using the MIMO training field for motion detection provides more accurate motion detection capabilities. For example, in some instances, motion detection may be performed with higher spatial and temporal resolution, precision, and accuracy by using PHY frames each with a corresponding MIMO training field. Furthermore, since MIMO transmissions are elicited using protocols in higher layers, MIMO transmissions may be elicited from a wider range of wireless communication devices (or both) in a more efficient manner. The ability of wireless sensing systems to elicit MIMO transmissions from a wider range of wireless communication devices may allow wireless sensing systems to operate in a more diverse environment and cover a larger spatial area. In addition, for example, existing resources on the responding device may be used to elicit MIMO transmissions without having to install any additional hardware, software, or firmware on the responding device (e.g., reducing or eliminating the need for dedicated motion detection hardware in some cases). Furthermore, the systems and techniques described here may be used in a wireless motion detection system or other type of wireless sensing system. For example, in various wireless sensing systems that utilize Channel State Information (CSI) derived from wireless signals (e.g., systems that accept CSI channel responses and apply digital signal processing, machine learning, or other types of analysis to the CSI channel responses), it may be useful to elicit MIMO transmissions. The technical improvements and advantages achieved in the examples where wireless sensing systems are used for motion detection may also be achieved in the examples where wireless sensing systems are used for other wireless sensing applications.
In some examples, the wireless sensing system may be implemented using a wireless communication network. Wireless signals received at one or more wireless communication devices in a wireless communication network may be analyzed to determine channel information for different communication links (between pairs of wireless communication devices) in the network. The channel information may represent a physical medium to apply a transfer function to a wireless signal passing through a space. In some examples, the channel information includes a channel response. The channel response may characterize the physical communication path, thereby representing the combined effects of, for example, scattering, fading, and power attenuation in the space between the transmitter and the receiver. In some examples, the channel information includes beamforming state information (e.g., feedback matrix, steering matrix, channel State Information (CSI), etc.) provided by the beamforming system. Beamforming is a signal processing technique often used in multi-antenna (MIMO) radio systems for directional signal transmission or reception. Beamforming may be achieved by operating elements in an antenna array in such a way that signals at a particular angle experience constructive interference, while other signals experience destructive interference.
The channel information of each communication link may be analyzed by one or more motion detection algorithms (e.g., running on a hub device, client device or other device in the wireless communication network, or on a remote device communicatively coupled to the network) to detect, for example, whether motion has occurred in space, to determine the relative location of the detected motion, or both. In some aspects, channel information for each communication link may be analyzed to detect whether an object is present or absent, for example, if no motion is detected in space.
In some examples, the motion detection system returns motion data. In some implementations, the motion data is a result that indicates a degree of motion in a space, a location of the motion in the space, a direction of the motion in the space, a time at which the motion occurred, or a combination thereof. In some examples, the athletic data may include an athletic score that may include, or may be, one or more of the following: a scalar indicative of a level of signal disturbance in an environment accessed by the wireless signal; an indication of whether motion is present; an indication of whether an object exists; or an indication or classification of a gesture made in the environment accessed by the wireless signal.
In some implementations, the motion detection system may be implemented using one or more motion detection algorithms. Example motion detection algorithms that may be used to detect motion based on wireless signals include the techniques described in the following patents, as well as other techniques: U.S. patent 9,523,760 entitled "Detecting Motion Based on Repeated Wireless Transmissions"; U.S. patent 9,584,974 entitled "Detecting Motion Based on Reference Signal Transmissions"; U.S. patent 10,051,414 entitled "Detecting Motion Based On Decompositions Of Channel Response Variations"; U.S. patent 10,048,350 entitled "Motion Detection Based on Groupings of Statistical Parameters of Wireless Signals"; U.S. patent 10,108,903 entitled "Motion Detection Based on Machine Learning of Wireless Signal Properties"; U.S. patent 10,109,167 entitled "Motion Localization in a Wireless Mesh Network Based on Motion Indicator Values"; U.S. patent 10,109,168 entitled "Motion Localization Based on Channel Response Characteristics"; U.S. patent 10,743,143 entitled "Determining a Motion Zone for a Location of Motion Detected by Wireless Signals"; U.S. patent 10,605,908 entitled "Motion Detection Based on Beamforming Dynamic Information from Wireless Standard Client Devices"; U.S. patent 10,605,907 entitled "Motion Detection by a Central Controller Using Beamforming Dynamic Information"; U.S. patent 10,600,314 entitled "Modifying Sensitivity Settings in a Motion Detection System"; U.S. patent 10,567,914 entitled "Initializing Probability Vectors for Determining a Location of Motion Detected from Wireless Signals"; U.S. patent 10,565,860 entitled "Offline Tuning System for Detecting New Motion Zones in a Motion Detection System"; U.S. patent 10,506,384 entitled "Determining a Location of Motion Detected from Wireless Signals Based on Prior Probability"; U.S. patent 10,499,364 entitled "Identifying Static Leaf Nodes in a Motion Detection System"; U.S. patent 10,498,467 entitled "Classifying Static Leaf Nodes in a Motion Detection System"; U.S. patent 10,460,581 entitled "Determining a Confidence for a Motion Zone Identified as a Location of Motion for Motion Detected by Wireless Signals"; U.S. patent 10,459,076 entitled "Motion Detection based on Beamforming Dynamic Information"; U.S. patent 10,459,074 entitled "Determining a Location of Motion Detected from Wireless Signals Based on Wireless Link Counting"; U.S. patent 10,438,468 entitled "Motion Localization in a Wireless Mesh Network Based on Motion Indicator Values"; U.S. patent 10,404,387 entitled "Determining Motion Zones in a Space Traversed by Wireless Signals"; U.S. patent 10,393,866 entitled "Detecting Presence Based on Wireless Signal Analysis"; U.S. patent 10,380,856 entitled "Motion Localization Based on Channel Response Characteristics"; U.S. patent 10,318,890 entitled "Training Data for a Motion Detection System using Data from a Sensor Device"; U.S. patent 10,264,405 entitled "Motion Detection in Mesh Networks"; U.S. patent 10,228,439 entitled "Motion Detection Based on Filtered Statistical Parameters of Wireless Signals"; U.S. patent 10,129,853 entitled "Operating a Motion Detection Channel in a Wireless Communication Network"; U.S. patent 10,111,228 entitled "Selecting Wireless Communication Channels Based on Signal Quality Metrics".
Fig. 1 illustrates an example wireless communication system 100. The wireless communication system 100 may perform one or more operations of a motion detection system. The technical improvements and advantages achieved from using the wireless communication system 100 to detect motion are applicable in examples where the wireless communication system 100 is used for other wireless sensing applications as well.
The example wireless communication system 100 includes three wireless communication devices 102A, 102B, and 102C. The example wireless communication system 100 may include additional wireless communication devices 102 and/or other components (e.g., one or more network servers, network routers, network switches, cables or other communication links, etc.).
The example wireless communication devices 102A, 102B, 102C may operate in a wireless network, for example, according to a wireless network standard or other type of wireless communication protocol. For example, the wireless network may be configured to operate as a Wireless Local Area Network (WLAN), a Personal Area Network (PAN), a Metropolitan Area Network (MAN), or other type of wireless network. Examples of WLANs include networks (e.g., wi-Fi networks) configured to operate in accordance with one or more of the IEEE developed family of 802.11 standards, and the like. Examples of PANs include those according to the short-range communication standard (e.g., bluetooth Near Field Communication (NFC), zigBee, millimeter wave communication, and the like.
In some implementations, the wireless communication devices 102A, 102B, 102C may be configured to communicate in a cellular network, for example, according to a cellular network standard. Examples of cellular networks include networks configured according to the following criteria: 2G standards such as Global System for Mobile (GSM) and enhanced data rates for GSM evolution (EDGE) or EGPRS; 3G standards such as Code Division Multiple Access (CDMA), wideband Code Division Multiple Access (WCDMA), universal Mobile Telecommunications System (UMTS), and time division-synchronous code division multiple access (TD-SCDMA); 4G standards such as Long Term Evolution (LTE) and LTE-advanced (LTE-a); 5G standard; etc.
In some cases, one or more of the wireless communication devices 102 are Wi-Fi access points or other types of Wireless Access Points (WAPs). In some cases, one or more of the wireless communication devices 102 are access points of a wireless mesh network (e.g., a commercially available mesh network system (e.g., GOOGLE Wi-Fi, EERO mesh, etc.). In some examples, one or more of the wireless communication devices 102 may be implemented as wireless Access Points (APs) in the mesh network, while the other wireless communication device(s) 102 are implemented as leaf devices (e.g., mobile devices, smart devices, etc.) that access the mesh network through one of the APs. In some cases, one or more of the wireless communication devices 102 are mobile devices (e.g., smart phones, smartwatches, tablets, laptops, etc.), wireless enabled devices (e.g., smart thermostats, wi-Fi enabled cameras, smart televisions), or other types of devices that communicate in a wireless network.
In the example shown in fig. 1, wireless communication devices communicate wireless signals to each other over a wireless communication link (e.g., according to a wireless network standard or non-standard wireless communication protocol), and the wireless signals communicated between the devices may be used as motion detectors to detect motion of objects in the signal path between the devices. In some implementations, standard signals (e.g., channel sounding signals, beacon signals), non-standard reference signals, or other types of wireless signals may be used as motion detectors.
In the example shown in fig. 1, the wireless communication link between the wireless communication devices 102A, 102C may be used to detect the first motion detection zone 110A, the wireless communication link between the wireless communication devices 102B, 102C may be used to detect the second motion detection zone 110B, and the wireless communication link between the wireless communication devices 102A, 102B may be used to detect the third motion detection zone 110C. In some examples, motion detection region 110 may include, for example, air, solid material, liquid, or other medium through which wireless electromagnetic signals may propagate.
In the example shown in fig. 1, as an object moves in any of the motion detection regions 110, the motion detection system may detect motion based on signals transmitted through the associated motion detection region 110. In general, the object may be any type of static or movable object, and may be living or inanimate. For example, the object may be a human (e.g., human 106 shown in fig. 1), an animal, an inorganic object, or other apparatus, device, or assembly, an object defining all or a portion of a boundary of a space (e.g., a wall, a door, a window, etc.), or other type of object.
In some examples, the wireless signal may propagate through a structure (e.g., a wall) before or after interacting with the moving object, which may enable detection of movement of the object without a line of sight of light between the moving object and the transmitting or receiving hardware. In some examples, the motion detection system may communicate the motion detection event to other devices or systems, such as a security system or a control center.
In some cases, the wireless communication device 102 itself is configured to perform one or more operations of the motion detection system, for example, by executing computer-readable instructions (e.g., software or firmware) on the wireless communication device. For example, devices may process received wireless signals to detect motion based on changes in the communication channel. In some cases, other devices (e.g., remote servers, cloud-based computer systems, network attached devices, etc.) are configured to perform one or more operations of the motion detection system. For example, each wireless communication device 102 may transmit channel information to a designated device, system, or service that is performing the operation of the motion detection system.
In an example aspect of operation, the wireless communication devices 102A, 102B may broadcast or address wireless signals to other wireless communication devices 102C, and the wireless communication device 102C (and possibly other devices) receives wireless signals transmitted by the wireless communication devices 102A, 102B. The wireless communication device 102C (or other system or device) then processes the received wireless signals to detect movement of objects in the space accessed by the wireless signals (e.g., in the zones 110A, 110B). In some examples, the wireless communication device 102C (or other system or device) may perform one or more operations of the motion detection system.
Fig. 2A and 2B are diagrams illustrating example wireless signals communicated between wireless communication devices 204A, 204B, 204C. The wireless communication devices 204A, 204B, 204C may be, for example, the wireless communication devices 102A, 102B, 102C shown in fig. 1, or may be other types of wireless communication devices.
In some cases, one or a combination of more than one of the wireless communication devices 204A, 204B, 204C may be part of, or may be used by, a motion detection system. The example wireless communication devices 204A, 204B, 204C may transmit wireless signals through the space 200. The example space 200 may be fully or partially enclosed or open at one or more boundaries of the space 200. The space 200 may be or include an interior of a room, a plurality of rooms, a building, an indoor or outdoor area, or the like. In the illustrated example, the first wall 202A, the second wall 202B, and the third wall 202C at least partially enclose the space 200.
In the example shown in fig. 2A and 2B, the first wireless communication device 204A repeatedly (e.g., periodically, intermittently, at scheduled, non-scheduled, or random intervals, etc.) transmits wireless motion probe signals. The second wireless communication device 204B and the third wireless communication device 204C receive signals based on the motion detection signal transmitted by the wireless communication device 204A.
As shown, at an initial time (t 0) in FIG. 2A, the object is in a first position 214A, and at a subsequent time (t 1) in FIG. 2B, the object has moved to a second position 214B. In fig. 2A and 2B, the moving object in the space 200 is represented as a human being, but the moving object may be other types of objects. For example, the moving object may be an animal, an inorganic object (e.g., a system, device, apparatus, or assembly), an object defining all or a portion of the boundary of the space 200 (e.g., a wall, door, window, etc.), or other type of object. In the example shown in fig. 2A and 2B, the wireless communication devices 204A, 204B, 204C are stationary, and therefore at the same location at the initial time t0 and the subsequent time t 1. However, in other examples, one or more of the wireless communication devices 204A, 204B, 204C may be mobile and may move between an initial time t0 and a subsequent time t 1.
As shown in fig. 2A and 2B, a plurality of example paths of wireless signals transmitted from the first wireless communication device 204A are shown by dashed lines. Along the first signal path 216, wireless signals are transmitted from the first wireless communication device 204A and reflected from the first wall 202A toward the second wireless communication device 204B. Along the second signal path 218, the wireless signal is transmitted from the first wireless communication device 204A and reflected from the second wall 202B and the first wall 202A toward the third wireless communication device 204C. Along the third signal path 220, the wireless signal is transmitted from the first wireless communication device 204A and reflected from the second wall 202B toward the third wireless communication device 204C. Along the fourth signal path 222, the wireless signal is transmitted from the first wireless communication device 204A and reflected from the third wall 202C toward the second wireless communication device 204B.
In fig. 2A, along a fifth signal path 224A, wireless signals are transmitted from the first wireless communication device 204A and reflected from the object at the first location 214A toward the third wireless communication device 204C. Between time t0 of fig. 2A and time t1 of fig. 2B, the object moves in space 200 from first location 214A to second location 214B (e.g., a distance from first location 214A). In fig. 2B, along a sixth signal path 224B, the wireless signal is transmitted from the first wireless communication device 204A and reflected from the object at the second location 214B toward the third wireless communication device 204C. Since the object moves from the first position 214A to the second position 214B, the sixth signal path 224B shown in fig. 2B is longer than the fifth signal path 224A shown in fig. 2A. In some examples, signal paths may be added, removed, or otherwise modified due to movement of objects in space.
The example wireless signals shown in fig. 2A and 2B may experience attenuation, frequency shift, phase shift, or other effects through their respective paths, and may have portions that propagate in other directions, for example, through walls 202A, 202B, and 202C. In some examples, the wireless signal is a Radio Frequency (RF) signal. The wireless signals may include other types of signals.
The transmission signal may have a plurality of frequency components in a frequency bandwidth, and the transmission signal may include one or more frequency bands within the frequency bandwidth. The transmit signal may be transmitted from the first wireless communication device 204A in an omni-directional manner, in a directional manner, or otherwise. In the illustrated example, the wireless signal passes through multiple respective paths in the space 200, and the signals along each path may become attenuated due to path loss, scattering, reflection, or the like, and may have a phase offset or frequency offset.
As shown in fig. 2A and 2B, signals from the various paths 216, 218, 220, 222, 224A, and 224B are combined at the third wireless communication device 204C and the second wireless communication device 204B to form a received signal. Due to the effects of multiple paths in the space 200 on the transmit signal, the space 200 may be represented as a transfer function (e.g., a filter) that inputs the transmit signal and outputs the receive signal. In the case where an object moves in the space 200, the attenuation or phase shift applied to the wireless signal along the signal path may change, and thus the transfer function of the space 200 may change. When the same wireless signal is transmitted from the first wireless communication device 204A, if the transfer function of the space 200 is changed, the output of the transfer function (e.g., the received signal) may also be changed. The change in the received signal may be used to detect movement of the object. In contrast, in some cases, if the transfer function of the space is not changed, the output (reception signal) of the transfer function may not be changed.
Fig. 2C is a diagram illustrating an example wireless sensing system operating to detect motion in space 201. The example space 201 shown in fig. 2C is a home that includes a plurality of different spatial regions or zones. In the illustrated example, the wireless motion detection system uses a multi-AP home network topology (e.g., mesh network or self-organizing network (SON)) that includes three Access Points (APs) that are a central access point 226 and two extended access points 228A, 228B. In a typical multi-AP home network, each AP typically supports multiple frequency bands (2.4G, 5G, 6G) and may enable multiple frequency bands simultaneously. Each AP may use a different Wi-Fi channel to serve its clients, as this may allow for better spectral efficiency.
In the example shown in fig. 2C, the wireless communication network includes a central access point 226. In a multi-AP home Wi-Fi network, one AP may be denoted as a central AP. The selection, which is often managed by manufacturer software running on each AP, is typically an AP with a wired internet connection 236. The other APs 228A, 228B are wirelessly connected to the central AP 226 via respective wireless backhaul connections 230A, 230B. The central AP 226 may select a different wireless channel than the extended AP to serve its connected clients.
In the example shown in fig. 2C, the extension APs 228A, 228B extend the range of the central AP 226 by enabling the device to connect to a potentially closer AP or a different channel. The end user does not need to know which AP the device has connected to, as all services and connectivity are typically the same. In addition to serving all connected clients, the extended APs 228A, 228B are connected to the central AP 226 using wireless backhaul connections 230A, 230B to move network traffic between other APs and provide a gateway to the internet. Each extended AP 228A, 228B may select a different channel to serve its connected clients.
In the example shown in fig. 2C, client devices (e.g., wi-Fi client devices) 232A, 232B, 232C, 232D, 232E, 232F, 232G are associated with one of the extended APs 228 or the central AP 226 using respective wireless links 234A, 234B, 234C, 234D, 234E, 234F, 234G. Client device 232 connected to the multi-AP network may operate as a leaf node in the multi-AP network. In some implementations, the client device 232 may include a wireless-enabled device (e.g., a mobile device, a smart phone, a smart watch, a tablet, a laptop, a smart thermostat, a wireless-enabled camera, a smart television, a wireless-enabled speaker, a wireless-enabled power outlet, etc.).
When client devices 232 attempt to connect to and associate with their respective APs 226, 228, the client devices 232 may experience authentication and association phases with their respective APs 226, 228. The association phase assigns address information (e.g., an association ID or other type of unique identifier) to each client device 232, among other things. For example, within the IEEE 802.11 family of Wi-Fi, each client device 232 may identify itself using a unique address (e.g., a 48-bit address, an example being a MAC address), although other types of identifiers embedded within one or more fields of a message may be used to identify the client device 232. The address information (e.g., MAC address or other type of unique identifier) may be hard coded and fixed or may be randomly generated according to network address rules at the beginning of the association process. Once the client devices 232 are associated with their respective APs 226, 228, their respective address information may remain fixed. Subsequently, the transmission with the AP 226, 228 or client device 232 typically includes transmitting address information (e.g., MAC address) of the wireless device and address information (e.g., MAC address) of the receiving device.
In the example shown in fig. 2C, wireless backhaul connections 230A, 230B carry data between APs and may also be used for motion detection. The respective wireless backhaul channels (or bands) may be different from the channels (or bands) used to serve the connected Wi-Fi devices.
In the example shown in fig. 2C, wireless links 234A, 234B, 234C, 234D, 234E, 234F, 234G may include frequency channels used by client devices 232A, 232B, 232C, 232D, 232E, 232F, 232G to communicate with their respective APs 226, 228. Each AP may independently select its own channel to serve their respective client device and wireless link 234 may be used for data communications as well as motion detection.
The motion detection system (which may include one or more motion detection or positioning processes running on one or more of the client devices 232 or on one or more of the APs 226, 228) may collect and process data (e.g., channel information) corresponding to local links engaged in the operation of the wireless sensing system. The motion detection system may be installed as a software or firmware application on the client device 232 or on the APs 226, 228, or may be part of the operating system of the client device 232 or APs 226, 228.
In some implementations, the APs 226, 228 do not contain motion detection software and are not otherwise configured to perform motion detection in the space 201. Instead, in such an implementation, the operation of the motion detection system is performed on one or more of the client devices 232. In some implementations, the channel information may be obtained by the client device 232 by receiving wireless signals from the APs 226, 228 (or possibly from other client devices 232) and processing the wireless signals to obtain the channel information. For example, a motion detection system running on the client device 232 may utilize channel information provided by the client device's radio firmware (e.g., wi-Fi radio firmware) so that the channel information may be collected and processed.
In some implementations, the client devices 232 send requests to their respective APs 226, 228 to transmit wireless signals that may be used by the client devices as motion detectors to detect motion of objects in the space 301. The request sent to the respective AP 226, 228 may be a null data packet frame, a beam forming request, a ping, standard data traffic, or a combination thereof. In some implementations, the client device 232 is stationary when motion detection is performed in the space 201. In other examples, one or more of the client devices 232 may be mobile and may move within the space 201 during motion detection.
Mathematically, the signal f (t) transmitted from a wireless communication device (e.g., wireless communication device 204A in fig. 2A and 2B or APs 226, 228 in fig. 2C) may be described according to equation (1):
wherein omega n Representing the frequency of the nth frequency component of the transmitted signal c n Represents the complex coefficient of the nth frequency component, and t represents time. In the case where the transmission signal f (t) is being transmitted, the output signal r from the path k can be described according to the equation (2) k (t):
Wherein alpha is n,k An attenuation factor (or channel response; e.g., due to scattering, reflection, and path loss) representing the nth frequency component along path k, and phi n,k Representing the phase of the signal of the nth frequency component along path k. The received signal R at the wireless communication device can then be described as all output signals R from all paths to the wireless communication device k The sum of (t), which is shown in formula (3):
substituting formula (2) into formula (3) yields the following formula (4):
the received signal R at the wireless communication device (e.g., the wireless communication devices 204B, 204C in fig. 2A and 2B or the client device 232 in fig. 2C) may then be analyzed (e.g., using one or more motion detection algorithms) to detect motion, for example. For example, the received signal R at the wireless communication device may be transformed to the frequency domain using a Fast Fourier Transform (FFT) or other type of algorithm. The transformed signal may represent the received signal R as a series of n complex values One complex value of (a) is used for the corresponding frequency component (n frequencies omega n Where) each frequency component in the set. For frequency omega n The frequency component at which the complex value Y can be expressed in the equation (5) as follows n
Given frequency component omega n Complex value Y of (2) n Indicating the frequency component omega n The relative magnitude and phase offset of the received signal at that location. The signals f (t) may be repeatedly transmitted within a certain period of time, and a complex value Y may be obtained for each transmitted signal f (t) n . When an object moves in space, the channel response alpha due to space n,k Continuously changing, thus complex value Y n During which time it changes. Thus, the detected change in the channel response (and thus the complex value Y n ) Movement of the object within the communication channel may be indicated. In contrast, a stable channel response may indicate lack of motion. Thus, in some implementations, complex value Y for each of a plurality of devices in a wireless network may be processed n To detect whether motion has occurred in the space through which the transmission signal f (t) passes. The channel response may be expressed in the time domain or the frequency domain and a fourier transform or an inverse fourier transform may be used to switch between the time domain representation of the channel response and the frequency domain representation of the channel response.
In another aspect of fig. 2A, 2B, 2C, beamforming state information may be used to detect whether motion has occurred in the space traversed by the transmitted signal f (t). For example, beamforming may be performed between devices based on some knowledge of the communication channel (e.g., feedback properties generated by the receiver), which may be used to generate one or more steering properties (e.g., steering matrices) applied by the transmitter device to shape the transmit beam/signal in one or more particular directions. In some examples, a change in a steering or feedback attribute used in the beamforming process indicates a change in space accessed by the wireless signal that may be caused by the moving object. For example, motion may be detected by identifying significant changes in the communication channel over a period of time (as indicated by channel response, or steering or feedback properties, or any combination thereof).
In some implementations, for example, the steering matrix may be generated at the transmitter device (beamforming sender) based on a feedback matrix provided by the receiver device (beamforming receiver) based on channel sounding. Since the steering matrix and the feedback matrix are related to the propagation characteristics of the channel, these beamforming matrices change as the object moves within the channel. The variation of the channel characteristics is reflected in these matrices accordingly, and by analyzing the matrices, the motion can be detected and different characteristics of the detected motion can be determined. In some implementations, the spatial map may be generated based on one or more beamforming matrices. The spatial map may indicate a general direction of objects in space relative to the wireless communication device. In some cases, a "pattern" of beamforming matrices (e.g., feedback matrices or steering matrices) may be used to generate the spatial map. The spatial map may be used to detect the presence of motion in space or to detect the location of detected motion.
In some implementations, the output of the motion detection system may be provided as a notification of a graphical display on a user interface on the user device. In some implementations, the user device is a device for detecting motion, a user device assigned to a caretaker or emergency contact of a person in the space 200, 201, or any other user device communicatively coupled to the motion detection system to receive notifications from the motion detection system.
In some examples, the graphical display includes a plot of motion data indicative of a degree of motion detected by the motion detection system for each point in a series of points in time. The graphical display may display the degree of relative motion detected by the nodes of the motion detection system. The graphical display may assist the user in determining appropriate actions to take in response to the motion detection event, correlating the motion detection event with the user's observations or knowledge, determining whether the motion detection event is true or false, and so forth.
In some implementations, the output of the motion detection system may be provided in real-time (e.g., to an end user). Additionally or alternatively, the output of the motion detection system may be stored (e.g., locally on the wireless communication device 204, the client device 232, the APs 226, 228, or on a cloud-based storage service) and analyzed to reveal statistical information within a certain time frame (e.g., hours, days, or months). Examples of statistical information that may be stored and analyzed by the motion detection system to reveal within a certain time frame are at health monitoring, vital sign monitoring, sleep monitoring, etc. In some implementations, an alert (e.g., a notification, an audio alert, or a visual alert) may be provided based on the output of the motion detection system. For example, the motion detection event may be communicated to other devices or systems (e.g., security systems or control centers), designated caregivers, or designated emergency contacts based on the output of the motion detection system.
In some implementations, the wireless motion detection system may detect motion by analyzing components of wireless signals specified by the wireless communication standard. For example, the motion detection system may analyze standard headers of wireless signals exchanged in a wireless communication network. One such example is the IEEE 802.11ax standard, also known as "P802.11ax/D4.0, IEEE Draft Standard for Information Technology-Telecommunications and Information Exchange Between Systems Local and Metropolitan Area Networks-Specific Requirements Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment Enhancements for High Efficiency WLAN", available at https:// ieeeexplore. Ieeee. Org/document/8672643, and incorporated herein by reference in its entirety. In some cases, standard headers specified by other types of wireless communication standards may be used for motion detection.
In some implementations, the motion detection algorithm used by the wireless motion detection system utilizes the channel response (output of the channel estimation process) calculated by the wireless receiver (e.g., wi-Fi receiver). For example, the channel response calculated by the channel estimation process according to the Wi-Fi 6 standard may be received as an input to a motion detection algorithm. Channel estimation in the Wi-Fi 6 standard occurs at the PHY layer using PHY frames (also referred to as PPDUs) of the received wireless signals.
In some examples, a motion detection algorithm employed by the wireless motion detection system uses a channel response calculated from Orthogonal Frequency Division Multiplexing (OFDM) based PHY frames, including PHY frames generated by the Wi-Fi 6 standard. In some examples, an OFDM-based PHY frame may be a frequency domain signal having a plurality of fields, each field having a corresponding frequency domain signal. For such OFDM-based PHY frames, there are typically two types of PPDU fields that allow Wi-Fi receivers to estimate the channel. The first is the legacy training field and the second is the MIMO training field. Either or both fields may be used for motion detection. An example of a MIMO training field that may be used is a so-called "high efficiency long training field" called HE-PHY (e.g., in accordance with the IEEE 802.11ax standard, in the Wi-Fi 6 standard).
Fig. 3 shows an example PHY frame 300 including HE-LTFs. The example PHY frame 300 shown in fig. 3 is from the IEEE 802.11ax standard. In some cases, these and other types of PHY frames including HE-LTFs may be used for motion detection. As shown in fig. 3, an example PHY frame 300 includes a plurality of fields defined in the 802.11 standard: ext> Lext> -ext> STFext> (ext> legacyext> shortext> trainingext> fieldext>)ext>,ext> Lext> -ext> LTFext> (ext> legacyext> longext> trainingext> fieldext>)ext>,ext> Lext> -ext> SIGext> (ext> legacyext> signalext>)ext>,ext> RLext> -ext> SIGext> (ext> repeatedext> legacyext> signalext>)ext>,ext> HEext> -ext> SIGext> -ext> aext> (ext> highext> efficiencyext> signalext>)ext>,ext> HEext> -ext> STFext> (ext> highext> efficiencyext> shortext> trainingext> fieldext>)ext>,ext> multipleext> HEext> -ext> LTFsext>,ext> dataext>,ext> peext> (ext> packetext> extensionext>)ext>.ext> In some examples, the L-LTF field may be used to estimate a channel response, which may be provided as an input to a motion detection algorithm. The HE-LTF field provided as a MIMO training field may also be used to estimate the channel response that may be provided as an input to a motion detection algorithm.
In the example shown in fig. 3, the HE-LTF may have a variable duration and bandwidth, and in some examples, the PHY frame 300 divides the 20MHz channel into 256 frequency points (instead of the 64 used by the previous PHY frame version). Thus, the example HE-LTF in PHY frame 300 may provide four times better frequency resolution (e.g., as compared to earlier versions of PHY frames) because the individual points represent a frequency bandwidth of 78.125kHz instead of 312.5 kHz. Furthermore, the HE-LTF provides more contiguous subcarriers than other fields, and thus a wider contiguous bandwidth may be used for motion detection. For example, table I (below) shows the contiguous bandwidth and frequency resolution of the HE-LTF field (labeled "HE" in the table) compared to the legacy PHY fields (L-STF and L-LTF) and other MIMO training fields, e.g., high Throughput (HT) long training fields and Very High Throughput (VHT) long training fields.
TABLE I
In some IEEE 802.11 standards, the PHY layer is divided into two sublayers: PLCP sublayer (physical layer convergence procedure) and PMD sublayer (PHY medium dependent). The PLCP sublayer (physical layer convergence procedure) acquires data from the MAC layer and converts it into a PHY frame format. The format of the PHY frame is also referred to as PPDU (PLCP protocol data unit). The PPDU may include a field for channel estimation. The PMD sublayer (PHY medium dependent) provides a modulation scheme for the PHY layer. A number of different IEEE 802.11-based PHY frame formats are defined. In some examples, the wireless motion detection system uses information derived from OFDM-based PHY frames (e.g., frames described in the following standard documents: IEEE 802.11a-1999: legacy OFDM PHY; IEEE 802.11n-2009: ht PHY (high throughput); IEEE 802.11ac-2013: vht PHY (very high throughput); IEEE 802.11ax (draft 4.0, 3 months 2019): HE PHY (high efficiency)).
Other types of PHY layer data may be used and each PHY layer specification may provide its own PPDU format. For example, the PPDU format of the PHY layer specification may be found under a section entitled "< XXX > PHY specification" = = > "< XXX > PHY" = > "< XXX > PPDU format" in some IEEE 802.11 standards. The example PHY frame 300 shown in fig. 3 is an HE PHY frame provided by the ODFM PHY layer of the example 802.11 standard.
In some IEEE 802.11 standards (e.g., IEEE 802.11 a-1999), an OFDM PHY divides a 20MHz channel into 64 frequency cells. Modulation and demodulation are performed using 64-point complex Inverse Fast Fourier Transforms (IFFTs) and Fast Fourier Transforms (FFTs). In an example modulation process: the data bits are grouped (e.g., according to a QAM constellation), each group of bits being assigned to one of the subcarriers (or inter-frequency cells); according to the QAM constellation diagram, the bit group is mapped to complex numbers for each subcarrier; and a 64-point IFFT is performed to generate complex time-domain I and Q waveforms for transmission. In an example demodulation process: receiving complex I and Q time domain signals; performing 64-point FFT to calculate complex numbers for each subcarrier; according to the QAM constellation diagram, each subcarrier complex number is mapped into a bit; and bits from each subcarrier are reassembled into data. In a typical modulation or demodulation process, not all 64 subcarriers are used; for example, only 52 of the subcarriers may be considered valid for data and pilot, while the remaining subcarriers may be considered empty. The PHY layer specifications in the recently developed IEEE 802.11 standards utilize larger channel bandwidths (e.g., 40MHz, 80MHz, and 160 MHz).
Fig. 4 shows an example PHY frame 400 that includes a very high throughput long training field (also referred to as a "VHT-LTF"). The example PHY frame 400 shown in fig. 4 is from the IEEE 802.11ac standard. The draft publication of the IEEE 802.11ac standard was entitled "802.11ac-2013-IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements-Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications-Ampendment 4:Enhancements for Very High Throughput for Operation in Bands below 6GHz" in month 12 of 2018, which is available at https:// ieeeExplore.ieee.org/document/7797535, and is incorporated herein by reference in its entirety. In some cases, these and other types of PHY frames including VHT-LTFs may be used for motion detection.
As shown in fig. 4, an example PHY frame 400 includes a plurality of components defined in the 802.11 standard: ext> Lext> -ext> STFext>,ext> Lext> -ext> LTFext>,ext> Lext> -ext> SIGext>,ext> VHText> -ext> SIGext> -ext> Aext> (ext> veryext> highext> throughputext> signalext> Aext>)ext>,ext> VHText> -ext> STFext> (ext> veryext> highext> throughputext> shortext> trainingext> fieldext>)ext>,ext> VHText> -ext> LTFext> (ext> veryext> highext> throughputext> longext> trainingext> fieldext>)ext>,ext> VHText> -ext> SIGext> -ext> Bext> (ext> veryext> highext> throughputext> signalext> Bext>)ext>,ext> dataext>.ext> PPDUs of legacy, HT, VHT, and HE PHYs begin with legacy preambles including L-STF and L-LTF, as shown by the example PHY frame 400 in fig. 4. In some cases, the L-LTF may be used for channel estimation. VHT-LTFs, which have a wider bandwidth than L-LTFs and contain similar information, can be used for MIMO channel estimation. HT-LTF and VHT-LTF are very similar except that VHT-LTF allows higher order MIMO and allows 80MHz and 160MHz channels. These fields are advantageous for motion detection because they can provide a wider contiguous bandwidth and MIMO channel information. For MIMO channel estimation, nr×nc channel responses are typically calculated. This provides more information that facilitates motion detection. Fig. 5 shows an example MIMO device configuration 500 that includes a transmitter with Nr antennas and a receiver with Nc antennas. In the example of fig. 5, nr×nc channel responses may be calculated based on the HE-LTF or VHT-LTF of the PHY frame or another MIMO training component.
In some implementations, the wireless communication device calculates the channel response, for example, by performing a channel estimation process based on the PHY frame. For example, the wireless communication device may perform channel estimation based on the example PHY frame 300 shown in fig. 3, the example PHY frame 400 shown in fig. 4, or another type of PHY frame from the wireless signal.
In some examples, the channel information for motion detection may include a channel response generated by channel estimation based on the L-LTF in the PHY frame. The L-LTF in the 802.11ax standard may be identical to the LTF in the IEEE 802.11a-1999 standard. The L-LTF may be provided as an input to a 64-point IFFT in the frequency domain. Typically, only 52 of the 64 points are considered to be valid points for channel estimation; and the remaining points (points [ -32, -26) and (26, 31) are zero, as described in the IEEE 802.11a-1999 standard, the L-LTF may be a long OFDM training symbol comprising 53 subcarriers (including zero values at DC), the 53 subcarriers being modulated by the elements of the sequence L given below:
L -26,26 ={1,1,-1,-1,1,1,-1,1,-1,1,1,1,1,1,1,-1,-1,1,1,-1,1,-1,1,1,1,1,0,1,-1,-1,1,1,-1,1,-1,1,-1,-1,-1,-1,-1,1,1,-1,-1,1,-1,1,-1,1,1,1,1}
the example "L" vector shown above represents a complex frequency domain representation of the field at baseband (DC centered) and is described in IEEE 802.11a-1999 standard draft, page 13. The IEEE 802.11a-1999 standard draft is published in the literature entitled "802.11a-1999-IEEE Standard for Telecommunications and Information Exchange Between Systems-LAN/MAN Specific Requirements-Part 11:Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: high Speed Physical Layer in the 5GHz band" and is available at https:// ieeeexplore. Org/document/815305. The example "L" vector is considered "legacy" because it is part of the original OFDM PHY specification and is considered part of the legacy preamble. Therefore, in a later version of the specification (for the legacy long-term training field) it is called L-LTF.
In some examples, the channel information for motion detection may include a channel response generated by channel estimation based on one or more MIMO training fields (e.g., HE-LTF, HT-LTF, or VHT-LTF fields) in the PHY frame. The HE-LTF may be provided as an input to a 256-point IFFT in the frequency domain. For a typical HE-LTF, there are 241 significant points (e.g., instead of 52 as is conventionally the case). Each point in the HE-LTF represents a frequency range of 78.125kHz, while each conventional point represents a larger frequency range of 312.5 kHz. Thus, the HE-LTF may provide higher frequency resolution, more frequency domain data points, and greater frequency bandwidth, which may provide more accurate and higher resolution (e.g., higher temporal and spatial resolution) motion detection. An example of HE-LTF described on page 561 of the IEEE 802.11ax standard draft is as follows:
In a 20MHz transmission,the 4x HE-LTF sequence transmitted on subcarriers[-122:122]is given by Equation(27-42).
in some examples, the channel response may be estimated at the receiver device by performing an FFT on the received time domain sequences (e.g., the example L-LTF and HE-LTF sequences shown above) and dividing by the expected result [ CH (N) =rx (N)/L (N) ]. The 64-point FFT inter-cell 600 in the upper part of fig. 6 shows the resulting spectrum (20 MHz and 40MHz channels) that can be measured from the L-LTF in an example PHY frame. The 128-point FFT interval 650 in the lower part of fig. 6 shows the resulting spectrum that can be measured from the HE-LTF in the example PHY frame for the same 20MHz channel. As shown in fig. 6, the HE-LTF may provide higher frequency resolution (more points in the same frequency bandwidth), a greater number of frequency domain data points (more cells), and a greater frequency bandwidth.
In some aspects described herein, messages initiated by protocols in higher layers (e.g., layers 1 and 2 above the OSI model) may be used to elicit MIMO transmissions from a wireless communication device. MIMO wireless signals may be used for motion detection or other types of wireless sensing applications. In some implementations, the MIMO wireless signal includes a MIMO training field that may be used for motion detection. In some aspects, HT-LTF, VHT-LTF, or HE-LTF fields in a PHY frame of a wireless transmission according to the IEEE Wi-Fi standard may be used for motion detection. Such wireless signals may be transmitted through space for a period of time, e.g., from one wireless communication device to another. A MIMO training field (e.g., an HT-LTF, VHT-LTF, or HE-LTF field) may be identified in the PHY frame of each wireless signal, and channel information may be generated based on the corresponding MIMO training field. The channel information may then be used for wireless sensing of the space during the time period (e.g., to detect movement of the subject, to detect respiration, to detect gestures, etc.).
Fig. 7 is a diagram illustrating a typical representation of an Open Systems Interconnection (OSI) model 700. As shown in fig. 7, the typical OSI network model defines seven layers: (layer 1) physical layer, (layer 2) data link layer, (layer 3) network layer, (layer 4) transport layer, (layer 5) session layer, (layer 6) presentation layer, (layer 7) application layer. In some cases, the network model may define additional or different layers.
As shown in fig. 7, the OSI layers provide the specified functions and define the specified data objects. User applications operating on the device (e.g., operating in layer 6 and/or layer 7) may communicate using standard network features represented in OSI model 700; the user application may initiate such communications by interacting with an Operating System (OS) socket library in the session layer. As shown in fig. 7, the OS socket inventory resides in layer 5 and has nearly the same API on all modern operating systems (e.g., linux, windows, android, OSX, etc.) due to standardization. Each session may be identified by a "socket handle" returned by the operating system to the user application, and the user application may use the socket handle when interacting with the socket API.
In the example OSI model 700 shown in fig. 7, the transport layer (layer 4) defines the manner in which multiple applications talk to each other. There are many transport layer protocols used; the most common are: TCP (transmission control protocol) and UDP (user datagram protocol). The application may select which protocol to use for communication through the socket API. The transport layer message and corresponding content are identified by a "port number," which is typically a 16-bit value. Many standardized applications have dedicated port numbers; for example, web servers typically communicate on port 80, and the OS socket library knows to pass data received on port 80 to the socket handle belonging to the web server.
In the example OSI model 700 shown in fig. 7, below the transport layer (layer 4) is the network layer (layer 3). The network layer provides Internet Protocol (IP) resources that primarily allow grouping of multiple devices into a logical network. Network layer services generally allow for the identification of both logical networks and physical devices, and also provide a mechanism (typically referred to as routing) for different networks to communicate with each other. For example, the network layer may include internet protocol version 4 (IPv 4), internet protocol version 6 (IPv 6), or another IP version. Internet Protocol (IP) may be used as a communication protocol to relay data between devices and across network boundaries (e.g., on the internet). In some examples, the devices are identified by a logical 32-bit address (e.g., in IPv 4) or a 128-bit address (e.g., IPv 6) in the network layer. Both IPv4 and IPv6 addresses include network portions and device portions that are determined based on standardized criteria.
In the example OSI model 700 shown in fig. 7, below the network layer (layer 3) are the data link layer (layer 2) and the physical layer (layer 1). The data link layer (also referred to as the MAC layer) handles coordination of how multiple devices communicate using a shared medium (e.g., a shared wireless channel for Wi-Fi or another form of shared medium). At the MAC layer, each device is identified by a 48-bit MAC address. In Wi-Fi networks, the network layer and the data link layer are defined by the IEEE 802.11 standard. The physical layer generates PHY frames for communication between devices.
In some systems, a motion detection algorithm employed by a wireless motion detection system uses a channel response calculated from Orthogonal Frequency Division Multiplexing (OFDM) based PHY frames, including frames defined by the IEEE 802.11 standard for Wi-Fi networks. For OFDM modulation, the Wi-Fi signal contains multiple fields that can be used to calculate a channel estimate or response. First, there are legacy LTFs (long training fields), which are typically present in every Wi-Fi message. Second, there are MIMO LTFs (HT-LTFs, VHT-LTFs, HE-LTFs). For devices supporting HE/VHT/HE mode, MIMO fields typically exist for longer transmissions, and these fields consume talk time and may reduce efficiency for short transmissions.
In some examples, in order for the motion detection system to measure the channel response, the client/leaf device needs to send a wireless message (e.g., a message addressed to an access point or another device in the Wi-Fi network). The IEEE 802.11MAC layer standard contains a defined mechanism that states: if the device receives the data message, the device acknowledges that the data message was received correctly. The mechanism may provide a form of "probe"/"illumination" because it allows a MAC frame (null data frame) of 0 payload length to be sent to any Wi-Fi enabled device (knowing that the device will return with an ACK message). In some systems, the limitation of the null data/ACK mechanism is that the standard defines that an ACK must be sent using the "legacy" mode, because switching to MIMO mode for short transmissions is not efficient. In such a system, wireless messages sent according to the IEEE 802.11 standard do not provide MIMO estimation unless the client/leaf device generates a transmission large enough for the radio to utilize the MIMO transmission mode.
While some systems may use a legacy training field for motion detection, other systems may not support capturing legacy estimates due to hardware or other constraints, and thus only provide the ability to extract MIMO estimates. Thus, some systems are limited in the following sense: for example, higher layers in the OSI model may be required to elicit MIMO channel estimation when there is no standardization mechanism in the MAC/PHY layer and clients/leaves do not necessarily support non-standard components. In some instances, utilizing higher layers in the OSI model may reduce efficiency, for example, if more data transmission overhead is required to generate the channel estimate.
Motion detection algorithms may also benefit from MIMO estimation (e.g., as opposed to traditional estimation) because multiple antennas on both the transmit and receive sides introduce spatially diverse elements, each antenna illuminating or sensing a slightly different view or perspective of the environment due to the physical separation of the antennas. To obtain these and other benefits provided by having MIMO estimation, in some cases, mechanisms that use standard components in higher layers in the OSI model may be utilized to elicit MIMO channel estimation.
In some aspects, the systems and techniques described herein provide a solution for using higher layers in the OSI model to elicit MIMO channel estimation, e.g., using components in the MAC/PHY layer specification to elicit client/leaf nodes to generate messages containing MIMO training fields. This solution can take advantage of the fact that: higher layers encapsulate their messages into the payload of a MAC/PHY "data frame" that may contain the MIMO field to be transmitted. Thus, by using existing standard components or protocols within the network/transport layer to bring up the client/leaf nodes, the MIMO training field can be obtained from the device.
Fig. 8 is a diagram showing an example frame format of three layers of a typical OSI model. In particular, the diagram in fig. 8 shows the frame format of TCP messages generated by the transport layer, IPv4 messages generated by the network layer, and 802.11 messages generated by the MAC layer. As shown in fig. 8, the OSI model works based on the concept of "encapsulation" for message transmission, where data provided from the upper layers is "encapsulated" into the payload field of a message. For reception, the situation is the opposite. In the example of fig. 8, data provided in the network layer is included in the payload field of the message in the MAC layer, and data provided in the transport layer is included in the payload field of the message in the network layer.
In some cases, a wireless communication device may use one or more layers above the MAC layer (e.g., a transport layer, a network layer, or another layer above the data link layer) to elicit MIMO transmissions from another wireless communication device. For example, an Access Point (AP) in a wireless network (e.g., a mesh node or another type of AP) may generate and transmit a network layer message or a transport layer message that causes a client device to transmit a response using MIMO transmission. The following discussion and the processes shown in fig. 9, 10, 11A, 11B, 11C, 12A, 12B, and 13 provide examples of systems and techniques that may be used to initiate or otherwise elicit client data transmissions (e.g., MIMO transmissions) for motion detection; other systems and techniques may be used in some instances.
In some examples, the software-implemented process may utilize components in layers above the MAC layer (in some cases, existing components) to cause the client/leaf device to send data. Such processing may be used to enable motion detection functionality using the MIMO field without the need to add or modify or add any software on the client/leaf device.
In some implementations, the address discovery process is used to obtain an address for communicating with a layer above the MAC layer. For example, the channel estimate may be defined at the MAC/PHY layer, and the identity of the client/leaf device may be given by its MAC address (e.g., a 48-bit MAC address). In some instances, knowledge of the upper layer logical address (e.g., IP address) of the device may be required for higher layer transmissions to the device, and the address discovery process may be used to obtain the upper layer logical address (e.g., IP address) of the device from the lower layer physical address (e.g., MAC address) of the device. In at least some contexts, the operation of obtaining an upper layer logical address (e.g., an IP address) of a device from a lower layer physical address (e.g., a MAC address) of the device requires a different (typically more difficult) process than the normal process of obtaining the lower layer physical address (e.g., a MAC address) given the upper layer logical address (e.g., IP address).
Fig. 9 is a flow chart illustrating an example process 900 of looking up an upper logical address (e.g., an IPv4 address or an IPv6 address) from a lower physical address (e.g., a MAC address). Process 900 may include additional or different operations, and the operations shown in fig. 9 may occur in the order shown or in another order. In some cases, one or more operations shown in fig. 9 are implemented as a process including a plurality of operations, sub-processes for other types of routines. In some cases, operations may be combined, performed in another order, performed in parallel, iterated, or otherwise repeated or performed in another manner. The process 900 may be performed by the example wireless communication device 102A, 102B, 102C shown in fig. 1, the example wireless communication device 204A, 204B, 204C shown in fig. 2A and 2B, any of the example devices shown in fig. 2C (e.g., the client device 232 or the AP devices 226, 228), or another type of device.
In some examples, the upper layer logical address obtained from process 900 may be encapsulated in a payload field of the lower layer message. For example, in implementations that use process 900 to obtain a network address, the network address may be encapsulated in a payload field of a MAC layer message (e.g., as shown in fig. 8). As another example, in an implementation of process 900 for obtaining a transport layer address, the transport layer address may be encapsulated in a payload field of a network layer message (e.g., as shown in fig. 8). In some examples, the wireless communication device may create a cache of address mappings. The cache is stored on the wireless communication device and shows a mapping between lower layer physical addresses (e.g., MAC addresses) and upper layer logical addresses (e.g., network addresses). The IPv4 protocol or IPv6 protocol may operate at the network layer and process 900 queries the cache (which may contain an IPv4 neighbor table or an IPv6 neighbor table depending on which protocol operates at the network layer) to determine the network address from a lower layer physical address (e.g., MAC address).
At 902, the cache is queried to determine if it contains an IPv4 neighbor table. In some implementations, the IPv4 neighbor table may also be referred to as an IPv4 Address Resolution Protocol (ARP) table. At 904, process 900 determines whether the IPv4 neighbor table is stored in a cache. At 906, in response to determining that the IPv4 neighbor table is stored in the cache, a network address (e.g., an IPv4 address) is obtained from the cache, and an Internet Protocol (IP) variable for the IPv4 address is set and initialized. As an example, the fields of the network layer packet shown in fig. 8 are set and initialized at 906.
At 908, responsive to determining that the IPv4 neighbor table is not stored in the cache, the cache is queried again to determine if it contains an IPv6 neighbor table. At 910, process 900 determines whether an IPv6 neighbor table is stored in a cache. At 912, in response to determining that the IPv6 neighbor table is stored in the cache, a network address (e.g., an IPv6 address) is obtained from the cache, and an IP variable for the IPv6 address is set and initialized.
At 914, responsive to determining that the IPv6 neighbor table is not stored in the cache, the network is scanned. As an example, at 914, process 900 iterates through IPv4 and IPv6 link-local addresses to determine whether one or more of the IPv4 and IPv6 link-local addresses elicit a response. At 916, process 900 determines whether an error has occurred. In some examples, an error occurs when the scan performed at 914 does not elicit any response. At 918, in response to determining that an error has occurred, a delay of a predetermined time (e.g., in the range of from about 5 seconds to about 15 seconds) occurs before the process 900 iterates from 902. In the example shown in fig. 9, 10 seconds is depicted as a delay, but in other examples another delay may be used. At 920, in response to determining that no error has occurred (e.g., the scan-out response performed at 914), the cache is updated at 920 to reflect a mapping between the underlying physical address (e.g., the MAC address) and the IPv4 or IPv6 link-local address that provided the response. From 920, process 900 iterates from 902.
One example of a technique that may be used to derive MIMO transmissions from a wireless communication device is commonly referred to as "ICMP Ping". In some cases, ICMP Ping processing is defined in the network layer and there are existing off-the-shelf applications to generate such messages (e.g., ping6, fping). ICMP Ping may be specifically defined to provide a response at a given request and may be used for network connection troubleshooting or other purposes. The ICMP Ping process may be built locally into the network stack and may provide a mechanism for client/leaf devices to generate data transmissions in some instances. ICMP Ping may utilize IPv4, IPv6 or another similar network layer protocol. However, some devices disable ICMP (for security, privacy, or other reasons). In the event ICMP is disabled, the device receiving the ping message may not generate a response and therefore may not elicit a wireless transmission capable of producing a channel response measurement. In some cases, existing ICMP Ping and related processes may be modified to provide advantages for wireless motion detection systems. For example, the ICMP Ping process shown in fig. 11A, 11B, and 11C is tailored to send periodic requests, may provide a feedback mechanism to ensure received responses, and may provide better data efficiency (e.g., by eliminating padding and unnecessary data inserted by off-the-shelf applications). Another type of ICMP Ping process may be used.
Another example technique that may be used to derive MIMO transmissions from wireless communication devices is referred to herein as "ARP Ping," which may utilize aspects of a standardized ARP exchange mechanism in some implementations. Address Resolution Protocol (ARP) is a protocol typically defined in the network layer; there are existing applications (e.g., arping) for generating duplicate standardized ARP exchanges. In many network environments, communication is not possible without ARP, and APR is considered mandatory for every device. For example, ARP may be required for all IP networking devices. The device may use ARP to obtain the data link layer address of another device (which may be needed for communication). The standardized ARP exchange process is typically used to find the MAC address of a device that holds a given network layer (IP) address. In some systems, there are four utilized addresses: (1) sender network layer address, (2) sender MAC layer address, (3) destination network layer address, (4) destination MAC layer address. Both sender addresses (1 and 2) are known to the requesting party because both are local addresses of the requesting device. When the destination network layer address (3) is known, but the destination MAC layer address (4) is unknown, a standardized ARP exchange may be used. The standardized ARP exchange sends a broadcast MAC frame (destination MAC address=ff: ff: ff: ff: ff), meaning that every device on the network receives the message. However, only devices that maintain a given target network layer (IP) address may respond and the source MAC address may be extracted from the response. In some examples, the exchange may create a request/response encapsulated within a MAC/PHY MIMO data transmission from the responding device. However, in other examples, the standardized ARP exchange does not elicit a MIMO transmission from the responding device. For example, some modern wireless communication devices may respond to standardized ARP exchange requests using conventional MAC/PHY data transmissions, or may be cached and not actually transmitted.
As described above, the standardized ARP request is a broadcast layer 2 transmission (identified with a destination MAC address field set to ff: ff: ff: ff) that generally requires all devices belonging to the same logical network to receive the message. This means that all layer 2 network devices (such as switches, bridges, wireless access points, etc.) are required to send ARP requests to all clients and may result in a single request flooding the entire network. Flooding the entire network for the purpose of eliciting a single device to send a response for motion sensing is undesirable and may introduce negative effects (e.g., power consumption, call efficiency, or wired network resources). These negative effects may affect the network in a global scope, whether or not a particular client is engaged in the motion detection system. In some cases, the ARP Ping process described herein may be implemented in a more efficient manner and avoid the negative effects described above. For example, the ARP Ping process shown in fig. 13 may send ARP requests with known destination MAC addresses (and no broadcast MAC) to eliminate the broadcast nature of the request. For example, the ARP request may be addressed to the device from which the MIMO transmission is sought. Another type of ARP Ping process may be used.
Another example technique that may be used to derive MIMO transmissions from a wireless communication device is referred to herein as "TCP Ping," which may utilize aspects of a standardized TCP handshake mechanism in some implementations. In some cases, TCP Ping may be used to probe a wireless communication device to obtain a wireless signal that may be used by a motion detection system. The TCP Ping process may be used to elicit MIMO transmissions from client/leaf devices in various contexts, including scenarios where the client/leaf device is configured not to respond to ICMP requests (e.g., devices without enabled ICMP), and scenarios where ARP responses from the client/leaf device result in traditional Wi-Fi transmissions or in cached responses. The Transmission Control Protocol (TCP) is typically defined in the transport layer; TCP generally operates as a connection-oriented protocol, meaning that data exchange typically occurs in both directions, which can be leveraged to elicit MIMO transmissions from devices. An example TCP Ping process is shown in fig. 12A, 12B. Another type of TCP Ping process may be used.
In some contexts, a typical execution of a standardized TCP handshake begins with a client "requesting" to initiate a connection with a host. To initiate the transaction, the client populates the SRC and DST port fields and sets the SYN flag. The host may do one of three actions: (1) The host may respond by setting an ACK flag to accept the request; (2) The host may reject the request by setting the RST flag to respond; or (3) the host may do nothing but just discard the frame. If there is an application on the host listening for a given port and the connection has been accepted, a response is received from act (1). If there is no application listening on the host for a given port, or the port may be blocked, a response is typically received from action (2). And act (3) typically occurs if there is a firewall with explicit instructions to discard any transmissions received by a particular host/port. Technically, the result of action (1) or action (2) may create a ping request/response action that can produce a MIMO transmission. However, in some instances, action (1) is a less desirable response because the client requires additional message exchanges to properly close the connection (thus consuming more talk time and reducing efficiency).
In some implementations, the TCP Ping process shown in FIGS. 12A, 12B performs a "port scan" that identifies a set of ports that respond with the result of act (2). For example, the "port scan" may be performed in the same manner as the initial steps in the standardized TCP handshake, or in another manner. After the ideal port list has been obtained, one or more of the ports may be targeted for the TCP Ping process. In some implementations, a delay may be added between requests during the scan phase (without delay, the request may eventually be discarded); the scan phase of the destination port need not be linear (ports 1 to 65535) (e.g., a 16-bit maximum length PR sequence may be used to pick up the destination port); and the TCP source port may be random (e.g., a 16-bit maximum length PR sequence may be used for this). In some cases, it may be sufficient to scan and cycle through 16 ports that respond to SYN with RST. This may be true if the source port is randomized in a way that is difficult to detect. A new set of 16 ports may also be scanned periodically, however this may not be required in all cases (e.g. when ping with a period of 100 ms).
Fig. 10 is a state machine diagram illustrating an example process 1000 for deriving a MIMO transmission from a wireless communication device. Process 1000 may include additional or different operations, and the operations shown in fig. 10 may occur in the order shown or in another order. For example, in the example of fig. 10, ICMP Ping is followed by TCP Ping, which is followed by ARP Ping. However, in other implementations, any sequence or order of Ping processing may be used. In some cases, one or more operations shown in fig. 10 are implemented as a process including a plurality of operations, sub-processes for other types of routines. In some cases, operations may be combined, performed in another order, performed in parallel, iterated, or otherwise repeated or performed in another manner. Process 1000 may be performed by the example wireless communication devices 102A, 102B, 102C shown in fig. 1, the example wireless communication devices 204A, 204B, 204C shown in fig. 2A and 2B, any of the example devices shown in fig. 2C (e.g., client device 232 and AP devices 226, 228), or another type of device.
An implementation of the example process 1000 shown in fig. 10 may utilize ICMP Ping, TCP Ping, IPv4 ARP Ping, IPv6 neighbor discovery protocol, or a combination of multiple types of Ping. Process 1000 may be modified to utilize additional or different types of Ping processes.
The example process 1000 shown in fig. 10 combines multiple different ping mechanisms into a single protocol that can be controlled by a state machine. In some cases, process 1000 may select the best ping mechanism that may be used to generate channel information to be used for motion detection by having the mechanisms provide feedback to the state machine (as shown in fig. 10). In some cases, feedback within each sub-process is used to help the state machine determine which mechanism to use is optimal and may ensure that a reliable mechanism is selected. In the example shown in fig. 10, three ping mechanisms each provide feedback to the motion detection system so that the motion detection system can select one of the mechanisms based on the feedback (e.g., the mechanism that provides the best data for motion detection) and the motion detection system can select a different mechanism for each client/leaf node used by the motion detection system.
At 1002, a network layer address of a device is determined. For example, the process 900 shown in FIG. 9 or another type of process may be used to obtain an IP address for a device.
At 1010, 1012, and 1014, ICMP Ping processing is performed. As shown in fig. 10, the ICMP Ping process includes setting an ICMP Ping operation at 1010, an ICMP Ping operation at 1012, and stopping the ICMP Ping operation at 1014. The ICMP Ping process may include additional or different operations. In some examples, the ICMP Ping process derives a MIMO transmission from a device (e.g., a device corresponding to the IP address found at 1002). In some cases, the ICMP Ping process does not elicit MIMO transmissions from the device, and process 1000 proceeds to the TCP Ping process. In some implementations, the following two types of feedback may be used to make the decision whether to proceed to the TCP Ping process: (1) In response to the reception delay, and (2) a Channel State Information (CSI) generation rate. One or both of these criteria may be used to evaluate the ICMP Ping process and, if the result is insufficient, optionally switch to the TCP Ping process.
At 1020, 1022, and 1024, TCP Ping processing is performed. As shown in fig. 10, the TCP Ping process includes a set TCP Ping operation at 1020, a TCP Ping operation at 1022, and a stop TCP Ping operation at 1024. The TCP Ping process may include additional or different operations. In some examples, the TCP Ping process derives a MIMO transmission from a device (e.g., a device corresponding to the IP address found at 1002). In some cases, the TCP Ping process does not elicit a MIMO transmission from the device, and process 1000 proceeds to the ARP Ping process. In some implementations, the following two types of feedback may be used to make the decision whether to proceed to ARP Ping processing: (1) In response to the reception delay, and (2) a Channel State Information (CSI) generation rate. One or both of these criteria may be used to evaluate the TCP Ping process and, if the result is insufficient, optionally switch to the ARP Ping process.
ARP Ping is performed at 1030, 1032, and 1034. As shown in fig. 10, in the example where the IP address is an IPv4 address, the ARP Ping process includes a set IPv4 ARP Ping operation at 1030, an IPv4 ARP Ping operation at 1032, and a stop IPv4 ARP Ping operation at 1034. In the example where the IP address is an IPv6 address, the ARP Ping process includes a set IPv6 neighbor discovery protocol operation at 1030, an IPv6 neighbor discovery protocol operation at 1032, and a stop IPv6 neighbor discovery protocol operation at 1034. ARP Ping processing may include additional or different operations. In some examples, ARP Ping processes elicit a MIMO transmission from a device (i.e., a device corresponding to the IP address found at 1002). In some cases, the ARP Ping process does not elicit a MIMO transmission from the device, and process 1000 proceeds to 1040. In some implementations, the decision whether to proceed to operation 1040 may be made using two types of feedback: (1) In response to the reception delay, and (2) a Channel State Information (CSI) generation rate. One or both of these criteria may be used to evaluate the ARP Ping process and optionally reiterate another mechanism if the result is insufficient. At 1040, the neighbor cache is flushed, and process 1000 proceeds to another iteration starting at 1002.
Fig. 11A shows a flow chart representing an example process 1100 of setting ICMP ping. Fig. 11B shows a flowchart of an example process 1110 of stopping ICMP ping. Fig. 11C shows a flowchart representative of an example process 1120 of performing ICMP ping. The various processes 1100, 1110, 1120 may include additional or different operations, and the operations shown in fig. 11A, 11B, and 11C may occur in the order shown or in another order. In some cases, one or more of the operations shown in fig. 11A, 11B, and 11C are implemented as a process including a plurality of operations, sub-processes for other types of routines. In some cases, operations may be combined, performed in another order, performed in parallel, iterated, or otherwise repeated or performed in another manner. The processes 1100, 1110, 1120 may be performed by the example wireless communication devices 102A, 102B, 102C shown in fig. 1, the example wireless communication devices 204A, 204B, 204C shown in fig. 2A and 2B, any of the example devices shown in fig. 2C (e.g., the client device 232 and the AP devices 226, 228), or by another type of device.
11A, 11B, and 11C may be used, for example, to perform operations 1010, 1014, 1012, respectively, in the example process 1000 shown in FIG. 10. In some implementations, the example processes 1100, 1110, 1120 shown in fig. 11A, 11B, and 11C may be used in another context. In some implementations, the ICMP Ping process represented in fig. 11A, 11B, and 11C may provide advantages such as those described above for applications with wireless motion detection systems.
The example process 1100 in fig. 11A illustrates the initialization logic of the ICMP Ping process. In some implementations, the process 1100 initializes the computing resources and message fields required by the ICMP Ping process 1110. The example process 1100 includes determining whether the timer has been successfully set (at 1101). In some implementations, setting the timer includes initiating an Operating System (OS) level call, thereby requesting the OS to set the timer handle. In some instances, there may be no computing resources to set the timer handle, and the OS may return an error message indicating the lack of such resources, indicating that the timer has not been successfully set. Conversely, when there are sufficient computing resources to set the timer handle, the OS may return a message indicating a successful setting of the timer handle.
In response to determining that the timer has not been successfully set, the ICMP Ping mechanism may be terminated (e.g., by performing process 1110 shown in fig. 11B). Conversely, in response to determining that the timer has been successfully set, a determination is made as to whether the socket has been successfully opened (at 1103). In some implementations, setting the socket includes initiating an OS level call, thereby requesting the OS to set the socket handle. In some instances, there may be no computing resource to set the socket handle, and the OS may return an error message indicating the lack of such resources, indicating that the socket has not been successfully set. Conversely, when there are sufficient computing resources to set the socket handle, the OS may return a message indicating successful setting of the socket handle.
In response to determining that the socket has not been successfully opened, the ICMP Ping mechanism may be terminated (e.g., by performing process 1110 shown in fig. 11B). In contrast, in response to determining that the socket has been successfully opened, process 1100 proceeds to initialize the original ICMP echo request frame (e.g., at 1105). At 1105, the fields required for the icmp ping message are initialized and placed in the payload of an IPv4 or IPv6 frame.
At 1107, the sequence counter is initialized to zero. The sequence counter tracks the number of ICMP ping messages sent and each ICMP ping message matches a corresponding sequence number (e.g., as described in the example of fig. 11C). At 1109, CSI rate feedback is initialized. In some implementations, the device that elicits the MIMO transmission may provide CSI to the device that sent the ICMP ping message. By initializing CSI rate feedback at 1109, CSI may be obtained from the MIMO transmission elicited by the ICMP ping message, and the rate at which CSI is being received may be determined to determine whether to receive CSI at a rate fast enough to accurately or reliably detect motion in spaces 200, 201.
The example process 1110 in FIG. 11B illustrates termination logic of the ICMP ping process. In some implementations, the process 1110 releases the computing resources requested in the initialization process 1100. At 1111, the timer (e.g., requested at 1101) is disabled, and at 1113, the socket (e.g., requested at 1103) is closed. In some implementations, the timer is disabled and the socket is closed by indicating to the OS that an OS-level call for these resources is no longer needed.
Example process 1120 in fig. 11C illustrates a process of ICMP ping. In some implementations, ICMP ping includes sending a predetermined number of consecutive ICMP ping messages (e.g., using operations at 1121, 1123, 1125, 1127, 1129, 1131). In some examples, the predetermined number of consecutive ICMP ping messages may be referred to as an ICMP ping message block. The number of consecutive ICMP ping messages within a block (referred to as the "block size") may be an application specific adjusted parameter, e.g. 64 ICMP ping messages. The "block size" may also be set based on the period of time that the space 200, 201 is sampled for motion. In some implementations, the spaces 200, 201 are sampled every 100 milliseconds, and a reasonable "block size" is equal to 64 ICMP ping messages. After the ICMP ping message block has been sent, process 1120 analyzes the received response (e.g., using operations at 1133, 1135, 1137, 1139) to determine whether a MIMO transmission has been successfully elicited by the ICMP ping message block, or whether another ICMP ping message block needs to be sent.
At 1121, the ICMP ping message is updated. In some examples, the ICMP ping message may be referred to as an echo request frame, and updating the ICMP ping message may include updating a field (e.g., a checksum field) of the ICMP ping message. At 1123, wait for a timer tick (tick). The timer tick is allowed to elapse for a predetermined period of time (e.g., about 100 milliseconds) so that a wireless signal (e.g., a MIMO transmission) may be received in response to a previously sent ICMP ping message. In some examples, the predetermined period of time may be equal to a period of time that the space 200, 201 is sampled for motion. After the timer tick has occurred, at 1125, the timestamp of the ICMP ping message updated at 1121 is determined. In some examples, the timestamp of the ICMP ping message matches the current sequence number. At 1127, an ICMP ping message updated at 1121 is sent. In some implementations, the ICMP ping message may be referred to as an ICMP echo request.
At 1129, a determination is made as to whether a predetermined number of consecutive ICMP ping messages (e.g., "block size") have been sent. In response to determining that the predetermined number of consecutive ICMP ping messages have not been sent, a sequence counter is incremented (at 1131), and process 1120 iterates from 1121. A feedback or check mechanism is performed in response to determining that a predetermined number of consecutive ICMP ping messages have been sent.
In example process 1120, a feedback or check mechanism (e.g., including operations 1133, 1135, 1137, 1139) is performed after the ICMP ping message block has been sent. At 1133, the time stamp of the received response is processed to determine the difference between the time at which the corresponding ICMP ping message was sent (e.g., obtained from the time stamp associated with the ICMP ping message) and the time at which the corresponding response of the message was received. If the time difference associated with any ICMP ping message within the ICMP ping message block is greater than the threshold, then the entire ICMP ping message block is deemed to be a failed block. The failure logic may be implemented within operation 1133 that processes the timestamp of the received response.
At 1135, a determination is made as to whether the number of consecutive failed blocks is greater than a failure threshold number. In the example shown in fig. 11C, the failure threshold number is depicted as 10, but in other examples another integer threshold number may be used. A determination that the number of consecutive failed blocks is greater than the failure threshold number may indicate that repeated ICMP ping message blocks failed to elicit successful MIMO transmissions from the wireless communication device. Thus, in response to determining that the number of consecutive failed blocks is greater than the failure threshold number, the ICMP Ping mechanism may be terminated to facilitate attempting another type of mechanism.
In response to determining that the number of consecutive failed blocks is not greater than the failure threshold number, a secondary feedback check is performed. The secondary feedback check is referred to as CSI rate feedback (CSI rate FB) in fig. 11C (e.g., in operations 1137 and 1139). The checks made at 1137 and 1139 determine the rate at which MIMO transmissions (including CSI) are being received in response to the ICMP ping message block. If the ICMP Ping response is encapsulated by the client/leaf device in a MAC data frame that does not contain a MIMO training field, the response time may pass the check at 1135, but without the MIMO training field, there may be no CSI output from the radio. Thus, a secondary check at 1137 and 1139 may be used to ensure that the ICMP ping message block elicits a response containing the MIMO training field.
At 1137, a determination is made as to whether CSI rate feedback is enabled, and if so (at 1139) the following determination is made: whether the average CSI rate is greater than or equal to twice the period during which the space 200, 201 is sampled for motion. Determining that the average CSI rate is greater than or equal to twice the period of sampling the space 200, 201 may indicate that MIMO transmissions (including CSI) are not received at a rate fast enough to accurately or reliably detect motion in the space 200, 201. Thus, in response to determining that the average CSI rate is greater than or equal to twice the period of sampling the space 200, 201, the ICMP Ping mechanism may be terminated to facilitate attempting another type of mechanism. Conversely, if CSI rate feedback is not enabled, or if the average CSI rate is less than twice the period of space 200, 201, then the sequence counter is incremented (at 1131) and process 1120 iterates from 1121.
Fig. 12A shows a flow chart representing an example process 1200 of setting TCP Ping. Fig. 12B shows a flowchart representing an example process 1210 of performing TCP Ping. The respective processes 1200, 1210 may include additional or different operations, and the operations shown in fig. 12A and 12B may be performed in the order shown or in another order. In some cases, one or more of the operations shown in fig. 12A and 12B are implemented as a process that includes multiple operations, sub-processes for other types of routines. In some cases, operations may be combined, performed in another order, performed in parallel, iterated, or otherwise repeated or performed in another manner. Processes 1200 and 1210 may be performed by the example wireless communication devices 102A, 102B, 102C shown in fig. 1, the example wireless communication devices 204A, 204B, 204C shown in fig. 2A and 2B, any of the example devices shown in fig. 2C (e.g., client device 232 and AP devices 226, 228), or another type of device.
The example processes 1200, 1210 illustrated in fig. 12A, 12B may be used, for example, to perform operations 1020, 1022 in the example process 1000 illustrated in fig. 10. In some implementations, the example processes 1200, 1210 shown in fig. 12A, 12B may be used in another context.
The example process 1200 determines the number of valid TCP ports in the network, obtains a valid local interface IP address, and initializes the computing resources and message fields required for the TCP Ping process 1210. The example process 1200 includes scanning a network for TCP ports (at 1201). In some implementations, the network is scanned for TCP ports by sending TCP packets with a Synchronization (SYN) flag set to each port identifier. For example, fig. 8 shows a TCP packet with various fields (including fields for various flags). The SYN flag depicted in the example of fig. 8 may be set in a TCP packet sent to each port identifier. In some examples, the port identifier is a 16-bit identifier and the TCP packet with the SYN flag set is sent to each unique 16-bit identifier. A valid TCP port may respond to a TCP packet with a SYN flag set with a TCP packet with a Reset (RST) flag set. For example, the RST flag depicted in the example of fig. 8 may be set in a TCP packet sent in response. At 1203, a determination is made as to whether there is more than one valid TCP port. In some implementations, the number of valid TCP ports is determined by the number of TCP packets received with a RST flag set.
In response to determining that there is less than or equal to one valid TCP port, the TCP ping setting is terminated (e.g., to facilitate another type of mechanism). In contrast, in response to determining that there is more than one valid TCP port, a determination is made (at 1205) as to whether the timer has been successfully set. In some implementations, an OS level call similar to the OS level call described for operation 1101 may be used to determine whether the timer has been successfully set.
In response to determining that the timer has not been successfully set, the TCP ping setting is terminated (e.g., in favor of another type of mechanism). In contrast, in response to determining that the timer has been successfully set, a determination is made (at 1207) as to whether the socket has been successfully opened. An OS level call similar to the OS level call described for operation 1103 may be used to determine whether the socket has been successfully set.
In response to determining that the socket has not been successfully opened, the TCP ping settings are terminated (e.g., to facilitate another type of mechanism). However, in response to determining that the socket has been successfully opened, a local interface IP address is requested (at 1209). In some implementations, requesting the local interface IP address includes initiating an OS-level call requesting the local interface IP address from the OS. At 1211, a determination is made as to whether a valid local interface IP address has been obtained. A valid local interface IP address is obtained when sufficient computing resources are available for the OS to provide the local interface IP address. In some instances, there may be no computing resource to provide the local interface IP address, and the OS may return an error message indicating this. Thus, when insufficient computing resources are available to provide a local interface IP address, a valid local interface IP address cannot be obtained.
In response to determining that a valid local interface IP address is not obtained, the TCP ping setting is terminated (e.g., in favor of another type of mechanism). Conversely, in response to determining that a valid local interface IP address has been obtained, a variable of the TCP ping message is set (at 1213). For example, various fields of the example TCP packet shown in FIG. 8 are set at 1213. In some examples, the TCP ping message may be referred to as a datagram (indicated as "dgram" in fig. 12A), and an acknowledgement variable of the datagram (indicated as "ack" in fig. 12A and shown as flag "ack" in fig. 8), an address variable (indicated as "addr" in fig. 12A and shown as "source port" and "destination port" in fig. 8), or both, may be set at 1213. The set combination of variables may depend at least in part on whether the IPv4 or IPv6 protocol is used at the network layer.
At 1215, the contents of the TCP field and datagram are initialized. For example, various fields of the TCP packet shown in FIG. 8 are initialized at 1215. At 1217, a file descriptor (indicated as "FD" in fig. 12A) for the selection function (indicated as "select ()" in fig. 12A) is set. In some examples, the selection function is configured to notify the OS to generate the alert when an event included in the file descriptor has occurred. In some implementations, the file descriptor may include receipt of a TCP packet with a RST flag set, expiration of a timer, or both. Thus, in such an implementation, the OS generates an alert when the timer has expired or when a TCP packet with a RST flag set is received. In some examples, the timer is set to expire after a predetermined period of time, which may be equal to the period of time that the space 200, 201 is sampled for motion (e.g., 100 milliseconds in some examples).
At 1219, CSI rate feedback is initialized. In some implementations, the device that elicits the MIMO transmission may provide CSI to the device that sent the ICMP ping message. By initializing CSI rate feedback at 1219, CSI may be obtained from the MIMO transmission elicited by the TCP ping message and the rate at which the CSI is being received may be determined to confirm whether the CSI is being received at a rate fast enough to accurately or reliably detect motion in spaces 200, 201.
An example process 1210 in fig. 12B illustrates a process of performing TCP ping. In some implementations, TCP ping includes sending a predetermined number of consecutive TCP ping messages (e.g., using operations at 1221, 1223, 1225, 1227, 1229, 1231, 1233, 1235, 1237). In some instances, a predetermined number of consecutive TCP ping messages may be referred to as datagram blocks. The number of consecutive datagrams within a block (referred to as the "block size") may be application specific adjusted parameters, e.g. 64 datagrams. The "block size" may depend on the period of time that the space 200, 201 is sampled for motion. In some implementations, the spaces 200, 201 are sampled every 100 milliseconds, and a reasonable "block size" is equal to 64 datagrams. After a datagram block has been sent, process 1210 analyzes the received response (e.g., using operations at 1239, 1241, 1243, 1245) to determine whether the datagram block has successfully led out of a MIMO transmission or whether another datagram block needs to be sent.
At 1221, a selection function is performed. The selection function waits for events included in the file descriptor to occur. In some implementations, the file descriptor may include receipt of a TCP packet with a RST flag set, expiration of a timer, or both. Essentially, at 1221, a period of time is allowed to elapse such that a wireless signal (e.g., a MIMO transmission) may be received in response to a previously transmitted TCP ping message.
After the OS has generated the alert, a determination is made (at 1223) as to whether the timer has expired. The determination at 1223 confirms whether the alarm at 1221 can be attributed to expiration of a timer. In response to determining that the timer has not expired, a determination is made (at 1225) as to whether a TCP packet with a RST flag set is received. The determination at 1225 confirms whether the alarm at 1221 can be attributed to receipt of a TCP packet with a RST flag set. In response to determining that a TCP packet with a RST flag set has not been received, process 1210 iterates from 1221. Conversely, in response to determining that a TCP packet with a RST flag set is received, a timestamp of the received datagram is obtained and used to indicate the time at which the datagram was received (at 1227). Process 1210 then iterates from 1221.
Conversely, in response to determining that the timer has expired, the datagram is updated (at 1229). In some examples, the port identifiers (e.g., 16-bit port identifiers) of the active source port (indicated as "sport" in fig. 12B and shown as "source port" in fig. 8) and the active destination port (indicated as "dport" in fig. 12B and shown as "destination port" in fig. 8) are updated at 1229. For example, when the network is scanned for valid TCP ports, the port identifiers of valid source ports and valid destination ports may be obtained at 1201 and 1203.
At 1231, the timestamp of the datagram updated at 1229 is determined. In some examples, the time stamp of the datagram matches the current sequence number. At 1233, the datagram updated at 1229 is sent (e.g., from the active source port to the active destination port). In some implementations, the datagram is sent as a TCP packet with a SYN flag set.
At 1235, a determination is made as to whether a predetermined number of consecutive datagrams (e.g., "block size") have been sent. In response to determining that the predetermined number of consecutive datagrams have not been transmitted, the sequence counter is incremented, the active source port is pseudo-randomly selected, and the next active destination port is selected (at 1237), and the process 1210 iterates from 1221. A feedback or checking mechanism is performed in response to determining that a predetermined number of consecutive datagrams have been sent.
In example process 1210, a feedback or check mechanism (e.g., including operations 1239, 1241, 1243, 1245) is performed after a block of datagrams has been sent. At 1239, the time stamp of the received response is processed to determine the difference between the time at which the corresponding datagram was sent (e.g., the time obtained from the time stamp associated with the datagram) and the time at which the corresponding response of the datagram was received. If the time difference associated with any datagram within the datagram block is greater than the threshold, then the entire datagram block is considered a failed block. The failure logic may be implemented within operation 1239, which processes the timestamp of the received response.
At 1241, a determination is made as to whether the number of consecutive failed blocks is greater than a failure threshold number. In the example shown in fig. 12B, the failure threshold number is depicted as 10, but in other examples another integer threshold number may be used. A determination that the number of consecutive failed blocks is greater than the failure threshold number may indicate that repeated datagram (or TCP ping message) blocks failed to elicit a successful MIMO transmission from the wireless communication device. Thus, in response to determining that the number of consecutive failed blocks is greater than the failure threshold number, the TCP Ping mechanism may be terminated to facilitate attempting another type of mechanism.
In response to determining that the number of consecutive failed blocks is not greater than the failure threshold number, a secondary feedback check is performed. The secondary feedback check is referred to as CSI rate feedback (CSI rate FB) in fig. 12B (e.g., in operations 1243 and 1245). The checks performed at 1243 and 1245 determine the rate at which MIMO transmissions (including CSI) are being received in response to the datagram blocks. If the TCP packet with the SYN flag set is encapsulated by the client/leaf device in a MAC data frame that does not contain a MIMO training field, the response time may pass the check at 1241, but without the MIMO training field, there may be no CSI output from the radio. Thus, a secondary check at 1243 and 1245 may be used to ensure that the datagram block elicits a response containing the MIMO training field.
At 1243, a determination is made as to whether CSI rate feedback is enabled, and if so, at 1245) a determination is made as to whether the average CSI rate is greater than or equal to twice the period of time that space 200, 201 is sampled for motion. Determining that the average CSI rate is greater than or equal to twice the period of sampling the space 200, 201 may indicate that MIMO transmissions (including CSI) are not received at a rate fast enough to accurately and reliably detect motion in the space 200, 201. Thus, in response to determining that the average CSI rate is greater than or equal to twice the period of sampling the space 200, 201, the TCP Ping mechanism may be terminated to facilitate attempting another type of mechanism. Conversely, if CSI rate feedback is not enabled, or if the average CSI rate is less than twice the period of space 200, 201, then the sequence counter is incremented, the active source port is pseudo-randomly selected, and the next active destination port is selected (at 1237), and process 1210 iterates from 1221.
Fig. 13 shows a flow chart representing an example process 1300 of setting ARP ping. Process 1300 may include additional or different operations, and the operations shown in fig. 13 may occur in the order shown or in another order. In some cases, one or more operations shown in fig. 13 are implemented as a process including a plurality of operations, sub-processes for other types of routines. In some cases, operations may be combined, performed in another order, performed in parallel, iterated, or otherwise repeated or performed in another manner. Process 1400 may be performed by the example wireless communication devices 102A, 102B, 102C shown in fig. 1, the example wireless communication devices 204A, 204B, 204C shown in fig. 2A and 2B, any of the example devices shown in fig. 2C (e.g., client device 232 and AP devices 226, 228), or another type of device.
The example process 1300 shown in fig. 13 may be used, for example, to perform operation 1030 in the example process 1000 shown in fig. 10. In some implementations, the example process 1300 shown in fig. 13 may be used in another context. In some implementations, the ARP Ping process shown in fig. 13 may provide advantages for applications with wireless motion detection systems, for example, compared to using standard tools (e.g., arping). For example, the ARP Ping process shown in fig. 13 may provide ARP requests that do not broadcast MACs, but instead are replaced by the desired destination MAC address (which is known), which may eliminate the broadcast nature of ARP requests.
When the IPv4 protocol is operating at the network layer, an example process 1300 is used, and at 1301, a determination is made as to whether to use the IPv4 protocol. When using the IPv4 protocol, the cache queried at 902 in fig. 9 contains an IPv4 neighbor table, and thus, the determination at 1301 may be made based on whether an IPv4 neighbor table is present in the cache queried at 902. In response to determining that the IPv4 protocol is not being used, ARP Ping settings may be terminated (e.g., to facilitate another type of mechanism to attempt).
In contrast, in response to determining to use the IPv4 protocol, a determination is made (at 1303) as to whether the timer has been successfully set. In some implementations, an OS level call similar to the OS level call described for operation 1101 may be used to determine whether the timer has been successfully set.
In response to determining that the timer has not been successfully set, the ARP ping setting is terminated (e.g., to facilitate another type of mechanism). In contrast, in response to determining that the timer has been successfully set, a determination is made (at 1305) as to whether the socket has been successfully opened. An OS level call similar to the OS level call described for operation 1103 may be used to determine whether the socket has been successfully set.
In response to determining that the socket has not been successfully opened, the ARP ping setting is terminated (e.g., to facilitate another type of mechanism). However, in response to determining that the socket has been successfully opened, the local interface IP address and MAC address are requested (at 1307). In some implementations, requesting the local interface IP address and the MAC address includes initiating an OS-level call requesting the local interface IP address and the MAC address from the OS. At 1309 a determination is made as to whether a valid local interface IP address has been obtained. A valid local interface IP address is obtained when sufficient computing resources are available for the OS to provide the local interface IP address. In some instances, there may be no computing resource to provide the local interface IP address, and the OS may return an error message indicating this. Thus, when insufficient computing resources are available to provide a local interface IP address, a valid local interface IP address is not obtained.
In response to determining that a valid local interface IP address is not obtained, the ARP ping setting is terminated (e.g., to facilitate another type of mechanism). In contrast, in response to determining that a valid local interface IP address has been obtained, process 1300 proceeds to initialize an original ARP request frame (e.g., at 1311). At 1311, the fields required for the arp ping message are initialized and placed in the payload of the IPv4 frame.
At 1313, CSI rate feedback is initialized. In some implementations, the device that elicits the MIMO transmission may provide CSI to the device that sent the ARP ping message. By initializing CSI rate feedback at 1313, CSI may be obtained from the MIMO transmission elicited by the ARP ping message and the rate at which CSI is being received may be determined to confirm whether CSI is being received at a rate fast enough to accurately or reliably detect motion in spaces 200, 201.
Fig. 14 illustrates a flow chart representative of an example process 1400 for deriving a MIMO transmission from a wireless communication device. Process 1400 may include additional or different operations, and the operations shown in fig. 14 may be performed in the order shown or in another order. In some cases, one or more operations shown in fig. 14 are implemented as a process including a plurality of operations, sub-processes for other types of routines. In some cases, operations may be combined, performed in another order, performed in parallel, iterated, or otherwise repeated or performed in another manner. Process 1400 may be performed by the example wireless communication devices 102A, 102B, 102C shown in fig. 1, the example wireless communication devices 204A, 204B, 204C shown in fig. 2A and 2B, any of the example devices shown in fig. 2C (e.g., client device 232 and AP devices 226, 228), or another type of device.
Process 1400 may be performed by a wireless communication device seeking to elicit a MIMO transmission from another wireless communication device. At 1402, a network or transport layer message is generated. The network layer message may be generated when ICMP ping (e.g., as described in fig. 11A, 11B, 11C) or ARP ping (e.g., as described in fig. 13) is used to elicit MIMO transmissions. As depicted in fig. 8, the network layer messages may be encapsulated into the payload field of respective Medium Access Control (MAC) layer messages. When TCP ping processing (e.g., described in fig. 12A, 12B) is used to elicit MIMO transmissions, a transport layer message may be generated. As depicted in fig. 8, the generatable transport layer messages may be encapsulated into the payload fields of the respective network layer messages. In some implementations, the network or transport layer messages may be addressed to the device seeking MIMO transmission. The address of the device seeking MIMO transmission may be an upper layer logical address (e.g., a network address) of the device, and may be obtained using the process described in fig. 10.
At 1404, a network or transport layer message is wirelessly transmitted to a device seeking MIMO transmission. The network layer message may be transmitted wirelessly according to ICMP Ping processing (e.g., described in fig. 11A, 11B, 11C), ARP Ping processing (e.g., described in fig. 13), or a combination thereof. The transport layer message may be transmitted wirelessly according to a TCP Ping process (e.g., described in fig. 12A, 12B).
In some examples, a device sending a network or transport layer message may detect that the network or transport layer message has failed to elicit a successful MIMO transmission from the device to which the network or transport layer message is addressed. For example, failure of a network or transport layer message to elicit a successful MIMO transmission may manifest itself as a number of consecutive failed blocks greater than a failure threshold number (e.g., 1135 in fig. 11C or 1241 in fig. 12B), or a MIMO transmission (including CSI) not being received at a rate fast enough to accurately or reliably detect motion in space (e.g., 1139 in fig. 11C or 1245 in fig. 12B). When such a failure occurs, the means for sending the network or transport layer message may terminate the mechanism for sending the network or transport layer message to facilitate attempting another type of mechanism to send the network or transport layer message. For example, as shown in fig. 10, ICMP ping that sends network layer messages may not result in successful MIMO transmission, and the device may instead send transport layer messages using TCP ping to result in successful MIMO transmission. As another example, TCP Ping processing that sends a transport layer message may not result in successful MIMO transmission, and the device may instead send a network layer message using ARP Ping processing to result in successful MIMO transmission.
At 1406, a MIMO transmission is received from a device to which the network or transport layer message is addressed. The MIMO transmission may include a MIMO training field. The MIMO training field contains signals (e.g., CSI) with higher frequency resolution, a greater number of subcarrier frequencies, and a higher frequency bandwidth than conventional training fields in PHY frames. Using the MIMO training field for motion detection provides more accurate motion detection capabilities. Thus, at 1408, a training field is identified in each MIMO transmission and channel information is generated based on the training field (at 1410). At 1412, the channel information is used to detect motion occurring in a space (e.g., space 200, 201).
Fig. 15 is a block diagram illustrating an example wireless communication device 1500. As shown in fig. 15, the example wireless communication device 1500 includes an interface 1530, a processor 1510, a memory 1520, and a power supply unit 1540. The wireless communication devices (e.g., wireless communication devices 102A, 102B, 102C in fig. 1, wireless communication devices 204A, 204B, 204C shown in fig. 2A and 2B, any of client device 232 and AP devices 226, 228 shown in fig. 2C) may include additional or different components, and wireless communication device 1500 may be configured to operate as described for the above examples. In some implementations, the interface 1530, processor 1510, memory 1620, and power supply unit 1540 of the wireless communication device are housed together in a common housing or other assembly. In some implementations, one or more of the components of the wireless communication device may be individually housed in, for example, a separate housing or other assembly.
The example interface 1530 may communicate (receive, transmit, or both) wireless signals. For example, interface 1530 may be configured to communicate Radio Frequency (RF) signals formatted according to a wireless communication standard (e.g., wi-Fi, 4G, 5G, bluetooth, etc.). In some implementations, the example interface 1530 includes a radio subsystem and a baseband subsystem. The radio subsystem may include, for example, one or more antennas and radio frequency circuitry. The radio subsystem may be configured to communicate radio frequency wireless signals over a wireless communication channel. As an example, the radio subsystem may include a radio chip, an RF front end, and one or more antennas. The baseband subsystem may include, for example, digital electronics configured to process digital baseband data. In some cases, the baseband subsystem may include a Digital Signal Processor (DSP) device or other type of processor device. In some cases, the baseband system includes digital processing logic to operate a radio subsystem, communicate radio network traffic through a radio subsystem, or perform other types of processing.
The example processor 1510 may execute instructions to generate output data based on data input, for example. The instructions may include programs, code, scripts, modules, or other types of data stored in the memory 1520. Additionally or alternatively, the instructions may be encoded as preprogrammed or re-programmable logic circuits, logic gates, or other types of hardware or firmware components or modules. The processor 1510 may be or include a general purpose microprocessor as a special purpose coprocessor or other type of data processing device. In some cases, the processor 1510 performs high-level operations of the wireless communication device 1500. For example, the processor 1510 may be configured to execute or interpret software, scripts, programs, functions, executable files, or other instructions stored in the memory 1520. In some implementations, the processor 1510 is included in an interface 1530 or other component of the wireless communication device 1500.
Example memory 1520 may include computer-readable storage media such as volatile memory devices, nonvolatile memory devices, or both. Memory 1520 may include one or more read-only memory devices, random access memory devices, buffer memory devices, or a combination of these and other types of memory devices. In some examples, one or more components of the memory may be integrated with or otherwise associated with other components of the wireless communication device 1500. Memory 1520 may store instructions executable by processor 1510. For example, the instructions may include instructions for performing one or more of the operations described above.
The example power supply unit 1540 provides power to other components of the wireless communications device 1500. For example, other components may operate based on power provided by the power supply unit 1540 through a voltage bus or other connection. In some implementations, the power supply unit 1540 includes a battery or battery system, such as a rechargeable battery. In some implementations, the power supply unit 1540 includes an adapter (e.g., an AC adapter) that receives an external power signal (from an external source) and converts the external power signal to an internal power signal conditioned for components of the wireless communications device 1500. The power supply unit 1540 may include other components or operate in other ways.
Wireless signals may be communicated (e.g., transmitted and received) between various wireless communication devices shown in the example wireless communication systems of fig. 1, 2A, 2B, and 2C. For example, data may be communicated over one or more wireless links of the example wireless communication systems of fig. 1, 2A, 2B, and 2C. The data communicated may be unicast data, multicast data, or broadcast data, depending on the wireless communication device to which the data is addressed or intended to be transmitted. For example, unicast data is addressed to and intended to have a single destination or recipient. Illustratively, in the wireless communication system of fig. 2C, AP 228A may transmit unicast data addressed to client device 232B and intended for client device 232B. In this example, the other client devices 232A, 232C, 232D, and 232E are not intended recipients of unicast data from AP 228A. In contrast, multicast data is addressed to and intended to have one or more than one destination or recipient. Illustratively, in the wireless communication system of fig. 2C, the AP 228A may transmit multicast data addressed to the client devices 232A, 232B, 232C and intended for the client devices 232A, 232B, 232C. In this example, the other client devices 232D, 232E are not intended recipients of the multicast data from the AP 228A. Broadcast data is intended for all devices within the broadcast coverage area. In an IP network (e.g., IPv4 or IPv6 protocol), the broadcast coverage area may be determined by a network portion of the IP address, which may be defined by an IP subnet mask. Illustratively, in the wireless communication system of fig. 2C, the client devices 232A, 232B, 232C, 232D, 232E may be within the broadcast coverage area of the AP 228A, and the AP 228A may transmit broadcast data intended for all of the client devices 232A, 232B, 232C, 232D, 232E.
In some examples, the example wireless communication systems of fig. 1, 2A, 2B, and 2C may be configured to operate in accordance with one or more of the IEEE 802.11 family of standards. For example, an example wireless communication system may operate as a Wi-Fi network, which may have a built-in power saving feature that allows a wireless communication device (e.g., an AP device or a client device) to power down transmitting and receiving components for a negotiated amount of time without any data loss. In other words, wi-Fi networks may have built-in power saving features that allow a wireless communication device to enter a sleep mode for a predetermined duration (e.g., to reduce or save power consumption). For example, the Wi-Fi network may have a built-in power saving feature that causes the power supply unit 1540 shown in fig. 15 to cause the wireless communication device 1500 to enter a sleep mode for a predetermined duration (e.g., to reduce power consumption of the wireless communication device 1500). Example wireless communication devices that may use the built-in power saving feature of the Wi-Fi network include the example wireless communication devices 102A, 102B, 102C shown in fig. 1, the example wireless communication devices 204A, 204B, 204C shown in fig. 2A and 2B, or the example devices shown in fig. 2C (e.g., client device 232 or AP devices 226, 228), or any other wireless communication device.
As described above in the example shown in fig. 2C, a client device (e.g., a Wi-Fi client device) 232A, 232B, 232C, 232D, 232E, 232F, 232G may be associated with one of the central AP 226 or the extended AP 228 using a respective wireless link 234A, 234B, 234C, 234D, 234E, 234F, 234G. Fig. 16 illustrates an example message exchange in an association process 1600 between a client device 1602 and an AP device 1604. In some examples, the client device 1602 may be identified with any of the example client devices 102A, 102B, 102C, 204A, 204B, 204C, 232 shown in fig. 1, 2A, 2B, and 2C, or any other client device. AP device 1604 may be identified with any of the example AP devices shown in fig. 1, 2A, 2B, and 2C or any other AP device.
In association process 1600, client device 1602 and AP device 1604 are co-located in space 1606, and after association process 1600, devices 1602, 1604 may be nodes in a Wi-Fi network. In some examples, the client device 1602, the AP device 1604, or both may perform a search within their respective ranges (e.g., about 10 meters) to find other wireless communication devices that have registered themselves as visible or discoverable to the other wireless communication devices. In some instances (e.g., in one or more of the IEEE 802.11 family of standards), the AP device 1604 periodically transmits a beacon signal that the client device 1602 can use to discover the AP device 1604. Each beacon signal may be a broadcast message (e.g., for associated and non-associated client devices). The rate at which the beacon signal is transmitted may be programmed by the network operator and in some instances the beacon signal is transmitted approximately once every 100ms (e.g., approximately every 102.4 ms). Each beacon signal transmitted by the AP device 1604 may contain information about the wireless network. For example, the AP device 1604 may use the beacon signals to announce or broadcast the presence of the wireless network, identify the wireless network and its supported capabilities, synchronize time on all associated client devices, and broadcast Traffic Indication Map (TIM) elements (e.g., as will be discussed in further detail below). In some implementations, the AP device 1604 may use the beacon signals for other purposes.
In some implementations, once the client device 1602 discovers the AP device 1604, the client device 1602 may send an association request message 1608 to the AP device 1604. In some implementations, the association request message 1608 includes a plurality of fields 1610 related to the capabilities of the client device 1602. Regarding built-in power saving features in Wi-Fi networks, the plurality of fields 1610 of the association request message 1608 include a listening interval field 1612, which field 1612 may be used by the client device 1602 to indicate to the AP device 1604 that the client device 1602 may be in a sleep mode for a maximum amount of time before retrieving, for example, any buffered data (e.g., unicast, broadcast, or multicast data) from the AP device 1604. In some implementations, the value in the listening interval field 1612 may be an integer value represented by 2 octets (e.g., 16 bits). The integer value may indicate a maximum number (and thus a maximum amount of time) of beacon signals that the client device 1602 may be in sleep mode. As an example, a value of 20 in the listening interval field 1612 indicates to the AP device 1604 that the client device 1602 may be in a sleep mode for up to 20 beacon signals before requesting to communicate buffered unicast data from the AP device 1604 to the client device 1602. As another example, a value of 0 in the listening interval field 1612 may indicate to the AP device 1604 that the client device 1602 will not enter a sleep mode and may be used to receive all beacon signals transmitted by the AP device 1604.
After receiving the association request message 1608, the AP device 1604 may determine whether to permit the client device 1602 to associate with the AP device 1604. In some examples, the AP device 1604 sends an association response message 1614 to the client device 1602 in response to receiving the association request message 1608. In the case where the client device 1602 is permitted to associate with the AP device 1604, the association response message 1614 includes an Association Identifier (AID) field that the AP device 1604 uses to assign a unique identifier to the now associated client device 1602. The value in the AID field of the association response message 1614 is unique to each associated client device and may be an integer value in the range of 1 to 2007 (both 1 and 2007 are included in this range). Regarding built-in power saving features in Wi-Fi networks, the value in the AID field of the association response message 1614 may be used as an index within the TIM element of the beacon signal sent from the AP device 1604 to the client device 1602 after the client device 1602 is associated with the AP device 1604.
As described above, each beacon signal may include a TIM element. Fig. 17 shows an example TIM element 1700. In some examples, the TIM element 1700 may be used by the AP device 1604 to identify the presence of buffered unicast, broadcast, or multicast data for the client device 1602. For example, the TIM element 1700 may be used by the AP device 1604 to indicate to each associated client device that the AP device 1604 has buffered unicast data for each client device, and a beacon signal including a TIM element indicating the presence of buffered unicast data may be referred to as a TIM beacon signal. As another example, the TIM element 1700 may be used by the AP device 1604 to indicate to each associated client device that the AP device 1604 has buffered broadcast or multicast data for each client device. The TIM element 1700 indicating the presence of buffered broadcast or multicast data at the AP device 1604 may be referred to as a transmit traffic indication (DTIM) element, and the beacon signal including the DTIM element may be referred to as a DTIM beacon signal.
The example TIM element 1700 includes a plurality of fields 1702, 1704, 1706, 1708, 1710, 1712. The TIM element 1700 includes an element Identification (ID) field 1702. For the TIM element, the element ID field 1702 is equal to 5. The length field 1704 indicates the number of bytes in the TIM element 1700. In some implementations, the DTIM count field 1706 is a countdown counter value that indicates a count until the DTIM beacon signal is scheduled to be transmitted. The DTIM count field 1706 decrements with each successive beacon signal transmitted by the AP device 1604. If the DTIM count field 1706 is zero, the beacon signal is a DTIM beacon signal and the broadcast or multicast data may be scheduled to be transmitted by the AP device 1604 after (e.g., immediately after) the DTIM beacon signal. The DTIM period field 1708 indicates the number of beacon signals transmitted by the AP device 1604 for each DTIM time interval. In some examples, partial virtual bitmap field 1712 is a variable length bitmask array (up to 251 bytes) that indicates that there is buffered data available from AP device 1604. For example, if the AP device 1604 has buffered data for the client device 1602, the AP device 1604 may indicate the presence of the buffered data by setting a bit corresponding to the client device 1602 within the bitmask to 1. For some implementations, the bit within the bitmask may be described as a TIM value. To reduce the size of the partial virtual bitmap field 1712, the bitmap control field 1710 may be used to indicate which portion of the full traffic indication map (251 bytes) is sent via the partial virtual bitmap field 1712. In some examples, the bitmap control field 1710 may provide an indication of whether broadcast or multicast data is available to the client device 1602.
In instances where the AP device 1604 transmits a DTIM beacon signal, the AP device 1604 may transmit broadcast or multicast data after (e.g., immediately after) the transmission of the DTIM beacon signal. Thus, one difference between a TIM beacon signal (e.g., indicating the presence of buffered unicast data for each client device) and a DTIM beacon signal (e.g., indicating the presence of buffered broadcast or multicast data for each client device) is that the AP device 1604 transmits the buffered broadcast or multicast data to each client device after (e.g., immediately after) the DTIM beacon signal. Thus, the DTIM beacon signal may indicate to the client device 1602 that a wake-up is required to receive buffered broadcast or multicast data from the AP device 1604.
Legacy power saving is a power saving mechanism defined for one or more standards in the IEEE 802.11 family of standards that allows a client device 1602 to inform an AP device 1604 that the client device is expected to enter a sleep mode and, thus, may not be available to receive a given number of subsequent beacon signals from the AP device 1604. As described above, the maximum number of beacon signals that the client device 1602 expects to sleep through may be indicated by the listening interval field 1612 negotiated during the association process (e.g., the example process 1600 shown in fig. 16). During this time, the client device 1602 may power down, but may need to maintain an accurate clock to ensure that it powers up in time to receive the beacon signal from the AP device 1604.
Conventional power save mechanisms utilize power management bits in the frame control field of the MAC header. Fig. 18 shows an example MAC header 1800 with a frame control field 1802. The frame control field 1802 includes power management bits 1804. Client device 1602 may indicate to AP device 1604 that the client device is expected to enter sleep mode by sending a MAC layer message to AP device 1604. The MAC layer message may be a 0 payload length MAC frame (null data frame) with the power management bit 1804 set to a first value (e.g., 1). When the client device 1602 is in the sleep mode, the AP device 1604 may buffer any unicast data of the client device 1602 and set a bit in the TIM element 1700 corresponding to a given AID, indicating that unicast data is queued. Regarding broadcast or multicast data, although the client device 1602 may sleep past the number of TIM beacon signals indicated in the listening interval field 1612, the client device 1602 may need to wake up for all DTIM beacon signals so that it may receive the broadcast or multicast data. Once the client device 1602 has waked up to receive the TIM beacon signal and any buffered data, the client device 1602 may send a MAC layer message to the AP device 1604 with the power management bit 1804 set to a second, different value (e.g., 0), indicating to the AP device 1604 that any buffered data may be sent to the client device 1602.
To begin fetching buffered data from AP device 1604, client device 1602 may send a power save POLL (PS-POLL) message to AP device 1604. Fig. 19 shows an example format of a PS-POLL message 1900. PS-POLL message 1900 includes a frame control field 1902, a duration or AID field 1904, a Basic Service Set Identifier (BSSID) field 1906, a Transmitter Address (TA) field 1908, and a Frame Control Sequence (FCS) field 1910. The PS-POLL message sent from client device 1602 to AP device 1604 is acknowledged by AP device 1604, and AP device 1604 then sends a single data frame to client device 1602. If more than one data frame is buffered at the AP device 1604, the more data field 1806 of the MAC header 1800 may be set to 1. Then, in the conventional power saving mechanism, the AP device 1604 provides the subsequent data frames to the client device 1602 one by one.
In some examples, a non-scheduled automatic power save delivery (U-APSD) mechanism may be used as an enhancement to traditional power save mechanisms. The U-APSD mechanism introduces the concept of quality of service (QoS) allowing applications to group messages into different categories according to quality. As part of the U-APSD feature, a mechanism may be added to allow client device 1602 to wake up from sleep mode and request more than one message (depending on QoS indication) to be delivered by AP device 1604. A longer time window may be allocated for higher priority data. In general, the U-APSD mechanism may be similar to the traditional power save mechanism, except that the client device 1602 retrieves buffered data from the AP device 1604 to obtain an efficiency gain.
As described above, wireless sensing (e.g., wireless motion detection) may be based on a wireless communication device transmitting a set of wireless signals that may be used to detect changes in a communication channel. In many wireless transmission applications, many sensing applications may require periodic measurements of the communication channel to detect changes in the communication channel. To enable such periodic measurements, a central coordinator (e.g., residing on an AP device in some implementations) may be used to elicit transmissions (e.g., MIMO transmissions) from wireless communication devices (e.g., client devices associated with the AP device). As described above with respect to fig. 9, 10, 11A-11C, 12A, 12B, and 13, various protocols within all layers (including MAC layer, network layer, transport layer, and even to application layer) of OSI model 700 (e.g., shown in fig. 7) may be used to elicit periodic transmissions.
The presence of power save functions (e.g., conventional power save or U-APSD mechanisms) in one or more of the IEEE 802.11 families allows power saving for all types of wireless communication devices. However, in order to take full advantage of existing off-the-shelf wireless communication devices for wireless sensing without additional software or firmware modifications, power saving functionality presents challenges because the wireless communication device may suspend or power down wireless communication for a time interval (typically under the control of the device). Refer to fig. 16. Since the client device 1602 may not request data to be transferred for a duration defined by the value in the listening interval field 1612, different client devices may sleep for different periods of time that are not controlled by the wireless network or AP device 1604. When the client device 1602 is in sleep mode, it may not know that queuing data (e.g., unicast queuing data) is present at the AP device 1604 until the client device 1602 wakes up to receive the TIM beacon signal. This occurs with both conventional power save or U-APSD mechanisms.
Broadcast or multicast messages from the AP device 1604 may be used to elicit transmissions from the client device 1602. In some examples, it may be attractive to use broadcast or multicast messages to elicit transmissions from the client device 1602 because the client device 1602 may need to wake up to receive the DTIM beacon signal as a parameter of network control. From an outgoing point of view, it may also be more efficient if a single broadcast or multicast message may be used to generate multiple transmissions for client device 1602. Further, the DTIM period settings (e.g., in field 1708 of fig. 17) are generic across all associated client devices, requiring that these client devices all wake up at a time determined by the DTIM period. However, the DTIM period may typically be set such that the DTIM beacon signal is transmitted once every 2 or 3 beacons (e.g., every 204.8ms or 307.2ms, respectively), which may not be suitable for wireless sensing applications (which in some cases may require periodic measurements at a rate of about 100 ms).
The ARP broadcast protocol may be leveraged to elicit periodic transmissions from the client device 1602 at a rate suitable for wireless sensing applications. However, some smart AP devices may implement a cached ARP service that may respond on behalf of the client device without sending a broadcast transmission. For other multicast protocols, not all client devices subscribe to the multicast service without explicit user action or additional software installation. In summary, these constraints present challenges to schemes that utilize deterministic wake-up to receive DTIM beacon signals and broadcast or multicast messages. There are services such as multicast domain name system (mDNS) or DNS service discovery (DNS-SD) that operate using broadcast or multicast messages, however their use has just begun to become more prevalent in common IoT devices. Thus, a mechanism to prevent a particular client device from entering sleep mode may be required.
The decision for the client device to enter the power save mode may be made at one or more layers in the OSI model (e.g., as shown in fig. 7). In some examples, the network implementer may make a decision as to which layer in the OSI model may be used to decide whether the client device enters a power save mode. Typically, the primary criteria used is based on whether the client device has data to send (e.g., at a given layer) or the frequency or type of data the client device is receiving. The processes described above with respect to fig. 9, 10, 11A-11C, 12A, 12B, and 13 may be used to generate signals (and cause corresponding responses to be sent) at one or more layers in the OSI model; thus, the processing described above with respect to fig. 9, 10, 11A to 11C, 12A, 12B, and 13 may be used to prevent the client device from entering the power saving mode.
In particular, the processes described above with respect to fig. 9, 10, 11A-11C, 12A, 12B, and 13 may utilize existing protocols existing on off-the-shelf client devices and may operate without any user configuration or installation of additional software. Furthermore, messages are communicated in an efficient manner using existing protocols and with little overhead in bringing out transmissions (e.g., as shown in fig. 8).
As described above, the processing shown in fig. 9, 10, 11A to 11C, 12A, 12B, and 13 may be used to elicit MIMO transmissions, and the PHY preamble training field into the MIMO transmissions may be used to detect changes in the communication channel. Additionally or alternatively, the processes shown in fig. 9, 10, 11A-11C, 12A, 12B, and 13 may be used to prevent a wireless communication device (e.g., a client device) from entering a sleep mode. In particular, the rate of request pull may be programmable to minimize. The programmable pull rate may prevent the wireless communication device from entering sleep mode and may reduce the load added to the network and the device.
The programmable extraction rate may be provided as an input to one or more of the processes shown in fig. 11A through 11C, 12A, 12B, and 13. For example, during the timer settings in operations 1101, 1205, 1303 in fig. 11A, 12A, and 13, respectively, the timer of the wireless communication device may use a programmable pull rate (e.g., the timer may be set to pull transmissions at the programmed pull rate). As another example, during a timer tick operation 1123 shown in fig. 11B, a timer of the wireless communication device may use a programmable pull rate (e.g., each timer tick may be asserted at a rate substantially equal to the programmable pull rate). As other examples, programmable extraction rates may be used in operations 1221 and 1223 shown in fig. 12B.
Fig. 20 illustrates an example control loop 2000 that may be used to vary the rate of outgoing transmissions. The example control loop 2000 may be used to ensure that the rate of outgoing transmissions is greater than a minimum value, which in turn may prevent the wireless communication device from entering sleep mode and may reduce the load added to the network and the device.
The example control loop 2000 includes a first wireless communication device 2002 and a second wireless communication device 2004. The first wireless communication device 2002 sends a message 2003 (e.g., a network or transport layer message) addressed to the second wireless communication device 2004. The message 2003 may be sent in response to one or more of the pull processes 2006A, 2006B. In some implementations, the extraction process 2006A may be one or more of the processes described above with respect to fig. 9, 10, 11A-11C, 12A, 12B, and 13. In such an implementation, message 2003 may be a higher layer data service. In some implementations, the extraction process 2006B may be an alternative or additional extraction process. By way of example, the extraction process 2006B may be an asynchronous subsystem or state machine implemented separately from the process 2006A. For example, the pull process 2006B may be configured to independently generate the message 2003 (e.g., leveraging a MAC protocol) for transmission to the second wireless communication device 2004. The response from the second wireless communication device 2004 may be used by the first wireless communication device 2002 to generate channel information (e.g., channel state information), which in turn may be used to detect changes in the communication channel. An example of the pull process 2006B is a state machine implemented within the MAC and/or PHY layers (without using higher layer protocols). The state machine may even include components or subsystems defined by the IEEE 802.11 family of standards.
As described above, the extraction process 2006B may be an alternative or additional extraction process. In implementations where the extraction process 2006B is an additional process, the extraction process 2006B operates independently of the extraction process 2006A. In some examples, the pull process 2006B generates the pull message 2003 at a rate suitable for the wireless sensing application and preventing the first wireless communication device 2002 from entering a sleep mode. For example, in the case where the wireless sensing application operates on channel information generated every 100ms, the pull process 2006B may generate a message 2003 every 100 ms. One feature of using the pull process 2006B is that the message 2003 generated by the pull process 2006B causes the second wireless communication device 2004 to generate a corresponding response 2005 that can be used to generate channel information, while the response to the message generated by the pull process 2006A is not used to generate channel information, but is used to prevent the device from entering a power save mode. As described above, the extraction process 2006B may be an alternative or additional extraction process. In implementations that optionally exclude the pull process 2006B from the control loop 2000, the pull process 2006A may be used to generate a message 2003, which message 2003 may be used to both prevent the first wireless communication device 2002 from entering sleep mode and to generate channel information (e.g., channel state information) that may be used to detect changes in the communication channel.
The transmitter of the first wireless communication device 2002 communicates a message 2003 to the second wireless communication device 2004. In some implementations, the second wireless communication device 2004 is a Wi-Fi client device having a Wi-Fi subsystem 2008 (which includes a radio subsystem and a baseband subsystem). In such an implementation, the transmitter of the first wireless communication device 2002 may have IEEE 802.11 compliant features. The second wireless communication device 2004 may also include device higher level logic 2010. Along with the Wi-Fi subsystem 2008, the device higher layer logic 2010 performs decision logic to determine whether the second wireless communication device 2004 enters a sleep mode. The criteria for entering sleep mode may be implementation-specific and may be based on the rate of data exchange between the Wi-Fi subsystem 2008 and the device higher layer logic 2010 in some instances. As an example, the second wireless communication device 2004 may not enter the sleep mode when there is a high rate data exchange between the Wi-Fi subsystem 2008 and the device higher layer logic 2010.
In response to receiving the message 2003 (e.g., a network or transport layer message), the second wireless communication device 2004 transmits a response transmission (e.g., a MIMO transmission) across the space between the first wireless communication device 2002 and the second wireless communication device 2004. The response transmission is received by the receiver of the first wireless communication device 2002. In some examples, the receiver of the first wireless communication device 2002 transmits generated channel information (e.g., channel state information) for each response received from the second wireless communication device 2004. As described above, the channel information may be generated based on one or more training fields in each response transmission received from the second wireless communication device 2004.
Since the channel information is generated for each responsive transmission received from the second wireless communication device 2004, the channel information is generated at a rate that can be measured using the rate measurement circuit 2012. In some examples, the rate measurement circuit 2012 determines the average number of times channel information is generated within a programmable time interval (indicated as an integration interval in fig. 20). In some examples, the integration interval is about 10 seconds.
The rate at which the channel information is generated is compared to an expected rate (e.g., in difference block 2014). In some examples, the expected rate may be a minimum rate that requires an outgoing response transmission to prevent the wireless communication device from entering sleep mode. The difference block 2014 subtracts between the measured rate (e.g., the output of the rate measurement circuit 2012) and the expected rate and the difference is provided to a rate selection block 2016, which rate selection block 2016 initially selects and then changes the rate at which the outgoing message 2003 is sent from the first wireless communication device 2002 to the second wireless communication device 2004 (e.g., based on the difference provided to the rate selection block 2016 by the difference block 2014).
In some examples, the initial rate at which the outgoing message 2003 is sent from the first wireless communication device 2002 to the second wireless communication device 2004 may be based on the initial value 2018. In some implementations, the initial value 2018 may be a system-defined value or a user-defined value. In some examples, the initial value 2018 may be substantially equal to the expected rate (e.g., as shown in difference block 2014). If the output generated by the difference block 2014 indicates that channel information is being generated at a rate less than the expected rate, the rate selection block increases the rate at which the outgoing message 2003 is sent from the first wireless communication device 2002 to the second wireless communication device 2004 until a maximum rate 2020. The maximum rate 2020 may be selected based on external factors such as network load or device load. In some examples, maximum rate 2020 is set to approximately 40ms. The output of the rate selection block 2016 (representing the update rate at which the outgoing message 2003 is sent) may then be provided as input to one or more of the processes shown in fig. 11A-11C, 12A, 12B, and 13.
Fig. 21 illustrates a flow chart representative of an example method 2100 that facilitates altering a rate at which MIMO transmissions are derived from a wireless communication device. In some examples, method 2100 illustrates the general operation of control loop 2000 shown in fig. 20. Process 2100 may include additional or different operations, and the operations shown in fig. 21 may occur in the order shown or in another order. In some cases, one or more operations shown in fig. 21 are implemented as a process including a plurality of operations, sub-processes for other types of routines. In some cases, operations may be combined, performed in another order, performed in parallel, iterated, or otherwise repeated or performed in another manner. Process 2100 may be performed by the example wireless communication devices 102A, 102B, 102C shown in fig. 1, the example wireless communication devices 204A, 204B, 204C shown in fig. 2A and 2B, any of the example devices shown in fig. 2C (e.g., client device 232 and AP devices 226, 228), or by another type of device.
Process 2100 may be performed by a wireless communication device seeking to elicit a MIMO transmission from another wireless communication device. At 2102, a first set of messages is wirelessly transmitted at a first transmission rate to a device seeking MIMO transmission. The first set of messages may be first network layer messages that may be generated and sent according to ICMP ping (e.g., described in fig. 11A, 11B, 11C), ARP ping (e.g., described in fig. 13), or a combination thereof. As illustrated in fig. 8, the first network layer message may be encapsulated into a payload field of each Media Access Control (MAC) layer message. The first set of messages may additionally or alternatively be first transport layer messages that may be generated and sent according to a TCP ping process (e.g., described in fig. 12A, 12B). As described in fig. 8, the first transport layer messages that may be generated may be encapsulated into the payload fields of the respective network layer messages. In some implementations, the network or transport layer messages may be addressed to the device seeking MIMO transmission. The address of the device seeking MIMO transmission may be an upper layer logical address (e.g., a network address) of the device, and may be obtained using the process described in fig. 10.
At 2104, a MIMO transmission is received from the apparatus. The MIMO transmission may include a MIMO training field. The MIMO training field contains signals (e.g., CSI) with higher frequency resolution, a greater number of subcarrier frequencies, and a higher frequency bandwidth than conventional training fields in PHY frames. Using the MIMO training field for motion detection provides more accurate motion detection capabilities. Thus, at 2106, training fields are identified in each MIMO transmission, and channel information is generated based on the training fields (at 2108). At 2110, a rate at which channel information is generated is determined (e.g., using rate measurement circuit 2012 shown in fig. 20). At 2112, the first transmission rate is changed to a different second transmission rate based on the rate at which the channel information is generated (e.g., using the difference block 2014 and the rate selection block 2016 shown in fig. 20). At 2114, a second set of messages (e.g., a second set of network or transport layer messages) is wirelessly transmitted at a second transmission rate to a device seeking MIMO transmission.
Some of the subject matter and operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of these structures. Some of the subject matter described in this specification can be implemented as one or more computer programs (i.e., one or more modules of computer program instructions) encoded on a computer storage medium for execution by, or to control the operation of, data processing apparatus. The computer storage medium may be or may be included in the following: a computer readable storage device, a computer readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Furthermore, while the computer storage medium is not a propagated signal, the computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium may also be or be included in the following: one or more separate physical components or media (e.g., multiple CDs, discs, or other storage devices).
Some of the operations described in this specification may be implemented as operations performed by a data processing apparatus on data stored on one or more computer readable storage devices or received from other sources.
The term "data processing apparatus" encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system-on-a-chip, or a combination of several or all of the foregoing. The device may comprise a dedicated logic circuit, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). The apparatus may comprise, in addition to hardware, code for creating an execution environment for the computer program in question, e.g. code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them.
A computer program (also known as a program, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. The computer program may, but need not, correspond to a file in a file system. A program may be stored in a portion of a file that is used to hold other programs or data (e.g., one or more scripts stored in a markup language document) in a single file dedicated to the program, or in multiple coordinated files (e.g., files that are used to store portions of one or more modules, sub-programs, or code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
Some of the processing and logic flows described in this specification may be performed by: one or more computer programs are executed by one or more programmable processors to perform actions by operating on input data and generating output. These processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
To provide for interaction with a user, the operations may be implemented on a computer having a display device (e.g., a monitor or other type of display device) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse, trackball, tablet, touch-sensitive screen, or other type of pointing device) by which the user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input. In addition, a computer may interact with a user by sending and receiving documents with respect to a device used by the user (e.g., by sending web pages to a web browser on the user's client device in response to requests received from the web browser).
In a general aspect, MIMO transmissions are derived from a wireless communication device and used for wireless sensing.
In some aspects, a wireless sensing system (e.g., a motion detection system) initiates a message through a communication protocol defined in a layer above a Physical (PHY) layer and a data link (MAC) layer in a first wireless communication device (e.g., in a transport layer or a network layer). The message is addressed to the second wireless communication device and is wirelessly transmitted to the second wireless communication device. In response to the message, the second wireless communication device transmits a MIMO transmission across a space between the first wireless communication device and the second wireless communication device. The first wireless communication device senses space (e.g., detects motion of an object in space) based on the MIMO transmission.
In a first example, a first wireless communication apparatus: obtaining a network layer address of a second wireless communication device; addressing the network layer message to a network layer address of the second wireless communication device; initiating wireless transmission of network layer messages; receiving a MIMO transmission from a second wireless communication apparatus in response to the network layer message, wherein the MIMO transmission traverses a space between the first wireless communication apparatus and the second wireless communication apparatus; generating a series of channel responses based on training fields in the MIMO transmission; and detecting motion of an object in space based on the series of channel responses.
Implementations of the first example may include one or more of the following features. The network layer message may be sent according to ICMP ping, ARP ping, or other types of processing. The MIMO training field may be HE-LTF, VHT-LTF, or HT-LTF. Wireless sensing may include detecting movement of an object in space.
In a second example, a first wireless communication apparatus: generating a transport layer message addressed to the second wireless communication device; initiating wireless transmission of a transport layer message; receiving a MIMO transmission from the second wireless communication apparatus in response to the transport layer message, wherein the MIMO transmission traverses a space between the first wireless communication apparatus and the second wireless communication apparatus; generating a series of channel responses based on training fields in the MIMO transmission; and wireless sensing of space based on the series of channel responses.
Implementations of the second example may include one or more of the following features. The transport layer message may be sent according to the TCP Ping process or other type of process. The MIMO training field may be HE-LTF, VHT-LTF, or HT-LTF. Wireless sensing may include detecting movement of an object in space.
In a third example, a first wireless communication apparatus: initiating a first mechanism to elicit MIMO transmissions from a second wireless communication device and detecting failure of the first mechanism; initiating a second, different mechanism to elicit MIMO transmissions from the second wireless communication device and detecting success of the second mechanism; generating a series of channel responses based on the MIMO transmission directed from the second device using the second mechanism; and wireless sensing is performed based on the series of channel responses.
Implementations of the third example may include one or more of the following features. The first and second mechanisms may include ICMP Ping, TCP Ping, ARP Ping, or another type of request/response processing. The first wireless communication device may initiate the first mechanism and the second mechanism (and possibly additional mechanisms) based on the state of the state machine. Wireless sensing may include detecting motion of objects in space traversed by MIMO transmissions.
In a fourth example, a first wireless communication apparatus in a wireless communication network may: generating a network or transport layer message addressed to a second wireless communication device in the wireless communication network; wirelessly transmitting a network or transport layer message to a second wireless communication device to elicit a multiple-input multiple-output (MIMO) transmission from the second wireless communication device; and receiving the MIMO transmission from the second wireless communication apparatus. The MIMO transmission may traverse a space between the first wireless communication device and the second wireless communication device. The first wireless communication device may also identify a training field in each MIMO transmission; generating channel information based on the corresponding training fields; and detecting motion occurring in the space based on the channel information.
Implementations of the fourth example may include one or more of the following features. The network or transport layer message includes a network layer message encapsulated into a payload field of a corresponding Medium Access Control (MAC) layer message. The network layer message is transmitted wirelessly according to the Internet Control Message Protocol (ICMP) Ping process. The first wireless communication device may also obtain a network layer address of the second wireless communication device; and encapsulating the network layer address of the second wireless communication device into a payload field of each MAC layer message. The network or transport layer messages include transport layer messages encapsulated into payload fields of respective network layer messages and the transport layer messages are wirelessly transmitted according to a Transmission Control Protocol (TCP) Ping process, an Address Resolution Protocol (ARP) Ping addressed to the second wireless communication device, or a combination thereof. The first wireless communication device may also detect failure of the network or transport layer message to elicit MIMO transmissions from the second wireless communication device; generating a second network or transport layer message addressed to the second wireless communication device in response to detecting the failure; and wirelessly transmitting a second network layer or transport layer message to the second wireless communication device to elicit a MIMO transmission from the second wireless communication device. The network or transport layer messages are wirelessly transmitted according to a first type of communication process and the second network or transport layer messages are wirelessly transmitted according to a second, different type of communication process. The first type of communication process and the second type of communication process are selected from the group consisting of ICMP Ping, ARP Ping and TCP Ping addressed to the second wireless communication device. Identifying training fields in each MIMO transmission includes identifying training fields in PHY frames of each MIMO transmission.
In a fifth example, a non-transitory computer readable medium stores instructions that when executed by a data processing apparatus are operable to perform one or more operations of the first example, the second example, the third example, and the fourth example. In a sixth example, a system includes a plurality of wireless communication devices, and devices configured to perform one or more operations of the first example, the second example, the third example, and the fourth example.
Implementations of the sixth example may include one or more of the following features. One of the wireless communication devices may be or include a device. The device may be remote from the wireless communication device.
In another general aspect, a rate at which multiple input/multiple output (MIMO) transmissions are directed from a wireless communication device is changed (e.g., to prevent the wireless communication device from entering a sleep/power save mode).
In a seventh example, the first wireless communication apparatus: the method includes wirelessly transmitting a first set of messages to a second wireless communication device at a first transmission rate to elicit a first multiple-input multiple-output (MIMO) transmission from the second wireless communication device. The first wireless communication device also receives a first MIMO transmission from the second wireless communication device, wherein the first MIMO transmission traverses a space between the first wireless communication device and the second wireless communication device. The first wireless communication device also generates first channel information based on each training field identified in each first MIMO transmission; determining a rate at which first channel information is generated; and changing the first transmission rate to a different second transmission rate based on the rate at which the first channel information is generated. The first wireless communication device additionally wirelessly transmits a second set of messages to the second wireless communication device at a second transmission rate to elicit a second MIMO transmission from the second wireless communication device.
Implementations of the seventh example may include one or more of the following features. Changing the first transmission rate to the second transmission rate includes: comparing the rate at which the first channel information is generated with a threshold value, the threshold value being a minimum transmission rate at which the second wireless communication device is prevented from entering a power saving mode; and increasing the first transmission rate to the second transmission rate in response to the rate at which the first channel information is generated being less than the threshold. The first set of messages includes a first set of network or transport layer messages and the second set of messages includes a second set of network or transport layer messages. At least one of the first aggregate network or transport layer message and the second aggregate network or transport layer message includes network layer messages encapsulated into a payload field of each Media Access Control (MAC) layer message. The network layer message is transmitted wirelessly according to the Internet Control Message Protocol (ICMP) Ping process. At least one of the first set of network or transport layer messages and the second set of network or transport layer messages includes transport layer messages encapsulated into payload fields of respective network layer messages. The transport layer message is wirelessly transmitted according to a Transmission Control Protocol (TCP) Ping process, an Address Resolution Protocol (ARP) Ping addressed to the second wireless communication device, or a combination thereof.
While this specification contains many specifics, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular examples. Certain features described in this specification or shown in the drawings may also be combined in the context of separate implementations. Conversely, various features that are described or illustrated in the context of a single implementation can also be implemented in multiple embodiments separately or in any suitable subcombination.
Similarly, although operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single product or packaged into multiple products.
Many embodiments have been described. However, it should be understood that various modifications may be made. Accordingly, other embodiments are within the scope of the above description.

Claims (20)

1. A method, comprising:
operation by a first wireless communication device in a wireless communication network:
wirelessly transmitting a first set of messages to a second wireless communication device at a first transmission rate to elicit a first multiple-input multiple-output transmission, a first MIMO transmission, from the second wireless communication device;
receiving the first MIMO transmission from the second wireless communication apparatus, wherein the first MIMO transmission traverses a space between the first wireless communication apparatus and the second wireless communication apparatus;
generating first channel information based on respective training fields identified in each of the first MIMO transmissions;
determining a rate at which the first channel information is generated;
changing the first transmission rate to a different second transmission rate based on a rate at which the first channel information is generated; and
wirelessly transmitting a second set of messages to the second wireless communication device at the second transmission rate to elicit a second MIMO transmission from the second wireless communication device.
2. The method of claim 1, wherein changing the first transmission rate to the second transmission rate comprises:
comparing a rate at which the first channel information is generated with a threshold value, the threshold value being a minimum transmission rate at which the second wireless communication device is prevented from entering a power saving mode; and
In response to the rate at which the first channel information is generated being less than the threshold, the first transmission rate is increased to the second transmission rate.
3. The method of claim 1 or 2, wherein the first set of messages comprises a first set of network or transport layer messages and the second set of messages comprises a second set of network or transport layer messages.
4. A method according to claim 3, wherein at least one of the first and second sets of network or transport layer messages comprises a network layer message encapsulated into a payload field of a respective medium access control layer message, MAC layer message.
5. The method of claim 4, wherein the network layer message is transmitted wirelessly according to an internet control message protocol Ping process, ICMP Ping process.
6. A method according to claim 3, wherein at least one of the first and second sets of network or transport layer messages comprises a transport layer message encapsulated into a payload field of the respective network layer message.
7. The method of claim 6, wherein the transport layer message is transmitted wirelessly according to a transmission control protocol Ping process, TCP Ping process, an address resolution protocol Ping, ARP Ping, addressed to the second wireless communication device, or a combination thereof.
8. A wireless communications apparatus, comprising:
one or more processors; and
a memory comprising instructions that, when executed by the one or more processors, cause the wireless communication device to perform operations comprising:
wirelessly transmitting a first set of messages to a second wireless communication device at a first transmission rate to elicit a first multiple-input multiple-output transmission, a first MIMO transmission, from the second wireless communication device;
receiving the first MIMO transmission from the second wireless communication apparatus, wherein the first MIMO transmission traverses a space between the wireless communication apparatus and the second wireless communication apparatus;
generating first channel information based on respective training fields identified in each of the first MIMO transmissions;
determining a rate at which the first channel information is generated;
changing the first transmission rate to a different second transmission rate based on a rate at which the first channel information is generated; and
wirelessly transmitting a second set of messages to the second wireless communication device at the second transmission rate to elicit a second MIMO transmission from the second wireless communication device.
9. The wireless communications apparatus of claim 8, wherein changing the first transmission rate to the second transmission rate comprises:
comparing a rate at which the first channel information is generated with a threshold value, the threshold value being a minimum transmission rate at which the second wireless communication device is prevented from entering a power saving mode; and
in response to the rate at which the first channel information is generated being less than the threshold, the first transmission rate is increased to the second transmission rate.
10. The wireless communication apparatus of claim 8 or 9, wherein the first set of messages comprises a first set of network or transport layer messages and the second set of messages comprises a second set of network or transport layer messages.
11. The wireless communications apparatus of claim 10, wherein at least one of the first set of network or transport layer messages and the second set of network or transport layer messages comprises a network layer message encapsulated into a payload field of a respective medium access control layer message, MAC layer message.
12. The wireless communications apparatus of claim 11, wherein the network layer message is wirelessly transmitted in accordance with an internet control message protocol Ping process, ICMP Ping process.
13. The wireless communications apparatus of claim 10, wherein at least one of the first set of network or transport layer messages and the second set of network or transport layer messages comprises a transport layer message encapsulated into a payload field of a respective network layer message.
14. The wireless communications apparatus of claim 13, wherein the transport layer message is transmitted wirelessly according to a transmission control protocol Ping process, TCP Ping process, an address resolution protocol Ping, ARP Ping, addressed to the second wireless communications apparatus, or a combination thereof.
15. A non-transitory computer-readable medium comprising instructions that when executed by a data processing apparatus of a first wireless communication device perform operations comprising:
wirelessly transmitting a first set of messages to a second wireless communication device at a first transmission rate to elicit a first multiple-input multiple-output transmission, a first MIMO transmission, from the second wireless communication device;
receiving the first MIMO transmission from the second wireless communication apparatus, wherein the first MIMO transmission traverses a space between the first wireless communication apparatus and the second wireless communication apparatus;
generating first channel information based on respective training fields identified in each of the first MIMO transmissions;
Determining a rate at which the first channel information is generated;
changing the first transmission rate to a different second transmission rate based on a rate at which the first channel information is generated; and
wirelessly transmitting a second set of messages to the second wireless communication device at the second transmission rate to elicit a second MIMO transmission from the second wireless communication device.
16. The non-transitory computer-readable medium of claim 15, wherein changing the first transmission rate to the second transmission rate comprises:
comparing a rate at which the first channel information is generated with a threshold value, the threshold value being a minimum transmission rate at which the second wireless communication device is prevented from entering a power saving mode; and
in response to the rate at which the first channel information is generated being less than the threshold, the first transmission rate is increased to the second transmission rate.
17. The non-transitory computer readable medium of claim 15 or 16, wherein the first set of messages comprises a first set of network or transport layer messages and the second set of messages comprises a second set of network or transport layer messages.
18. The non-transitory computer-readable medium of claim 17, wherein at least one of the first set of network or transport layer messages and the second set of network or transport layer messages comprises a network layer message encapsulated into a payload field of a respective medium access control layer message, MAC layer message.
19. The non-transitory computer readable medium of claim 18, wherein the network layer message is wirelessly transmitted according to an internet control message protocol Ping process, ICMP Ping process.
20. The non-transitory computer-readable medium of claim 17, wherein at least one of the first set of network or transport layer messages and the second set of network or transport layer messages comprises a transport layer message encapsulated into a payload field of the respective network layer message.
CN202280051905.4A 2021-05-24 2022-05-12 Changing the rate at which MIMO transmissions are derived from a wireless communication device Pending CN117730486A (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/328,479 2021-05-24
US17/328,479 US11570712B2 (en) 2019-10-31 2021-05-24 Varying a rate of eliciting MIMO transmissions from wireless communication devices
PCT/CA2022/050749 WO2022246539A1 (en) 2021-05-24 2022-05-12 Varying a rate of eliciting mimo transmissions from wireless communication devices

Publications (1)

Publication Number Publication Date
CN117730486A true CN117730486A (en) 2024-03-19

Family

ID=84228261

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280051905.4A Pending CN117730486A (en) 2021-05-24 2022-05-12 Changing the rate at which MIMO transmissions are derived from a wireless communication device

Country Status (4)

Country Link
EP (1) EP4348855A1 (en)
CN (1) CN117730486A (en)
CA (1) CA3219662A1 (en)
WO (1) WO2022246539A1 (en)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114599991A (en) * 2019-10-31 2022-06-07 认知系统公司 Causing MIMO transmissions from a wireless communication device
WO2021081635A1 (en) * 2019-10-31 2021-05-06 Cognitive Systems Corp. Using mimo training fields for motion detection

Also Published As

Publication number Publication date
WO2022246539A1 (en) 2022-12-01
EP4348855A1 (en) 2024-04-10
CA3219662A1 (en) 2022-12-01

Similar Documents

Publication Publication Date Title
US11018734B1 (en) Eliciting MIMO transmissions from wireless communication devices
US11570712B2 (en) Varying a rate of eliciting MIMO transmissions from wireless communication devices
US20210273685A1 (en) Using MIMO Training Fields for Motion Detection
US11304254B2 (en) Controlling motion topology in a standardized wireless communication network
CN113302517A (en) Ranging specific MAC service and PIB attributes for IEEE 802.15.4Z
WO2022172247A1 (en) Systems and methods for wi-fi sensing
CN117730486A (en) Changing the rate at which MIMO transmissions are derived from a wireless communication device
US20240085551A1 (en) Systems and methods for motion detection using sensing transmission clusters
WO2024047528A1 (en) Wi-fi sensing taking into consideration received noise power information
WO2024069528A1 (en) Systems and methods for wi-fi network evaluation
WO2023199176A1 (en) Systems and methods for time synchronization of sensing measurements made out of bss
WO2023031795A1 (en) Identifying devices within transmissions within a sensing network
WO2024089534A1 (en) Systems and methods for determination of sensing roles in a mesh network
WO2023214340A1 (en) Systems and methods for time synchronization of sensing transmissions made by unassociated stations
CA3173377A1 (en) Identifying devices within transmissions within a sensing network
WO2023223217A1 (en) Systems and methods for selecting and updating a set of sounding devices
WO2023073583A1 (en) Methods and systems for time spread assembled csi for wideband channels
CA3173373A1 (en) Systems and methods for dynamic time domain channel representations
WO2022263982A1 (en) Systems and methods for dynamic time domain channel representations
CN117999462A (en) Device in identification transmission in sensing network
KR20240011713A (en) Systems and methods for accommodating flexibility in sensing transmissions

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination