COMMUNICATION APPARATUS AND METHOD FOR LOW COMPLEXITY WLAN SENSING RELATED APPLICATIONS - Patent application

Abstract

A communication apparatus and a communication method for low-complexity WLAN sensing are provided. An exemplary embodiment provides a first communication apparatus, the first communication apparatus comprising: a receiver that, during operation, receives a measurement request frame from a second communication apparatus, where the measurement request frame carries a delayed response field indicating whether a delayed response is allowed; and a transmitter that, during operation, transmits a measurement physical protocol data unit (PPDU) used for channel measurement in response to the measurement request frame.

Description

[Technical field]

[0001] This application claims priority to Singapore Patent Application No. 10202108368V and Singapore Patent Application No. 10202108443R, both of which are hereby incorporated by reference.

[0002] The present embodiments relate generally to communication devices, and more particularly, to a method and apparatus for low-complexity wireless local area network (WLAN) sensing. [Background technology]

[0003] In the standardization of next-generation wireless local area networks (WLANs), the IEEE 802.11 Working Group has been discussing a new wireless access technology that is backward compatible with IEEE 802.11a / b / g / n / ac / ax technologies, and has named it 802.11be EHT (Extremely High Throughput) WLAN.

[0004] Many sub-7 GHz WLAN sensing use cases, especially those classified as room sensing in Non-Patent Document 1, may involve low-complexity Internet of Things (IOT) devices (e.g., smart appliances such as TVs, washing machines, refrigerators, air conditioners, Wi-Fi enabled vending machines, etc.) to perform sensing measurements. Many of these devices have relatively long life spans, and thus legacy WLAN devices (e.g., 802.11ac in the 5 GHz band, 802.11n in the 2.4 GHz and 5 GHz bands, etc.) are expected to be in use for a significant number of years as part of the WLAN sensing ecosystem. Supporting 802.11bf in low-complexity 802.11 devices (with or without legacy PHY) will facilitate early and widespread adoption of standardized WLAN sensing.

[0005] Recent 802.11bf meetings have proposed that 11bf ensures at least one mode of operation that can support 11bf in devices with legacy physical layers (PHYs), such as 802.11n or 802.11ac, and that these devices can participate in WLAN sensing. Although 802.11n and 802.11ac are given here as examples of legacy PHYs, this is not meant to exclude other 802.11 PHYs, such as 802.11a, 802.11b, 802.11g, and 802.11ax, which may also be considered legacy PHYs if the host device does not natively support 802.11bf. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] IEEE contribution 21 / 1047rl (Legacy Support in llbf, Rojan Chitrakar) [Non-Patent Document 2] IEEE contributions 21 / 504rl (Specification Framework for TGbf, Claudio da Silva) [Non-Patent Document 3] IEEE contributions 20 / 1851r4 (Overview of Wi-Fi Sensing Protocol, Cheng Chen et. al.) [Non-Patent Document 4] IEEE 802.11-2020 Summary of the Invention [Problem to be solved by the invention]

[0007] However, low-complexity WLAN sensing relevant to support low-complexity (IOT type) devices (with / without legacy PHY) has not been discussed so far.

[0008] Thus, there is a need for a communication apparatus and method that can solve the problems discussed above. Furthermore, other desirable features and characteristics will become apparent from the following detailed description and appended claims, taken in conjunction with the accompanying drawings and the Background section of this disclosure. [Means for solving the problem]

[0009] The non-limiting and illustrative embodiments facilitate providing a communications apparatus and method for low-complexity WLAN sensing.

[0010] According to one aspect of the present disclosure, there is provided a first communications device, the first communications device comprising: a receiver that, during operation, receives a measurement request frame from a second communications device, where the measurement request frame carries a delayed response field indicating whether a delayed response is allowed; and a transmitter that, during operation, transmits a measurement Physical Protocol Data Unit (PPDU) used for channel measurement in response to the measurement request frame.

[0011] According to another aspect of the present disclosure, a second communications device is provided that includes: a receiver that, during operation, receives information related to the first communications device; circuitry that, during operation, generates a measurement request frame based on the information, where the measurement request frame carries a delayed response field indicating whether a delayed response is allowed; and a transmitter that, during operation, transmits the measurement request frame to the first communications device.

[0012] According to another aspect of the present disclosure, there is provided a communication method including the steps of receiving a measurement request frame from a communication device, the measurement request frame carrying a delayed response field indicating whether a delayed response is allowed, and transmitting a measurement physical protocol data unit (PPDU) used for channel measurement in response to the measurement request frame.

[0013] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof. Additional benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. These benefits and / or advantages may be obtained individually by the various embodiments and features of the specification and drawings, and it is not necessary for all of the embodiments and features to be provided in order to obtain one or more of such benefits and / or advantages. [Brief description of the drawings]

[0014] The accompanying drawings, together with the following detailed description, are incorporated in and form a part of this specification, and serve to illustrate various embodiments and to explain various principles and advantages according to the present embodiments. Throughout the different drawings, like reference numbers indicate identical or functionally similar elements. [Figure 1] 1 shows an overview of a WLAN sensing protocol according to an example. [Diagram 2] 1 shows an illustration of a sensing process according to an example. [Diagram 3] 1 shows an illustration of a network in accordance with an example. [Figure 4] 1 illustrates an implementation of a sensing process according to various embodiments. [Diagram 5] 1 illustrates another implementation of a sensing process according to various embodiments. [Figure 6] 1 shows an illustration of a Type 1 station (STA) having a legacy physical layer (PHY) according to a first embodiment. [Figure 7] 2 shows an illustration of a WLAN Sensing Capability element according to a first embodiment. [Figure 8] 1 shows an illustration of sensing window setup during a setup phase using Scheduled Automatic Power Save Delivery (S-APSD) according to a first embodiment. [Figure 9] 2 shows an illustration of a Sensing Setup Request frame and a Sensing Setup Response frame according to a first embodiment; [Figure 10] 1 shows an illustration of the setup of sensing windows during the setup phase using individual target wakeup time (TWT) service periods (SP) according to a first embodiment. [Figure 11] 1 shows an illustration of an Individual TWT Setup frame according to a first embodiment. [Figure 12] 1 shows an illustration of the setup of sensing windows during the setup phase using broadcast TWT SP according to a first embodiment. [Figure 13] 1 shows an illustration of a Broadcast TWT element according to a first embodiment. [Figure 14] 1 illustrates an illustration of a Sensing Setup Request frame and a Sensing Setup Response frame for negotiating a TWT SP according to a first embodiment. [Figure 15] 4 shows an illustration of a measurement phase according to a first embodiment; [Figure 16] 2 shows an illustration of a PHY receive (RX) mode according to a first embodiment. [Figure 17] 2 shows an illustration of a Measurement Request frame according to a first embodiment; [Figure 18] 1 shows an illustration of solicited measurements using a measurement request frame with padding according to a first embodiment; [Figure 19] 2 shows an illustration of solicited measurements using a measurement request frame in an aggregated MAC protocol data unit (A-MPDU) according to a first embodiment; [Figure 20] 1 shows an illustration of a new Ranging Trigger subtype (802.11az) defined as a Measurement Request frame according to a first embodiment. [Figure 21] 1 illustrates a diagram of a PHY receiving procedure in a sensing measurement mode of a very high throughput (VHT) null data packet (NDP) according to a first embodiment. [Figure 22] 1 shows an illustration of solicited measurement with delayed response allowed according to a first embodiment; [Figure 23] 2 shows an illustration of a VHT NDP Announcement frame according to a first embodiment. [Figure 24] 1 shows an illustration of an unsolicited measurement process using a Type 1 sensing initiator according to a first embodiment. [Diagram 25] 1 shows an illustration of an unsolicited measurement process using a Type 1 responder according to a first embodiment. [Figure 26] 4 shows an illustration of a summary of the sensing phase according to the first embodiment; [Figure 27] 13 shows an illustration of an exemplary WLAN sensing deployment having two Type-1 sensing STAs according to a second embodiment. [Figure 28]13 shows an illustration of an exemplary sensing measurement using a Data frame as a measurement PPDU according to a second embodiment. [Figure 29] 13 shows an illustration of a sensing measurement phase using a sounding PPDU as a measurement PPDU according to a second embodiment. [Diagram 30] 13 shows an illustration of an exemplary transmission procedure of a VHT sounding sequence according to a second embodiment. [Diagram 31] 13 shows an illustration of an exemplary WLAN sensing deployment having two Type-1 sensing STAs according to a third embodiment. [Diagram 32] 13 shows an illustration of a sensing measurement process according to a third embodiment. [Diagram 33] 13 shows an illustration of an exemplary WLAN sensing deployment having Type 1 and Type 2 STAs according to a fourth embodiment. [Diagram 34] 13 shows an illustration of an Ethertype 89-0d frame according to a fourth embodiment. [Diagram 35] 13 illustrates an illustration of an exemplary WLAN sensing procedure between a Type 1 STA (STA1) and a Type 2 STA (AP) according to the fourth embodiment. [Diagram 36] 13 shows an illustration of an exemplary WLAN sensing procedure between a Type 1 STA (STA1) and a Type 2 STA (sensing initiator) according to the fourth embodiment. [Figure 37] 1 shows a flow diagram illustrating a method for low complexity WLAN sensing according to various embodiments. [Figure 38] 1 shows a partially boxed schematic diagram of a STA that may be implemented for low-complexity WLAN sensing in accordance with various embodiments.

[0015] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] The following detailed description is merely illustrative and is not intended to limit the embodiments or the application and uses of the embodiments. Moreover, there is no intention to be bound by the theories presented in the preceding Background or Detailed Description sections. Moreover, other desirable features and characteristics will become apparent from the following detailed description and the appended claims, taken in conjunction with the accompanying drawings and the background of this disclosure.

[0017] An overview of the WLAN sensing protocol is provided in Non-Patent Document 2 and Non-Patent Document 3. Referring to Fig. 1, the WLAN sensing protocol 100 between the sensing initiator 102 and the sensing responder 104 can be divided into a discovery phase 106, a setup phase 108, a measurement phase 110, a reporting phase 112, and a teardown phase 114. In the discovery phase 106, information about the capabilities of the sensing initiator 102 and the sensing responder 104 is exchanged, for example, during the association of the sensing initiator 102 and the sensing responder 104. In the setup phase 108, a sensing session is established between the sensing initiator 102 and the sensing responder 104, and the sensing transmitters and sensing receivers of the sensing initiator 102 and the sensing responder 104 are identified, and relevant parameters of the sensing transmission are determined. In the measurement phase 110, the sensing transmitter performs a transmission to the sensing receiver for measurement purposes. In the reporting phase 112, depending on the scenario, the sensing receiver may need to feed back the measurement results to the sensing initiator 102. In the teardown phase 114, the sensing session is terminated in an explicit or implicit manner.

