1. 802.16 WG Response to comments on 802.16p PAR & 5C IEEE 802.16 Presentation Submission Template (Rev. 9) Document Number: IEEE 802.16ppc-10/0009 Date Submitted: 2010-07-14 Source: Jose Puthenkulam E-mail: jose.p.puthenkulam@intel.com Project Planning Committee Chair Venue: San Diego, USA Base Contribution: None Purpose: To address comments received by the 802.16 WG on the 802.16p PAR & 5C and respond on behalf of the Working Group as authorized during the 802.16 WG Session #68 opening plenary Notice: This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16. Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: and.http://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/guides/opman/sect6.html#6.3 Further information is located at and.http://standards.ieee.org/board/pat/pat-material.htmlhttp://standards.ieee.org/board/pat

2. 210/27/2015 Outline Comments on 802.16p PAR & 5C received Revised PAR and 5C Responses to comments

3. 310/27/2015 Comments Received on the 802.16p PAR Comments from 802.11 WG –https://mentor.ieee.org/802.11/dcn/10/11-10-0860-00-0000-comments- for-802-16p-new-par-july-2010.ppthttps://mentor.ieee.org/802.11/dcn/10/11-10-0860-00-0000-comments- for-802-16p-new-par-july-2010.ppt Comments from 802.19 WG –https://mentor.ieee.org/802.19/dcn/10/19-10-0103-00-0000-proposed- par-comment.ppthttps://mentor.ieee.org/802.19/dcn/10/19-10-0103-00-0000-proposed- par-comment.ppt Comments from Pat Thaler received by email –http://www.ieee802.org/secmail/msg12756.htmlhttp://www.ieee802.org/secmail/msg12756.html –http://www.ieee802.org/secmail/msg12757.htmlhttp://www.ieee802.org/secmail/msg12757.html

