15-06-0295-00-004a-lb34-ranging-comment-resolution
24 Pages
English

15-06-0295-00-004a-lb34-ranging-comment-resolution

-

Downloading requires you to have access to the YouScribe library
Learn all about the services we offer

Description

1 IEEE P802.1523 Wireless Personal Area Networks456Project IEEE P802.15 Working Group for Wireless Personal Area Networks 78 (WPANs)910Title11 LB34 Ranging comment resolution1213 Date [8 June, 2006]14Submitted151617 Source [ Vern Brethour] Voice: [+1 256.428.6331]18[ Time Domain Corp.] Fax: [ ]1920 [ ] E-mail: [ 21vern.brethour@timedomain.c2223 om]2425 Re: [15-06-0240-00-004a-lb34-comment-resolution.xls]262728 Abstract [This document is a record of comment resolutions and text for ranging 29 comments in LB34.]3031Purpose [To provide a record of the proposed changes to D2 of the WG 3233 recirculation letter ballot as a result of comments received from LB34.]3435Notice This document has been prepared to assist the IEEE P802.15. It is 3637 offered as a basis for discussion and is not binding on the contributing 38individual(s) or organization(s). The material in this document is subject 3940 to change in form and content after further study. The contributor(s) 41reserve(s) the right to add, amend or withdraw material contained herein.424344 Release The contributor acknowledges and accepts that this contribution 45 becomes the property of IEEE and may be made publicly available by 4647 P802.15.484950515253545556575859606162636465Copyright © 2005 IEEE. All rights reserved. 1IEEE LOCAL AND METROPOLITAN AREA NETWORKS - PART 15.4aDraft P802.15.4a/D212345 1. Ranging comment text development based on 6 ...

Subjects

Informations