[0018] The setup phase 108 is used to set up a sensing session between two or more sensing STAs. In a sensing procedure, a STA can perform WLAN sensing and obtain measurement results. A sensing session is an instance of a sensing procedure with associated operational parameters of that instance. A sensing initiator is a STA that initiates a WLAN sensing session. A sensing responder is a STA that participates in a WLAN sensing session initiated by a sensing initiator. A sensing transmitter is a STA that transmits PPDUs used for sensing measurements in a sensing session. A sensing receiver is a STA that receives PPDUs transmitted by a sensing transmitter in a sensing session and performs sensing measurements. A STA can play multiple roles in one sensing session. In a sensing session, a sensing initiator can be a sensing transmitter, a sensing receiver, both, or neither.

[0019] Low-complexity Internet of Things (IOT) devices are typically characterized by the use of low-capability hardware (CPU, memory, etc.) that results in limitations in processing power, response time, storage capacity, and other similar specifications. Many of these low-complexity IOT devices are battery-powered and therefore have power usage limitations. Low-complexity IOT devices, including devices with legacy PHYs, may not be able to comply with some of the measurement sequences currently being discussed in 11bf. This is true for IOT devices, even those with modern PHYs. For example, a low complexity device (e.g., a legacy device) may not be able to respond with an NDP within a short interframe space (SIFS) of 16 μS after receiving a request frame, such as a sensing request frame; e.g., as shown in FIG. 2, the sensing responder 204 may not be able to respond with an HT NDP 216 within a SIFS 210 after receiving a request frame 208 from the sensing initiator 202, and the sensing responder 206 may not be able to respond with a VHT NDP 218 within a SIFS 212 after receiving a request frame 214 from the sensing initiator 202. However, not all devices with legacy PHYs are low complexity devices, and some devices with modern PHYs may also be considered low complexity devices.

[0020] The WLAN sensing protocol currently discussed in 11bf (especially the measurement and reporting phases) is not suitable or optimized for low-complexity devices and devices running legacy PHYs (11n, 11ac). Therefore, it is desirable to optimize the WLAN sensing protocol (especially the measurement and reporting phases) for low-complexity devices and devices running legacy PHYs (11n, 11ac) to address processing delays (e.g., to account for slow responses to measurement request frames) and power profiles (e.g., to enable low-power operation for battery-powered devices). Note that although 802.11n and 802.11ac are cited as examples of legacy PHYs, this does not mean to exclude other 802.11 PHYs such as 802.11a, 802.11b, 802.11g, and 802.11ax, and these 802.11 PHYs may also be considered legacy PHYs if the host device does not natively support 802.11bf.

[0021] According to the supported capabilities or supported PHY versions, 11bf STAs are classified into two types: Type 1 (basic): Example: STA with legacy PHY, IOT STA Type 2 (Advanced): Example: Non-IOT type STAs, STAs with the latest PHY Type 1 (basic) STAs are (e.g. due to hardware capabilities) - Computing power / processing power - Power Profile - Supported PHYs Type 1 STAs are 11bf STAs that are constrained with respect to one or more of the following: 11bf STAs that support only basic 11bf functionality, such as legacy sounding and sensing based on feedback type, and / or sensing between a single pair of STAs. For simplicity, STAs that support only legacy PHYs, such as 11n, 11ac, etc., can be classified as Type 1 STAs, regardless of their hardware capabilities. Although 802.11n and 802.11ac are mentioned here as examples of legacy PHYs, this does not exclude other 802.11 PHYs, such as 802.11a, 802.11b, 802.11g, 802.11ax, etc., which may also be considered legacy PHYs if the host device does not natively support 802.11bf.

[0022] On the other hand, Type 2 (Advanced STAs) are 11bf STAs that do not have such constraints and support advanced 11bf features (e.g., secure long training field (LTF), trigger-based sensing measurements, etc.). Type 2 STAs are sometimes referred to as non-basic STAs. For example, with reference to the network 300 of FIG. 3, AP1 302 (supporting 802.11be and 802.11bf), STA2 308 (supporting 802.11az and 802.11bf), and STA3 310 (supporting 802.11ax and 802.11bf) are Type 2 (Advanced) 11bf STAs, while STA1 306 (supporting 802.11ac and 802.11bf) and AP2 304 (supporting 802.11n and 802.11bf) are Type 1 (Basic) 11bf STAs. Additionally, STA4 312 (which supports 11ac) can participate in WLAN sensing, even though it is not an 11bf STA. This disclosure considers the option of having Type 1 and Type 2 STAs participate together in a sensing session.

[0023] 4, when the sensing responder 404 is a Type 1 STA, the sensing initiator 402 may use a delayed response field in the Measurement Request frame 406 to indicate whether a delayed response is allowed, and if a delayed response is allowed, the sensing responder 404 may transmit the measurement PPDU 408 delayed (i.e., not within a SIFS), e.g., in a different transmit opportunity (TXOP). Alternatively, with reference to FIG. 5, the sensing initiator 502 may use a delayed response field in the Measurement Request frame 506 to indicate that a delayed response is not allowed, however, the sensing initiator 502 may include one or more padding fields 510 in the Measurement Request frame 506 to provide the sensing responder 504 more time to respond with a measurement PPDU 508 within a SIFS from the end of the Measurement Request frame 506 in the same TXOP. When the sensing responder 504 receives the measurement request frame 506 and detects the start of the padding field 510, it can begin preparing to transmit a measurement PPDU 508. The sensing responder 504 can detect the start of the padding field 510 and, in response to the detection, transmit a measurement PPDU 508 within a certain length of time after the measurement request frame 506 is received. The measurement PPDUs 408 and 508 can be used for channel measurements by the sensing initiators 402, 502. The STAs can advertise themselves as either Type 1 or Type 2 devices, with Type 1 devices being less capable than Type 2 devices. The delayed response field of the measurement request frame is set to indicate that a delayed response is allowed if the sensing responder STA is a Type 1 device and is set to indicate that a delayed response is not allowed if the sensing responder STA is a Type 2 device.

[0024] In the first embodiment E1, we consider upgrading a Type 1 STA with a legacy PHY with 11bf modifications at factory installation or after deployment through firmware updates and / or patches to support most 11bf related changes to the medium access control (MAC) and MAC-PHY interface. Referring to the diagram 600 of FIG. 6, a WLAN sensing application 602 located above a MAC 604 interacts with a sensing module 606 in the MAC 604 via a MAC sublayer management entity (MLME) service access point (SAP) (e.g., management plane) 608. A 11bf STA may, for example, Beacons, probe responses, association responses, sensing request / response frames, etc., sent by a sensing STA that is an AP, or Probe requests, association requests, sensing request / response frames, etc. sent by sensing STAs that are non-AP STAs A STA advertises its sensing STA type (Type 1 or Type 2) by using a WLAN Sensing Capability element in an associated frame such as:

[0025] 7 illustrates a WLAN Sensing Capability element 700 that may include a Sensing Capabilities field 702. The Sensing Capabilities field 702 may include a Sensing STA type field 704 that may be used to indicate the type of the STA, e.g., having a value of "0" to indicate that the sensing STA type is Type 1 (Basic) or a value of "1" to indicate that the sensing STA type is Type 2 (Advanced). The Sensing Capabilities field 702 may also include a Solicited Measurements field 706 that may indicate whether the corresponding STA supports solicited measurements, e.g., responding with a measurement PPDU (e.g., an NDP, or a PPDU carrying a Data frame) upon receiving a measurement request frame. If set to Yes to indicate that solicited measurements are supported by the STA, the STA may further indicate the type of measurement PPDU used to respond to the measurement request frame, e.g., whether the measurement PPDU is an NDP or an 802.11 PPDU carrying a Data frame. Thus, the STA may advertise whether it is capable of transmitting a measurement PPDU (e.g., whether solicited measurements are supported by the STA) when receiving a measurement request frame, and if it is advertised that it is capable of transmitting a measurement PPDU, it may further advertise the type of measurement PPDU it is capable of transmitting in the Measurement PPDU Type field 710, which may be an NDP or an 802.11 PPDU carrying a Data frame.A Type 1 STA supporting solicited measurements may further advertise the length of time (e.g., >SIFS) it needs to respond with a measurement PPDU (e.g., NDP, Data frame) upon receiving a measurement request frame, e.g., via the Response delay field 708. For example, the Response delay field 708 may be set to 0 if it is able to respond within a SIFS (e.g., receive the measurement request frame and then send a measurement PPDU within a SIFS), or any high non-zero value (e.g., 1 to indicate a 32 μS response delay, 2 to indicate a 48 μs response delay, etc.) otherwise. Alternatively, the Solicited Measurements field itself may indicate whether the STA supports immediate or delayed responses. 0: Requested measurements are not supported 1: Supports delayed transmission of measurement PPDU 2: Supports immediate transmission of measurement PPDU

[0026] A separate field, e.g. "Supports NDP Measurement PPDU", can be used to indicate whether solicited NDP transmission is supported.

[0027] The supported PHYs and respective PHY capabilities of an 11bf STA can be advertised / discovered by including HT / VHT / HE / EHT capability elements in the relevant frames and can be independent of the sensing STA type capability. Alternatively, the sensing STA type can be derived based on the STA's other capabilities without explicitly signaling it. For example, all STAs that only support legacy PHYs such as 11n, 11ac, etc. are considered as Type 1 (basic) sensing STAs, while STAs with newer PHYs such as HE / EHT are considered as Type 2 (advanced) sensing STAs. Alternatively, if the Response Delay field has a non-zero value, the STA is considered as a Type 1 STA, and STAs with a 0 value in the Response Delay field are considered as Type 2 STAs. A Type 1 STA, which is a legacy device upgraded by 11bf amendments, means that the device's software has been upgraded (e.g., by firmware update / patch) and supports the relevant 11bf MAC functionality and MAC-PHY interface.

[0028] WLAN sensing related information discovered during active / passive scanning can be forwarded to upper layers via the MLME-SCAN.confirm primitive as shown below.

number

[0029] Two parameters related to WLAN sensing can be included in the above mentioned BSSDescriptionSet, as shown in Table 1 below. [Table 1]

[0030] The following parameters can be negotiated during the setup phase: 1) Sensing role: By default, the STA that initiates the setup assumes the role of the sensing initiator and the peer STA becomes the sensing responder. The sensing transmitter / receiver roles can be subject to negotiation. 2) Transmission parameters of the PPDU used for sensing measurements: PPDU format, channel bandwidth, number of spatial streams, and transmit power. The parameters are according to the supported PHY. During the setup phase, one or more time windows for performing sensing measurements can also be negotiated. In addition, a sensing sequence for the sensing measurements can also be negotiated as follows: A) Solicited (or trigger-based): The sensing initiator sends an explicit frame (e.g., a measurement request frame) to solicit (or trigger) a measurement PPDU from the sensing responder. B) Unsolicited (or non-trigger based): A sensing initiator may send a measurement PPDU and ask a responder to provide feedback including the sensing measurement results. 3) Measurement feedback type: Type 1 sensing STAs may only support default feedback types, e.g., channel state information (CSI), compressed / uncompressed beamforming in 11n, and compressed beamforming in 11ac. Type 2 sensing STAs may support additional feedback types, e.g., compressed / uncompressed 11bf CSI matrices.

