May 2006 doc IEEE 15 06 0265 02

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: LB 34 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: TG 4 a Abstract: Ranging Comments no Draft 2 of 802. 15. 4 a Purpose: To inform and enable comment resolution on the recirculation LB 34. Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15. TG 4 a 1 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a On Tuesday (AM-1) we looked at 06/0242 r 0 which described (as background) the ranging strategy implemented in Draft 2. • In light of that, we will now turn to the ranging comments on LB 34. • 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. TG 4 a 2 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Ben Rolf got ripped off by the ballot posting sequence. • 5 of Ben’s “T’s” were really “E’s”. 1. 2. 3. 4. 5. TG 4 a CID 93 CID 95 CID 96 CID 97 CID 99 3 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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”. 1. 2. 3. 4. TG 4 a CID 44 CID 45 CID 47 CID 49 4 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Zafer Sahinoglu was apparently feeling squeamish about his status as a ranging editor ! (? ? ) • TG 4 a Zafer’s CID 107 was posted as an “E” but it’s really a “T”. 5 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a After correction; We have 23 T’s Comment Group # CID’s Need an extra time snapshot in the timestamp report 6 2, 30, 50, 44, 50, 52 Private Ranging Dither Management 5 27, 49, 98, 105, 107 Calibration of internal delays 5 25, 26, 48, 146 Poor explanation of the re-use of PD-DATA. confirm 3 24, 45, 47 Poor explanation of the use of HEADER_ONLY 2 32, 54 Leading edge computation overrun management 1 7 Leading edge computation offloading 1 145 TG 4 a 6 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Need an extra time snapshot in the timestamp report: The “Vancouver” timestamp report Time snapshot Tracking interval Fo. M TG 4 a Time offset Subtract this number from this number and put the result here 7 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Need an extra time snapshot in the timestamp report: The “Jacksonville” timestamp report Start Time snapshot Stop Time snapshot Put this number in here. Tracking interval Fo. M TG 4 a Time offset Put this number in here. 8 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a What does it mean? • Going from here to here retires 6 “T’s” The “Jacksonville” timestamp report The “Vancouver” timestamp report Fo. M Time snapshot Start Time snapshot Tracking interval Stop Time snapshot Tracking interval Time offset Fo. M Time offset • It get’s the PHY (more) out of the arithmetic business. • It helps the infrastructure nodes in a one-way ranging system. TG 4 a 9 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a What’s the story with dither management? • In 06/0242 r 0 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. TG 4 a 10 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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” TG 4 a 11 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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 TG 4 a 12 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Calibration of internal delays is a real weakness in draft 2 Tx Rx In Draft 1, this was captured in “phy. Tx. Sync. Symbol. Offset” In Draft 1, this was captured in “phy. Rx. Sync. Symbol. Offset” • In Draft 2, the PHY is on his own for calibration. TG 4 a 13 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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. TG 4 a 14 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a The calibration issue: • One command set: PLME-CALIBRATE. request & PLME-CALIBRATE. indication • 2 PHY PIB values: phy. Tx. RMARKEROffset & This will retire 5 “T’s” phy. Rx. RMARKEROffset TG 4 a 15 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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. TG 4 a 16 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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 PPSU (PHY Protocol Scan Unit) and an “indicate” primitive set that mimics the behavior of a PPDU transfer. TG 4 a 17 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a What about the Fo. M when the PHY is returning scan data? • We will use the expansion bit to say “defer Fo. M computation to the PPSU data”. • Using the expansion bit in the Fo. M: Is that a bad thing? • No: There are still 4 “future bits” in the timestamp report. TG 4 a 18 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Octet 11 Octet 10 31 30 29 28 27 16 25 24 Fo. M Octet 9 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 lsb msb This is the 4’th 32 bit word of the timestamp report: Octet 8 8 7 6 5 4 3 2 1 0 Total tracking offset Reserved tracking offset sign Use this bit to say “defer to the PPSU TG 4 a 19 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a What else is the scan 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 loopback waveform. TG 4 a 20 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Adding a PPSU 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. TG 4 a 21 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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”. TG 4 a 22 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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: PHYRanging. Processing. Time that the application can read (and write) will give a great hint to the application about how to schedule ranging traffic to avoid overruns. TG 4 a 23 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Identifying the Leading Edge overrun 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. TG 4 a 24 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a Remember this from 06/0242 r 0? 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. TG 4 a 25 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a A poor explanation in Draft 2 of this “dual use” of PD-DATA. confirm drew 3 “T”s TG 4 a 26 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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. TG 4 a 27 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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 TG 4 a 28 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a 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. TG 4 a 29 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -02 -004 a That’s the Ranging editor’s recommended disposition for the ranging comments in LB 34. • Much thanks to the voters / commenters / reviewers! TG 4 a 30 Vern Brethour