1 March 2010 Micheal McLaughlin, DecaWave Submission IEEE 802. 15-10-0166-01-004h Project: IEEE P802.15 Working Group for Wireless Personal Area Networks.

Slides:



Advertisements
Similar presentations
Doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 1 Project: IEEE P Working Group for Wireless Personal Area.
Advertisements

Doc.: IEEE a July, 2006 Project: IEEE Study Group for Wireless Personal Area Networks (WPANs) Submission Title: [SFD Design] Date.
Doc.: IEEE a-Updating-15-7-security Submission May 2015 Robert Moskowitz, HTT ConsultingSlide 1 Project: IEEE P Working Group for.
Doc: IEEE Submission July 2013 Verso, Mc Laughlin (DecaWave)Slide 1 Project: IEEE P Working Group for Wireless Personal Area.
Doc.: g September, 2011 Daniel Popa, Ruben Salazar Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE /133r0 Submission March 2003 Michael Park, Samsung Electronics co., LtdSlide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE Submission doc. : IEEE March 2009 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE a Submission June, 2005 Brethour, Time DomainSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE Submission November 2013 Dotlic, Li, Hernandez, Miura (NICT), Verso, McLaughlin (Decawave) Project: IEEE P Working.
Doc.: IEEE r3 Submission November 2004 Michael Mc Laughlin, decaWaveSlide 1 Project: IEEE P Working Group for Wireless Personal Area.
1 May 2010 Michael McLaughlin, DecaWave Submission IEEE f Project: IEEE P Working Group for Wireless Personal Area Networks.
a Slide 1 Michael Mc Laughlin, decaWave Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: IEEE c Submission Slide 1 July, 2008 Chang woo Pyo, NICT Project: IEEE P Working Group for Wireless Personal Area Networks.
Nov 2004 doc:IEEE b Slide 1 Submission Liang Li, WXZJ Inc./Helicomm Project: IEEE P Working Group for Wireless Personal Area.
Doc.: IEEE m SubmissionSlide 1 May 2012 Project: IEEE P Working Group for Wireless Personal Area Networks(WPANs) Submission.
Doc.: IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Communicating.
Doc.: IEEE r0 Submission September 2004 Michael Mc Laughlin, decaWaveSlide 1 Project: IEEE P Working Group for Wireless Personal Area.
Doc.: IEEE g Submission March 2010 Tim Schmidl (Texas Instruments), Emmanuel Monnerie (Landis & Gyr), Shusaku Shimada (Yokogawa Co.),
Doc.: IEEE g Submission March 2010 Kuor Hsin Chang, Monique Brown (Elster Solutions, M.B. Brown Consulting) Project: IEEE P
July 2009 Slide 1 Michael McLaughlin, DecaWave IEEE f Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE g Submission July 14, 2009 René Struik (Certicom Research)Slide 1 Project: IEEE P Working Group for Wireless Personal.
Submission Title: [Resolution on comment #20,22 and 30]
doc.: IEEE <doc#>
September 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: PIB Coordination in g Date Submitted:
<month year> doc.: IEEE < e>
June 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Scenarios for Usage Model Document.
doc.: IEEE <doc#>
<doc.: IEEE −doc>
May 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Considerations on general MAC frame] Date Submitted:
<month year> doc.: IEEE < e>
<month year> doc.: IEEE /244r0 May 2001
March 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Toumaz response to TG6 Call for Applications]
Submission Title: [Errors in a] Date Submitted: [19 February, 2010]
<doc.: IEEE −doc>
Submission Title: [DecaWave UWB SFD Proposal]
Submission Title: [Rate one over four code for TG4a]
doc.: IEEE <doc#>
Date Submitted: [26-Oct-2005]
doc.: IEEE g-Trends-in-SUN-capacity
Jul 12, /12/10 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed resolution for CID 180.
July Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [On unifying PPDU formats] Date Submitted:
Submission Title: [Errors in a] Date Submitted: [18 March, 2010]
Submission Title: [FEC Options summary for TG4a ]
Submission Title: [Resolution on comment #20,22 and 30]
<month year> doc.: IEEE < e>
February 19 doc.: IEEE /424r1 February 2007
Submission Title: [HRP UWB PHY enhanced mode converged consensus]
Date Submitted: [26-Oct-2005]
Submission Title: [Example UWB Tx Data]
Submission Title: [Uniform bandplan for TG4a Modulation]
February 19 doc.: IEEE /424r1 November 2006
July Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [On unifying PPDU formats] Date Submitted:
Submission Title: [FEC Multipath performance for TG4a ]
doc.: IEEE <doc#>
Submission Title: [Channel Bands Update]
September 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: PIB Coordination in g Date Submitted:
doc.: IEEE <doc g>
Submission Title: [SFD comparison] Date Submitted: [18−July−2006]
Submission Title: [SFD comparison] Date Submitted: [18−July−2006]
Submission Title: Rogue Resolutions from kivinen
May 19 doc.: IEEE /424r1 November 2006
<month year> doc.: IEEE < e>
doc.: IEEE <doc#>
Submission Title: [SFD comparison] Date Submitted: [18−July−2006]
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: CID 422 Proposal Date Submitted: 14 August,
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Still More LB156 Comment Resolutions Date.
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Still More LB156 Comment Resolutions Date.
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: CID 422 Proposal Date Submitted: 14 August,
Presentation transcript:

1 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Errors in a] Date Submitted: [19 February, 2010] Source: [Michael McLaughlin] Company [DecaWave] Address [Digital Depot, Thomas Street, Dublin 8, Ireland] Voice:[ ], FAX: [none], Re: [Errors in a] Abstract:[Errors in a] Purpose:[To correct errors in 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

2 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Errors and ambiguities in a

3 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h SECDED code in PHR There is an error in paragraph *6.8a.7.2*: C5 = XOR(R0, R1, L5, L6, C3, C4) should read C5 = XOR(R1, R0, L6, L5, L4, L3, L2, L1, L0, RNG, EXT, P1, P0, C4, C3, C2, C1, C0)

4 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h When to switch to 6.8M bit/sec The IEEE a standard is not entirely clear as to when the switch from PHY Header mode modulation into modulation at the data rate should be made This is only relevant when at 6.8Mbps and 27Mbps. The other two rates use identical modulation for PHY header and data Annex I does not clear this ambiguity up because the data rate used in the example is 850kbps

5 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Let us denote the 19 PHY header bit as H 0 to H 18 Let this be followed by N data bits, D 0 to D N-1 Appended to this are two tail bit T 0 and T 1 There are then three possible interpretations as follows:

6 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Interpretation 1 19 Symbols of Pure Header at 850kbps N+2 Symbols of Data at e.g. 6.8 Mbps

7 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Interpretation 2 20 Symbols of Header at 850kbps N+1 Symbols of Data at e.g. 6.8 Mbps

8 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Interpretation 3 21 Symbols of Header at 850kbps N Symbols of Data at e.g. 6.8 Mbps

9 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Arguments for various interpretations Figure 27b of the standard says that there are 19 symbols of PHY header followed by 0 – 1209 symbols of Data 19 Symbols is consistent with interpretation 1 – In this case the data field should be symbols long. 0 is not allowed and two tail bits are added Interpretation 3 is consistent with the view that all symbols which contain information coming from the header need to be encoded at the lower data rate. In this case Figure 27b should have 21 symbols in the header and symbols in the data. Interpretations 1 & 2 both require the strange situation where, even with an empty data field, the data rate needs to be switched, e.g. to 6.8Mbps, to send the last one or two symbols.

10 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Personal view My own view is that interpretation 3 is the correct one – The switch to a higher data rate happens AFTER all the header bits, including the convolutional parity bits have been received. – This makes the most sense, since (a) all these bits are required to use the SECDED code to correct the R0 and R1 bits which tell you if you need to switch rates. (b) all the header bits are sent at the robust 850k default rate Fig 27b needs to be corrected to show 21 symbols in the header and symbols in the data. We should put interpretation 3 into the standard (Perhaps into Annex I?)

11 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Is the leading zero transmitted? It has been said to me that a reasonable interpretation of the text of the standard is that the first symbol with the “initialisation zero” as the position and the first data bit as the polarity is not transmitted. In this interpretation, the first bit to be transmitted is symbol 1 in the above tables

12 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Annex I clears this up This interpretation is most likely to occur to implementers of a non-coherent receiver, because, in this case, the first symbol contains absolutely no information. This interpretation is wrong because it results in the first data bit having less redundancy than the other bits. Annex I clearly shows that this first symbol IS transmitted Nonetheless, to avoid misinterpretation, the main body of the text should explicitly state that this symbol is transmitted.

13 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Various small corrections Table 39c - Nhdr=19 not 16 Table 39c - Thdr should be 19.5, 20.0, 77.9 Table 39c - Ndata is given by -> (round up to =8*(6*ROUNDUP(Length*8/(6*55)+Length)) Fig 27m shows an example of a 1ns pulse width (which does not correspond to any specified bandwidth). The text says it is 2ns, but it is not. Incorrect figure

14 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Various small corrections The equation for r(t) is wrong. to correct: a) Remove square bracket at end of Sin term b) Add a square bracket at end of cos term, just before the + c) put a minus sign in front of the whole thing, i.e. negate the whole thing. Incorrect equation

15 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Various small corrections Clarifications: 110kbps bit rate always uses length 64 SFD. Paragraph 6.8a.6.2 is ambiguously worded. It could be read as meaning that either length SFD can be used with 110kbps. This is not the case. It must be the longer one, otherwise you cannot know how to demodulate the PHR. Receiver is not aware of bit rate and must decode from received PHR, can determine bit rate of PHR 110kbps or 850kbps based on number of SFD symbols received, 64 or 8 respectively. PHY PIB parameter 0x08 phyPreambleSymbolLength (0 = 31 symbols, 1 = 127 symbols) is redundant since PHY PIB parameter 0x1A phyCurrentCode which specifies the preamble code index, essentially gives this same information. Here codes 1 to 8 are 31 symbols long, while codes 9 to 24 are 128 symbols long. Proposed Fix: Make phyPreambleSymbolLength a ReadOnly element of the PIB. The MAC will return 0 if phyCurrentCode is less than or equal to 8

16 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Figure 27d Corrected Figure 27d Signs of last 2 shown Si’s need to be swapped