1. Contents of this presentation ● PAR material (Title, Scope, Purpose) ● Material as developed at previous meetings ● Provision for new/revised material ● 802 Five Criteria ● Material as developed at previous meetings ● Provision for new/revised material ● Technical/Regulatory Problem Statement ● Technical Description of Project (TBA) ● Rationale for technical approach (TBA)

2. (Draft) PAR Title (as of 11/19/09) 2.1 Title: Standard for Local and Metropolitan Area Networks- Emergency Services for Internet Protocol (IP) Based Citizen to Authority Communications

3. (Draft) PAR Scope (as of 11/19/09) Scope of Proposed Standard: ● This standard will define a mechanism that supports the need for consistent data that is specifically required for citizen-to-authority emergency services packet data encoded session initiation request and support compliance within IEEE 802 to applicable civil authority requirements. ● A new MAC or PHY is outside the scope of this effort.

4. (Draft) PAR Scope (as prop. 1/1/10) ● (Fill in any new text here)

5. (Draft) PAR Purpose (as of 11/19/09) The purpose of this standard is to support compliance to civil authority requirements complementary to IETF ECRIT specifications for citizen to authority emergency services functionality. This standard intends to encompass voice, data and multi-media requests across IEEE 802 using a new Layer 2 entity and associated behaviors and provide a uniform Structure of Management Information (SMI) for transferring required data for emergency services requests.

6. (Draft) PAR Purpose (as proposed 1/10) ● (Fill in any new text here)

7. 802 Five Criteria (ref: LMSC OM 081114, Cl. 11.5) ● 1. Broad Market Potential ● 2. Compatibility ● 3. Distinct Identity ● 4. Technical Feasibility ● 4.1. Coexistence of 802 wireless standards specifying devices for unlicensed operation ● 5. Economic Feasibility

8. 802 Criteria:1-Broad Market Potential OM Requirements: A standards project authorized by IEEE 802 shall have a broad market potential. Specifically, it shall have the potential for: a) Broad sets of applicability. b) Multiple vendors and numerous users. c) Balanced costs (LAN versus attached stations).

9. 802 Criteria:1-Broad Market Potential ECSG Response (as of 11/19/09): a)802 networks could be called upon to support emergency services requests. An IEEE 802 Emergency Services standard would be applicable to all such 802 wireless and wireline networks and mixtures thereof. b)This standard is needed to comply with existing and forthcoming multi-national regulatory requirements for those 802 networks described above. This standard will be extensible to enable support of emerging requirements for next generation emergency services. Next generation emergency services requirements are being generated by the emergency services operators and SDOs in concert with government authorities. c)Implementation of changes required by this standard will affect both end and relay devices in a balanced manner.

10. 1-Broad Market Potential A standards project authorized by IEEE 802 shall have a broad market potential. Specifically, it shall have the potential for: a)Broad sets of applicability. b) Multiple vendors and numerous users. c) Balanced costs (LAN versus attached stations). d)802 networks could be called upon to support emergency services requests. An IEEE 802 Emergency Services standard would be applicable to all such 802 wireless and wireline networks and mixtures thereof. e)This standard is needed to comply with existing and forthcoming multi-national regulatory requirements for those 802 networks described above. This standard will be extensible to enable support of emerging requirements for next generation emergency services. Next generation emergency services requirements are being generated by the emergency services operators and SDOs in concert with government authorities. f)Implementation of changes required by this standard will affect both end and relay devices in a balanced manner.

11. 802 Criteria:2-Compatibility OM Requirements: IEEE 802 defines a family of standards. All standards should be in conformance with the IEEE 802.1 Architecture, Management, and Interworking documents as follows: IEEE 802. Overview and Architecture, IEEE 802.1D, IEEE 802.1Q, and parts of IEEE 802.1F. If any variances in conformance emerge, they shall be thoroughly disclosed and reviewed with IEEE 802.1. Each standard in the IEEE 802 family of standards shall include a definition of managed objects that are compatible with systems management standards.

