IEEE 802.11-22/2065r2 Timestamp Discussion

 
Timestamp Discussion
 
Date:
 December 19, 2022
 
Slide 1
 
 Author:
 
December 2022
 
Chris Beg, Cognitive Systems
 
December 2022
 
Chris Beg, Cognitive Systems
 
Slide 2
 
Abstract
 
Collect member feedback for PDT development on:
Need for measurement timestamp
Timestamping at Receiver vs Transmitter
Timestamp Generation
 
Topic 1: Need for Measurement Timestamp
 
Slide 3
 
Chris Beg, Cognitive Systems
 
December 2022
 
Topic 1: Need for Measurement Timestamp
 
TB measurement instance schedule based on Availability
Window, which can occur anywhere within negotiated 10ms
interval.
non-TB measurement instance schedule based on whenever
the medium is available with constraint of “a minimum time
interval”
Timestamp is useful to accurately place measurements on
time axis, which will improve ability for application to
measure doppler [1].
 
Slide 4
 
Chris Beg, Cognitive Systems
 
December 2022
 
Topic 1: Need for Measurement Timestamp
 
For DMG “reference timestamp” field always present in
Sensing Report Header sub element
Design options for non-DMG:
1.
Timestamp is always present in report
2.
Application negotiates optional presence of timestamp
3.
Inclusion is implementation decision, signaled through capability bits
If timestamp is always present, no complexity added to
signal or negotiate its inclusion, and we align DMG and non-
DMG reports
Sensing Measurement Report field can be as large as 40416
bytes [3], so tradeoff of overhead of (1) vs (2)/(3) is small
Given application benefits from timestamp, preference is (1)
 
Slide 5
 
Chris Beg, Cognitive Systems
 
December 2022
 
Topic 2: Timestamp at Transmitter or Receiver
 
Slide 6
 
Chris Beg, Cognitive Systems
 
December 2022
 
(b.1) Timestamp Derived by Receiver
 
(b.2) Timestamp Derived by Transmitter
 
Sensing Receiver
 
Sensing Transmitter
 
Sensing Receiver
 
Sensing Transmitter
 
1
 
2
 
3
 
1
 
2
 
(1) Build Measurement Report
        
- Add corresponding RX Timestamp
 
(2) Output Received Report
        - Deliver output to Sensing Application
 
(1) Record TX timestamp
        - Maintain lookup table mapping identifier to TX timestamp
 
(2) Build Measurement Report
      - NO Timestamp in report
 
(3) Obtain TX timestamp from (1) given identifier in report
        - Deliver output to Sensing Application
 
Slide 7
 
Chris Beg, Cognitive Systems
 
December 2022
 
In cases where no over-the-air report is required, Sensing Receiver will generate timestamp
Adding complexity to timestamp on Sensing Transmitter saves overhead of including timestamp in report,
however savings is minimal given total report may span multiple MPDUs.
In SBP cases where AP is Sensing Transmitter, a TX timestamp would require AP to manipulate received
report and insert timestamp before forwarding to SBP initiator.
In R2R case, Sensing Transmitter may not have opportunity to add timestamp into report.  As a result, AP
would need to manipulate report to insert timestamp before forwarding to application.
 
Topic 2: Timestamp at Transmitter or Receiver
 
To unify all reporting flows, having the receiver timestamp the measurement and include it in the report is
the simplest and most consistent.
 
Topic 3: Timestamp Generation
 
It is not required that the sensing application receive
timestamps fully synchronized among all participants
For measuring the doppler, the delta timestamp from each
STA is important
An additional level of clock synchronization beyond the TSF
clock management is NOT required for participating STAs
Existing mechanisms already defined in .11 specs for both associated and
non-associated STAs
 
 
Slide 8
 
Chris Beg, Cognitive Systems
 
December 2022
 
Topic 3: Timestamp Generation
 
Summary of TS accuracy requirements given use-cases in [2]
 
Slide 9
 
Chris Beg, Cognitive Systems
 
December 2022
 
Accuracy required ranges from 
115.2us 
to
 
7.2ms
 
Topic 3: Timestamp Generation
 
To justify length of timestamp, consider time between measurements
 
Slide 10
 
Chris Beg, Cognitive Systems
 
December 2022
 
TB instance schedule based on Availability Window:
    RSTA Availability Window Element in Sensing Measurement Setup Request:
 
Non-TB instance schedule up to STA, with Max Time Between Measurement:
 