[0031] When one of the sensing STA pair is a type 1 sensing STA with a legacy PHY and the other is also an AP, the sensing service periods (SP) can be scheduled using scheduled automatic power save delivery (S-APSD), i.e., one or more negotiated time windows can be S-APSD SP. FIG. 8 shows an illustration of a sensing setup phase 800 according to a first embodiment. As part of the sensing setup phase, to use the scheduled SP (service period) for sensing measurements, a non-AP STA 802 sends an add traffic stream (ADDTS) request frame 806 to an AP 804 with both the APSD subfield 814 and the Schedule subfield 816 of a traffic stream information (TS Info) field 810 in a traffic specifications (TSPEC) element 808 set to 1. If the AP 804 accepts the scheduled APSD request, it responds with an ADDTS Response frame 832. The ADDTS response frame 832 may include a Schedule element 822 that includes a Schedule Info field 824 , a Service Start time field 826 , and a Service Interval field 828 .

[0032] Such a scheduled SP may be referred to as a sensing SP (SSP) (e.g., SSP 830). A specific value in the traffic stream identifier (TSID) field 812 is reserved (e.g., 15) to indicate a sensing SP. Alternatively, the reserved bits B17-B23 in the TS Info field 810 or the reserved bits B7-B15 in the Schedule Info field 824 may be used to indicate a sensing SP.

[0033] The Minimum Service Interval field 818 of the TSPEC element 808 may contain an unsigned integer that specifies the minimum interval in microseconds between the start of two consecutive SPs. The Maximum Service Interval field 820 may contain an unsigned integer that is used to indicate a latency limit that limits the amount of aggregation (A-MSDU or A-MPDU) used so that excessive latency is not introduced. The Service Start Time field 826 contains an unsigned integer that specifies the time in microseconds when the first scheduled SP will start. The Service Start Time in the TS Info field 810 indicates to the AP 804 the time when the STA is first expected to be ready to perform sensing measurements, and power-saving STAs must be awake to receive frames used for sensing measurements. This may advantageously help the AP 804 schedule services such that the frames used for sensing measurements experience little delay in the MAC, helping power-saving STAs reduce power consumption. This field represents the low-order 4 octets of the TSF timer at the start of the SP.

[0034] If the APSD mechanism is supported by the AP 804 and the AP 804 accepts the corresponding ADDTS Request frame 806 from the STA 802, the AP responds to the ADDTS Request frame 806 with a response (e.g., an ADDTS Response frame 832) that includes a Schedule element 822 indicating that the requested service can be supported by the AP 804.

[0035] The Service Start Time field 826 indicates the expected time in microseconds when the service will start and represents the lowest 4 octets of the TSF timer value at the start of the first SP. The AP 804 uses this field to confirm or modify the service start time indicated in the TSPEC request. The Service Interval field 828 indicates the time in microseconds between two consecutive SPs and represents the time measured from the start of one SP to the start of the next SP. A scheduled SP starts at the scheduled wake-up time corresponding to the scheduled interval (SI) and service start time indicated in the Schedule element 822 sent in response to the TSPEC request. During the Sensing SP 830, only frames / PPDUs related to WLAN sensing may be allowed to be exchanged.

[0036] Alternatively, instead of using ADDTS request / response frames, the schedule APSD of the sensing SP may be negotiated by including a TSPEC element in the sensing setup request frame and a schedule element in the sensing setup response frame, as shown in Sensing Setup Request frame 900 and Sensing Setup Response frame 902 of Figure 9. For example, Sensing Setup Request frame 900 may include a TSPEC element 904, and Sensing Setup Response frame 902 may include a Schedule element 906.

[0037] A TWT SP can be used to schedule a sensing service period (SP) between two or more sensing STAs (e.g., type 2 sensing STAs, or type 1 STAs with 11ax PHY) that support a target wake time (TWT). In a first option, an individual TWT SP can be used, for example, as shown in the diagram 1000 of FIG. 10. During the setup phase, the sensing STAs (e.g., AP 1004 and STA1 1002) can negotiate an individual TWT SP 1008 to be used for WLAN sensing by exchanging TWT setup frames, e.g., the TWT SP is negotiated for use as one or more time windows during which sensing measurements are performed. For example, the STA 1002 can send a TWT Request frame 1010 to the AP 1004, and the AP 1004 can respond with a TWT Response frame 1012 if it accepts the TWT request. The TWT responder (AP 1004 in this example) can also schedule another sensing STA (e.g., STA2 1006) to participate in the TWT SP by sending an unsolicited TWT response (TWT RESPONSE) frame 1014 to STA2 1006. During the sensing SP 1008, only frames / PPDUs related to WLAN sensing can be allowed to be exchanged. The sensing STA can also negotiate for the TWT SP to be "protected" (e.g., the sensing TWT SP begins with a request to send (RTS) / clear to send (CTS) exchange) to protect the sensing TWT SP from other STAs.

[0038] 11 shows an illustration of an individual TWT Setup frame 1100 according to a first embodiment. The TWT Setup frame 1100 can be used as a TWT Request frame (e.g., TWT Request frame 1010 of FIG. 10) and / or a TWT Response frame (e.g., TWT Response frames 1012 and 1014 of FIG. 10) and can include one or two TWT elements 1102. The TWT element 1102 can include a Sensing TWT Info field 1108 within a TWT Parameter Information field 1104. The Sensing TWT Info field 1108 can be used to convey parameters related to sensing SP, such as solicited / unsolicited measurements, feedback type, and other similar parameters. The TWT element 1102 may further include, within the Control field 1106, a Negotiation Type field 1110 and a Sensing TWT SP field 1112. The Negotiation Type field 1110 may be configured to indicate the negotiation type of the TWT Setup frame 1100 as “Individual TWT”, and the Sensing TWT SP field 1112 may indicate that the corresponding TWT SP is for sensing, and the TWT Parameter Information field 1104 includes a Sensing TWT Info field 1108. The Sensing TWT Info field 1108 may be used to convey parameters related to the sensing SP, such as solicited / unsolicited measurements, feedback type, etc.

[0039] In the second option, the sensing SP can be scheduled using a broadcast TWT SP. Figure 12 shows an illustration of a setup phase 1200 utilizing a broadcast TWT SP according to the first embodiment. When the sensing transmitter is an AP (e.g., AP 1204), the AP can announce the TWT SP dedicated to sensing by including one or more broadcast TWT elements in the beacon frame and the probe response frame transmitted by the AP 1204. During the sensing setup phase, the sensing STAs (e.g., STA1 1202 and STAn 1206) can negotiate to join the broadcast sensing TWT SPs 1208 and 1216 used for WLAN sensing by exchanging TWT setup frames with the AP 1204. For example, in a target beacon transmission time (TBTT) negotiation phase in which the wake TBTT and wake interval are negotiated, the STA 1202 may transmit a TWT request frame 1210 to the AP 1204, which may respond with a TWT response frame 1212 if it accepts the TWT request. At the first TBTT after the end of the transmission of the TWT response frame 1212, a broadcast TWT element 1214 may be broadcast in a beacon frame transmitted by the AP 1204, and a sensing TWT SP 1208 may be scheduled in the wake interval after the first TBTT. The sensing TWT SPs 1208 and 1216 may also be protected from third party STA transmissions by scheduling a quiet interval that overlaps with the sensing TWT SP 1208. The overlapping quiet intervals may be scheduled by including one or more Quiet elements in the beacon and probe response frames transmitted by the AP 1204.A broadcast TWT based sensing TWT SP may be suitable for solicited or unsolicited sensing measurements involving multiple sensing responders.

[0040] 13 illustrates an illustration of a TWT element 1300 that can be used to set up a Broadcast TWT SP, for example, as utilized in the Broadcast TWT element 1214 of FIG. 12. The TWT element 1300 can include a Sensing TWT Info field 1304 in a TWT Parameter information field 1302 that can be used to convey parameters related to the Sensing SP, such as solicited / unsolicited measurements, feedback type, and other similar parameters. The TWT Parameter Information field 1302 can further include a Broadcast TWT Recommendation field 1306 in a Request Type field, where a reserved value (e.g., 5) can be used to indicate that the Broadcast TWT SP is for sensing and that the Sensing TWT Info field 1304 is included in the TWT Parameter Information field 1302. The TWT element 1300 may further include a Negotiation Type field 1310 in the Control field 1308, which may be used to indicate that the TWT element 1300 is for setting up a broadcast TWT SP. The Sensing TWT Info field 1304 may be used to convey parameters related to the sensing SP, such as solicited / unsolicited measurements, feedback type, etc.

[0041] Alternatively, instead of using the TWT request / response frames, the TWT SP for the sensing SP can be negotiated by including the TWT element in the sensing setup request frame and the sensing setup response frame as shown in the Sensing Setup Request frame 1400 with the TWT element field 1404 and the Sensing Setup Response frame 1402 with the TWT element field 1406 of FIG. 14. The Sensing Setup Request frame 1400 and the Sensing Setup Response frame 1402 can be utilized as the WLAN sensing session request / response frame. The TWT element fields 1404 and 1406 can be the same as the TWT element 1102 of FIG. 11 or the TWT element 1300 of FIG. 13.

[0042] As shown in FIG. 15, when solicited measurement is used for sensing measurement, a type 2 sensing initiator STA1 1502 (11ax+11bf) can send a measurement request frame 1506 to a type 1 sensing responder STA2 1504 (11ac+11bf) to trigger the transmission of a measurement PPDU 1508 (e.g., NDP). When the sensing responder 1504 is a type 1 STA, it may not be able to respond with a measurement PPDU 1508 within a SIFS after completing reception of the measurement request frame 1506. In such a case, the measurement request frame 1506 can indicate that a delayed response is allowed, for example, in a “delayed response” field, and the sensing responder 1504 can send the measurement PPDU 1508 with a delay, either in the same TXOP or in a different TXOP acquired by the sensing responder (e.g., in TXOP2 1512 instead of TXOP1 1510).

[0043] Further, referring to diagram 1600 of FIG. 16, a PHY primitive PHY-SENSING_START.request 1602 can be defined to put the sensing receiver PHY into sensing measurement mode 1604, where the PHY extracts sensing measurements (e.g., CSI) from non-legacy LTF (e.g., HT / VHT / HE / EHT-LTF) and passes them to the MAC. The PHY can automatically return to normal RX mode 1606 at the end of the PPDU, or another PHY primitive (e.g., PHY-SENSING_STOP.request) can be defined for this purpose.

[0044] Extracting sensing measurements may be computationally expensive and may also consume more power than normal RX mode 1606. In the above example 1500 of FIG. 15, the initiator 1502 switches the PHY to sensing measurement mode 1604 immediately after receiving an acknowledgment to the measurement request frame in order to prepare the PHY for extracting sensing measurements. However, because the measurement PPDU is transmitted in a different subsequent TXOP, factors such as channel access delay may cause some uncertainty in the length of time the PHY is in this mode. If the initiator does not detect the measurement PPDU within a certain length of time, it may switch its PHY back to normal RX mode 1606.