12. 802 Criteria:2-Compatibility ECSG Response (as of 11/19/09): a)The proposed project will be developed in conformance with the 802 Overview and Architecture. In addition it will accommodate the relay needs of the currently approved 802 wireless standards. b)The proposed project will be developed in conformance with 802.1D, 802.1Q, 802.1f. The equivalent needed specification notations will need to be brought forth by 802.11, 802.15, and 802.16. c)Managed objects will be defined in a manner that is consistent with existing policies and practices for 802.1 standards. Consideration will be made to ensure compatibility with the 802 architectural model including at least 802, 802.2, 802.1D, 802.1Q, and 802.1X. Consideration will be made to ensure that compatibility is maintained with 802 security mechanisms and that existing security is not compromised. There may be a minor amendment to 802.1Q required that is anticipated to be fully aligned the existing architecture.

13. 802 Criteria:3-Distinct Identity OM Requirements: Each IEEE 802 standard shall have a distinct identity. To achieve this, each authorized project shall be: a) Substantially different from other IEEE 802 standards. b) One unique solution per problem (not two solutions to a problem). c) Easy for the document reader to select the relevant specification.

14. 802 Criteria:3-Distinct Identity ECSG Response (as of 11/19/09): a)There is no single standard that provides Emergency Services citizen-to- authority calling support and location information for all of IEEE 802. Existing IEEE 802 standards provide some of the individual capabilities required to meet emergency services functionality (e.g. location, connection integrity). However, current implementations are inconsistent and do not provide all of the expected capabilities. b)The need for a unique and consistent IEEE 802 solution for emergency calls is driven by insufficient functionality for VoIP based citizen-to-authority emergency calls across current IEEE 802 data link standards. c)This standard by its title will be identified as the consistent and unique IEEE 802 definition of capabilities to support citizen-to-authority emergency calls.

15. 802 Criteria:3-Distinct Identity a)There is no single standard that provides Emergency Services citizen-to-authority calling support and location information for all of IEEE 802. Existing IEEE 802 standards provide some of the individual capabilities required to meet emergency services functionality (e.g. location, connection integrity). However, current implementations are inconsistent and do not provide all of the expected capabilities. b)The need for a unique and consistent IEEE 802 solution for emergency calls is driven by insufficient functionality for VoIP based citizen-to-authority emergency calls across current IEEE 802 data link standards. c)This standard by its title will be identified as the consistent and unique IEEE 802 definition of capabilities to support citizen-to-authority emergency calls. Each IEEE 802 standard shall have a distinct identity. To achieve this, each authorized project shall be: a) Substantially different from other IEEE 802 standards. b) One unique solution per problem (not two solutions to a problem). c) Easy for the document reader to select the relevant specification.

16. 802 Criteria:4-Technical Feasibility OM Requirements: For a project to be authorized, it shall be able to show its technical feasibility. At a minimum, the proposed project shall show: a) Demonstrated system feasibility. b) Proven technology, reasonable testing. c) Confidence in reliability.

17. 802 Criteria:4-Technical Feasibility ECSG Response (as of 11/19/09): a)The IEEE 802 portion of the functionality has been demonstrated by IEEE 802.16. There are other portions of the system functionality whose technical feasibility is outside our scope but IEEE 802 needs to provide the underlying support functions. b)This project would reuse and harmonize existing IEEE 802 functionality and utilize extensions to existing and proven IEEE 802 functionality to provide full implementation of citizen to authority emergency services capabilities. c)Existing IEEE 802 functions are tested and in service in commercial networks leading to a high confidence in those parts of the solution.

18. 802 Criteria:4-Technical Feasibility For a project to be authorized, it shall be able to show its technical feasibility. At a minimum, the proposed project shall show: a) Demonstrated system feasibility. b) Proven technology, reasonable testing. c) Confidence in reliability. a)The IEEE 802 portion of the functionality has been demonstrated by IEEE 802.16. There are other portions of the system functionality whose technical feasibility is outside our scope but IEEE 802 needs to provide the underlying support functions. b)This project would reuse and harmonize existing IEEE 802 functionality and utilize extensions to existing and proven IEEE 802 functionality to provide full implementation of citizen to authority emergency services capabilities. c)Existing IEEE 802 functions are tested and in service in commercial networks leading to a high confidence in those parts of the solution.

