Mar. 2018 Consolidated Responses to Comments Received on the PARs and CSDs for: 802.15.4w LPWA 802.15.4x FAN Extensions 802.15.4y Security Next Gen 802.15.4z.

Mar. 2018 Consolidated Responses to Comments Received on the PARs and CSDs for: w LPWA x FAN Extensions y Security Next Gen z Enhanced Impulse Radio-UWB Bob Heile, Wi-SUN Alliance

802.15.4w PAR & CSD Comment Responses
Mar. 2018 w PAR & CSD Comment Responses Joerg ROBERT (FAU Erlangen-Nuernberg), Chair w Joerg Robert, FAU Erlangen-Nuernberg

Response to the comments from Dr. P. K. (Train Wreak) Gilb
Mar. 2018 Response to the comments from Dr. P. K. (Train Wreak) Gilb Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment JG #1: PAR 5.2b Comment: Add the anticipated range that this new PHY will provide Remarks / Answers to the Comments: Accept: Added text to anticipate the range of typical LPWAN networks. Text in PAR/CSD: This amendment defines a Low Power Wide Area Network (LPWAN) extension to the IEEE Std LECIM PHY layer to cover network cell radii of typically km in rural areas. Joerg Robert, FAU Erlangen-Nuernberg

Comment JG #2: PAR 5.2b cont’d
Mar. 2018 Comment JG #2: PAR 5.2b cont’d Comment: Delete "as needed“ Remarks / Answers to the Comments: Accept: “as needed” is deleted as suggested. Text in PAR/CSD: Modifications to the Medium Access Control (MAC) layer, needed to support this PHY extension, are defined as needed. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment JG #3: PAR 5.5 Comment: The text says that high link margin is required for interferers, but doesn't put a value on "high". What is high and why don't current PHYs in meet it? Remarks / Answers to the Comments: Accept: Figures added to PAR document. Text in PAR/CSD: A main functional requirement for LPWANs is achieving improved link margin (typically 155 dB dB) to deal with interferers and achieve distances of typically 10 km - 15 km in rural areas using a low transmit power (typically 14 dBm), while maintaining low energy consumption Joerg Robert, FAU Erlangen-Nuernberg

Comment JG #4: PAR 5.5 cont’d
Mar. 2018 Comment JG #4: PAR 5.5 cont’d Comment: -140 dBm sensitivity implies -174 dBm/Hz + 10 dB SNR and NF gives -164 dBm/Hz, leaving only 24 dB for BW, or 251 Hz. That would likely give < 1 kb/s, which doesn't work for IoT. From where does this -140 dBm come? Text in PAR/CSD: Remarks / Answers to the Comments: Revised: We will insert in 8.1 the following clarification: -140 dBm is the typical sensitivity in current Low Power Wide Area Systems. A bit-rate of 1 kb/s is sufficient for many LPWA IoT applications. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment JG #5: PAR 5.5 cont’d Comment: “The end result is the inability to guarantee the required transmission reliability in such scenarios." Wireless networks can never "guarantee the required transmission reliability" and this project won't change that fact. Text in PAR/CSD: The end result is the inability to guarantee the required transmission reliability in such scenarios. This amendment is needed to close this gap and to provide reliable transmission at receiver sensitivities of -140dBm while delivering multiyear battery life. The end result is the inability to achieve the required transmission reliability in such scenarios. This amendment is needed to close this gap and to provide adequate receiver sensitivities of typically -140 dBm while still delivering multiyear battery life. Remarks / Answers to the Comments: Accept: “Guarantee” and “reliable” are removed and text revised. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment JG #6: PAR 5.5 cont’d Comment: "receiver sensitivities of -140dBm while delivering multiyear battery life." already provides multi-year battery life with the existing PHYs. There does not appear to be anything proposed with the amendment that would improve battery life. In fact, by spreading the information over a longer period of time, the receiver would be on longer, using more power, not less. Text in PAR/CSD: Remarks / Answers to the Comments: Accepted: See comment JG #5 for revised text. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment JG #7: CSD 1.2.3 Comment: Quantify "high immunity to interference". Remarks / Answers to the Comments: Accept: Text is revised in CSD document. Text in PAR/CSD: The proposed project enhances and is limited to the existing LECIM FSK PHY. It uniquely provides a combination of capacities in low data rate, latency tolerant applications not available in any other standard, such as enhanced link margin and long range, while delivering high immunity to interference and still maintaining a multiyear battery life. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment JG #8: CSD 1.2.5 Comment: None of the reasons given address why this specific, new addition will be similar in cost to existing devices (which vary widely in cost, depending on which version of you implement). Are there LECIM devices fielded? Remarks / Answers to the Comments: Accept: Text is modified in the CSD document. Text in PAR/CSD: This project can be implemented with no hardware changes and therefore change to the existing device cost basis which has been demonstrated, through billions of shipped devices. Joerg Robert, FAU Erlangen-Nuernberg

