Submission Title: [Errors in a] Date Submitted: [19 February, 2010]

Slides:



Advertisements
Similar presentations
1 March 2010 Micheal McLaughlin, DecaWave Submission IEEE h Project: IEEE P Working Group for Wireless Personal Area Networks.
Advertisements

<month year> <doc.: IEEE doc>
doc.: IEEE <doc#>
Name - WirelessHD doc.: IEEE g July 2010
<month year> doc.: IEEE < e>
doc.: IEEE <doc#>
<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>
doc.: IEEE <doc#>
May, 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Long-range mode preamble design for f.
Submission Title: [MC EventsList] Date Submitted: [11Jul00]
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]
<doc.: IEEE −doc>
Submission Title: [DecaWave UWB SFD Proposal]
Submission Title: [Rate one over four code for TG4a]
doc.: IEEE <doc#>
<month year> doc.: IEEE <xyz> January 2001
Date Submitted: [17-Nov-2005] Source: [Laurent Ouvry]
Date Submitted: [26-Oct-2005]
July Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [On unifying PPDU formats] Date Submitted:
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:
Doc.: IEEE /XXXr0 10 May 2011 Sep 19, 2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)‏ Submission Title:
Submission Title: [Errors in a] Date Submitted: [18 March, 2010]
Submission Title: [FEC Options summary for TG4a ]
<month year> doc.: IEEE < e>
Submission Title: [Rate 1/4 code for TG4a]
February 19 doc.: IEEE /424r1 February 2007
doc.: IEEE <doc#>
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]
doc.: IEEE <doc#>
<month year> doc.: IEEE <xyz> November 2000
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:
doc.: IEEE /XXXr0 Sep 19, 2007 June 2009
doc.: IEEE <doc#>
Submission Title: [Preamble structures for 4a]
Submission Title: [FEC Multipath performance for TG4a ]
doc.: IEEE <doc#>
Submission Title: [Channel Bands Update]
doc.: IEEE <doc g>
Submission Title: [SFD comparison] Date Submitted: [18−July−2006]
Submission Title: [SFD comparison] Date Submitted: [18−July−2006]
9-July-2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [DecaWave Proposal for TG3c Alternative PHY]
May 19 doc.: IEEE /424r1 November 2006
<month year> doc.: IEEE < e>
Submission Title: [SFD comparison] Date Submitted: [18−July−2006]
<month year> doc.: IEEE < e>
June, 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [OFDM PHY Mode Representation] Date Submitted:
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
Project: IEEE Study Group for Wireless Personal Area Networks (WPANs)
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
August, 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improve the latency between GTS request.
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: CID 422 Proposal Date Submitted: 14 August,
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: CID 422 Proposal Date Submitted: 14 August,
September, 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: CID 422 Proposal Date Submitted: Sept.
12/15/2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [AWGN Simulation Results] Date Submitted:
Presentation transcript:

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Errors in 802.15.4a] Date Submitted: [19 February, 2010] Source: [Michael McLaughlin] Company [DecaWave] Address [Digital Depot, Thomas Street, Dublin 8, Ireland] Voice:[+353 688 2514], FAX: [none], E-Mail:[michael.mclaughlin@decawave.com] Re: [Errors in 802.15.4a] Abstract: [Errors in 802.15.4a] Purpose: [To correct errors in 802.15.4a] 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.

Errors and ambiguities in 802.15.4a

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)

When to switch to 6.8M bit/sec The IEEE 802.15.4a 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

Let us denote the 19 PHY header bit as H0 to H18 Let this be followed by N data bits, D0 to DN-1 Appended to this are two tail bit T0 and T1 There are then three possible interpretations as follows:

Interpretation 1 19 Symbols of Pure Header at 850kbps N+2 Symbols of Data at e.g. 6.8 Mbps

Interpretation 2 20 Symbols of Header at 850kbps N+1 Symbols of Data at e.g. 6.8 Mbps

Interpretation 3 21 Symbols of Header at 850kbps N Symbols of Data at e.g. 6.8 Mbps

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 2-1210 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 0-1208 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.

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 you need to switch rates. (b) all the header bits are sent at the robust 850k default rate Fig 27b needs to be corrected We should put interpretation 3 into the standard (Perhaps into Annex I?)

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

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.

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. 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. 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

Figure 27d Corrected Figure 27d