es IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Response to ES PAR and 5C Comments Date Submitted: March, 11, 2009 Presented at IEEE session #31 in Vancouver Authors or Source(s): G. Scott Henderson, RIM Abstract: This presentation is a point by point response to Comments on the Emergency Services PAR and 5C as presented in contribution /0017. These comments were prepared by the membership.

es IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. 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. 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 The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. 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. 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 The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6

es thanks for its comments on the Emergency Services draft PAR and 5 Criteria. Point by point responses to the input are on the following slides, and the modified PAR and 5C files resulting from all comments can be found on the document server as: es emergency- services-draft-PAR and es emergency-services-five-criteria.

es (1) Questions for clarification Why is this being proposed as a New Standard? How can you propose to solve the problem across all 802 standards by writing a document that specifically, by virtue of being a NEW standard, does not amend or modify any existing 802 standards? Until we understand the proposed functionality, we cannot understand how this is possible. This work is not intended as an extension of , but rather as an independent standards development effort. What is common about the PHY/MAC protocols under the 802 architecture that provides the ability to do an 802-wide solution for emergency services? Until we understand the proposed functionality, we cannot understand how this is possible. The work project will provide enabling tools to support emergency calling. Specific MAC and PHY changes would have to be developed by the appropriate WGs if necessary. Section 5.2 (Scope) says ‘for emerging requirements for text message and multimedia based emergency services requests.’ How does the media type map into 802 access technologies, especially those that are insensitive to higher layer media type definitions? The PAR has been modified to indicate that this work project will provide SUPPORT for emergency data sessions of any type.

es (1) Questions for clarification Where are the emergency service (ES) ‘functions’ defined? At what layer? For what geographical regions? The proposed standard does not constrain the geographic applicability of the standard, but neither is there any clear indication that the requirements are global. Emergency call requirements are defined by NENA, FCC and ETSI EMTEL as at least support for location, call integrity, call back and authenticated & unauthenticated calling. Geographical requirements vary, but that should not affect the L1/L2 tools proposed here. In Item B under the 5 Criteria Broad Market Potential, the response indicates that interested parties will have to respond to ‘changes resulting from this standard’. But the proposed standard is a NEW standard, not changes to existing standards. Please clarify what the changes are. The wording in the 5C has been clarified to indicate that the 'changes' would be to higher layer functionality in, for instance, IETF ECRIT. In Item C under the 5 Criteria Broad Market Potential,, if the changes are expected to be primarily to ‘software/firmware’, why is this being considered as a PHY & MAC new standard? Software/firmware is usually implementation-dependent and outside the scope of 802. Implementation of the changes is expected to be limited to software/firmware rather than new hardware. The 5C has been amended.

es (1) Questions for clarification The 5 Criteria Technical Feasibility response alleges that existing 802 solutions to ‘do not fully address all emergency services criteria.’ However, the PAR proposal admits intention to meet only a very limited set of the overall set of ES features. So why is a new partial solution superior to an existing partial solution? The final paragraph in 'Technical Feasibility' addresses the comment. In the 5 Criteria Technical Feasibility, what existing 802 functionality does the proposed new standard plan to reuse? There has been development in for location, in u for location and unauthenticated sessions, and has indicated that they have some support for emergency calls. As much as feasible, this existing work would be reused, along with any other work by other WGs. The draft PAR indicates that the project plan anticipates going to Sponsor Ballot in June This seems remarkably optimistic. On what basis does the group make such evaluation, given the expected level of cross-group coordination and experience in time required to develop standards? Agreed. The PAR is changed to June, 2011.

es (1) Questions for clarification In the 5 Criteria Distinct Identity section (1), the response identifies ‘location’ and ‘connection integrity’ functional requirements. What is it about the 802 architecture that enables a common method for assessing ‘location’?‘Connection integrity?’ For and , this would be the location of the 'point of attachment' (Ethernet port or AP). Location for would inherit/require work by that WG/WMF. Connection integrity can be identified as a combination of call continuity and anti spoofing. A layer 1-2 implementation rather than the current L3 and above has inherent advantages. In 5 Criteria Distinct Identity section (2), the response identifies ‘VoIP based emergency calls across all current 802 transport standards’. Including wireline? Doe the draft PAR propose solving this problem in both 802 wireless and wireline solutions? Yes. Emergency calls over need to supported equally well.

es (2) Comments and Suggested Remedies Comment: This PAR proposal is bipolar: in one place it says that it will provide an entirely new PHY & MAC specification; in other places is says that it will write other layer solutions or will amend other 802 standards. Suggested remedy: Please specify coherently and unambiguously in the Scope and Purpose whether this proposed project will be for a new PHY & MAC specification, for amendments to existing other 802 PHY & MAC specifications, for some other entirely new non-PHY&MAC layer development, or for an amendment to the existing features and functions. Ensure that the remainder of the draft PAR and 5 Criteria is consistent with the expression of the Scope and Purpose. PAR and 5C have been limited to support for emergency calling, with supporting MAC/PHY development if necessary in respective WGs. Comment: Section 5.2 (Scope): ‘As first priority…’ is unacceptable language for a Scope statement. The anticipated standard either does or does not specify the mechanisms. The same problem exists with ‘The additional objectives.’ Suggested remedy: The Scope should say ‘This standard defines mechanisms…’ or ‘This standard provides...methods…’ or similar language. Modify the Scope statement to employ the proper format and language for standards PARs. Furthermore, be explicit as to what sort of mechanisms, at what network layers, are being specified. PAR is amended. Phase are for future PARs.

es (2) Comments and Suggested Remedies Comment: Section 5.4 (Purpose): The language refers to ‘initial’ and ‘longer term’ development. The proposed standard cannot bind a future action; can only address what THIS standard achieves. The purpose statement, as written, is inappropriate for inclusion in a standard. Suggested remedy: Modify the Purpose statement to employ the proper format and language for standards PARs. PAR has been modified to cover only emergency calling. Comment: Section 5.5 of the PAR specifies that the proposed standard will develop a NEW PHY and (“This standard will provide the underlying transport layer (PHY and MAC) functionality”). Please describe this protocol in more detail. What is the medium? Is it for wireline applications? Wireless? While this text is in the ‘Need for the Project’ section, this language is consistent with actual Scope language, while Section 5.2 language is more consistent with identification of need. Suggested remedy: Modify Section 5.5 (“Need for the Project”) section to use appropriate ‘needs’ language, not Scope language. Section 5.5 has been modified.

es (2) Comments and Suggested Remedies Comment: In the 5 Criteria “Technical Feasibility” section, none of the responses seem to address Technical Feasibility. Suggested remedy: Modify The 5 criteria Technical Feasibility section to properly address Technical Feasibility. 5C has been amended. Comment: In the 5 Criteria “Economic Feasibility” section, the response should not depend on connection to the Internet. It should be independent of L3/L4 solution and network design. Suggested remedy: Modify 5 Criteria Economic Feasibility section to eliminate reference to Internet. Reference to the Internet has been removed.