Comment JG #9: CSD 1.2.5 cont’d
Mar. 2018 Comment JG #9: CSD cont’d Comment: The answer for c) does not address item c), which has to do with installation costs, no manufacturing methods. Remarks / Answers to the Comments: Accept: Text is replaced in CSD document. Text in PAR/CSD: Implementation of this amendment requires no change to current manufacturing methods. This project can be implemented with no hardware changes and therefore to the existing implementation costs which has been demonstrated, through billions of shipped devices. Joerg Robert, FAU Erlangen-Nuernberg

Response to the comments from IEEE 802.3
Mar. 2018 Response to the comments from IEEE 802.3 Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #1: PAR 5.3 Comment: Question is not answered, please do so. Remarks / Answers to the Comments: Accept: Answer to question is added. Text in PAR/CSD: Is the completion of this standard dependent upon the completion of another standard: No Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #2: PAR 6.1b Comment: Not sure who recommended review but if so, the RAC Chair is unaware of a recommendation from the RAC or from editorial staff (typically occurring because of content found in MEC review). RAC review can also be requested by the WG/TG later without a PAR modification if "not anticipated" registry related content appears in the draft. Please refer to the PAR form instructions (copied at end of slide deck) for when a Yes answer is appropriate and consider if the answer should be changed to No. (The RAC has reviewed IEEE Std ) Remarks / Answers to the Comments: Accept: Registration activity is not required. Answer is changed to “no”. Text in PAR/CSD: 6.1.b. Is the Sponsor aware of possible registration activity related to this project?: YesNo If yes please explain: There should be none but a RAC review is recommended Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #3: CSD 1.2.5c Comment: The answer about manufacturing costs is non-responsive to the question about installation costs. Please provide a responsive answer. Remarks / Answers to the Comments: Accept: Text is modified in the CSD document. (identical to comment JG #8) Text in PAR/CSD: This project can be implemented with no hardware changes and therefore change to the existing device cost basis which has been demonstrated, through billions of shipped devices. Joerg Robert, FAU Erlangen-Nuernberg

Comment 802.3 #4: CSD 1.2.5d Comment:
Mar. 2018 Comment #4: CSD 1.2.5d Comment: Change IEEE Std to IEEE Std (remove the dot after Std). Remarks / Answers to the Comments: Accept: Dot is removed in the revised CSD document Text in PAR/CSD: There are already devices using IEEE Std in volume shipment operating in the same frequency bands and PHY modes. Joerg Robert, FAU Erlangen-Nuernberg