Published by
Reads 11
Language English
1 IEEE P802.152 3 Wireless Personal Area Networks 4 5 6 Project IEEE P802.15 Working Group for Wireless Personal Area Networks 7 8 (WPANs) 9 10 Title11 LB34 Ranging comment resolution 12 13 Date [8 June, 2006] 14 Submitted15 16 17 Source [ Vern Brethour] Voice: [+1 256.428.6331] 18 [ Time Domain Corp.] Fax: [ ]19 20 [ ] E-mail: [ 21 vern.brethour@timedomain.c22 23 om] 24 25 Re: [15-06-0240-00-004a-lb34-comment-resolution.xls]26 27 28 Abstract [This document is a record of comment resolutions and text for ranging 29 comments in LB34.] 30 31 Purpose [To provide a record of the proposed changes to D2 of the WG 32 33 recirculation letter ballot as a result of comments received from LB34.] 34 35 Notice This document has been prepared to assist the IEEE P802.15. It is 36 37 offered as a basis for discussion and is not binding on the contributing 38 individual(s) or organization(s). The material in this document is subject 39 40 to change in form and content after further study. The contributor(s) 41 reserve(s) the right to add, amend or withdraw material contained herein.42 43 44 Release The contributor acknowledges and accepts that this contribution 45 becomes the property of IEEE and may be made publicly available by 46 47 P802.15. 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 Copyright © 2005 IEEE. All rights reserved. 1 IEEE LOCAL AND METROPOLITAN AREA NETWORKS - PART 15.4a Draft P802.15.4a/D2 1 2 3 4 5 1. Ranging comment text development based on 6/265r4 6 7 8 1.1 Introduction 9 10 11 Table 1—6/265r4 ranging comment summary12 13 14 Comment Group # CID’s15 16 Need an extra time snapshot in the times- 6 2, 30, 50, 44, 50, 5217 18 tamp report 19 Private Ranging Dither Management 5 27, 49, 98, 105, 10720 21 Calibration of internal delays 5 25, 26, 46, 48, 14622 23 Poor explanation of the re-use of PD- 3 24, 45, 4724 25 DATA.confirm 26 Poor explanation of the use of 23 2, 5427 28 HEADER_ONLY 29 30 Leading edge computation overrun man-17 31 agement 32 33 Leading edge computation offloading 1 145 34 35 36 37 1.2 Need an extra time snapshot in the timestamp report 38 39 40 Change timestamp report “Time snapshot” to “Start Time snapshop” and “Stop Time snapshot” 41 42 To address CID's 2.30.50,44,&52: We fix up the timestamp reports43 44 45 The changes are unfortunately fairly widespread, 46 47 We start the fixing up in the second paragraph of clause 5.5.7.1. 48 49 50 In Figure 13b the bottom half of the sequence is grayed out to focus on the first frame of the two way 51 exchange. This RFRAME is sent from the originating device to the responding device. A ranging counter52 {delete starts }{ start value is captured}{delete counting} in the originator device upon the RMARKER53 54 departure from the originator, and a { ranging} counter { start value is captured} in the responding device 55 {delete begins counting} upon frame arrival at the responder. The RFRAME has the acknowledge request 56 bit is set in the MAC header. In the most general case, the counter in the responder PHY may have already 57 started running when a previous RFRAME arrived but the previous RFRAME was not intended for this58 device and thus did not get an acknowledge from this device. In the figures, the counter activity is labeled59 60 "start/snapshot" from the PHY perspective. For the PHY, the counter function is "start" for the first arriving 61 frame and "snapshot" for subsequent frames. Snapshot means that the value of the counter is captured and 62 stored at the instant of the snapshot, but the counter continues to count as if snapshot had not happened. The 63 responder PHY initiates PD-DATA.indicate primitives with counter snapshot values for all arriving64 RFRAMES. The responder MAC discards those snapshot values which are for RFRAMES not intended for65 # Copyright © 2006 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change WIRELESS MAC AND PHY SPECIFICATION FOR LR-WPANS IEEE Draft P802.15.4a/D2 1 the responder device. At the end of the first frame transmission in figure 13b the counters are running in 2 both devices. 3 4 The next paragraph {also in 5.5.7.1} (below Figure 13b) also changes:5 6 7 8 9 In Figure 13c the top half of the sequence is grayed out to focus on the second RFRAME of the two way10 exchange. This RFRAME is an acknowledge sent from the responding device to the originating device. The11 12 ranging counter { stop value} is snapshot in the responding device upon RMARKER departure from the 13 responder. The responder PHY is now in transmit mode, and the counter is still running. Because the PHY is 14 in transmit mode, it will not be receiving any frames or taking any counter snapshots. Leaving the counter 15 running in the responder at this point in the algorithmic flow only serves to deplete the battery of a mobile16 device. For overview purposes, in figures 13a,b,c &d, the counter action is labeled stop, not because it really17 18 is stopped (it isn't!), but because the algorithmic flow is done with it, and because it will appear to the appli- 19 cation like it has stopped because it will generate no more snapshots. The count{ er stop value} in the origi- 20 nator device is snapshot and saved upon RMARKER arrival at the originator. The originator MAC verifies 21 that the frame was from the responder and ultimately the application will then stop the counter with a22 MLME-RX-ENABLE.request/PLME-SET-TRX-STATE.request primitive pair. The originator PHY is in23 24 receive mode, so until the counter is stopped, that PHY will continue to generate PD-DATA.indication 25 primitives for all future arriving RFRAMES. 26 27 The paragraph {also in 5.5.7.1} immediately below Figure 13d also changes:28 29 30 The discussion above risks confusion because it includes the general case of arriving frames not intended for 31 the devices in the figures. That behavior is important for algorithmic robustness, but for understanding basic 32 ranging it is a distraction. In Figure 13d the ranging pair holds 2 { different sets of} counter values, { with a 33 start value and a stop value in each set}. Along the way, the application may have discarded counter snap-34 shots due to frames destined for other devices, but in any case what remains at the end of the exchange are {35 36 pairs of} counter values which { (when subtracted)} represent the elapsed times between the arrival and 37 departure of the intended frames. 38 39 The paragraph following that one {also in 5.5.7.1} also changes:40 41 42 At the system state represented by Figure 13d, the necessary information required to compute the range 43 between the devices is known. However, the information is still distributed in the system and before the 44 ranging computation can be accomplished, the data must be brought to a common compute node. The { dif- 45 ference of the} counter { start and stop} value{I s} in the originator device represents the total elapsed time46 from the departure of the first message to the arrival of the acknowledgement. The { difference} of counter47 48 {start and stop} value{s} in the responder represents the total elapsed time from arrival of the data message 49 to the departure of the acknowledgement. After these values are {all} brought together at a common com- 50 pute node, they are subtracted and the difference divided by 2 and the time of flight (and thus the inferred 51 range) is known.52 53 54 ************** 55 56 The very first line in 5.5.7.4 changes: 57 58 The standard specifies that the {start} counter value represent the times of arrival of the first pulse of the59 60 first 61 62 ************** 63 64 We change 5.5.7.7 65 Copyright © 2006 IEEE. All rights reserved. 3 This is an unapproved IEEE Standards Draft, subject to change WIRELESS MAC AND PHY SPECIFICATION FOR LR-WPANS IEEE Draft P802.15.4a/D2 1 Section 5.5.7.1 introduced the ranging counter value. Section 5.5.7.4 introduced the ranging Figure of 2 Merit. Section 5.5.7.5 introduced the two values which (as a ratio) characterize the crystal offsets. All of 3 these values ({d four}{ five} in all: one ranging counter{ start} value, {one ranging counter stop value,} two 4 numbers to characterize the crystals & 1 FoM) characterize a single ranging measurement. The {d four5 }{five} individual numbers which characterize a measurement are referred to in a group as a "timestamp6 7 report". It then takes (at least) two timestamp reports to do a time of flight computation. There are a total of 8 {d12}{ 16} octets in a timestamp report. The numbers in a single timestamp report have meaning in the con- 9 text of each other. They must be generated by the PHY as a set, and should not be split apart during subse- 10 quent data handling. 11 12 13 ************** 14 15 Now we get into the messy stuff: We have to fix up 6.2.1.2.1:16 17 18 Insert additional parameters into the PD-DATA.confirm at the end of the list but before the closing paren- 19 thesis. 20 UWBRangingReceived, 21 UWBRangingCounter{Start}{d Value},22 {UWBRangingCounterStop,}23 24 UWBRangingTrackingInterval, 25ngingOffset, 26 UWBRangingFOM27 28 29 Then the row for counter value in table 7 gets replaced with 2 rows: 30 31 Table 7-PD-DATA.confirm parameters 32 33 34 **************** 35 36 Then we have similar activity in Clause 6.2.1.3 37 38 39 Insert additional parameters into the PD-DATA.indication at the end of the list but before the closing paren- 40 thesis. 41 UWBPRF, 42 UWBPreambleSymbolRepetitions,43 DataRate,44 45 UWBRangingReceived, 46 {d UWBRangingCounterValue} 47 {UWBRangingCounterStart,48 UWBRangingCounterStop,}49 50 UWBRangingTrackingInterval, 51ngingOffset, 52 UWBRangingFOM53 54 55 Then just like we did for Table 7, we have to bump up the rows in Table 8: 56 57 Table 8 -- PD-DATA.indication parameters58 59 60 61 62 To: 63 64 ****************65 Copyright © 2006 IEEE. All rights reserved. 4 This is an unapproved IEEE Standards Draft, subject to change WIRELESS MAC AND PHY SPECIFICATION FOR LR-WPANS IEEE Draft P802.15.4a/D2 1 Table 2— 2 3 4 Name Type Valid range Description 5 6 UWBRangingReceived Boolean OFF,ON A value of OFF indi- 7 cates that ranging is ei- 8 ther not supported in an 9 UWB PHY or is not to10 be indicated for the11 12 PSDU received. A val- 13 ue of ON denotes rang- 14 ing operations 15 requested for this PS-16 DU. A value of OFF is17 18 used for non-UWB 19 PHYs 20 21 {UWBRanging- Unsigned Integer 0x00000000- 4 octet count of the time 22 CounterStart 0xFFFFFFFF units corresponding to 23 an RMARKER at the24 antenna at the begin-25 ning of a ranging ex-26 27 change. A value of 28 x00000000 is used if 29 ranging is not support-30 ed, or enabled, or this is31 not an UWB PHY. The32 33 value x00000000 is also 34 used if the counter is not 35 used for this PPDU. See36 6.8a.14.1 }37 38 {UWBRanging- Unsigned Integer 0x00000000- 4 octet count of the time39 CounterStop 0xFFFFFFFF units corresponding to40 41 an RMARKER at the 42 antenna at the end of a 43 ranging exchange. A 44 value of x00000000 is45 used if ranging is not46 47 supported or not en- 48 abled or this is not an 49 UWB PHY. The value 50 x00000000 is also used51 if the counter is not used52 53 for this PPDU. See 54 6.8a.14.1 } 55 56 57 58 59 60 61 62 63 64 65 Copyright © 2006 IEEE. All rights reserved. 5 This is an unapproved IEEE Standards Draft, subject to change WIRELESS MAC AND PHY SPECIFICATION FOR LR-WPANS IEEE Draft P802.15.4a/D2 1 Table 2— 2 3 4 Name Type Valid range Description 5 6 { d UWBRanging- Unsigned Integer 0x00000000- 4 octet count of the time 7 CounterValue 0xFFFFFFFF units corresponding to 8 an RMARKER at the 9 antenna. A value of10 x00000000 is used if11 12 ranging is not supported 13 or this is not an UWB 14 PHY. This value is also 15 used if the counter is not16 used for this PPDU. See17 18 6.8a.14.1 } 19 UWBRangingTrack- Unsigned Integer 0x00000000- 4 octet count of the time20 21 ingInterval 0xFFFFFFFF units in a message ex- 22 change over which the 23 tracking offset was24 measured. If tracking25 based crystal character-26 27 ization is not supported 28 or this is not a UWB 29 PHY, a value of30 x00000000 is used. See31 6.8a.14.2.232 33 UWBRangingOffset Signed Magnitude Inte- 0x000000- 0x0FFFFF 3 octet count of the time34 35 ger units slipped or ad- 36 vanced the radio track- 37 ing system over the 38 course of the entire39 tracking interval. The40 41 top 4 bits are reserved 42 and set to zero. The 43 most significant of the 44 active bits is the sign45 bit. See 6.8a.14.2.146 47 UWBRangingFOM Integer 0x00 - 0x7F One octet Figure of48 49 Merit characterizing the 50 ranging measurement. 51 The MSB is reserved 52 and must be zero. The 53 remaining 7 bits are54 55 used in three sub-fields. 56 The sub-fields are the 57 Confidence Level, The 58 Confidence Interval, 59 and the Confidence In-60 61 terval Scaling Factor. 62 See 6.8a.14.3 63 64 65 Copyright © 2006 IEEE. All rights reserved. 6 This is an unapproved IEEE Standards Draft, subject to change WIRELESS MAC AND PHY SPECIFICATION FOR LR-WPANS IEEE Draft P802.15.4a/D2 1 Table 3— 2 3 4 Name Type Valid range Description 5 6 UWBPRF Enumeration OFF, NOMINAL 4 M, The pulse repetition 7 NOMINAL 16 M value of the received 8 PPDU. Non-UWB 9 PHYs use a value of10 OFF.11 12 UWBPreambleSymbol- Enumeration 0,16,64,1024,4096 The preamble symbol13 Repetitions repetitions of the UWB14 15 PHY frame received by 16 the PHY entity. A value 17 of 0 is used with a non-18 UWB PHY19 20 DataRate Enumeration 0,1,2,3,4 The data rate of the21 PHY frame received by22 23 the PHY entity. A value 24 of 0 is used with a non- 25 UWB or non-CSS PHY 26 27 UWBRangingReceived Boolean OFF, ON A value of OFF indi- 28 cates that ranging is ei- 29 ther not supported in an30 31 UWB PHY or is not to 32 be used for the PSDU 33 received. A value of ON 34 denotes ranging opera- 35 tions requested for this36 37 PSDU. A value of OFF 38 is used for non-UWB 39 PHYs 40 41 {d UWBRanging- Unsigned Integer 0x00000000- 4 octet count of the time 42 CounterValue 0xFFFFFFFF units corresponding to 43 an RMARKER at the44 antenna. A value of45 46 x00000000 is used if 47 ranging is not supported 48 or this is not an UWB 49 PHY. This value is also50 used if the counter is not51 52 used for this PPDU. See 53 6.8a.14.1} 54 55 56 57 58 59 60 61 62 63 64 65 Copyright © 2006 IEEE. All rights reserved. 7 This is an unapproved IEEE Standards Draft, subject to change WIRELESS MAC AND PHY SPECIFICATION FOR LR-WPANS IEEE Draft P802.15.4a/D2 1 Table 3— 2 3 4 Name Type Valid range Description 5 6 {UWBRanging- Unsigned Integer 0x00000000- 4 octet count of the time 7 CounterStart 0xFFFFFFFF units corresponding to 8 an RMARKER at the 9 antenna at the begin-10 ning of a ranging ex-11 12 change. A value of 13 x00000000 is used if 14 ranging is not support- 15 ed, or enabled, or this is16 not an UWB PHY. The17 18 value x00000000 is also 19 used if the counter is not 20 used for this PPDU. See 21 6.8a.14.1 }22 23 {UWBRanging- Unsigned Integer 0x00000000- 4 octet count of the time24 CounterStop 0xFFFFFFFF units corresponding to25 an RMARKER at the26 27 antenna at the end of a 28 ranging exchange. A 29 value of x00000000 is30 used if ranging is not31 supported or not en-32 33 abled or this is not an 34 UWB PHY. The value 35 x00000000 is also used36 if the counter is not used37 for this PPDU. See38 39 6.8a.14.1 } 40 41 UWBRangingTrack- Unsigned Integer 0x00000000- 4 octet count of the time 42 ingInterval 0xFFFFFFFF units in a message ex- 43 change over which the 44 tracking offset was45 measured. If tracking46 47 based crystal character- 48 ization is not supported 49 or this is not a UWB 50 PHY, a value of51 x00000000 is used. See52 53 6.8a.14.2.2 54 55 56 57 58 59 60 61 62 63 64 65 Copyright © 2006 IEEE. All rights reserved. 8 This is an unapproved IEEE Standards Draft, subject to change WIRELESS MAC AND PHY SPECIFICATION FOR LR-WPANS IEEE Draft P802.15.4a/D2 1 Table 3— 2 3 4 Name Type Valid range Description 5 6 UWBRangingOffset Signed Magnitude Inte- 0x000000- 0x0FFFFF 3 octet count of the time 7 ger units slipped or ad- 8 vanced the radio track- 9 ing system over the10 course of the entire11 12 tracking interval. The 13 top 4 bits are reserved 14 and set to zero. The 15 most significant of the16 active bits is the sign17 18 bit. See 6.8a.14.2.1 19 20 21 A bit of tuning is needed in the second to last paragraph of 6.2.2.7.3:22 23 24 Once every 2**32 times (VERY rarely) the counter will be wrapping through a value that would cause a 25 final counter value of zero (after all corrections are applied) to be the proper and correct counter value to 26 present in a timestamp report. There is nothing in the standard to preclude the ranging counter wrapping27 28 through zero. However, the standard does give zero special meaning associated with devices which have no 29 counter or have counters that are not running. An RDEV with a running counter presenting a counter value 30 of zero will be algorithmically disruptive. If an RDEV with a running counter would ever normally present 31 a counter value of zero, it will trap that case and instead present a value of {d 0x00000002}{0x00000001}. 32 This will lead to a half of a centimeter ranging error on the exceptionally rare occurrence of this event.33 34 {dCounter values of 0x00000001 are presented for counter start-up events.} 35 36 ************** 37 38 39 The second paragraph of 6.8a.14 changes: 40 41 RDEVs produce results which are used by higher layers to compute the ranges between devices. These42 results shall comprise a set of {c 4 five} numbers occupying {c12 16} total octets and total collection of the43 {c 12 16} octets is called a timestamp report. An RDEV timestamp report shall consist of a 4 octet ranging44 45 counter {start} value, {a four octet ranging counter stop value,} a 4 octet ranging tracking interval, a 3 octet 46 ranging tracking offset and a single octet ranging figure of merit. These 4 5 numbers are always reported 47 together in the same primitive and remain together for their entire processing lifetime. It is not acceptable to48 have any pipelining of the individual results where (for example) in a timestamp report the ranging tracking49 offset and ranging tracking interval might be associated with the ranging counter value of the previous50 51 timestamp report and the ranging figure of merit might be associated with the ranging counter value of the 52 timestamp report before that. 53 54 55 ************** 56 57 Clause 6.8a.14.2 changes: 58 59 60 An RDEV which implements optional crystal characterization shall produce a tracking offset and a tracking 61 interval for every {c value of the ranging counter timestamp report} which is produced. The tracking offset 62 and the tracking interval are computed from measurements taken during an interval which includes the 63 {interval bounded by the ranging counter start value and the ranging counter stop value.}{d instant repre-64 sented by the value of the ranging counter. For example, if the ranging counter value is 0x00000001 (a very65 Copyright © 2006 IEEE. All rights reserved. 9 This is an unapproved IEEE Standards Draft, subject to change WIRELESS MAC AND PHY SPECIFICATION FOR LR-WPANS IEEE Draft P802.15.4a/D2 1 typical example, as this is the starting value) then the time instant represented by 0x00000001 is in the inte- 2 rior of the interval represented by ranging tracking interval.} 3 4 **************5 6 7 Similar changes keep rippling down into Clause 7.1.1.2.1 which changes: 8 9 10 Insert additional parameters into the MCPS-DATA.confirm at the end of the list but before the closing 11 parenthesis. 12 13 14 15 UWBRangingReceived, 16 {dUWBRangingCounterValue,} 17 {UWBRangingCounterStart, 18 19 UWBRangingCounterStop,} 20 UWBRangingTrackingInterval,21ngingOffset,22 23 UWBRangingFOM 24 25 Then just like we did in Clause 6, we change Table 42 26 27 28 Table 42-MCPS-DATA.confirm parameters 29 30 31 ************** 32 33 We're almost done… now we fix up Clause 7.1.1.3.1 which changes: 34 35 36 Insert additional parameters into the MCPS-DATA.indication at the end of the list but before the closing 37 parenthesis. 38 UWBPRF,39 40 UWBPreambleSymbolRepetitions, 41 DataRate, 42 UWBRangingReceived,43 44 {d UWBRangingCounterValue,} 45 {UWBRangingCounterStart, 46 UWBRangingCounterStop,}47 48 UWBRangingTrackingInterval, 49ngingOffset, 50 UWBRangingFOM51 52 53 Then we have to fix up Table 43 which changes: 54 55 Table 43-MCPS-DATA.indication parameters56 57 58 And I think that's all….. Mercifully, down in Clause 7.5.7a it just refers to timestamp reports as a complete 59 assembly which we have now got established as a 5 number entity.60 61 62 63 64 65 Copyright © 2006 IEEE. All rights reserved. 10 This is an unapproved IEEE Standards Draft, subject to change