19. 802 Criteria:4.1-Wireless Coexistence OM Requirements: Coexistence of 802 wireless standards specifying devices for unlicensed operation ● A WG proposing a wireless project is required to demonstrate coexistence through the preparation of a Coexistence Assurance (CA) document unless it is not applicable. ● The WG will create a CA document as part of the WG balloting process. ● If the WG elects not to create a CA document, it will explain to the Sponsor the reason the CA document is not applicable.

20. 802 Criteria:4.1-Wireless Coexistence (This item is yet to be addressed by the Study Group). ECSG Chair Proposed Response (1/11/10): ● The ES-ECSG believes that a Coexistence Assurance document is not applicable to the proposed project as no new wireless signaling is being proposed. ● The SG believes there is no need to create a CA document as part of the WG balloting process. ● The SG believes that the above explanation should be sufficient.

21. 802 Criteria:5-Economic Feasibility OM Requirements: For a project to be authorized, it shall be able to show economic feasibility (so far as can reasonably be estimated) for its intended applications. At a minimum, the proposed project shall show: a) Known cost factors, reliable data. b) Reasonable cost for performance. c) Consideration of installation costs.

22. 802 Criteria:5-Economic Feasibility ECSG Response (as of 11/19/09): a)This project is equivalent to earlier projects in IEEE 802 which provided significant additional functionality for relatively small additions to firmware. b)See a. c)Installation of these features is consistent with normal software/firmware upgrades to a large portion of the installed base. We believe that implementation of this standard will be a small part of the implementation of the total required solution set.

23. 802 Criteria:5-Economic Feasibility For a project to be authorized, it shall be able to show economic feasibility (so far as can reasonably be estimated) for its intended applications. At a minimum, the proposed project shall show: a) Known cost factors, reliable data. b) Reasonable cost for performance. c) Consideration of installation costs. a)This project is equivalent to earlier projects in IEEE 802 which provided significant additional functionality for relatively small additions to firmware. b)See a. c)Installation of these features is consistent with normal software/firmware upgrades to a large portion of the installed base. We believe that implementation of this standard will be a small part of the implementation of the total required solution set.

24. Technical/Regulatory Problem Statement 911 services were originally based on the wireline customer databases of legacy incumbent local exchange carriers. This system fell apart or was seriously weakened as: ● Local phone service ceased to be dominated by a wireline monopoly. ● Cellular phones became significant. (They had no built- in location mechanism. They also had a weakened sense of just where they wanted to call for 911.) ● VoIP phone services grew. They also had no inherent location or call target mechanism

25. FCC Consumer Info Sheet http://www.fcc.gov/cgb/consumerfacts/voip911.pdf

26. US Requirement (adapted from: http://www.fcc.gov/cgb/consumerfacts/voip911.pdf )http://www.fcc.gov/cgb/consumerfacts/voip911.pdf The US FCC has imposed the following requirement: ● All interconnected VoIP providers must automatically provide 911 service to all their customers as a standard, mandatory feature without customers having to specifically request this service. VoIP providers may not allow their customers to “opt-out” of 911 service.

27. Requirements: Other countries ● Many other countries have similar requirements. ● There are national differences, especially with respect to: ● Emergency numbers other than “911”. ● Some countries have several numbers ● Some countries prohibit location info. ● Other details

28. 802 Problem ● IEEE 802 needs a single standard so that IP applications that “should” not need to know which 802 MAC is currently being used. ● This is envisioned as a “shim layer” that goes between an 802 end station MAC and its upper layer client. ● There will be similar pieces required for 802.1 relays to add per-hop location information (required for back-up when no end-location provided).

29. Contents of this presentation from this point on (still needed) (DELETE THIS SLIDE) ● Technical Description of Project ● Rationale for technical approach