Response to the comments from IEEE 802.11
Mar. 2018 Response to the comments from IEEE Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #1: PAR 2.1 Comment: Use of “Low Power” should include a range or limit. Remarks / Answers to the Comments: Reject: This is the industry recognized nomenclature for this class of network Text in PAR/CSD: Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #2: PAR 2.1 cont’d Comment: expand “LEICM” Remarks / Answers to the Comments: Accept: LECIM is expanded. Text in PAR/CSD: Amendment for a Low Power Wide Area Network (LPWAN) extension to the LECIM (low-energy, critical infrastructure monitoring) Physical layer (PHY). Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #3: PAR 5.2b Comment: editorial remove extra period “Std.” should be “Std” Remarks / Answers to the Comments: Accept: Text is modified as suggested Text in PAR/CSD: This amendment defines a Low Power Wide Area Network (LPWAN) extension to the IEEE Std LECIM PHY layer Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #4: PAR 5.2b cont’d Comment: correct “<30kBit/s” should “< 30 kb/s” Remarks / Answers to the Comments: Accept: “<30kBit/s” is changed to “< 30 kb/s” and position of PHY is adjusted Text in PAR/CSD: It uses the LECIM PHY FSK (Frequency Shift Keying) PHY modulation schemes with extensions to lower bit-rates (e.g. payload bit-rate typically < 30 kbBit/s) Joerg Robert, FAU Erlangen-Nuernberg

Comment 802.11 #5: PAR 5.2b cont’d Comment: expand “FSK”
Mar. 2018 Comment #5: PAR 5.2b cont’d Comment: expand “FSK” Remarks / Answers to the Comments: Accept: The term FSK is expanded in the PAR document. The order of FSK and PHY is changed. Text in PAR/CSD: It uses the LECIM PHY FSK (Frequency Shift Keying) PHY modulation schemes with extensions to lower bit-rates (e.g. payload bit-rate typically < 30 kbBit/s). Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #6: PAR 5.2b cont’d Comment: delete “Furthermore, it defines lower code rates of the FEC in addition to the K=7 R=1/2 convolutional code. Modifications to the Medium Access Control (MAC) layer, needed to support this PHY extension, are defined as needed.” or at least reword to be definitive and define “lower code rates” and the reword to make meaning of “K=7 R=1/2 convolutional code” clear. Remarks / Answers to the Comments: Accept: It defines additional lower code rates of the Forward Error Correction (FEC). Modifications to the Medium Access Control (MAC) layer, needed to support this PHY extension, are defined. Text in PAR/CSD: It defines additional lower code rates of the Forward Error Correction (FEC). Modifications to the Medium Access Control (MAC) layer, needed to support this PHY extension, are defined. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #7: PAR 5.2b Comment: define the expected range of “Wide Area Network”. i.e. what are you expecting to reach. Remarks / Answers to the Comments: Accept: Added text to anticipate the range of typical LPWAN networks. (identical to comment JG #1) Text in PAR/CSD: This amendment defines a Low Power Wide Area Network (LPWAN) extension to the IEEE Std LECIM PHY layer to cover network cell radii of typically km in rural areas. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #8: PAR 5.5 Comment: What is “very high link margin” vs “high link margin”? rewording is expected. Remarks / Answers to the Comments: Accept: The word “very” is replaced by improved. Additionally, a commonly accepted link margin range figure (e.g. ETSI, 3GPP) of 155 dB – 160 dB is added. (identical to comment JG #3) Text in PAR/CSD: A main functional requirement for LPWANs is achieving improved link margin of typically 155 dB dB to deal with interferers and achieve distances of typically 10 km - 15 km in rural areas using a low transmit power (typically 14 dBm), while maintaining low energy consumption. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #9: PAR 5.5 cont’d Comment: Please include definition of the expected range and power that is being included in the specification. Remarks / Answers to the Comments: Accept: The expected range and the power are added to the PAR document. (identical to comment JG #3) Text in PAR/CSD: A main functional requirement for LPWANs is achieving improved link margin of typically 155 dB dB to deal with interferers and achieve distances of typically 10 km - 15 km in rural areas using a low transmit power (typically 14 dBm), while maintaining low energy consumption. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #10: PAR 5.5 cont’d Comment: “guarantee” reword this sentence as you will not be able to “guarantee” in general. Remarks / Answers to the Comments: Accept: The word “guarantee” is removed from the PAR. See identical comment JG #5 for revised text. Text in PAR/CSD: Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #12: PAR 5.6 Comment: delete “and similar organizations” – not necessary (and misspelled). Remarks / Answers to the Comments: Accept: Text is deleted from the PAR document. Text in PAR/CSD: Chip Vendors, Product Manufacturers, Wireless Carriers, Utilities, Cities, Agriculture, Infrastructure/Environmental Monitoring Organizations and similar organtizations. Joerg Robert, FAU Erlangen-Nuernberg