[0045] The receiving capabilities of the device's PHY when in sensing measurement mode 1604 may be hardware dependent. Some Type 1 STAs' PHYs may only be able to detect PPDUs and extract sensing measurements from received PPDUs while in sensing measurement mode 1604, but may not be able to process the data portion of the PPDU (if any), while other Type 1 and Type 2 STAs, for example, may be able to both extract sensing measurements and properly receive the data portion of the PPDU, with the only difference between normal Rx mode 1606 and sensing measurement mode 1604 being the additional step of extracting sensing measurements while in sensing measurement mode 1604. However, for other Type 1 and Type 2 STAs, the STAs may be able to extract sensing measurements from all PPDUs received even in normal Rx mode 1606, and thus may not need to explicitly set their PHY to sensing measurement mode 1604.

[0046] If a sensing SP was negotiated during the sensing setup phase, solicited measurements are performed during the sensing SP. The measurement request frame can be a control frame (i.e. frame type = control), and generally no acknowledgement is sent for control frames. However, if the "delayed acknowledge" field of the measurement request frame is set to 1 and the responder intends to send the measurement PPDU with a delay, the responder acknowledges the reception of the frame with an ACK frame to indicate to the initiator that the measurement request frame was received correctly.

[0047] FIG. 17 shows an illustration of a Measurement Request frame 1700 that can be used in the solicited measurement in the examples described in FIG. 15 and FIG. 16. The Measurement Request frame 1700 can include a padding element 1702 including an Element ID field, a Length field, an Element Extension ID field, a 4-octet FCS2 field 1704, and a padding field 1706 of 0 to 248 octets. The Measurement Request frame 1700 can further include a Delayed Response field 1708 in the SENS Control field. If the Delayed Response field 1708 indicates that a delayed response is allowed (e.g., set to 1), the sensing responder is allowed to respond to the Measurement Request frame 1700 with an ACK frame and transmit a measurement PPDU after a delay, either in the same TXOP or in the next TXOP.

[0048] Alternatively, if the Delayed Response field 1708 indicates that a delayed response is not allowed (e.g., set to 0), the measurement request frame 1700 may include one or more Padding elements 1702 to provide the sensing responder more time to respond with a measurement PPDU. The sensing initiator calculates the amount of padding required based on the "Response Delay" advertised by the responder. The Padding element 1702 is defined to convey a 4-octet long FCS2 field 1704 as the first field after the Element Extension ID field, and a variable length Padding field 1706 set to a fixed, known pattern (e.g., all ones, all zeros, or alternating ones and zeros). The FCS2 field 1704 may further convey a cyclic redundancy code (CRC) that is calculated based on the contents of the measurement request frame 1700 up to the occurrence of the FCS2 field. For example, the FCS2 field 1704 conveys a 32-bit CRC-32 that is calculated over all fields in the MAC header and frame body fields except for the FCS2 field 1704 itself, the Padding field 1706, and the FCS field (e.g., the Frame Control, Duration, RA, TA, SENS, Groups / Members Information, Request Transmit Power, Sounding Information, Element ID, Length, and Element Extension ID fields are included in the 32-bit CRC-32 calculation).To ensure the integrity of the CRC-32, after the CRC-32 is set in the FCS2 field 1704, no further modifications (by the MAC or PHY) must be made to the portion of the frame covered by the CRC-32 calculation.

[0049] The Padding element 1702 may be included in any management or appropriate control frame, and if included in a frame, the Padding element shall be the last element of the frame. Upon receiving the first Padding element, the receiving STA may discard the remainder of the frame body after checking the FCS2 field.

[0050] The measurement request frame 1700 may also be referred to as a Sounding Request frame. Typically, information elements are only carried in management frames according to the 802.11 specification, and the padding element of the current example may also be carried in control frames, such as measurement request frames. Alternatively, the padding element may be replaced by a padding field having a length subfield, a 4-octet FCS2 subfield 1704, and a padding subfield of variable size, with the length subfield indicating the number of octets in the padding subfield plus 4 (of the FCS2 field).

[0051] FIG. 18 shows an illustration of solicited measurement using a measurement request frame 1806 including padding 1808, such as the measurement request frame 1700. The initiator 1802 is a type 2 STA, STA1 (11ax+11bf), and the responder 1804 is a type 1 STA, STA2 (11ac+11bf). When a sensing SP has been negotiated, the STAs that are members of the SP are expected to be awake (e.g., not in power-saving doze) at the start of the sensing SP. The advantage of using padding instead of a delayed response is that the measurement PPDU 1810 can be transmitted within the same TXOP, thereby reducing the time that the initiator's PHY needs to remain in the sensing measurement mode. For example, ET 1812 represents the extra time available to the responder to prepare to transmit the measurement PPDU 1810 after detecting the padding element and before checking the FCS2 field. In this example, if the roles of the STAs were reversed, i.e., the initiator 1802 was a Type 1 STA (e.g., STA2) with a legacy PHY and the responder 1804 was a Type 2 STA (e.g., STA1), minimal or no padding would be required in the measurement request frame 1806 because the newer PHY would be able to respond with a measurement PPDU 1810 without delay.

[0052] 19, a measurement request frame 1908 (not including padding) may be transmitted by the initiator 1902 as the first MPDU of the A-MPDU 1906, with subsequent MPDUs being dummy MPDUs or end of frame (EOF)-padding fields 1912 that serve as padding for the responder 1904. Upon receiving the measurement request frame 1908, the responder 1904 may proceed to prepare its PHY for transmission of a measurement PPDU 1912 and discard the contents of the remaining A-MPDU.

[0053] Alternatively, as shown in FIG. 20, a new ranging trigger subtype (based on the 802.11az ranging trigger frame) can be defined as a measurement request frame. The ranging trigger subtype field 2002 of the Trigger frame 2000 can indicate a new subtype value (e.g., 5) that can be used to indicate that the Trigger frame 2000 is a sensing trigger frame. The Trigger frame was originally introduced in 802.11ax to allocate resource units (RUs) for uplink orthogonal frequency-division multiple access (OFDMA) transmission, but when the Sounding PPDU format field 2004 indicates HT or VHT, the Sensing Trigger frame requests a single HT NDP or VHT NDP occupying the entire bandwidth indicated in the UL BW subfield 2006. When the Sounding PPDU format field 2004 indicates HT or VHT, the RU Allocation field 2008 is reserved. Additionally, the Sensing Trigger frame 2000 may include one or more Padding User Info fields 2010 and 2012 to provide more time for associated sensing responders to respond with measurement PPDUs. The sensing initiator calculates the amount of padding required based on the "response delay" advertised by the responders. The first Padding User Info field 2010 may also carry an FCS2 field 2014.The FCS2 field 2014 may carry a 32-bit CRC-32 calculated over all fields of the MAC header and frame body fields except for the FCS2 field 2014 itself, the subsequent padding user information fields (e.g., the Padding User Info field 2012), and the FCS field 2016. If the Delayed Response field 2018 is set (e.g., to 1), the sensing responder is permitted to respond to the measurement request frame with an ACK frame and send the measurement PPDU after a delay, either in the same TXOP or in the next TXOP. The Sensing Trigger frame may also indicate in the NDPA Required field 2020 whether an NDPA frame preceding the SIFS before the measurement PPDU is required.

[0054] 21 shows an illustration of a PHY reception procedure in sensing measurement mode for VHT NDP according to a first embodiment, illustrating an exemplary PHY reception procedure for receiving sensing measurements (e.g., CSI) when PHY 2104 is in sensing measurement mode. MAC 2102 issues a PHY-SENSING_START.request primitive 2106 to PHY 2104 to switch PHY 2104 to sensing measurement mode. Upon receiving a measurement PPDU 2108 (e.g., VHT NDP), PHY 2104 extracts the sensing measurements from the non-legacy LTF 2110 (e.g., VHT LTF) and passes them to MAC 2102 in the RXVECTOR parameter of PHY-RXSTART.indication primitive 2112. The PHY 2104 may automatically return to normal RX mode upon the end of the PPDU 2108, or upon expiration of an indicated timeout period, or upon receipt of another PHY primitive defined for this purpose (e.g., PHY-SENSING_STOP.request). In an actual implementation, when the MAC issues a PHY-SENSING_START.request primitive to the PHY 2104 to switch the PHY 2104 to sensing measurement mode, some hardware register may be set to a known value that makes the PHY 2104 aware that it should perform CSI extraction on the received PPDU. Similarly, passing the sensing measurement results (e.g., CSI or beamforming feedback matrix, etc.) from the PHY 2104 to the MAC 2102 may be accomplished by writing the results to some table / buffer accessible to both the PHY 2104 and the MAC 2102.

[0055] To transition the PHY into sensing measurement mode, the following PHY-SENSING_START.request primitive is issued by the MAC sublayer to the local PHY entity.

number

[0056] Upon receiving this primitive, the PHY transitions to sensing measurement mode.

[0057] Table 2 below shows the parameters of (SENSING_VECTOR). [Table 2]

[0058] A corresponding PHY-SENSING_START.confirm primitive may also be defined, which is issued by the PHY to the MAC once the PHY transitions to the sensing measurement mode.

[0059] The PHY-SENSING_STOP.request primitive is issued by the MAC sublayer to the local PHY entity to transition the PHY to normal RX mode.

number

[0060] Upon receiving this primitive, the PHY transitions to normal RX mode.

[0061] 22, when a delayed response is allowed, e.g., if the Delayed Response field is set (e.g., to 1) in the measurement request frame 2206 and a sensing responder 2204, e.g., STA2 (11ac+11bf), transmits a measurement PPDU 2210 in the next TXOP (e.g., in TXOP2 2214 instead of TXOP1 2212), the measurement PPDU 2210 can be preceded by an NDP announcement (NDPA) frame 2208, e.g., the sensing responder 2204 can generate an announcement frame before transmitting the measurement PPDU, and the announcement frame can be an NDPA frame 2208 addressed to the sensing initiator 2202 STA1 (11ax+11bf). The NDPA frame 2208 can be transmitted within a certain amount of time (e.g., SIFS) before transmitting the measurement PPDU 2210. Whether an NDPA frame is required before the NDP can also be indicated in the measurement request frame, for example in the NDPA Required field 2020 of the sensing trigger frame 2000 of FIG. 20. If "required" is indicated, the responder transmits an NDPA frame in SIFS before transmitting the NDP. The sensing initiator 2202 issues a PHY-SENSING_START.request primitive to the local PHY entity to transition the PHY into sensing measurement mode only after receiving a valid NDPA frame 2208 addressed to it. For a responder that is an 11n device, the NDPA frame can be any valid frame carrying an HT control field with the HT NDP announcement subfield set to 1. Additionally, the CSD steering subfield of the HT variant HT control field is set to 0 to indicate that feedback is not required. Advantageously, the sensing initiator 2202 does not need to be in sensing measurement mode for an unnecessarily long time.

