Enhanced Mode Consensus for HRP UWB PHY Modulation Enhancements

doc 15 18 0590 00 004z n.w
1 / 11
Embed
Share

Discover the converged consensus agreement on the enhancements for HRP UWB PHY modulation elements, building on previous MIM consensus and advanced modes agreements. Delve into the specific UWB frame elements and specifications for the HRP UWB PHY in the 802.15.4z amendment. Explore topics such as PRF decisions, symbol lengths, SFD specifications, and more as outlined by a collaboration of industry contributors. Stay informed about the latest developments in wireless personal area networks.

  • Wireless Personal Area Networks
  • HRP UWB PHY
  • Modulation Enhancements
  • Consensus Agreement
  • IEEE

Uploaded on | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. doc.: <15-18-0590-00-004z> November 2018 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [HRP UWB PHY enhanced mode converged consensus] Date Submitted: [14th November 2018] Source: [Billy Verso (Decawave), Frank Leong (NXP Semiconductors), Jochen Hammerschmidt (Apple), Jaroslaw Niewczas (Decawave Ltd.), Brima Ibrahim (NXP Semiconductors), Tushar Shah (Apple) Alejandro Marquez (Apple), Thomas Reisinger (Continental), Daniel Knobloch (BMW)] Address [Peter Street, Dublin 8, Ireland] Voice:[+353.87.233.7323], E-Mail:[billy.verso (at) decawave.com] Re: [HRP UWB PHY enhanced mode] Abstract: [Describe the agreed UWB frame elements for the enhanced mode] Purpose: [As a next step after the MIM consensus of 15-18-0375-00, and the consensus reached at the Waikoloa meeting on the more advanced enhanced modes as captured in 15-18-0477-00, this document represents a further converged consensus agreement on the HRP UWB PHY modulation enhancements] 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. Decawave, NXP, Apple, Continental, BMW Submission Slide 1

  2. doc.: <15-18-0590-00-004z> November 2018 Introduction: We have reached agreement on all key aspects of specification for the HRP UWB PHY for the 802.15.4z amendment as captured in the following slides MIM was agreed at 64 MHz PRF Doc 15-18-0375-00-004z captures this consensus There were open items with respect to the more enhanced modes where there are higher PRFs, longer sequences, additional SFD, new data modulations, etc. Doc 15-18-0477-00-004z gives the Waikoloa meeting consensus This document specifies the consensus for these open items Decawave, NXP, Apple, Continental, BMW Submission Slide 2

  3. doc.: <15-18-0590-00-004z> November 2018 July 2018 MIM PHR decision PHR at the data rate for MIM shall not be mandatory, it shall be optional Decawave, NXP, Apple, Continental, BMW Submission Slide 3

  4. doc.: <15-18-0590-00-004z> November 2018 Preamble Symbol: We have agreed: A length 91 Ipatov symbol (with 81 non-zero elements) We will choose a set of 8 suitable codes The mandatory sequence lengths are: 32, 64 symbols The optional lengths are: 16, 24, 48, 96, 128, 256 Decawave, NXP, Apple, Continental, BMW Submission Slide 4

  5. doc.: <15-18-0590-00-004z> November 2018 SFD: We previously agreed a length 8 SFD: - - - + - - + - It shall be mandatory to support SFD lengths of: 4, 8 and 16 It shall be optional to support SFD lengths of: 32 We now agree the following SFD patterns: Length 4 pattern = - - + - Length 16 pattern is TBD Length 32 pattern is TBD Decawave, NXP, Apple, Continental, BMW Submission Slide 5

  6. doc.: <15-18-0590-00-004z> November 2018 Scrambled Timestamp Sequence (STS): We previously agreed the AES-128 generation of the sequences and spreading by L=8 for 64 MHz PRF and L=4 for 128 MHz PRF We have agreed 1 s (512 chip) gap at start and end of the sequence We have agreed one length 32768 chips (~65 s) for the 64MHz PRF MIM and 2 lengths 16384 chips (~32 s) & 32768 chips (~65 s) for 128MHz PRF Longer lengths based on multiples of the 16384 chip unit as single and/or multiple segments (separated by gaps of 512 chips) shall be defined We now agree to have mandatory support for 1 and 2 segments, and optional support for 3 and 4 segments We intend to specify the interfaces associated with the separate segments as part of the MAC discussion We agree that the mandatory segment lengths (for 128 MHz PRF) in multiples of 512 chips shall be: 32, 64 and 128 The segment length of 256 512 chips is optional Decawave, NXP, Apple, Continental, BMW Submission Slide 6

  7. doc.: <15-18-0590-00-004z> November 2018 Data Modulation (1) for ~30 Mb/s mode We have agreed: 256 MHz PRF with 8 pulses per coded bit, with the pulses on 2ns spacing separated into two groups of four as shown: Using the 4a convolutional code (with [2,5] generator) and the mapping shown (right): Then the sequence is scrambled using the 4a LFSR Final bit value to pulse polarity mapping shall be as per 4a Mandatory FEC: K=3+RS (~27 Mb/s) G0 G1 PATTERN 0 0 0 0 0 0 <GAP> 0 0 0 0 <GAP> 1 0 1 1 1 1 <GAP> 0 0 0 0 <GAP> 0 1 1 1 1 1 <GAP> 1 1 1 1 <GAP> 1 1 0 0 0 0 <GAP> 1 1 1 1 <GAP> Optional K=7 code without RS (~31.2 Mb/s) using convolution code generator polynomial [133,171] and same mapping as table above. Decawave, NXP, Apple, Continental, BMW Submission Slide 7

  8. doc.: <15-18-0590-00-004z> November 2018 Data Modulation (2) for ~7 Mb/s mode We have agreed: 128 MHz PRF with 16 pulses per coded bit, with the pulses on 4ns spacing separated into two groups of eight as shown: Using the 4a convolutional code (with [2,5] generator) and the mapping shown (right): Then the sequence is scrambled using the 4a LFSR. Final bit value to pulse polarity mapping shall be as per 4a Mandatory FEC: K=3+RS (~6.8 Mb/s) Optional K=7 code without RS (~7.8 Mb/s) using convolution code generator polynomial [133,171] and same mapping as table above. G0 G1 PATTERN 0 0 0 0 0 0 0 0 0 0 <GAP> 0 0 0 0 0 0 0 0 <GAP> 1 0 1 1 1 1 1 1 1 1 <GAP> 0 0 0 0 0 0 0 0 <GAP> 0 1 1 1 1 1 1 1 1 1 <GAP> 1 1 1 1 1 1 1 1 <GAP> 1 1 0 0 0 0 0 0 0 0 <GAP> 1 1 1 1 1 1 1 1 <GAP> Decawave, NXP, Apple, Continental, BMW Submission Slide 8

  9. doc.: <15-18-0590-00-004z> November 2018 PHR We now agree that the PHR shall be 19-bits formatted as shown: 4 3 6 5 7 1 0 Bit 2 8 9 10 11 12 13 14 15 16 17 18 A1 A0 L9 L8 L7 L6 L5 L4 L3 L2 L1 L0 R0 S5 S4 S3 S2 S1 S0 R / G1 Rang ing G0 PHY payload length SECDED a) Ranging bit and SECDED encoding and functionality shall be as per 802.15.4-2015 b) Payload length field shall be 10 bits, so max PHY payload is 1023 octets long c) In the frame formats with PHR, bits A1 and A0 shall be available for application specific use, and be signaled to or set by the higher layer, and zero when not being used for this purpose.. d) In the optional frame format where the STS follows the payload, A1 and A0 shall be optionally available to specify an additional gap between the payload and the STS. Decawave, NXP, Apple, Continental, BMW Submission Slide 9

  10. doc.: <15-18-0590-00-004z> November 2018 PHR Encoding PSDU and PHR shall use the same convolutional code For the mandatory K=3+RS code, in the case of zero length data field, the full 21 symbols of PHR shall be transmitted, including two leading data bits D0 and D1 set to 0 to form a tail. (See 802.15.4-2015 Table 16-1) For consideration: adding 2 tail bits (of bit value = 0) in all situations is under review For the optional K = 7 (no RS) code, 6 tail bits (of bit value = 0) shall be included, (giving a 25 symbol PHR), to allow the convolution code to return to the zero state, before starting any following data field. Decawave, NXP, Apple, Continental, BMW Submission Slide 10

  11. doc.: <15-18-0590-00-004z> November 2018 July 2018 General To reduce the complexity of combining the different frame parameters, only some combinations of these shall be considered mandatory For the St. Louis meeting we shall specify mandatory combinations of the frame parameters (i.e. the lengths of SYNC, SFD and STS fields and the data rate) other combinations of these parameters shall be considered non-mandatory As a guideline to this exercise we expect that the STS will be at least as long as the SYNC field, and for each SYNC length there will be constraints on the associated SFD lengths Decawave, NXP, Apple, Continental, BMW Submission Slide 11

More Related Content