1. Submission Title: [Ranging Issues in 15.4a]
September, 2005
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Ranging Issues in 15.4a]
Date Submitted: [19 September, 2005]
Source: [Vern Brethour] Company [Time Domain Corp.]
Address [7057 Old Madison Pike; Suite 250; Huntsville, Alabama 35806; USA]
Voice:[(256) ], FAX: [(256) ],
Re: [ a.]
Abstract: [Positioning applications imply high air-time useage. ]
Purpose: [To start a discussion of range figures of merit for a.]
Notice: This document has been prepared to assist the IEEE P 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
Brethour, Time Domain

2. Air time usage in Position Applications
September, 2005
Air time usage in Position Applications
The case for supporting high air-time usage in the a specification.
Brethour, Time Domain

3. What are we trying to do? The 15.4a PAR says:
September, 2005
What are we trying to do?
The 15.4a PAR says:
This project will define an alternative PHY clause for a data communication standard with precision ranging, extended range, enhanced robustness and mobility amendment to standard
Brethour, Time Domain

4. The PAR only says “ranging”.
September, 2005
The PAR only says “ranging”.
It does not say “location” or “positioning”.
The PAR didn’t say anything about location or positioning, we did, later.
Brethour, Time Domain

5. So what’s the difference?
September, 2005
So what’s the difference?
Ranging establishes the distance between two nodes. That’s all it does.
Positioning additionally requires the support of a “solver” to turn a set of ranges into a relative position solution.
Brethour, Time Domain

6. Why are we talking about positioning?
September, 2005
Why are we talking about positioning?
We have been talking about applications that track valuable assets:
Firemen and first responders
Alzheimer’s patients
Children in malls and theme parks
Bags of money
On and on… Once we say we are going to support positioning, there is certainly no lack of ideas for applications
Brethour, Time Domain

7. September, 2005
Positioning is a 3D problem. It’s hard to draw 3D, so let’s pretend it’s 2D:
Brethour, Time Domain

8. Ranging is what we do to get the radius of one of the circles.
September, 2005
Ranging is what we do to get the radius of one of the circles.
Brethour, Time Domain

9. September, 2005
It takes at least two transmissions on the air to get the radius of one circle.
Brethour, Time Domain

10. The two transmissions are the theoretical minimum.
September, 2005
The two transmissions are the theoretical minimum.
For secure ranging it can be more than that.
It we have a previous “request for ranging” and an acknowlege it will be yet more.
If we want to manage crystal offsets with additional traffic, it will be more still.
Brethour, Time Domain

11. To do positioning, we need the radius of lots of circles.
September, 2005
To do positioning, we need the radius of lots of circles.
Brethour, Time Domain

12. September, 2005
But even those are not enough: The solver also has to know where the blue, orange and green nodes are.
Brethour, Time Domain

13. Now we are seeing lots of traffic:
September, 2005
Now we are seeing lots of traffic:
Brethour, Time Domain

14. The solver problem The solver is not part of our standard.
September, 2005
The solver problem
The solver is not part of our standard.
We will probably discuss the solver in an informative annex, but we certainly will not specify how an application does that job.
Brethour, Time Domain

15. September, 2005
But isn’t positioning something that can be handled by an application once we provide hooks for getting the individual ranges? No
Positioning imposes the need for additional capabilities beyond simple ranging.
Brethour, Time Domain

16. September, 2005
Let’s re-draw the circles again with some realistic noise in the measurements:
Brethour, Time Domain

17. The solver will often have more ranges than the minimum needed for a relative position solution.
September, 2005
We are supposed to decide where all these circles intersect.
Brethour, Time Domain

18. Let’s color the example:
September, 2005
If trustworthy ranges are blue and untrustworthy ranges are red…..
We will call the positioning solution here
Brethour, Time Domain

19. Let’s look again:
September, 2005
If trustworthy ranges are blue and untrustworthy ranges are red…..
We will call the positioning solution here
Brethour, Time Domain

20. The solver needs to know which situation it’s dealing with:
September, 2005
The solver needs to know which situation it’s dealing with:
Case 1
Case 2
Brethour, Time Domain

