1 / 30

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: LB34 Ranging Comments. Date Submitted: May 18, 2006 Source: Vern Brethour, Time Domain Corp Contact: Vern Brethour, Time Domain Corp

neola
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: LB34 Ranging Comments. Date Submitted: May 18, 2006 Source: Vern Brethour, Time Domain Corp Contact: Vern Brethour, Time Domain Corp Voice: +1 256.428.6331; E-Mail: vern.brethour@timedomain.com; Re: TG4a Abstract: Ranging Comments no Draft 2 of 802.15.4a Purpose: To inform and enable comment resolution on the recirculation LB34. Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. Vern Brethour

  2. On Tuesday (AM-1) we looked at 06/0242r0 which described (as background) the ranging strategy implemented in Draft 2. • In light of that, we will now turn to the ranging comments on LB34. • The ranging commenters were generally a friendly bunch. As originally marked, there were 23 “T’s” and no TR’s. • After corrections, there are still 23 “T’s”: Because 4 of Lars’ “E’s” were really “T’s” and 5 of Ben’s “T’s” were really E’s & one of Zafer’s “E’s” was really a T. Vern Brethour

  3. Ben Rolf got ripped off by the ballot posting sequence. • 5 of Ben’s “T’s” were really “E’s”. • CID 93 • CID 95 • CID 96 • CID 97 • CID 99 Vern Brethour

  4. Lars Menzer was apparently feeling squeamish about his status as a non-voter. • Lars posted all of his comments as “E’s”. • 4 of Lars’ “E’s” were really “T’s”. • CID 44 • CID 45 • CID 47 • CID 49 Vern Brethour

  5. Zafer Sahinoglu was apparently feeling squeamish about his status as a ranging editor ! (??) • Zafer’s CID 107 was posted as an “E” but it’s really a “T”. Vern Brethour

  6. After correction; We have 23 T’s Vern Brethour

  7. Need an extra time snapshot in the timestamp report: The “Vancouver” timestamp report Subtract this number from this number and put the result here Time snapshot Tracking interval FoM Time offset Vern Brethour

  8. Need an extra time snapshot in the timestamp report: The “Jacksonville” timestamp report Put this number in here. Start Time snapshot Stop Time snapshot Tracking interval Put this number in here. FoM Time offset Vern Brethour

  9. What does it mean? • Going from here to here retires 6 “T’s” The “Jacksonville” timestamp report The “Vancouver” timestamp report Start Time snapshot Time snapshot Stop Time snapshot Tracking interval Tracking interval FoM Time offset FoM Time offset • It get’s the PHY (more) out of the arithmetic business. • It helps the infrastructure nodes in a one-way ranging system. Vern Brethour

  10. What’s the story with dither management? • In 06/0242r0 I said that private ranging dithering was a low cost solution to a low anxiety problem; So why not just do it? • Well, actually there is a cost. Vern Brethour

  11. What’s the story with dither management? • The cost is in getting the dither values into the PHY ahead of the time they will be used and always keeping one step ahead of the use. • Jay worked out a way to do that, but I explained it poorly when I wrote it up and my poor explanation attracted “T’s” Vern Brethour

  12. Zafer has offered to allow removal of dithering from the standard. • This will help the presentation in Clause 5 • The dither was starting to look like a noticeable bother to fix something that was only a slight potential problem. • This retires 5 T’s Vern Brethour

  13. Calibration of internal delays is a real weakness in draft 2 • In Draft 2, the PHY is on his own for calibration. Tx Rx In Draft 1, this was captured in “phyTxSyncSymbolOffset” In Draft 1, this was captured in “phyRxSyncSymbolOffset” Vern Brethour

  14. Recommendations for the calibration issue. • A new primitive set, from the application, through the MAC to the PHY causing calibration and returning 3 things: Tx delay, Rx delay, (or optionally) a scan trace. • Two writeable values in the PHY PIB for Tx Delay and Rx delay. Vern Brethour

  15. The calibration issue: • One command set: PLME-CALIBRATE.request & PLME-CALIBRATE.indication • 2 PHY PIB values: phyTxRMARKEROffset & phyRxRMARKEROffset This will retire 5 “T’s” Vern Brethour

  16. The issue with leading edge computations. • In Draft 2, the PHY must scan for the arriving signal leading edge and process the scan data with it’s own resources. • Having the PHY scan all of this is unavoidable, but the standard could allow the PHY to get rid of the scan data and put the processing burden onto an application layer. Vern Brethour

  17. How does the PHY get rid of the scan data? • The same way it gets rid of any other data: • The PHY gets rid of received demodulated data with a PPDU transfer. • To offload the scan data, we will create a PPRU (PHY Protocol Ranging Unit) and an “indicate” primitive set that mimics the behavior of a PPDU transfer. Vern Brethour

  18. What about the FoM when the PHY is returning scan data? • We will use the expansion bit to say “defer FoM computation to the PPRU data”. • Using the expansion bit in the FoM: Is that a bad thing? • No: There are still 4 “future bits” in the timestamp report. Vern Brethour

  19. This is the 4’th 32 bit word of the timestamp report: msb lsb Octet 11 Octet 10 Octet 9 Octet 8 31 30 29 28 27 16 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 FoM Reserved Total tracking offset tracking offset sign Use this bit to say “defer to the PPRU Vern Brethour

  20. What else is the channel sounding data good for? • It’s great for the calibration look back measurement. • Remember that the reason that we are getting the application involved in the calibration in the first place was to ease the burden on the PHY. • We’re not easing much burden if the PHY has to process it’s own scan of the loop-back waveform. Vern Brethour

  21. Adding a PPRU is going to be some work: What’s it worth? • If we do this, it only clears one “T” comment. • So is it really worth it? • Yes: If we do not do this, the scan computation burden will remain on the PHY and make ranging unattractive for low cost PHYs. • This is enough of a problem that if the standard does not provide relief, we risk implementers creating their own relief in non-standard ways. Vern Brethour

  22. The Leading Edge over-run issue: • The processing of leading edge computations takes some non-zero amount of time. • If a string of RFRAMES arrives faster that the processing time for a the leading edge computations for a single frame, the DEV will be “over-run”. Vern Brethour

  23. The Leading Edge over-run: Is this really a problem? • As problems go… it’s not a huge problem, but we can provide a fix “hook” very easily. • A PHY PIB attribute with a name like: PHYRangingProcessingTime that the application can read (and write) will give a great hint to the application about how to schedule ranging traffic to avoid overruns. Vern Brethour

  24. Identifying the Leading Edge over-run threshold: What’s this worth? • This one PIB attribute will resolve 1 “T” comment. • It’s a small problem, but it’s real. If we don’t provide a fix hook as part of the standard, it doesn’t mean the problem goes away, it just means that vendors will have to fix it in non-standard ways. Vern Brethour

  25. Remember this from 06/0242r0? However, In this instance, the PHY said it was ranging, and the counter value was non-zero, so the MAC forwarded the whole thing to the NHL. In this instance, the PHY said it was ranging, but the counter value was zero, so the MAC didn’t forward anything to the NHL. Vern Brethour

  26. A poor explanation in Draft 2 of this “dual use” of PD-DATA.confirm drew 3 “T”s Vern Brethour

  27. Without doing some serious tampering with the MAC protocols, this will need to stay as it is. • But we can certainly explain it better, possibly even going as far as including this picture in clause 5. Vern Brethour

  28. This is the Ranging Control from Draft 2: The problem is in this blue circle. By not adequately explaining how these parameters work, I drew 2 “T”s Vern Brethour

  29. These parameters are actually introduced and discussed in Clause 5. A cross reference to 5.5.7.2 in here and a little more discussion in that section might be all it takes. Vern Brethour

  30. That’s the Ranging editor’s recommended disposition for the ranging comments in LB34. • Much thanks to the voters / commenters / reviewers! Vern Brethour

More Related