4. 410/27/2015 Revised 802.16p PAR and 5C Addressing all the comments received the 802.16 Working Group has revised the 802.16p PAR and 5C –802.16ppc-10/0003r7 (http://dot16.org/ul//upload/ppc_db/80216ppc- 10_0003r7.doc )http://dot16.org/ul//upload/ppc_db/80216ppc- 10_0003r7.doc We thank the 802.11 WG, 802.19 WG and Pat Thaler for the useful comments. We hope the revised PAR addresses most of the concerns

5. 510/27/2015 Responses to 802.11 comments (1/11) Comments: –The 802.11 comments address a concern that other Working Groups may also consider “Machine to Machine” enhancements in future standards or amendments. - 2.1 Title – change the title to be more succinct. –Suggestion for title: “…- Enhancements for Machine to Machine Communication in licensed bands” –Is there a proper definition for “Machine to Machine” that is defined in the industry? Is there agreement for 802 usage of “Machine to Machine”? Responses: –We expect other Working Groups including 802.11 also to address the M2M space, so we have updated the 5.2 Scope and also the 5C appropriately –We agree with 802.11 WG suggestion in principle, however we prefer the title to be more general, so we decided to address the intent for licensed bands in the scope statement.

6. 610/27/2015 Responses to 802.11 comments (2/11) Comment: –The Scope should describe the technical description of the changes. We suggest that you drop the marketing portion of the description from the Scope. Also the acronym OFDMA and PHY will need to be spelled out. –5.2 Scope: Suggested scope-- –“This amendment specifies IEEE Std 802.16 medium access control (MAC) enhancements and minimal Orthogonal Frequency-Division Multiple Access (OFDMA) Physical layer (PHY) modifications in licensed bands for lower power consumption at the subscriber station, support by the base station of significantly larger numbers of devices, and efficient support for short burst transmissions. “ Response: –We have addressed these in the revised PAR as can be seen in the revised scope. We have more or less adopted the 802.11 suggested language with some additional modifications as shown below in the 5.2 scope: “This amendment specifies IEEE Std 802.16 medium access control (MAC) enhancements and minimal Orthogonal Frequency Division Multiple Access (OFDMA) Physical Layer (PHY) modifications in licensed bands to support lower power consumption at the device, support by the base station of significantly larger numbers of devices, efficient support for small burst transmissions, and improved device authentication.”

7. 710/27/2015 Responses to 802.11 comments (3/11) Comment: –5.3 – missing the explanation of the “yes”…please add a short description of why 802.16m is required. Response: –We have clarified this in the section 5.3. The 802.16p project builds on top of the features in 802.16m amendment. Comment: –5.4 Purpose – just describe what the amendment will include. This should be a present tense statement of what is in the document. The word “efficient” has no metric of quantification. Response: –We have removed the word “efficient”.

8. 810/27/2015 Responses to 802.11 comments (4/11) Comment: –5.5 Need for Project. The statement “significantly different” requirements does not seem correct. Nodes in the network pass data. It seems that the Need paragraph is describing application (Layer 7) differences rather than the MAC/PHY level differences that may be necessary. Response: –The Machine to Machine applications are cited to motivate the need for the project. However we have added language in 5.5 Need for Project, to also clarify the MAC and PHY enhancements that are needed.

9. 910/27/2015 Responses to 802.11 comments (5/11) Comment: - 5.6 Stakeholders: Describe “who” the stakeholders are. “government agencies” does not seem correct to include. Response: –We do not agree with 802.11 that government agencies are not stake holders. We believe US Department of Transportation (DOT), Department of Energy (DOE), National Institute of Standards and Technology (NIST) etc. could all benefit from this work. The reason we do not spell these out is because we would like to address all possible government agencies of interest.

10. 1010/27/2015 Responses to 802.11 comments (6/11) Comment: 7.1 add a note in 8.1 as to what the similarities or differences are. Response: –We updated 7.1 with current work. The work in other standards bodies is in different stages of progress. They may have similarities and differences, but they are not germane to this amendment, which is only enhancing the 802.16 Standard. Comment: –7.2c – Harmonization is not quite the right description for the relationship between WiMax and 802.16. This is for Harmonization with other International SDOs Response: –This has been addressed and the answer in 7.2c has been changed to No.

11. 1110/27/2015 Responses to 802.11 comments (7/11) Comment: –8.1 Additional explanatory Notes: Remove item 1.1 note…This is not necessary for the PAR. The number is assigned by the NesCom Administrator in consultation with the WG chair. NesCom does not allow the use of “o”. –The comment for 5.2 needs to be changed. We suggested that “machine-to- machine” was removed from the scope, so you do not need the definition here in 8.1. –Also the definition seems to be describing application (Layer 7) differences rather than the MAC/PHY level differences that may be necessary. Response: –The 8.1 notes have been updated to address the project numbering. –However, we have preserved the M2M definition, to help others understand the intent and relevance of this amendment. –We have also moved the backward compatibility statement from the scope 5.2 to this section.

12. 1210/27/2015 Responses to 802.11 comments (8/11) Comment: –Broad Market Potential The statement is primarily stating functionality that is provided in layers 3 to 7. The statement is not specific to what may be required in layer 1 or 2. Response: –We addressed this in the section 5.5. In this section we believe the broad market potential is with regards to the applications of this amendment. So we don’t feel the need to change it. Comment: –Distinct Identity While the statement is true for the 802.16 standard, it is not a complete or unique solution for all Machine-to-Machine communications. The word “standard” should be “amendment” in this context, and specific to 802.16. (both instances). Response: –We agree with this suggestion and have updated the 5C.

13. 1310/27/2015 Responses to 802.11 comments (9/11) Comment: –b) One unique solution per problem (not two solutions to a problem): Suggest to replace the text with the following: “The 802.16 standard does not currently address Machine-to-Machine communications.” Response: –We have updated b) with the statement “There is no other standard in IEEE 802 that is specifically targeting M2M applications in a wide coverage area supporting a large number of wireless devices in licensed bands at this time.” Comment: –c) Easy for the document reader to select the relevant specification. The use of “standard” is incorrect. Substitute “amendment” in two instances. Suggested change: “The title of this amendment and the scope are distinct enough for document readers to discern the application of this amendment ”. Response: –We have updated the 5C as per this suggestion.

14. 1410/27/2015 Responses to 802.11 comments (10/11) Comment: Technical Feasibility a) Demonstrated system feasibility. –Machine-to-Machine communication is an application and has been implemented using other technologies. –The statement should be reworded to state “Machine-to-Machine(M2M) communications has been shown to be feasible in many technologies and 802.16 is similar in characteristics of some of these technologies and therefore it is reasonable to assert that it is feasible for 802.16 to support M2M applications. Response: –We adopted the suggested language. Comment: Confidence in reliability. –Missing explanation. Response: –We have updated this section that was not filled out earlier.