[0062] FIG. 23 shows an illustration of a VHT NDP Announcement (NDPA) frame 2300 that can be used as the NDPA frame 2208 of FIG. 22. The VHT NDPA frame 2300 can include an RA field 2302 that can be set to the MAC address of the STA that requested the sensing measurement. When a VHT NDP is returned as a measurement PPDU (in solicited measurements), the preceding NDPA frame (e.g., NDPA frame 2300) can carry a single STA Info field 2304 with the AID12 field 2306 set to a special AID (e.g., 2048) to indicate that feedback from the addressed STA is not expected or requested. STAs that receive a VHT NDPA with a single STA Info field with the AID12 subfield set to a special AID (e.g., 2048) can use the subsequent VHT NDP for their own sensing measurements and do not respond with compressed beamforming feedback. If the VHT NDP is used by the AP as a broadcast measurement PPDU for unsolicited measurements that do not require feedback, the preceding NDPA frame (e.g., NDPA frame 2300) may carry a single STA Info field 2304 with AID12 field 2306 set to a special AID (e.g., 2048) to indicate that no feedback is expected. In this case, the RA field 2302 of the NDPA frame 2300 may be set as a broadcast address. Although a VHT NDPA frame is shown as an example, it will be appreciated that the above scenario is equally applicable to an HE NDPA or EHT NDPA frame preceding an HE NDP or EHT NDP.For example, the announcement frame may be a VHT, HE, or EHT NDPA frame addressed to the communication device (e.g., sensing initiator), and the NDPA frame carries a STA information field (e.g., STA Info field 2304) with the AID12 field (e.g., AID12 field 2306) set to a known AID value to indicate that the communication device is not expected to transmit a feedback frame. Alternatively, one or more bits of the Sounding Dialog Token Number field 2308 may be used to indicate that feedback is not expected. Alternatively, a special value (e.g., 255) of the Sounding Dialog Token Number field 2308 may be defined to indicate that feedback is not expected. If the Sounding Dialog Token Number field 2308 is used to indicate that no feedback is expected, the AID12 field 2306 of the STA Info field 2304 may convey the AID of the addressed non-AP STA, or may be set to 0 if addressed to an AP.

[0063] FIG. 24 shows an illustration of an unsolicited measurement process 2400 by a type 1 sensing initiator 2402 (e.g., type 1 STA1 (11ac+11bf)) according to a first embodiment. The sensing initiator 2402 can transmit a measurement PPDU and can ask a responder 2404, e.g., STA2 (11ac+11bf), to provide feedback including sensing measurement results. When a sensing SP is being negotiated, the STAs that are members of the SP, e.g., the sensing initiator 2402, the sensing responder 2404, and the sensing responder 2406 (e.g., STA3 (11ax+11bf)), are expected to be in an awake state (e.g., not in a power-saving doze state) at the start of the sensing SP.

[0064] When a Type 1 STA is a sensing initiator (e.g., sensing initiator 2402), the sensing initiator can obtain sensing measurements using legacy sounding procedures (e.g., VHT beamforming feedback). For example, an 11ac STA such as initiator 2402 can solicit VHT compressed beamforming feedback from two responders 2404 and 2406 by sending a VHT NDPA 2408 and a VHT NDP 2410 at the beginning of a sensing SP. Upon receiving the compressed beamforming feedback (e.g., VHT Compressed Beamforming frame 2412), the sensing initiator 2402 can reconstruct the beamforming feedback matrix V as described in equation (19-79) of non-patent document 4.

[0065] The sensing initiator 2402 can use the beamforming feedback matrix V and the SNR information of the subcarriers to calculate the channel matrix H, i.e., CSI, or can simply use the beamforming feedback matrix V as a representative of the channel. Alternatively, the sensing initiator 2402 can forward the received compressed beamforming feedback matrix to a higher layer sensing app on the same device or to a cloud server for further processing and analysis, where the sensing app is responsible for extracting the channel measurement information from the beamforming feedback matrix. However, since the beamforming feedback is in a compressed form, some information may be lost when the beamforming feedback matrix V is received from the compressed feedback, and the resulting sensing measurements may only be suitable for sensing use cases that do not require high-resolution sensing measurements. In this example, we assume that the feedback is compressed beamforming feedback, which is natively supported by 802.11ac, 802.11ax, and 802.11be as feedback for explicit beamforming feedback. However, it is also possible to upgrade the legacy sounding mechanism such that upon receiving a feedback request (e.g., NDPA, NDP), the sensing responder, instead of responding with compressed beamforming feedback, sends back a feedback frame that carries the CSI matrix (i.e., the original channel measurements, also known as H) in raw or some compressed form. In this case, the NDPA frame 2208 indicates that CSI feedback is requested, for example, using one or more bits from the Sounding Dialog Token field shown in FIG. 23.

[0066] FIG. 25 shows an illustration of an unsolicited measurement process 2500 using a type 1 responder 2504 (e.g., STA2 (11n+11bf)) according to a first embodiment. In this example, a type 2 sensing initiator 2502 (e.g., STA1 (11ax+11bf)) can transmit a measurement PPDU and can ask the responder 2504 to provide feedback of the sensing measurement results. When the sensing responder 2504 is a type 1 STA, the sensing initiator 2502 can obtain the sensing measurement values ​​using a legacy sounding procedure. For example, the sensing initiator 2502 (which is an 11ax STA) can request HT CSI feedback from the sensing responder 2504 (which is an 11n STA) by transmitting an HT NDPA 2506 and an HT NDP 2508 to request CSI feedback 2510. Alternatively, it may request uncompressed / compressed beamforming feedback matrices from 11n STAs.

[0067] FIG. 26 shows a summary diagram 2600 of the sensing phase according to the first embodiment, which shows an example flow of the WLAN sensing phase using solicited measurements with a non-AP STA 2602 as a sensing initiator / receiver and an associated AP 2604 as a sensing responder / transmitter. In step 2606, a beacon / probe response advertising the WLAN sensing capability is transmitted by the AP 2604. Although not shown in FIG. 26, the non-AP STA 2602 also indicates its WLAN sensing capability to the AP 2604 during the association procedure by including its WLAN sensing capability in an association request frame. In step 2608, the STA 2602 transmits a sensing setup request including information of sensing role, TX parameters, and feedback type to the AP 2604. In step 2610, a sensing setup response including status information whether the sensing setup request is accepted or rejected is sent from the AP 2604 to the STA 2602. The setup request / response frame may also include the WLAN sensing capabilities of the participating STAs.

[0068] In optional step 2612, scheduling of sensing SP can be performed. When either STA 2602 or AP 2604 is a type 1 STA, for example, an ADDTS request including a TSPEC element indicating APSD=1 and Schedule=1 is sent from STA 2602 to AP 2604. Then, an ADDTS response including a schedule element indicating a service start time and a service interval is sent from AP 2604 to STA 2602. On the other hand, when both STA 2602 and AP 2604 are type 2 STAs, for example, a TWT setup request including a TWT element indicating sensing TWT SP=1 and including sensing TWT information is sent from STA 2602 to AP 2604. For example, a TWT setup response including a TWT element indicating sensing TWT SP=1 and including sensing TWT information is sent from AP 2604 to STA 2602.

[0069] In step 2614, a sensing measurement request including transmission parameters is sent from the STA 2602 to the AP 2604. In step 2616, a sensing measurement PPDU (e.g., a PPDU carrying an NDP or Data frame, or a PPDU carrying a dedicated management frame defined for sensing) is sent from the AP 2604 to the STA 2602. Steps 2614 and 2616 are performed within each sensing SP, with each sensing SP being separated from the next sensing SP by a sensing SP interval. In optional step 2618, the STA 2602 sends a sensing termination request to the AP 2604 to tear down the sensing session.

[0070] The second embodiment E2 focuses on Type 1 STAs supporting minimal changes to the MAC and MAC-PHY interfaces. For example, in the WLAN sensing deployment diagram 2700 of FIG. 27 with two Type 1 sensing STAs (e.g., air conditioner 2702 and AP 2704) according to the second embodiment, minimal changes can be made to MLME SAPs 2706 and 2708 (e.g., management plane). It is assumed that most of the WLAN sensing intelligence is maintained in the WLAN sensing applications, e.g., WLAN sensing applications 2710 and 2712 located above MACs 2714 and 2716, respectively. Sensing setup can be performed using management frames, while sensing measurements can be performed using sensing application commands conveyed in Data frames (i.e., through MAC SAPs 2718 and 2720).

[0071] FIG. 28 shows an example sensing measurement diagram 2800 using Data frames as measurement PPDUs according to the second embodiment. In this example, sensing discovery and sensing setup are achieved using 11bf compliant MLME primitives. Dedicated 11bf management frames are used during the sensing setup phase, while Data frames carrying higher layer sensing APP commands as payload are used during the sensing measurement phase. Sensing measurements can use a combination of 11bf MLME primitives and higher layer APP commands (e.g., carried in Data frames). The sensing measurement procedure is mostly transparent to the MAC, since the MAC does not understand the contents of the Data frames.

[0072] Further, in FIG. 28, Data frame (xxx) indicates that the sensing APP's (xxx) command is carried in the Data frame as a payload and forwarded to the sensing APP running on the peer STA (e.g., Data frame (sensing measurement request) 2812 indicates that the sensing APP's (sensing measurement request) command is carried in the Data frame 2812 as a payload and forwarded to the sensing APP running on the peer STA, which is STA2 2804). Furthermore, the PPDU carrying the Data frame is also used as a measurement PPDU. In that sense, the measurement phase may be transparent to the MAC layer of the Type-1 STA, except when the PHY is instructed to switch to the sensing measurement mode.

[0073] As shown in FIG. 28, the sensing measurement phase proceeds as follows: The WLAN sensing APP 2806 issues an MA-UNITDATA.request 2828 to trigger the transmission of a Data frame carrying the sensing APP's sensing measurement request command 2812. The WLAN sensing APP 2806 issues an MLME-SENSINGSTART.request primitive 2814 or 2822 to the MAC 2808 to prepare the device (e.g., STA1 2802) for sensing measurement. Upon receiving the MLME-SENSINGSTART.request primitive 2814 or 2822, the MAC 2808 triggers a PHY-SENSING_START.request primitive to put the PHY 2810 into sensing measurement mode. The PHY 2810 returns to normal RX mode upon completion of reception of the measurement PPDU, e.g., Data frame (sensing measurement packet) 2816 or 2824 in this example. Once the MAC 2808 has completed the sensing measurement, it issues an MLME-SENSING.confirm primitive 2818 or 2826 to the sensing APP 2806 and passes the results of the sensing measurement.

[0074] In option 1, a sensing initiator, e.g., a sensing APP of STA1 2802, issues an MLME-SENSINGSTART.request primitive 2814 immediately after receiving an ACK frame for a Data frame (sensing measurement request) 2812 (e.g., a Data frame conveying a sensing measurement request command of the sensing APP) to put the PHY 2810 into sensing measurement mode and waits for a sensing responder, e.g., STA2 2804, to send a Data frame used as a measurement PPDU, e.g., a Data frame (sensing measurement packet) 2816.

