May 2006 doc IEEE 15 06 0265 01

  • Slides: 27
Download presentation
May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a Project: IEEE P

May 2006 doc. : IEEE 15 -06 -0265 -01 -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. [email protected] 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 -01 -004 a On Tuesday (AM-1)

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a Ben Rolf got

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a Lars Menzer was

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a Zafer Sahinoglu was

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a After correction; We

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a Need an extra

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a Need an extra

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a What does it

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a What’s the story

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a What’s the story

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a Zafer has offered

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a Calibration of internal

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a Recommendations for the

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a The calibration issue:

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a The issue with

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a How does the

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 -01 -004 a That’s some work:

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a That’s some work: What’s it worth? • If we do this, it only clears one “T” comment. • So is it 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 18 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a The Leading Edge

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 19 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a The Leading Edge

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 20 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a Identifying the Leading

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 21 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a Remember this from

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 22 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a A poor explanation

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

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a Without doing some

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 24 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a This is the

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 25 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a These parameters are

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 26 Vern Brethour

May 2006 doc. : IEEE 15 -06 -0265 -01 -004 a That’s the Ranging

May 2006 doc. : IEEE 15 -06 -0265 -01 -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 27 Vern Brethour