1. IEEE 802.21 Emergency Services DCN: 23-11-000x-00-0000 Title: Solution Proposals Review Date Submitted: Jan. 18, 2011 Presented at IEEE 802.23 interim session in Los Angeles Authors or Source(s): Geoff Thompson, Interdigital And others who do not wish to be credited Abstract: This presentation reviews the basic 802 Emergency Services problem and issues set and the several proposed solutions discussed to date.

2. – IEEE 802.23 presentation release statements This document has been prepared to assist the IEEE 802.23 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 802.23. 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 http://standards.ieee.org/board/pat/faq.pdf> Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6- 7.html#6http://standards.ieee.org/board/pat/faq.pdf

3. Regulatory Overview USA: FCC 05-116 has the general requirements to support VoIP based 911 calls; New and Emerging Technologies 911 Improvement Act of 2008 (extends FCC 05-116) NENA NG 9-1-1 covers text, video, other multimedia 911/112 type calls NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2) Canada: CRTC 2005-21 and CTRC 2006-60 EC: ETSI TR 102 180: Basis of requirements for communication of individuals with authorities/organizations in case of distress (Emergency call handling) (EMTEL); TR 102 299: Collection of European Regulatory Texts and orientations (EMTEL); TR 102 476: Emergency calls and VoIP: possible short and long term solutions and standardization activities (EMTEL); TR 102 758 Emergency Communications (EMTEL); Study on unauthenticated and unregistered access to emergency services TS 102 424 Requirements of the NGN network to support Emergency Communication from Citizen to Authority (TISPAN) Japan: summarized in H. Arai and M. Kawanishi, “Emergency call requirements for IP telephony services in japan,” draft-arai-ecrit-japan-req-00, Internet Draft, Feb. 2005

4. ES VoIP CALL Internet PSAP POA AP PONA Router EUT PSTN PROXY 802 x PSTN Default SIP Server

5. Diagram Labels A: End User Terminal (EUT) B: Point of Attachment (POA) (e.g. 802.11 access point or 802.3 jack/switch port) C: 802 infrastructure (intervening bridges, switches or wireless connections) D: Point of Network Attachment (PONA) E: Default SIP Server F: PSTN Proxy server (if the PSAP does not support IP directly) G: PSAP Router (Direct IP support in the PSAP) H: PSAP Station

6. ES Requirements Authorized Service L1/L2 Authorized Service L3 (IP) Unauthorized Service L1/L2 Unauthorized service L3 (IP) Location – LOC A to route to the correct PSAP, and LOC B to direct emergency responders Callback – PSAP must be able to callback to the source of the call Security – for both the privacy of the ES call, and to prevent fraud

7. 802 ES Requirements Authorized Service L1/L2 Unauthorized Service L1/L2 Location Callback Security

8. ES Issues Priority / QoS – ES calls should have the highest priority available 802.1/3, 802.11, 802.16 all have partial but inconsistent solutions to the requirements VPNs can cause misrouting to the wrong PSAP – Enterprise: LOC appears as the hub, not the source – VoIP service provider: may show up as in another country

9. 802.23 Case Analysis Case analysis for whether a VoIP Emergency Services call from an EUT over an IEEE 802 network needs to take advantage of the Unauthorized Access features of 802.23 VoIP Service AvailabilitySecurity Considerations Layer 1-2 AccessEUT has established VoIP service EUT does NOT have established VoIP service EUT has established VoIP Service EUT does NOT have established VoIP service EUT has no previous access & doesn’t have access credentials Call goes through full 802.23 service path to default ES VoIP provider (any other solution is a service security risk) Call goes through full 802.23 service path to default ES VoIP provider 802.23 must provide sufficient security to meet requirements EUT has established access Not a case for ES involvement. EUT's ES call handled as a normal phone call as far as the L1L2 network is concerned. EUT is responsible for reporting location EUT can decide to use 802.23 service. If it does not, then the problem is outside the scope of 802 and it must be solved w/i the IETF area of scope. Call inherently has as much security as a normal phone call. This is sufficient. Security through L1/L2 is already determined unless there is a switch to 802.23 path.

10. Solution Proposal Areas ES Special VLAN SIP Proxy in PONA router Reserved ES SIP credentials LOC in POA LOC in PONA router Unique EtherType VPNs: break, bypass or ignore VLAN Timer for callback, NG911 EUT ES upper layer client requirements

11. ES Special VLAN Single destination (leaf to root direction) VLAN dedicated and limited to ES calls. Used to provide secure connections to the PONA router for EUTs with or without L1/2 credentials Provides highest QoS/priority May be used for ES Calls at application’s choice (has the advantage of easy solution for LOC A problem)

12. SIP Proxy in PONA Router For unauthenticated L1/2 and L3 ES Calls Establish SIP call based on L2 indicators – ES VLAN – ES EtherType Only one call destination address allowed – “default” SIP service or – PSAP proxy address Qualified calls only (per above) – Test mode needed (security risk)

13. Reserved ES SIP credentials For EUTs lacking L3 subscription credentials Stored / issued by PONA router Issued based on two L2 indicators – ES EtherType – Dedicated ES VLAN port Only one call destination address allowed – “default” SIP service and – PSAP proxy address

14. Location in POA As per IEEE 802.11u for WLAN in the AP – Geospacial and Civic supported As per IEEE 802.1 for 802.3 – Will require an 802.1 or 802.23 MIB (new) As per IEEE 802.16n for WiMAX Better accuracy than PONA (e.g. <150’ for APs) Varying formats, processes across 802 need to be harmonized

15. LOC in PONA router Location supported by network provider – more trusted Less accurate than POA – Only resolves to the size of the 802 LAN – May cover multi building campus or more – Assumed to not meet accuracy requirement when attached to an 802 LAN/MAN

16. ES Call Unique EtherType All L1/L2 identified ES call packets tagged with VLAN header of unique EtherType. Qualifies call data for ES VLAN, and VoIP service access. Used to limit call destination to PSAP. Can be used to identify EUTs lacking L3 authorization/credentials.

17. VPNs: Break, Bypass or Ignore Decision on this is made above Layer 1/2. VPNs provide a challenge for properly handling ES calls. By their nature they make the EUT appear in the wrong location and require additional processing to route an ES request to the correct PSAP. Break or Bypass: When the EUT makes an ES Call request, any VPN in place is either broken down or bypassed and the request is routed to the “default” local SIP provider for handling. Ignore: Leave the location problem for the SIP provider to sort out at higher layers.

18. Timer for callback, NG911 Keep the call path (e.g. EUT switch to ES VLAN) open for a period of time to allow for both re- origination from the EUT and for callback to an unauthorized EUT. Help support NG911 non-connection oriented communication such as IM/chat type ES Requests.

19. EUT ES Upper Layer Client Requirements -Assign to ES VLAN tag -Assign ES EtherType -If there is no SIP client, an ES call application -Break out/bypass VPNs -Request ES Credentials from PONA -Request location from POA