[0075] In option 2, the sensing initiator 2802 transmits a Data frame 2812 carrying the sensing APP's sensing measurement request command, and then waits for the responder's Data frame 2820 carrying the sensing APP's sensing measurement response command. Only after receiving the sensing measurement response command, the sensing APP 2802 issues an MLME-SENSINGSTART.request primitive 2822 to put the PHY 2810 into sensing measurement mode. The responder 2804 transmits a Data frame 2824 used as a sensing measurement PPDU only after verifying that the Data frame 2820 carrying the sensing APP's sensing measurement response command has been successfully delivered to the sensing initiator 2802. Option 2 advantageously helps minimize the time the sensing initiator's PHY 2810 needs to be in the sensing measurement mode, and is therefore more attractive to Type 1 STAs that cannot perform normal RX operations when the PHY is in the sensing measurement mode.

[0076] In this example, it is assumed that the sensing receiver's MAC knows when the sensing measurements are to be made (e.g. when it receives an MLME-SENSINGSTART.request primitive) and is therefore able to retrieve the sensing measurement results received from the PHY during this period, even if a Data frame is used as the measurement PPDU, and correctly issue an MLME-SENSING.confirm primitive to the sensing APP to pass on the sensing measurement results.

[0077] As shown in the example of Figure 28, an MLME-SENSINGSTART.request primitive is issued to the MAC sublayer to prepare the device for sensing measurements. Upon receiving the MLME-SENSINGSTART.request primitive, the MAC issues a PHY-SENSING_START.request primitive to put the PHY into sensing measurement mode. The MLME-SENSINGSTART.request primitive can be presented as MLME-SENSINGSTART.request(SENSING_VECTOR), where the parameters of SENSING_VECTOR are as shown in Table 3 below. [Table 3]

[0078] A corresponding MLME-SENSING.confirm primitive is also defined, which is issued by the MAC to upper layers upon receiving confirmation from the PHY that it has transitioned to the sensing measurement mode. However, the receiver may also automatically extract CSI for every received PPDU (i.e. even in normal RX mode) and store these CSI in a temporary table / buffer within the PHY (e.g. in the CSI_TABLE) until it is overwritten when the next PPDU is received, and thus does not require a PHY-SENSING_START.request primitive to switch the PHY to the sensing measurement mode. In such a device, upon receiving the MLME-SENSINGSTART.request primitive, the MAC waits until the PHY indicates that the PPDU was successfully received, and upon verifying that the PPDU is indeed a correct measurement PPDU (e.g., sent by an expected peer STA and carries an expected payload such as a particular type of frame), the MAC can issue a PHY primitive PHY-CSI_RECEIVE.request(CSI_PARAMETER) to instruct the PHY to pass the collected sensing measurements to the MAC (e.g., in a PHY-CSI_RECEIVE.confirm(CSI_MATRIX) primitive). The CSI_PARAMETER can carry a CHAN_MAT_TYPE parameter that specifies the format in which the measurement results are passed to the MAC. Upon receiving the PHY-CSI_RECEIVE.request primitive, the PHY passes the contents of the CSI_TABLE to the MAC in the specified format, e.g., in a CSI_RECEIVE.confirm primitive. If a PPDU carrying a Data frame is used as a measurement PPDU, the sensing APP may indicate this in the MA-UNITDATA.request primitive and also pass the relevant transmission parameters.

number

[0079] The parameters of SENSING_PARAMS are shown in Table 3A. [Table 3A]

[0080] Alternatively, the sensing measurement phase may use a sounding PPDU as the measurement PPDU, as shown in FIG. 29 according to the second embodiment. The WLAN sensing APP (e.g., sensing APP 2906 and 2912) may issue an MLME-SOUNDING.request primitive (e.g., MLME-SOUNDING.request primitive 2918 and 2920, respectively) to the MAC (e.g., MAC 2908 and 2914, respectively) to trigger the transmission of an NDP and optionally an NDPA (e.g., VHT NDP 2922 / VHT NDPA 2924, and VHT NDP 2926 / VHT NDPA 2928, respectively). Upon receiving the MLME-SOUNDING.request primitive, the MAC issues a PHY-TXSTART.request primitive to trigger the transmission of an NDPA and an NDP. In option 1 (solicited measurement), upon receiving a sensing measurement request command (e.g., conveyed in Data frame 2938), an MLME-SOUNDING.request primitive 2920 is issued by the sensing APP 2912 of the sensing responder 2902, with the VHT NDPA 2928 indicating that no feedback is required, whereas in option 2 (unsolicited measurement), an MLME-SOUNDING.request primitive 2918 is issued by the sensing initiator's 2902 own sensing APP 2906, with the VHT NDPA 2924 indicating that feedback is required.

[0081] Once the MAC (e.g., MAC 2908 and 2914) has completed transmitting the NDP, it issues an MLME-SOUNDING.confirm primitive (e.g., MLME-SOUNDING.confirm primitive 2930 and 2932, respectively) to the sensing APP (e.g., sensing APP 2906 and 2912, respectively) to inform the NDP transmission status.

[0082] Once the MAC (e.g., MAC 2908 and 2914) has completed the sensing measurement (performed by itself upon receiving an NDP or upon receiving a feedback report from a peer STA), it issues an MLME-SENSING.confirm primitive (e.g., MLME-SENSING.confirm primitive 2936 and 2934, respectively) to the sensing app (e.g., sensing APP 2906, respectively) to pass the results of the sensing measurement.

[0083] When a sounding PPDU is used as the sensing measurement PPDU, the MAC (e.g., MAC 2908 and 2914) will automatically trigger a PHY-SENSING_START.request primitive to put the PHY (e.g., PHY 2910 and 2916) into sensing measurement mode upon receiving a valid NDPA frame (e.g., VHT NDPA 2928 and VHT NDPA 2924, respectively). The PHY will return to normal RX mode upon completion of receiving the NDP (e.g., VHT NDP 2926 and VHT NDP 2922, respectively).

[0084] The MLME-SOUNDING.request primitive issued to the MAC sublayer to transmit the NDP and optionally the preceding NDPA in the example of Figure 29 may be presented as MLME-SOUNDING.request(SOUNDING_VECTOR). Upon receiving this primitive, the PHY transmits the NDP and optionally the preceding NDPA. The parameters of SOUNDING_VECTOR may be as shown in Table 4 below. [Table 4]

[0085] The MLME-SOUNDING.confirm primitive issued by the MAC sublayer to upper layers to inform the status of the NDP transmission can be presented as MLME-SOUNDING.confirm(STATUS,Peer STA MAC Address). This primitive is issued by the MAC when a second PHY-TXEND.confirm primitive (e.g. corresponding to an NDP) is received from the PHY. STATUS conveys the status that the MAC sublayer provides to upper layers regarding the transmission of the NDP (and optionally the NDPA). If an NDPA was sent, Peer STA MAC Address conveys the MAC address used for the RA(Address 1) field of the NDPA.

[0086] 30 shows an illustration of an example transmission procedure 3000 of a VHT sounding sequence according to the second embodiment. A WLAN sensing APP 3002 issues an MLME-SOUNDING.request(SOUND_VECTOR) primitive 3008 to a MAC 3004 to trigger the transmission of a VHT NDPA 3012 and a VHT NDP 3014.

[0087] Upon receiving the MLME-SOUNDING.request(SOUND_VECTOR) primitive, the MAC 3004 issues a PHY-TXSTART.request(TXVECTOR) primitive 3010 to the PHY 3006 to trigger the transmission of the VHT NDPA 3012. Furthermore, within the SIFS 3018 from the end of the preceding NDPA 3012 transmission, the MAC 3004 issues a PHY-TXSTART.request primitive (e.g., PHY-TXSTART.request(TXVECTOR:PSDU_LENGTH=0) 3016) to the PHY 3006 with the TXVECTOR parameter PSDU_LENGTH set to 0 to initiate the transmission of the VHT NDP 3014. Upon completion of the NDP transmission, the MAC 3004 issues an MLME-SOUNDING.confirm(STATUS) primitive 3020 to the sensing APP 3002 to notify the transmission status.

[0088] In the third embodiment E3, Type 1 STAs do not support changes to the MAC and MAC-PHY interfaces and consider that all WLAN sensing intelligence is maintained in the WLAN sensing application located above the MAC. All sensing operations are performed in Data frames (i.e., through the MAC SAP) and using sensing application commands conveyed via the proprietary WLAN sensing API, e.g., a measurement request frame can be a data frame conveying the measurement request command of the sensing application, i.e., the sensing application command is encapsulated within the Data frame.

[0089] 31 shows an illustration 3100 of an exemplary WLAN sensing deployment having two Type 1 sensing STAs (e.g., AP 3102 and air conditioner 3104) according to the third embodiment described above. In this case, sensing modules 3106 and 3108 can be a very light layer located within or above the 802.11 upper MAC, providing an interface between the WLAN sensing application (e.g., WLAN sensing application 3110 and 3112, respectively) and the 802.11 MAC / PHY (e.g., 802.11 MAC / PHY 3114 and 3116, respectively). For example, the sensing modules 3106 and 3108 may assist in translating the proprietary sensing APP command PRPTY-SENSINGSTART.request into the appropriate 802.11 vendor-specific API to place the 802.11 PHY (e.g., the 802.11 PHY of 802.11 MAC / PHY 3114 and 3116, respectively) into sensing measurement mode in order to prepare the PHY for reception of a sensing measurement PPDU. Similarly, when the PHY / MAC (e.g., 802.11 MAC / PHY 3114 and 3116, respectively) receives a sensing measurement PPDU, the sensing module (e.g., sensing modules 3106 and 3108, respectively) assists in converting the sensing measurement results (e.g., CSI) into a format understood by the WLAN sensing application (e.g., WLAN sensing application 3110 and 3112, respectively) and triggers a PRPTY-SENSING.confirm sensing app command to forward the results to the WLAN sensing application (e.g., WLAN sensing application 3110 and 3112, respectively).

[0090] FIG. 32 shows a diagram 3200 of the sensing measurement process according to the third embodiment. In this example, all sensing-related signaling is conveyed to the remote peer STA (e.g., STA1 3202 or STA2 3204) in a Data frame or passed to the local MAC via a proprietary API. Sensing-related operations are transparent to the 802.11 MAC / PHY (e.g., MAC / PHY 3206 and MAC / PHY 3208, respectively). This deployment may be the only option for devices that are not capable of upgrading with 11bf-related features. Two proprietary APIs can be provided by the MAC (MAC of MAC / PHY 3206 and MAC of MAC / PHY 3208, respectively) to the sensing APP (SENSING APP 3210 and SENSING APP 3212, respectively). 1) PRPTY-SENSINGSTART.request (PRPTY-SENSINGSTART.request 3214 in option 1 or 3216 in option 2) is issued by APP 3210 to the MAC to instruct the MAC / PHY 3206 to perform sensing measurements on subsequently received PPDUs. Upon receiving a PRPTY-SENSINGSTART.request 3214 or 3216, the MAC switches the PHY into sensing measurement mode by setting some hardware registers to known values. 2) PRPTY-SENSING.confirm (PRPTY-SENSING.confirm 3218 in option 1, 3220 in option 2) is issued by the MAC / PHY 3206 to forward the results of the sensing measurements (e.g., CSI) to the sensing APP 3210. In some implementations, the sensing measurements can be passed to the APP 3210 by appending them to the payload of a received Data frame or by replacing the payload of a Data frame with the sensing measurement results.