Mar. 2018 Comment #13: PAR 8.1 Comment: Add full name of the cited “IEEE Std ah. Remarks / Answers to the Comments: Accept: Added full name as requested to the PAR document in section 8.1. Text in PAR/CSD: IEEE Std ah, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 2: Sub 1 GHz License Exempt Operation Joerg Robert, FAU Erlangen-Nuernberg

802.15 SG FANE PAR & CSD Response
March 2018 SG FANE PAR & CSD Response Matthew Gillmore Itron Matthew Gillmore (Itron)

March 2018 P x Comments from 802.3 Amendment: FANE (Field Area Network Enhancements) PAR 6.1.b — The RAC Chair is not aware of a recommendation from the RAC to review this project (nor it being flagged for review by editorial staff, typically occurring because of content found in MEC review), nor a request in general for PHY oriented projects. RAC review can also be requested by the WG/TG later without a PAR modification if "not anticipated" registry related content appears in the draft. Please refer to the PAR form instructions (copied at end of slide deck) for when a Yes answer is appropriate and consider if the answer should be changed to No. (The RAC has reviewed IEEE Std ) – Modify change the answer to NO CSD 1.2.1,b — Change IEEE Std to IEEE Std (remove the dot after Std). - Accept 1.2.5,c — The answer about manufacturing costs is non-responsive to the question about installation costs. Please provide a responsive answer. – MODIFY Change the answer to “Implementation of this amendment requires no change to current installation costs and costs could potentially be reduced because less network equipment could be required” Matthew Gillmore (Itron)

March 2018 x Comments from PAR 2.1 – Expand “SUN” – Modify:change to Smart Utility Network (SUN) PAR 2.1 – change “2.4Mb/s” to “2.4 Mb/s” – Accept PAR 5.2.b – delete “IEEE Std ” - Accept PAR 5.2.b - missing space in “2.4Mb/s” again. - Accept PAR 5.2.b – delete “, as needed,” - Accept PAR 5.5 – add “IEEE” in front of (two locations). - Accept PAR 6.1.b – Why “Yes” for a PHY specific only PAR? – should be “No”. – Modify: Change the answer to 6.1.b to NO Matthew Gillmore (Itron)

Comments from Dr. James P.K. (Train Wreak) Gilb
March 2018 PAR 5.2b o Provide an estimated range for this PHY mode in the scope. Modify: Add sentence to clarify range of up to 5 kilometers with line of sight using omnidirectional antennas. PAR 6.1.b o I would suggest that this is no as the PHY won't modify any of the use or definition of addressing. If the RAC wants to review, you can always send them a copy to look at. But the answer to the question is no, you don't anticipate any registration activity. - Modify, change to NO Matthew Gillmore (Itron)

Comments from Dr. James P.K. (Train Wreak) Gilb
March 2018 CSD 1.2.5 o None of the reasons given address why this specific, new addition will be similar in cost to existing devices (which vary widely in cost, depending on which version of you implement). At the very least, these answers should be specific to the widespread deployment of SUN PHY devices. o The answer for c) does not address item c), which has to do with installation costs, no manufacturing methods. The WG should take the time to actually answer these questions and not just cut and paste previous answers. – Modify 1.2.5b to : “Anticipated enhancements of this amendment will utilize current SUN implementations and should not affect or create additional costs for implementation. This amendment could reduce cost of SUN implementations” c to: Implementation of this amendment requires no change to current installation costs and costs could potentially be reduced because less network equipment could be required” d to : There are already IEEE devices in volume shipment operating in the same frequency bands and PHY modes. The proposed enhancements included in this project could reduce well-known operational costs. Matthew Gillmore (Itron)