15. 1510/27/2015 Responses to 802.11 comments (11/11) Comment: –Economic Feasibility –a) Known cost factors, reliable data. Change “…this standard over systems based on …“ to “…this amendment in systems based on …“ Response: –We have updated this section inline with the suggestion.

16. 1610/27/2015 Responses to 802.19 Comments (1/1) Comment –Technical feasibility requirement is not met. The Scope calls for only 3 specific narrow techniques to be developed. It is not clear that these 3 techniques can enable M2M operation nor is any information provided to demonstrate this under technical feasibility in the 5C’s. –Proposed resolution Broaden the scope to allow for any necessary means to enable M2M operation –Delete 2 nd sentence form scope and move it to the explanatory notes Provide detailed proof of technical feasibility under 5C’s – i.e. proof that the 3 techniques mentioned are sufficient to enable M2M Response –Please see revised 5C. The following statement has been added “Machine-to- Machine(M2M) communications has been shown to be feasible in many technologies and 802.16 is similar in characteristics of some of these technologies and therefore it is reasonable to assert that it is feasible for 802.16 to support M2M applications.” In addition to this we clarify the need for this project (5.5). –We have broadened the scope to address the device authentication aspects. At the same time, the intent is not to support every Machine to Machine application out there, but enable many that can benefit from the enhancements conceived in this amendment. We expect to address more features in future amendments as they become necessary.

17. 1710/27/2015 Responses to comments from Pat Thaler (1/3) Comment: –> The language in the PAR scope and purpose seems rather heavily based around buzz words that don't have clear meanings. –> Machine to Machine communication - all LAN communication is machine to machine in a reasonable sense of that term. (BTW, it isn't clear why Machine to Machine is capitalized in 5.2.) Even if you mean communication from machine to machine without a human directly initiating the transaction, much of internet traffic and data center traffic running on existing 802 networks fits that description. E.g. data transfers between servers, management monitoring, back-up. There should be a better term to describe communication with small automated devices for purposes such as observation and control. –> –> Even if one accepts that "machine" means some sort of autonomous device such as cameras, sensors and controllers, the communication with them is probably person/computer to machine and vice versa rather than the machines chatting amongst themselves. It seems that the issues addressed are more the need to efficiently support lots of simple machines connecting to the network regardless of whether messages are going between machines or machine to computer. Response: –We have updated the title to “Enhancements to support Machine to Machine Applications” We believe the word applications sufficiently signifies the intent and helps avoid the literal machine to machine interpretation –Also clarifications have been made to the purpose (5.3) to indicate the intent of this project. –If the title is obscure, it would be difficult to attract interested parties to the project.

18. 1810/27/2015 Responses to comments from Pat Thaler (2/3) Comment: –>Human-centric - I've looked around and don't see any consistent use of human-centric in a sense that works here. It seems to mostly be used with regard to technology to refer to making technology easy to use for humans. You seem to be using it more in the sense of human initiated or human controlled. And again, much of network traffic is already machine initiated. –> –> On a more minor note, you don't need an explanatory note to say you are skipping o. It has been IEEE practice to skip i and o since shortly after the time when we started IEEE 802.3i because of the tendency for confusion with 1 and 0. Response: –We adopted the terminology suggestions. –Also we did update the section 8.1 as per the comment.

19. 1910/27/2015 Responses to comments from Pat Thaler (3/3) Comment: –>Distinct Identity –>Regarding the 5 Criteria - Distinct Identity a): It isn't entirely accurate. The motivation for 802.3af Power over Ethernet standard was largely an enhancement to meet the needs of devices such as cameras, sensors and controllers so that they didn't require a separate power connection so there was a prior standard with the objective of providing for such devices. I'm not saying that your proposed work doesn't have distinct identity - just that the distinctness isn't as broad as your current statement. 802.3 already addresses large numbers of devices and very low power operation. Perhaps you can make your statement more accurate by qualifying it as applying to subscriber or wireless networks. Response: –We updated the sections as shown below : –a)Substantially different from other IEEE 802 standards: –This amendment is unique in its objective of providing M2M enhancements for 802.16 networks using licensed bands. Such capabilities are clearly distinct in terms of what’s provided in other standards because it requires unique enhancements like handling of extremely large number of devices in a large coverage area, very low power operation, etc. –b)One unique solution per problem (not two solutions to a problem): –There is no other standard in IEEE 802 that is specifically targeting M2M applications in a wide coverage area supporting a large number of wireless devices in licensed bands specifically at this time.