[0091] Furthermore, if a sensing SP has been negotiated (e.g., sensing SP 3222 in option 2), the sensing measurement request can be advantageously omitted and the sensing transmitter (e.g., STA2 3204) proceeds directly to sending sensing measurement packets (e.g., sensing measurement packets 3224 and 3226) at the start of sensing SP 3222, while the sensing initiator (e.g., STA2 3202) puts its PHY into sensing measurement mode at the start of sensing SP 3222.

[0092] In a fourth embodiment E4, referring to the diagram 3300 of FIG. 33, consider a deployment with a Type 2 STA (e.g., AP 3302, which is a Type 2 sensing STA) and a Type 1 STA (e.g., air conditioner 3304, which is a Type 1 sensing STA). The Type 1 STA 3304 supports minimal changes to the MAC and MAC-PHY interfaces, and assumes that the majority of the WLAN sensing intelligence is maintained in the WLAN sensing application 3308 located above the MAC. No changes are made to the MLME SAP 3306 (management plane). Sensing measurements are performed (for Type 1 STA 3304) using sensing application commands carried in Ethertype 89-0d Data frames and via a proprietary WLAN sensing API, e.g., the measurement request frame can be an Ethertype 89-0d Data frame.

[0093] FIG. 34 shows an illustration of an Ethertype 89-0d frame 3400 according to the fourth embodiment. The Ethertype 89-0d frame 3400 is an 802.11 Data frame with the Ethertype subfield (not shown) of the Subnetwork Access Protocol (SNAP) field 3402 set as 89-0d (IEEE standard 802.11). A measurement request frame can be transmitted as the payload of the Ethertype 89-0d frame 3400. The main difference between using an Ethertype 89-0d frame and using a normal 802.11 Data frame is that the 802.11 MAC can understand the Ethertype 89-0d frame, and therefore can perform sensing measurements using the sensing application commands carried in the Ethertype 89-0d Data frame. Type 2 STAs can understand the WLAN SENSING Ethertype 89-0d frame, but Type 1 STAs may not be able to understand it if they cannot upgrade their MAC.

[0094] In the Payload Type field 3404 of the Ethertype 89-0d frame 3400, a new Ethertype 89-0d payload type for WLAN sensing can be defined, for example, the Payload Type field 3404 can be set to "5" to indicate WLAN sensing, as shown in table 3406. Further, the Payload field 3408 can include a WLAN sensing packet type field 3410 and a Type specific Payload field 3412. The WLAN sensing packet type field 3410 can be set to any one of values ​​0 to 7 to indicate a packet type, as shown in table 3414, and the Type specific Payload field 3412 can be used to convey additional parameters related to each WLAN sensing packet type shown in table 3414. While other WLAN SENSING packets can carry type-specific payloads, the sensing measurement packet may not contain any payload since it is only used to measure the channel based on the PHY preamble. Also, instead of defining a WLAN SENSING packet for sensing measurements, it is also possible to use any Data frame as the sensing measurement packet, for example a QoS Null Data frame with ACK policy set to No Ack.

[0095] 35 shows an illustration 3500 of an exemplary WLAN sensing procedure between a type 1 STA (STA1, a non-AP STA) as a sensing initiator and a type 2 STA (STA2, which can be an AP or another non-AP STA) as a sensing responder according to the fourth embodiment. In this example, STA1 3502 is a type 1 STA with an 11n PHY, and STA2 3504 is a type 2 AP that can understand WLAN SENSING Ethertype 89-0d frames at the MAC layer and therefore can respond directly (without having to forward these frames up to the sensing APP). Furthermore, STA1 3502 is the sensing initiator and STA2 3504 is the sensing responder.

[0096] Being a type 2 sensing STA, the MAC of STA2 3504 can understand and respond directly to WLAN sensing Ethertype 89-0d frames, e.g., responding to an Ethertype 89-0d frame (sensing capability request) 3506 from STA1 3502 with an Ethertype 89-0d frame (WLAN sensing capability) 3508, and responding to an Ethertype 89-0d frame (sensing setup request) 3510 from STA1 3502 with an Ethertype 89-0d frame (sensing configuration response) 3512. Additionally, STA2 3504 may respond to a sensing measurement request (e.g., an Ethertype 89-0d frame (sensing measurement request) 3514 from STA1 3502) with a data frame (e.g., an Ethertype 89-0d frame (sensing measurement packet) 3516 in option 1) or a sounding PPDU (e.g., an HT NDP 3520 (and optionally an HT NDPA 3518) in option 2).

[0097] FIG. 36 shows an illustration 3600 of an exemplary WLAN sensing procedure between a type 1 STA (STA1 3602) as a sensing responder and a type 2 STA (sensing initiator STA2 3604) as a sensing initiator according to the fourth embodiment. As in the previous example of FIG. 35, STA1 3602 is a type 1 STA with 11n PHY, and STA2 3604 is a type 2 STA (either AP or non-AP) that can understand WLAN SENSING Ethertype 89-0d frames at the MAC layer and therefore can respond directly (e.g., without having to forward these frames up to the sensing APP). In this example, STA2 3604 is the sensing initiator. In this case, STA1 3602 is a non-AP STA, so it does not transmit beacon frames and may not include WLAN sensing capabilities in its MAC frames (e.g., in association request frames or probe request frames) if its MAC has not been upgraded by the 11bf discovery protocol. In such a case, a dedicated MLME can be defined in 11bf to discover such type-1 STAs. For example, an MLME-SENSINGCAPABILITY.request primitive 3606 is used by the APP of STA2 3604 to instruct the 11bf MAC of STA2 3604 to send a frame used to solicit WLAN sensing capabilities from a peer STA (e.g., STA1 3602), such as a WLAN SENSING Ethertype 89-0d frame (sensing capability request) 3608, and an MLME-SENSINGCAPABILITY.confirm primitive 3612 is issued by the 11bf MAC of STA2 3604 to pass the discovered WLAN sensing capabilities (e.g., from the Ethertype 89-0d frame (WLAN sensing capability) 3610 sent from STA1 3602) to the APP of STA2 3604.If the WLAN sensing capabilities indicate that STA1 supports solicited measurements, an MLME-SENSINGMEASUREMENT.request primitive 3614 is issued by the APP of STA2 3604 to instruct the 11bf MAC of STA2 3604 to transmit a sensing measurement request frame (e.g., an Ethertype 89-0d frame (Sensing Measurement Request) 3616) to STA1 3602 to request a measurement PPDU to be used for WLAN sensing. The MLME-SENSINGMEASUREMENT.request primitive 3614 (and the transmitted sensing measurement request frame 3616) indicates to STA1 3602 the type of PPDU being requested. If STA1 3602 indicates support for the NDP measurement PPDU, then the MAC / PHY of STA1 3602 may support a proprietary API that may be used to trigger the transmission of an NDPA / NDP (e.g., HT NDPA 3620 and HT NDP 3622 in option 2); otherwise, the MAC / PHY may transmit an Ethertype 89-0d Data frame (e.g., Ethertype 89-0d Frame (Sensing Measurement Packet) 3618 in option 1) as the measurement PPDU. As can be seen from these two examples, even if a Type 1 STA (e.g., a .11 device with a legacy PHY) does not support .11bf MAC / PHY functionality, such a STA may still advantageously participate in WLAN sensing, with or without the use of a minimal proprietary API.

[0098] In E2-E4, most of the examples presented were about sensing between an AP and a non-AP STA. When both STAs of a sensing STA pair are non-AP STAs, it may not be possible to send Data frames or WLAN SENSING Ethertype frames used to convey commands of the sensing APP directly to the peer STA (unless the two non-AP STAs have already negotiated a peer-to-peer protocol such as Tunnelled Direct Link Setup (TDLS)). In such a case, the Data frame can be forwarded to the peer STA via a common associated AP (called AP path), i.e., the initiating non-AP STA sends a Data frame to the AP with Address 3 (DA) set as the MAC address of the destination non-AP STA. The only exception is the Data frame used as a measurement PPDU, which is sent directly (called direct path) to the peer STA (i.e., Address 1 (RA) is set as the MAC address of the non-AP STA). It is also possible to define the response frame used during sensing discovery to be a public management action frame sent to the peer non-AP STA via the direct path. Such a definition can be made to allow the initiator to estimate whether the discovered peer STA (responder) is within the initiator's coverage range and whether a direct link is suitable for WLAN sensing purposes.

[0099] 37 shows a flow diagram 3700 illustrating a method of communication according to various embodiments. In step 3702, a measurement request frame is received, the measurement request frame carrying a delayed response field indicating whether a delayed response is allowed. In step 3704, in response to the measurement request frame, a measurement PPDU is transmitted to be used for channel measurement.

[0100] 38 illustrates a partially boxed schematic diagram of a communication device 3800 that can be implemented for low-complexity WLAN sensing according to the first to fourth embodiments. The communication device 3800 can be implemented as a STA or an AP according to various embodiments.

[0101] The various functions and operations of the communication device 3800 are arranged in layers according to a hierarchical model, where lower layers report to and receive instructions from higher layers according to IEEE specifications, and for the purposes of brevity, the details of the hierarchical model are not described in this disclosure.

[0102] As shown in FIG. 38, the communication device 3800 may include a circuit 3814, at least one wireless transmitter 3802, at least one wireless receiver 3804, and multiple antennas 3812 (for simplicity, only one antenna is depicted in FIG. 38 for illustrative purposes). The circuit may include at least one controller 3806, which is used to perform the tasks it is designed to perform with the aid of software and hardware, including controlling communications with one or more other multi-link devices in a MIMO wireless network. The at least one controller 3806 may control at least one transmit signal generator 3808 to generate frames to be transmitted via the at least one wireless transmitter 3802 to one or more other STAs or APs, and may further control at least one receive signal processor 3810 to process frames received via the at least one wireless receiver 3804 from one or more other STAs or APs. At least one transmit signal generator 3808 and at least one receive signal processor 3810 may be independent modules of the communication device 3800 that communicate with at least one controller 3806 for the above-mentioned functions. Alternatively, at least one transmit signal generator 3808 and at least one receive signal processor 3810 may be included in at least one controller 3806. It will be understood by those skilled in the art that the arrangement of these functional modules is flexible and may vary according to actual needs and / or requirements. The data processing device, storage device, and other related control devices may be provided on a suitable circuit board and / or chipset.

[0103] In various embodiments, during operation, the at least one wireless transmitter 3802, the at least one wireless receiver 3804, and the at least one antenna 3812 can be controlled by at least one controller 3806. Additionally, while only one wireless transmitter 3802 is shown, it will be understood that there may be multiple such transmitters.

[0104] In various embodiments, in operation, the at least one wireless receiver 3804 together with the at least one receive signal processor 3810 form a receiver of the communications device 3800. In operation, the receiver of the communications device 3800 provides the functionality necessary for sensing operations. Although only one wireless receiver 3804 is shown, it will be understood that there may be multiple such receivers.