Range (0 to ~838.9s)
 
Topic 3: Timestamp Generation
 
Options for slicing TSF to generate timestamp
 
Slide 11
 
Chris Beg, Cognitive Systems
 
December 2022
 
Timestamp length to prevent multiple wrap-around between two measurements:
 
Note: non-TB case is “minimum time between measurements”, and actual time may be more
 
2 extra bits to allow for larger time for non-TB case, and potential missed measurement
 
Topic 3: Timestamp Generation
 
Current Report Control field contains 32-bits, with 4 reserved
Proposal for using 2x reserved bits to encode Rx_OP_Gain_Type (22-2116)
 
Slide 12
 
Chris Beg, Cognitive Systems
 
December 2022
 
To keep byte aligned, need to add 32 bits regardless
Can either use all 32-bits for timestamp, or mark some as reserved
Proposal to use Option (A), allowing for 1us resolution, 4-bytes to match with DMG format
 
Option (A) – Append 32-bits
--------------------------------------------------------------------------------------------------------------------------------------------------
| Report Control Length | Presence and control bitmap |  CW  |  N_TX  |  N_RX  |  N_b  |   I_ng   |  RX_OP_Gain_Type  |  reserved  |  Timestamp  |
--------------------------------------------------------------------------------------------------------------------------------------------------
              8                       8                  4       3        3        1        1              2                2           32
 
Option (B) – Pack and pad for byte-alignment
--------------------------------------------------------------------------------------------------------------------------------------------------
| Report Control Length | Presence and control bitmap |  CW  |  N_TX  |  N_RX  |  N_b  |   I_ng   |  RX_OP_Gain_Type  |  Timestamp  |  reserved  |
--------------------------------------------------------------------------------------------------------------------------------------------------
              8                       8                  4       3        3        1        1              2                 27           7
 
Topic 3: Timestamp Generation
 
Proposal:
The timestamp can be derived from the STAs local clock with the same
resolution and accuracy/drift as its existing TSF clock
1us resolution (+/- 100ppm accuracy)
A 4-byte timestamp can be used like the DMG report format
Associated STAs may synchronize their timestamp relative to the AP’s
clock by using the TSF in Beacon frames
Non-Associated STAs may synchronize their timestamp relative to the
AP’s clock by using the Partial TSF in the Trigger/NDPA (defined in 11az
and required to keep synchronization with the Availability Window)
Initial AP TSF may be obtained via beacon or probe request.
The Partial TSF defined in 11az is 16-bits and represent TSF[21:6], which
provides a resolution of 32us.
Partial TSF may be used to help maintain synchronization to AP time
Timestamp corresponds to start of the SI2SR or SR2SI NDP preamble
 
Slide 13
 
Chris Beg, Cognitive Systems
 
December 2022
 
SP1
 
Do you agree to the following design approach:
Timestamp is always present in Sensing Report
Timestamp is generated by Sensing Receiver
Timestamp corresponds to start of the SI2SR or SR2SI NDP preamble
Timestamp is generated from local clock of STA:
Same resolution, and accuracy/drift requirements as TSF
1us resolution (+/- 100ppm accuracy)
Same width as DMG reported timestamp (4 bytes)
Associated STAs may synchronize their timestamp relative to the AP’s
clock by using the TSF mechanisms
Non-Associated STAs may synchronize their timestamp relative to the
AP’s clock by using the Partial TSF in the Trigger/NDPA
Yes/No/Abstain = 7/2/8
 
Slide 14
 
Chris Beg, Cognitive Systems
 
November 2022
 
SP2
 
Do you agree to the following design approach:
Timestamp is always present in Sensing Report
 
Yes/No/Abstain = 7/4/6
 
Slide 15
 
Chris Beg, Cognitive Systems
 
November 2022
 
November 2022
 
Chris Beg, Cognitive Systems
 
Slide 16
 
References
 
[1] 
D. Yang, T. Wang, Y. Sun and Y. Wu, "Doppler Shift
Measurement Using Complex-Valued CSI of WiFi in
Corridors," 
2018 3rd International Conference on Computer and
Communication Systems (ICCCS)
, 2018, pp. 367-371, doi:
10.1109/CCOMS.2018.8463285.
[2] 11-20-1712-02-00bf-wifi-sensing-use-cases.xlsx
[3] 11-22-1020-05-00bf-pdt-formatting-of-csi.docx
Slide Note

