Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

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


  • 35 Views
  • Uploaded on
  • Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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

Voice: +1 256.428.6331; E-Mail: [email protected];

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


Project ieee p802 15 working group for wireless personal area networks wpans

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


Ben rolf got ripped off by the ballot posting sequence

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


Project ieee p802 15 working group for wireless personal area networks wpans

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


Project ieee p802 15 working group for wireless personal area networks wpans

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


After correction we have 23 t s

After correction; We have 23 T’s

Vern Brethour


Need an extra time snapshot in the timestamp report

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


Project ieee p802 15 working group for wireless personal area networks wpans

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


What does it mean

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


What s the story with dither management

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


Project ieee p802 15 working group for wireless personal area networks wpans

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


Zafer has offered to allow removal of dithering from the standard

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


Calibration of internal delays is a real weakness in draft 2

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


Recommendations for the calibration issue

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


The calibration issue

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


The issue with leading edge computations

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


How does the phy get rid of the scan data

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.

Vern Brethour


What about the fom when the phy is returning scan data

What about the FoM when the PHY is returning scan data?

  • We will use the expansion bit to say “defer FoM computation to the PPSU 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


Project ieee p802 15 working group for wireless personal area networks wpans

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 PPSU

Vern Brethour


What else is the scan data good for

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 loop-back waveform.

Vern Brethour


Adding a ppsu is going to be some work what s it worth

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.

Vern Brethour


The leading edge over run issue

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


The leading edge over run is this really a problem

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


Project ieee p802 15 working group for wireless personal area networks wpans

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


Project ieee p802 15 working group for wireless personal area networks wpans

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


Project ieee p802 15 working group for wireless personal area networks wpans

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

Vern Brethour


Project ieee p802 15 working group for wireless personal area networks wpans

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


This is the ranging control from draft 2

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


Project ieee p802 15 working group for wireless personal area networks wpans

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


That s the ranging editor s recommended disposition for the ranging comments in lb34

That’s the Ranging editor’s recommended disposition for the ranging comments in LB34.

  • Much thanks to the voters / commenters / reviewers!

Vern Brethour


  • Login