[0105] In operation, the communication device 3800 provides functionality necessary for low-complexity WLAN sensing. For example, the communication device 3800 may be a first communication device. In operation, the receiver 3804 may receive a measurement request frame from a second communication device, the measurement request frame carrying a delayed response field indicating whether a delayed response is allowed. In operation, the transmitter 3802 transmits a measurement PPDU used for channel measurement in response to the measurement request frame.

[0106] The transmitter 3802 may be further configured to transmit the measurement PPDU at a next transmission opportunity when the delayed response field indicates that a delayed response is permitted. In operation, the circuit 3814 may generate an announcement frame prior to transmitting the measurement PPDU, the announcement frame may be a VHT, HE or EHT NDPA frame addressed to the second communication device, the NDPA frame carrying a STA information field with an AID12 field set to a known AID value to indicate that the second communication device is not expected to transmit a feedback frame. The transmitter 3802 may be further configured to transmit the announcement frame within a certain length of time prior to transmitting the measurement PPDU.

[0107] In operation, the circuitry 3814 can detect the start of a padding field when the delayed response field indicates that a delayed response is not allowed and the measurement request frame further carries a padding field, and in response to the detection, the transmitter 3802 can be further configured to transmit a measurement PPDU within a certain length of time after the measurement request frame is received. The padding field can further carry a CRC calculated based on the contents of the measurement request frame.

[0108] The receiver 3804 may be further configured to receive the measurement request frame as a payload of an 802.11 Data frame, the 802.11 Data frame including a SNAP field including an Ethertype subfield, the Ethertype subfield set as 89-0d. The first communication device 3800 may be further configured to advertise itself as being either a Type 1 or Type 2 device, a Type 1 device being less capable than a Type 2 device, the delayed response field being set to indicate that a delayed response is allowed if the first communication device 3800 is a Type 1 device, and set to indicate that a delayed response is not allowed if the first communication device 3800 is a Type 2 device. The first communication device 3800 may be further configured to advertise a response delay, the response delay being set to 0 to indicate that the first communication device 3800 may transmit a measurement PPDU within SIFS from receiving the measurement request frame, and set to a non-zero value otherwise. The transmitter 3802 may be further configured to transmit the measurement PPDU as one of an NDP or any 802.11 PPDU carrying a Data frame. The first communication device 3800 may be further configured to advertise whether it is capable of transmitting the measurement PPDU upon receipt of the measurement request frame, and if so, further advertise a type of measurement PPDU it is capable of transmitting, the type of measurement PPDU being an NDP or an 802.11 PPDU carrying a Data frame.

[0109] The first communication device 3800 may be further configured to negotiate, during the setup phase, one or more time windows for performing sensing measurements with the second communication device. The one or more negotiated time windows may be scheduled S-APSD SPs. The one or more negotiated time windows may be TWT SPs.

[0110] The measurement request frame may be a Data frame carrying a measurement request command of a sensing application. The measurement request frame may be an Ethertype 89-0d Data frame. For example, the communication device 3800 may be a second communication device. The receiver 3804 may receive information related to a first communication device during operation. The circuit 3814 may generate a measurement request frame based on the information during operation, the measurement request frame carrying a delayed response field indicating whether a delayed response is allowed. The transmitter 3802 may transmit the measurement request frame to the first communication device during operation. The information may indicate a response delay, the response delay being set to 0 to indicate that the first communication device may transmit a measurement PPDU within a SIFS from receiving the measurement request frame, otherwise the response delay is set to a non-zero value. The circuit 3814 may be further configured to classify the first communication device as a Type 2 device if the response delay is set to 0, classify the first communication device as a Type 1 device if the response delay is set to a non-zero value, and set the delayed response field to indicate that a delayed response is allowed if the first communication device is classified as a Type 1 device and to indicate that a delayed response is not allowed if the first communication device is classified as a Type 2 device. The information may indicate a PHY of the first communication device, and the circuit 3814 may be further configured to classify the first communication device as a Type 1 device if the PHY is based on 802.11n or 802.11ac, and to classify as a Type 2 device if the PHY is based on 802.11ax or 802.11be, and set the delayed response field to indicate that a delayed response is allowed if the first communication device is classified as a Type 1 device and to indicate that a delayed response is not allowed if the first communication device is classified as a Type 2 device.

[0111] The present disclosure can be implemented by software, hardware, or software cooperating with hardware. Each functional block used in the description of each embodiment above can be implemented in part or in whole by an LSI such as an integrated circuit, and each process described in each embodiment can be controlled in part or in whole by the same LSI or a combination of LSIs. The LSI can be formed as multiple chips individually, or a single chip can be formed to include some or all of the functional blocks. The LSI can include a data input / output unit coupled to it. Depending on the degree of integration, the LSI can also be called an IC, a system LSI, a super LSI, or an ultra LSI. However, the technology for implementing the integrated circuit is not limited to the LSI, and can be implemented by using a dedicated circuit, a general-purpose processor, or a dedicated processor. Furthermore, an FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connections and settings of the circuit cells arranged inside the LSI, can also be used. The present disclosure can be implemented as digital processing or analog processing. If a future integrated circuit technology replaces LSI as a result of advances in semiconductor technology or other derivative technologies, the future integrated circuit technology can be used to integrate the functional blocks. Biotechnology can also be applied.

[0112] The present disclosure may be implemented by any type of apparatus, device, or system having communication capabilities, referred to as a communications device.

[0113] Some non-limiting examples of such communications devices include phones (e.g., mobile phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, e-book readers, telehealth / telemedicine devices, vehicles that provide communications capabilities (e.g., cars, airplanes, ships), and various combinations of these.

[0114] Communications devices are not limited to being portable or portable, but can also include any type of apparatus, device, or system that is non-portable or stationary, such as smart home devices (e.g., appliances, lights, smart meters, control panels), vending machines, and any other "things" in the network of the "Internet of Things" (IoT).

[0115] Communications may include, for example, exchanging data through cellular systems, wireless LAN systems, satellite systems, and various combinations thereof.

[0116] A communications device may include devices such as a controller or sensors coupled to the communications device to perform the communications functions described in this disclosure. For example, a communications device may include a controller or sensors that generate control or data signals used by the communications device to perform the communications functions of the communications device.

[0117] The communications devices may further include infrastructure facilities, such as base stations, access points, and any other apparatus, devices, or systems that communicate with or control apparatus such as the apparatus in the non-limiting examples above.

[0118] A non-limiting example of a station may be a station included in a first plurality of stations belonging to a multi-link station logical entity (i.e., MLD, etc.), where the stations of the first plurality of stations, as part of the first plurality of stations belonging to the multi-link station logical entity, share a common Medium Access Control (MAC) data service interface to higher layers, where the common MAC data service interface is associated with a common MAC address or traffic identifier (TID).

[0119] Thus, it can be seen that the present embodiment provides a communication apparatus and method for low-complexity WLAN sensing.

[0120] In the above detailed description of the embodiments of the present invention, exemplary embodiments have been presented, but it should be understood that a vast number of variations exist. Furthermore, it should be understood that the exemplary embodiments are examples and are not intended to limit the scope, applicability, operation, or configuration of the present disclosure in any way. Rather, the above detailed description provides those skilled in the art with a convenient guide for implementing the exemplary embodiments. It should be understood that various changes can be made in the function and organization of the steps and methods of operation described in the exemplary embodiments, and in the modules and structures of the devices described in the exemplary embodiments, without departing from the scope of the subject matter described in the appended claims.

Claims

1. A first communication device, comprising: a receiver configured to receive a beacon or a probe response advertising WLAN sensing capability transmitted from a second communication device; a transmitter configured to transmit a sensing request including at least one of a sensing role, TX parameters, and feedback type information to the second communication device; The first communication device comprising the above.

2. The receiver is configured to receive a measurement request frame from a second communication device, The transmitter is configured to transmit a measurement physical protocol data unit (PPDU) used for channel measurement in response to the measurement request frame, The first communication device according to claim 1.

3. The transmitter is configured to be able to transmit the measurement PPDU in the next transmission opportunity, The first communication device according to claim 2.

4. The transmitter is configured to be able to transmit the measurement PPDU within a certain time period after the measurement request frame is received, The first communication device according to claim 2.

5. Further comprising a circuit configured to generate an announcement frame before transmitting the measurement PPDU, The announcement frame is a VHT (Very High Throughput), HE (High Efficiency), or EHT (Extremely High Throughput) null data packet announcement (NDP A) frame addressed to the second communication device, and the NDP A frame conveys a STA information field with the AID12 field set to a known association identifier (AID) value to indicate that the second communication device is not expected to transmit a feedback frame, The first communication device according to claim 3.

6. The transmitter is further configured to transmit the announcement frame within a certain time period before transmitting the measurement PPDU, The first communication device according to claim 5.

7. The receiver is further configured to receive the measurement request frame as the payload of an 802.11 Data frame, The 802.11 Data frame includes a Subnetwork Access Protocol (SNAP) field that includes an Ethertype subfield, and the Ethertype subfield is set as 89-0d. The first communication device according to claim 2. **Claim 8** The transmitter is further configured to transmit the measurement PPDU as one of a Null Data Packet (NDP) or any 802.11 PPDU that conveys a Data frame. The first communication device according to claim 2. **Claim 9** Advertise whether it can transmit a measurement PPDU when receiving a measurement request frame, If it is advertised that it can transmit, further advertise the type of measurement PPDU that it can transmit, The type of the measurement PPDU is an NDP or an 802.11 PPDU that conveys a Data frame. The first communication device according to claim 2. **Claim 10** It is further configured to negotiate with the second communication device one or more time windows for performing sensing measurements before a measurement phase. The first communication device according to claim 2. **Claim 11** The one or more time windows to be negotiated are a scheduled Automatic Power Save Delivery (S-APSD) service period (SP). The first communication device according to claim 10. **Claim 12** The one or more time windows to be negotiated are a Target Wake Time (TWT) service period (SP). The first communication device according to claim 10. **Claim 13** The measurement request frame is a Data frame that conveys a measurement request command for a sensing application. The first communication device according to claim 2. **Claim 14** The measurement request frame is an Ethertype 89-0d Data frame. The first communication device according to claim 2. **Claim 15** A second communication device, A transmitter configured to transmit a beacon or a probe response that advertises WLAN sensing capabilities, A receiver configured to receive information related to the first communication device, and The receiver receives, as the information, a sensing request including at least one of sensing role, TX parameters, and feedback type information transmitted from the first communication device. The second communication device. **Claim 16** The apparatus further comprises a circuit configured to generate a measurement request frame based on information received by the receiver. The transmitter is configured to transmit the measurement request frame to the first communication device. The second communication device according to claim 15. **Claim 17** A communication method, comprising: receiving, from a communication device, a beacon or a probe response advertising WLAN sensing capability; transmitting, to the communication device, a sensing request including at least one of sensing role, TX parameter, and feedback type information; A method comprising the above steps. **Claim 18** receiving a measurement request frame from the communication device; responding to the measurement request frame by transmitting a measurement physical protocol data unit (PPDU) used for channel measurement; The method according to claim 17, further comprising the above steps.

Images