802.15 SG SECN PAR & CSD Comment Responses
March 2018 SG SECN PAR & CSD Comment Responses Don Sturek Itron Don Sturek (Itron)

March 2018 y Comments from PAR 2.1 Change “Amendment defining security extensions to IEEE Std adding at a minimum Advanced Encryption Standard (AES)-256” to “ Amendment defining support for Advanced Encryption Standard (AES)-256 encryption and security extensions.” Accept PAR 5.2.b change “Std.” to “Std” Accept Don Sturek (Itron)

y Comments from March 2018 PAR 5.2b Change Scope statement to present tense and remove “at a minimum”. Accept Change “This amendment defines security extensions to IEEE Std adding, at a minimum, AES-256. It also defines possible methods to simplify the addition of future encryption modes and key lengths. IEEE Std currently supports either AES-128 or no security” To “This amendment adds support for AES-256 encryption and defines security extensions to allow for future encryption modes and key lengths. “ Accept PAR 5.5 no need to capitalize “Quantum Computing” Revise, removed the reference as a result of sn comment CSD b) need space between “control,etc.” Accept Don Sturek (Itron)

y Comments from 802.3 March 2018 PAR 2.1 — As an amendment to , it is unnecessary to repeat what standard the extensions are for (especially when Std is incorrectly followed by a dot). Accept. Fixed in revised title suggested by Also the title doesn’t need to include a repeat of the project scope. How about Amendment Security extensions (preferred) or Amendment Security extensions including Advanced Encryption Standard (AES) Revised, used the change suggested by PAR 5.2.b — Change IEEE Std to IEEE Std (remove the dot after Std). Accept PAR 5.2.b — The “possible” does not seem to be properly placed in: “It also defines possible methods to simplify the addition of future encryption modes and key lengths.” (Hopefully no standard will define an impossible method.) Is the project really planning to define a set (“methods") of ways to add new modes and keys; or is the possible supposed to mean the project may or may not define a method to simplify adding new keys and modes; or should “possible” simply be deleted? Accept, removed the word “possible” as part of an comment response. Don Sturek (Itron)

March 2018 P y Comments from 802.3 CSD Title — If PAR title is changed per comments, also change on the CSD. Accept 1.2.1,a — Not all that responsive to the question about broad applicability. Isn’t the point that has significant market presence and that addition of better security is demanded for that broad application base, and continued deployment to will require better security? Adding something on that line would make the answer more responsive to the question. Accept, changed the text to read: “IEEE has significant market presence and the addition of better security is demanded for that broad application base and continued deployments.” 1.2.3 — Change IEEE Std to IEEE Std (remove the dot after Std). Accept 1.2.3, last sentence — Should it read: "The SECN extensions will be unique from features in the existing standard which is currently limited to AES-128 encryption or no security." Accept Don Sturek (Itron)

y Comments from 802.1 March 2018 This PAR is being brought forward in advance of calls for proposals, but at the same time introduces a constraint on those proposals. For the reasons described in the following comments it would be better to delay the PAR until there is a better sense of what the final standard should achieve. Revise: This and the next 4 comments are addressed by modifying the scope to: “This amendment defines security extensions to IEEE Std adding AES-256-CCM plus a cipher suite/authentication method registry and a process for inclusion of additional algorithms. The registry defines a capability to align IEEE Std with the security requirements of higher layer standards.” 2. Referencing the use of a block cipher (AES-256 or any other) might meet a marketing need but is not technically sufficient as a description of a project constraint, unless all possible modes (allowing the use of a block cipher to encipher data - such as frame contents - in excess of the block size) are to be supported, which is not well expressed by "at a minimum". If a specific cipher is to be identified as part of the Scope, the Cipher Suite (mode as well as block cipher, if a block cipher such as AES is to be used) needs to be specified. Don Sturek (Itron)

March 2018 P y Comments from 802.1 3. Changes to protect against future attacks should not prejudge the nature of or the solution to those attacks. This proposed amendment should ensure that replacement of the specification of one Cipher Suite by another can be accomplished in a modular fashion, without further extensive specification revision. It should also ensure that the Cipher Suite (or Cipher Suites) that might be use by a particular implementation are appropriately identifiable by each of the key management protocols specified in IEEE Std While it is highly desirable to limit the proliferation of Cipher Suites, with a goal of there being a single Cipher Suite in predominant use at any time, transition periods and the need for stability for particular groups of implementations have to be accommodated. Don Sturek (Itron)

P y Comments from 802.1 March 2018 4. An appropriate project description might (a) introduce the appropriate standard flexibility/agility for Cipher Suite use as noted in our comment 3 above, while (b) setting out criteria for inclusion of one or more Cipher Suites for inclusion in this amendment (as opposed to future amendments, in response to new attacks or a general need for more stringent criteria). These criteria should encompass security strength, relative cost (licensing, computational efficiency, memory), hardware and software suitability, and external acceptability. For ease of general understanding these criteria might be stated in terms of existing well-known Cipher Suites and implementation characteristics (e.g. offering a security strength greater than that of AES-128-CCM). 5. Real world systems that make use of can also participate in higher layer protocols that also need to be secured. The effect of decisions on total system cost is affected by the degree to which resources (hardware assist, code) can be shared across the system. This makes it important to be sensitive to, and some extent dependent on, developments outside the scope of What are the other security standards that systems targeted by this PAR will depend upon (e.g. EAP-TLS and its options, IEC 62591, IEC 62374)? Don Sturek (Itron)

P y Comments from 802.1 March 2018 6. The point made about automated configuration made in CSD c does not appear to be supported by any activity identified by the PAR scope. Why will automated configuration not apply equally to the use of AES-128 and to the use of AES-256? Agreed, removed 7. This PAR is being brought forward at a time when there is active high quality work on future Cipher Suites. See CAESAR: It is reasonably likely that this competition will complete prior to the completion of the proposed y project, and will result in one or more widely acceptable Cipher Suites with at least one of these offering significant cost advantages for computationally constrained and memory constrained implementations. Insisting on the inclusion of an AES-256 based Cipher Suite in the proposed amendment might then result in confusion as to what should be included in an implementation with resulting increased costs if a superior (in the general application space) is available. Understood. That is why we have included define methods of security extensions to allow for future encryption modes and key lengths Don Sturek (Itron)

P y Comments from 802.1 March 2018 8. As an editorial issue, the title of this PAR is inappropriate. It appears to be a sentence, being nearly identical to the first sentence of the scope of the project. It may more appropriate to generalize it as simply " Amendment: security extensions” Revise: Used the modified title provided by Don Sturek (Itron)

<month year> doc.: IEEE <492> March 2018 Responses to PAR/CSD Comments Received on PAR and CSD P z Amendment: Enhanced IR-UWB Ranging (EIR) Benjamin Rolfe, Blind Creek Associates <author>, <company>

Summary Comments received from 802.3 (6)
March 2018 Summary Comments received from (6) Comments received from (6) Comments received from James Gilb (3) Benjamin Rolfe, Blind Creek Associates

March 2018 Comment # : PAR Comment: PAR 5.5 — Change IEEE Std to IEEE Std (remove the dot after Std). Response: Agree. Change made as suggested. Benjamin Rolfe, Blind Creek Associates

Comment #2 802.3: PAR Comment: Response: Agree. Changed to “No”.
March 2018 Comment # : PAR Comment: PAR 6.1.b — The RAC Chair is not aware of a recommendation from the RAC to review this project (nor it being flagged for review by editorial staff, typically occurring because of content found in MEC review, nor in general PHY oriented projects. RAC review can also be requested by the WG/TG later without a PAR modification if "not anticipated" registry related content appears in the draft.) Please refer to the PAR form instructions for when a Yes answer is appropriate and consider if the answer should be changed to No. (The RAC has reviewed IEEE Std ) Response: Agree. Changed to “No”. Benjamin Rolfe, Blind Creek Associates

Comment #3,4 802.3: CSD Response: Agree. Change made as requested
March 2018 Comment #3, : CSD Broad Market, a — Typo and grammar: “is a widely” -> “is widely”, “Ihings” -> “Things“ Response: Agree. Change made as requested Broad Market, b — Doesn’t the phrase "into automotive remote control and associated Smart Phone Applications, to cite just one example” have two examples? Response: Agree. Changed “one” to “two” Benjamin Rolfe, Blind Creek Associates

Comment #5,6 802.3: CSD Response: Agree. Change made as requested
March 2018 Comment #5, : CSD Distinct Identity — Change IEEE Std to IEEE Std (remove the dot after Std). Response: Agree. Change made as requested Technical Feasibility, b — Change IEEE Std to IEEE Std (replace the dot after Std with a space). Benjamin Rolfe, Blind Creek Associates

Comment #7,8 802.11: PAR Response: Agree. Changed as requested
March 2018 Comment #7, : PAR PAR 2.1 change “Amendment enhancing existing Impulse Radio-Ultra Wide Band (IR-UWB) Physical Layers (PHYs) and associated ranging techniques” To “Amendment enhanced Impulse Radio-Ultra Wide Band (IR-UWB) Physical Layers (PHYs) and associated ranging techniques” Response: Agree. Changed as requested PAR 5.2.b. change “This amendment enhances existing” to “This amendment enhances the” Benjamin Rolfe, Blind Creek Associates

March 2018 Comment #9,10,11, : PAR PAR 5.2.b delete “within IEEE Std ”. (this is self-referencing). Response: Agree. Changed as requested PAR 5.2.b – delete “, and others as appropriate” and move “and” before last item. PAR 5.2.b – move second to last sentence (“The goal….”) to 5.5 – not needed here. Response: Agree. “These PHY enhancements better address the needs of current applications and as well as meeting the needs of a wider set of applications where the integrity and accuracy of distance measurement is important.” has been moved to 5.5 PAR 5.2.b – replace last sentence with “The amendment defines MAC changes to support these PHY enhancements. Response: Agree. Change as requested Benjamin Rolfe, Blind Creek Associates

Comment 12,13,14 from James Gilb-PAR
March 2018 2.1: I am unaware of any IR-UWB PHYs in There are LRP UWB and HRP UWB PHYs, but not IR-UWB PHYs. Rename the standard to modify either the HRP or LRP UWB PHYs, which ever is appropriate. Agree: Changed IR-UWB to “High Rate Pulse repetition frequency (HRP) and Low Rate Pulse repetition frequency (LRP) UWB” 5.2b Include the anticipated range of the PHY developed for this amendment to the scope. Agree: add “Typical range of the radio is up to 100 meters” 6.1.b I would suggest that this is no as the PHY won't modify any of the use or definition of addressing. If the RAC wants to review, you can always send them a copy to look at. But the answer to the question is no, you don't anticipate any registration activity. Agree: changed to “no” Benjamin Rolfe, Blind Creek Associates

Mar. 2018 Consolidated Responses to Comments Received on the PARs and CSDs for: 802.15.4w LPWA 802.15.4x FAN Extensions 802.15.4y Security Next Gen 802.15.4z.

Similar presentations

Presentation on theme: "Mar. 2018 Consolidated Responses to Comments Received on the PARs and CSDs for: 802.15.4w LPWA 802.15.4x FAN Extensions 802.15.4y Security Next Gen 802.15.4z."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Mar. 2018 Consolidated Responses to Comments Received on the PARs and CSDs for: 802.15.4w LPWA 802.15.4x FAN Extensions 802.15.4y Security Next Gen 802.15.4z.

Similar presentations

Presentation on theme: "Mar. 2018 Consolidated Responses to Comments Received on the PARs and CSDs for: 802.15.4w LPWA 802.15.4x FAN Extensions 802.15.4y Security Next Gen 802.15.4z."— Presentation transcript:

Similar presentations

About project

Feedback