21. The solver needs Figures of Merit.
September, 2005
The solver needs Figures of Merit.
The solver will get terrible results if it cannot know which ranges to trust and which to discount.
We must set bits aside for a figure of merit associated with each report of a ranging timestamp and the PHY needs to compute that figure of merit with a meaning similar across all vendors
Brethour, Time Domain

22. But that’s not the only issue: What about motion?
September, 2005
But that’s not the only issue: What about motion?
If the blue, green, orange and black crosses represent firemen, they are all mobile.
For the solver to work, all of the individual ranges must be taken quickly enough so that none of them moved very far during the time interval when the measurements were taken.
Brethour, Time Domain

23. That’s perfectly reasonable, given the applications….. BUT….
September, 2005
We have said repeatedly that we want to support positioning with motion.
That’s perfectly reasonable, given the applications….. BUT….
As soon as we add motion to the positioning that we added to ranging, we have added a new time urgency to completing all of the traffic that goes into a single solver range set.
Brethour, Time Domain

24. September, 2005
Getting the traffic for a solver range set completed quickly implies the use of guaranteed time slots.
If there are only 6 nodes (an unrealistically small number) in the node set that the solver is going to work with….. then when every node ranges to every other node we have =15 exchanges needed to determine the ranges for a solver set.
Brethour, Time Domain

25. 15 exchanges to be scheduled doesn’t seem to bad……..
September, 2005
15 exchanges to be scheduled doesn’t seem to bad……..
But there are only 7 Guaranteed Time Slots in the 15.4 superframe.
From section 5.4 of the specification
Brethour, Time Domain

26. There is still hope, because the GTS times can be quite long.
September, 2005
So we’ve completely blown the GTS budget and that was only attempting to support 6 nodes!
There is still hope, because the GTS times can be quite long.
We might get creative within the interior of the GTS.
Brethour, Time Domain

27. Structure interior to a single GTS?
September, 2005
Structure interior to a single GTS?
Maybe we have lots of ranging exchanges inside the GTS
Brethour, Time Domain

28. Fine structure inside of a GTS?
September, 2005
Fine structure inside of a GTS?
What’s going on inside of this fine structure?
We have to decide. But first, do we even want to try using a fine structure?
Brethour, Time Domain

29. What about the duty cycle issue?
September, 2005
What about the duty cycle issue?
Some applications (mobile high value assets) need a nearly constant update.
The .5% per hour time occupancy being talked about in Europe will not work for those applications.
Brethour, Time Domain

30. The 5% occupancy in a second is also a problem.
September, 2005
The 5% occupancy in a second is also a problem.
5% means we can only use 50 ms in every second.
Any individual packet (one way) is nominally 5 ms.
The simplest ranging exchange is nominally 10 ms.
We also seem to want more messaging to move dither values (for security) and cryptographically secured timestamps!
Brethour, Time Domain

31. September, 2005
Tracking mobile high value assets: 15.4 is not very friendly to the use of GTS.
The 15.4 spec states strongly that a very substantial portion of the superframe is to be left allocated to the CAP for use by non-GTS players.
Brethour, Time Domain

32. September, 2005
How do we manage the CAP?
The intent of the 15.4 MAC was to use carrier sense to manage the contention period. That’s probably not going to work well for UWB.
We can decrease our risk if we simply decide now to use Aloha during the CAP.
We can improve our performance if we decide now to use slotted Aloha during the CAP.
If we want to use slotted Aloha, how do we remain compatible with 15.4?
Brethour, Time Domain

33. What about the Regulatory environment for UWB?
September, 2005
What about the Regulatory environment for UWB?
Are we willing to take on the burden of developing a strategy for Detect and Avoid?
Are we going to have different levels of regulatory support?
Brethour, Time Domain

34. Why are all these things MAC issues?
September, 2005
Why are all these things MAC issues?
For Positioning, we need new stuff from the MAC:
New data elements like Figure of Merit on the time stamps.
New signaling protocols to support positioning with motion.
New mechanisms for supporting high duty cycles.
Brethour, Time Domain