This presentation is making the assumption that a sensing measurement timestamp is necessary. Contribution 3 of the memo was the “Should vs Shall” discussion. If you believe that it will take several slides to illustrate what is lost by not having a timestamp at all, or by the timestamp being optional, then it would be better to have a second contribution about the “what if we didn’t have any timestamp”.

This contribution combines the TX discussion with the RX discussion, which was contributions 1 and 2 from the memo. https://qipworks.box.com/s/ccsiiwcbcl413byixdyd06emmr0e0963

Embed
Share

In the December 2022 IEEE document, Chris Beg of Cognitive Systems discusses the need for measurement timestamping at the receiver vs. transmitter for signal measurement applications like WLAN sensing and Doppler estimation. The document outlines the importance of timestamp placement for accurate measurements and proposes design options for incorporating timestamps in sensing reports. Various scenarios and considerations regarding timestamp generation and utilization are explored, shedding light on the challenges and benefits associated with timestamping in digital signal processing.


Uploaded on Sep 07, 2024 | 2 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. December 2022 doc.: IEEE 802.11-22/2065r2 Timestamp Discussion Date: December 19, 2022 Author: Name Chris Beg Affiliations Cognitive Systems Address Phone email chris.beg@cognitivesystems.com mohammad.omer@cognitivesystems.com Mohammad Omer Cognitive Systems anirudha.sahoo@nist.gov Anirudha Sahoo NIST Submission Slide 1 Chris Beg, Cognitive Systems

  2. December 2022 doc.: IEEE 802.11-22/2065r2 Abstract Collect member feedback for PDT development on: Need for measurement timestamp Timestamping at Receiver vs Transmitter Timestamp Generation Submission Slide 2 Chris Beg, Cognitive Systems

  3. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 1: Need for Measurement Timestamp Traditional Digital Audio/RF/etc. Measurement Signal (Volts) Signal (Volts) ADC time time Tsample Well Controlled (low jitter) Tsample WLAN Sensing Doppler Measurement Example Doppler (Radians) Doppler Estimate .11bf Doppler (Radians) time Spacing adjusted from report timestamps Report Sampling gated by: - spectrum availability - scheduling (priorities) - STA availability time Submission Slide 3 Chris Beg, Cognitive Systems

  4. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 1: Need for Measurement Timestamp TB measurement instance schedule based on Availability Window, which can occur anywhere within negotiated 10ms interval. non-TB measurement instance schedule based on whenever the medium is available with constraint of a minimum time interval Timestamp is useful to accurately place measurements on time axis, which will improve ability for application to measure doppler [1]. Submission Slide 4 Chris Beg, Cognitive Systems

  5. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 1: Need for Measurement Timestamp For DMG reference timestamp field always present in Sensing Report Header sub element Design options for non-DMG: 1. Timestamp is always present in report 2. Application negotiates optional presence of timestamp 3. Inclusion is implementation decision, signaled through capability bits If timestamp is always present, no complexity added to signal or negotiate its inclusion, and we align DMG and non- DMG reports Sensing Measurement Report field can be as large as 40416 bytes [3], so tradeoff of overhead of (1) vs (2)/(3) is small Given application benefits from timestamp, preference is (1) Submission Slide 5 Chris Beg, Cognitive Systems

  6. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 2: Timestamp at Transmitter or Receiver (b.1) Timestamp Derived by Receiver (b.2) Timestamp Derived by Transmitter Sensing Receiver Sensing Transmitter Sensing Transmitter Sensing Receiver SME MLME SME SME MLME SME MLME MLME MLME-SENSMSMTSETUP .request MLME-SENSMSMTSETUP .indication MLME-SENSMSMTSETUP .response MLME-SENSMSMTSETUP .request MLME-SENSMSMTSETUP .indication MLME-SENSMSMTSETUP .response MLME-SENSMSMTSETUP .confirm MLME-SENSMSMTSETUP .confirm MLME-SENSTBMSMTRQ .request MLME-SENSTBMSMTRQ .request 1 MLME-SENSTBREPORT .indication MLME-SENSTBREPORT .indication 1 2 MLME-SENSTBREPORTRQ .request MLME-SENSTBREPORTRQ .request MLME-SENSTBMSMTRQ .confirm MLME-SENSTBREPORTRQ .confirm MLME-SENSTBMSMTRQ .confirm MLME-SENSTBREPORTRQ .confirm 2 3 (1) Build Measurement Report - Add corresponding RX Timestamp (1) Record TX timestamp - Maintain lookup table mapping identifier to TX timestamp (2) Output Received Report - Deliver output to Sensing Application (2) Build Measurement Report - NO Timestamp in report (3) Obtain TX timestamp from (1) given identifier in report - Deliver output to Sensing Application Submission Slide 6 Chris Beg, Cognitive Systems

  7. December 2022 Topic 2: Timestamp at Transmitter or Receiver doc.: IEEE 802.11-22/2065r2 In cases where no over-the-air report is required, Sensing Receiver will generate timestamp Adding complexity to timestamp on Sensing Transmitter saves overhead of including timestamp in report, however savings is minimal given total report may span multiple MPDUs. In SBP cases where AP is Sensing Transmitter, a TX timestamp would require AP to manipulate received report and insert timestamp before forwarding to SBP initiator. In R2R case, Sensing Transmitter may not have opportunity to add timestamp into report. As a result, AP would need to manipulate report to insert timestamp before forwarding to application. Evaluation RX Timestamp TX Timestamp Sensing Receiver must generate timestamp Sensing Transmitter unable to generate timestamp No over-the-air report Extra overhead required in report, however report size is already LARGE. Overhead saved in report, however report size is LARGE, resulting in negligible savings Report Overhead No extra processing or manipulation of Sensing Measurement Report by AP to add timestamp. AP will need to manipulate Sensing Measurement Report to insert timestamp before sending to SBP Initiator. SBP Handling Extra overhead required in report, however report size is already LARGE. Report will be generated by R2R receiver and delivered to AP. AP will need to manipulate Sensing Measurement report to insert timestamp. R2R Handling To unify all reporting flows, having the receiver timestamp the measurement and include it in the report is the simplest and most consistent. Submission Slide 7 Chris Beg, Cognitive Systems

  8. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 3: Timestamp Generation It is not required that the sensing application receive timestamps fully synchronized among all participants For measuring the doppler, the delta timestamp from each STA is important An additional level of clock synchronization beyond the TSF clock management is NOT required for participating STAs Existing mechanisms already defined in .11 specs for both associated and non-associated STAs Submission Slide 8 Chris Beg, Cognitive Systems

  9. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 3: Timestamp Generation Summary of TS accuracy requirements given use-cases in [2] 7 GHz 5 GHz 2.4 GHz Use-Case Max Velocity(m/s) Velocity Accuracy (m/s) Fdoppler Fdoppler Accuracy TS Accuracy Fdoppler Fdoppler Accuracy TS Accuracy Fdoppler Fdoppler Accuracy TS Accuracy Smart meeting room - 2.1.2 Store Sensing - 2.1.6 Smart meeting room - 2.1.2 Store Sensing - 2.1.6 Proximity Detection - 2.2.6 Room Sensing - 2.1.1 Gesure recognition - 2.2.3 Home Security - 2.1.4 Home Security - 2.1.4 Home Appliance Control - 2.2.7 Tracking / presence detection - 2.3.3 Accuracy required ranges from 115.2us to 7.2ms 1 0.3 46.7 14.0 2.5E-3 33.3 10.0 3.5E-3 16.0 4.8 7.2E-3 1 0.1 0.2 46.7 70.0 4.7 9.3 974.0E-6 840.3E-6 33.3 50.0 3.3 6.7 1.4E-3 1.2E-3 16.0 24.0 1.6 3.2 2.8E-3 2.5E-3 1.5 2 3 0.1 0.3 93.3 140.0 4.7 14.0 255.1E-6 324.7E-6 66.7 100.0 3.3 10.0 357.1E-6 454.5E-6 32.0 48.0 1.6 4.8 744.0E-6 947.0E-6 3 0.1 140.0 4.7 115.2E-6 100.0 3.3 161.3E-6 48.0 1.6 336.0E-6 t1= t1= t1= + - time t0= 0 Submission Slide 9 Chris Beg, Cognitive Systems

  10. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 3: Timestamp Generation To justify length of timestamp, consider time between measurements TB instance schedule based on Availability Window: RSTA Availability Window Element in Sensing Measurement Setup Request: Non-TB instance schedule up to STA, with Max Time Between Measurement: Range (0 to ~838.9s) Submission Slide 10 Chris Beg, Cognitive Systems

  11. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 3: Timestamp Generation Timestamp length to prevent multiple wrap-around between two measurements: 1us Resolution 32us Resolution 64us Resolution Period(s) Timestamp Count Required Bits Timestamp Count 25 30 Required Bits 20 25 Timestamp Count Required Bits 19 24 TB Instance non-TB Instance 26.1 838.9 26100000 838900000 815625 26215625 407812.5 13107812.5 Note: non-TB case is minimum time between measurements , and actual time may be more Options for slicing TSF to generate timestamp 1us Resolution timestamp (32-bits) 32us resolution timestamp (27-bits) 64us resolution timestamp (26-bits) 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 TSF Counter 2 extra bits to allow for larger time for non-TB case, and potential missed measurement Submission Slide 11 Chris Beg, Cognitive Systems

  12. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 3: Timestamp Generation Current Report Control field contains 32-bits, with 4 reserved Proposal for using 2x reserved bits to encode Rx_OP_Gain_Type (22-2116) Option (A) Append 32-bits -------------------------------------------------------------------------------------------------------------------------------------------------- | Report Control Length | Presence and control bitmap | CW | N_TX | N_RX | N_b | -------------------------------------------------------------------------------------------------------------------------------------------------- 8 8 4 3 3 I_ng | RX_OP_Gain_Type | reserved | Timestamp | 1 1 2 2 32 Option (B) Pack and pad for byte-alignment -------------------------------------------------------------------------------------------------------------------------------------------------- | Report Control Length | Presence and control bitmap | CW | N_TX | N_RX | N_b | -------------------------------------------------------------------------------------------------------------------------------------------------- 8 8 4 3 I_ng | RX_OP_Gain_Type | Timestamp | reserved | 3 1 1 2 27 7 To keep byte aligned, need to add 32 bits regardless Can either use all 32-bits for timestamp, or mark some as reserved Proposal to use Option (A), allowing for 1us resolution, 4-bytes to match with DMG format Submission Slide 12 Chris Beg, Cognitive Systems

  13. December 2022 doc.: IEEE 802.11-22/2065r2 Topic 3: Timestamp Generation Proposal: The timestamp can be derived from the STAs local clock with the same resolution and accuracy/drift as its existing TSF clock 1us resolution (+/- 100ppm accuracy) A 4-byte timestamp can be used like the DMG report format Associated STAs may synchronize their timestamp relative to the AP s clock by using the TSF in Beacon frames Non-Associated STAs may synchronize their timestamp relative to the AP s clock by using the Partial TSF in the Trigger/NDPA (defined in 11az and required to keep synchronization with the Availability Window) Initial AP TSF may be obtained via beacon or probe request. The Partial TSF defined in 11az is 16-bits and represent TSF[21:6], which provides a resolution of 32us. Partial TSF may be used to help maintain synchronization to AP time Timestamp corresponds to start of the SI2SR or SR2SI NDP preamble Submission Slide 13 Chris Beg, Cognitive Systems

  14. November 2022 doc.: IEEE 802.11-22/2065r2 SP1 Do you agree to the following design approach: Timestamp is always present in Sensing Report Timestamp is generated by Sensing Receiver Timestamp corresponds to start of the SI2SR or SR2SI NDP preamble Timestamp is generated from local clock of STA: Same resolution, and accuracy/drift requirements as TSF 1us resolution (+/- 100ppm accuracy) Same width as DMG reported timestamp (4 bytes) Associated STAs may synchronize their timestamp relative to the AP s clock by using the TSF mechanisms Non-Associated STAs may synchronize their timestamp relative to the AP s clock by using the Partial TSF in the Trigger/NDPA Yes/No/Abstain = 7/2/8 Submission Slide 14 Chris Beg, Cognitive Systems

  15. November 2022 doc.: IEEE 802.11-22/2065r2 SP2 Do you agree to the following design approach: Timestamp is always present in Sensing Report Yes/No/Abstain = 7/4/6 Submission Slide 15 Chris Beg, Cognitive Systems

  16. November 2022 doc.: IEEE 802.11-22/2065r2 References [1] D. Yang, T. Wang, Y. Sun and Y. Wu, "Doppler Shift Measurement Using Complex-Valued CSI of WiFi in Corridors," 2018 3rd International Conference on Computer and Communication Systems (ICCCS), 2018, pp. 367-371, doi: 10.1109/CCOMS.2018.8463285. [2] 11-20-1712-02-00bf-wifi-sensing-use-cases.xlsx [3] 11-22-1020-05-00bf-pdt-formatting-of-csi.docx Submission Slide 16 Chris Beg, Cognitive Systems

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#