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)

(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(Affirmed 1/12/2010)

(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.

(Draft) PAR Scope (as prop. 1/12/10) ● This standard will define a mechanism that supports compliance within IEEE 802 to applicable civil authority requirements for citizen-to-authority emergency services packet data communications. Specifically, it supports the need for consistent data that is required for citizen-to-authority emergency services packet data encoded session initiation requests. ● A new MAC or PHY is outside the scope of this effort. (Affirmed unan. as revised 10:10 AM, 1/12/2010)

(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. (Affirmed unan. 10:25 AM, 1/12/2010)

802 Five Criteria (ref: LMSC OM , 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

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).

802 Criteria:1-Broad Market Potential ECSG Response (as of 1/12/10): 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.

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). 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.

802 Criteria:2-Compatibility OM Requirements: IEEE 802 defines a family of standards. All standards should be in conformance with the IEEE 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 Each standard in the IEEE 802 family of standards shall include a definition of managed objects that are compatible with systems management standards.

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 , , and c)Managed objects will be defined in a manner that is consistent with existing policies and practices for 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.

802 Criteria:2-Compatibility ECSG Response (Modified and accepted 1/12/10): ➔ Managed objects will be defined in a manner that is consistent with existing policies and practices for 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. Some adaptations may be needed to meet regulatory requirements and thus will need a thorough cross-802 security considerations review. There may be a minor amendment to 802.1Q required that is anticipated to be fully aligned the existing architecture.

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.

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.

802 Criteria:3-Distinct Identity ECSG Response Draft (as of 1/12/10): 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 (and emerging technology) 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.

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.

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.

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 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.

802 Criteria:4-Technical Feasibility ECSG Response (drafted/approved 1/12/10, 11:30 AM): a)The IEEE 802 portions of the functionality have been demonstrated in existing IEEE 802 standards (.1,.11, 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 with understood existing mechanisms. b)This project would reuse and harmonize existing IEEE 802 functionality and utilize extensions to existing and proven IEEE 802 functionality to provide full and consistent 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.

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 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.

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.

802 Criteria:4.1-Wireless Coexistence ECSG Accepted Response (1/12/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.

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.

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.

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.

Break for Lunch Tues 11:55

Technical/Regulatory Problem Statement 911 call origination identification was originally based on the wireline legacy incumbent local exchange carriers' databases of their customers. 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

Regulatory Technical Problem Statement Emergency Services calls need: ● To be directed to the appropriate PSAP ● Carry originating location information ● Be handled on a high priority basis ● To provide sufficient information for call-back Further: ● Systems are required to provide service to any user. (Authorized subscriber or not)

FCC Consumer Info Sheet

(Example:) US Requirement (adapted from: ) 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.

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

Defined Problem lies in Multiple Domains ● IP, routing and higher layer portions of the problem belong to the IETF. ● These problems are being addressed primarily by IETF ECRIT. ● The below Layer 3 portion of the problem is for 802 to address. ● and have already done some explicit work in this area. ● Needs to be handled uniformly across 802.

802 Problem ● IEEE 802 needs a single standard so that IP applications “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 relays to add per-hop location information (required for location back-up information when no end-location information is provided).

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