IEEE Emergency Services DCN: Title: call flow for Layer 2 support for unauthenticated requests Date Submitted: March, 2011 Presented at IEEE session in Singapore Authors or Source(s): G. Scott Henderson, Research In Motion Abstract: This contribution proposes an call flow for Layer 2 support for unauthenticated ES requests. It also identifies some changes by component required to support this call flow.

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 VoIP CALL Internet PSAP POA AP PONA Router EUT PSTN PROXY 802 x PSTN Default SIP Server/ GW DHCP Server

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

Assumptions u and v conformance DHCP support would define the ES VLAN and the ES call flow identifier (e.g. ES Ethertype, SNAP Headers or 11u UESA bit (clause ) ) Default GW/SIP proxy address would be provided by a DHCP server (RFC 3361) Default GW/SIP proxy is similar to a P-CSCF in functionality Higher layer development would be similar/equivalent to 3GPP IMS ES support (e.g. TS , TS ) and would need to be developed by the IETF

Layer 2 Call Flow (1) User initiates an emergency service call. EUT has no L2 association or authentication EUT scans for all SSIDs in range, for each SSID detected it listens to the beacon for the interworking IE (information element) and looks for ESR (emergency services reachable =1) and UESA (unauthenticated emergency services access = 1) bits in the interworking element advertising ES support (802.11u 2011 clause X.1.5) EUT requests ES association (802.11u 2011 clause X.4.2)

Layer 2 Call Flow (2) AP bridges to an ES VLAN to the PONA router and maps the VLAN to only support emergency service traffic from the EUT from the air interface. EUT records location from AP (802.11u 2011) (Optional for the EUT: EUT can use its own location, uses the AP location, or ask the AP for the EUT’s location.) (802.11u 2011 clause X.4.2)* The layer 2 session is established. *in regulatory domains that allow/require location

Upper Layer Functions DHCP provides EUT with an IP address and the address to the Default GW/SIP Proxy The EUT signals to default SIP proxy/GW to open an ‘emergency context’ (comparable to an emergency bearer in 3GPP) to/from the EUT. (3GPP ) EUT sends an emergency SIP (unauthenticated) request (e.g. 911 SIP invite) (using ES Ethertype) (Includes MAC id of EUT and AP (for callback) as well as location) Default SIP proxy/GW forwards call only to a PSAP/ E(emergency)-CSCF PSAP responds with ‘2xx ok’ During the call and/or shortly after ending, PSAP may request new/updated location information

EUT Applications Requirements EUT must be u and v compliant EUT must get location from the AP if needed (802.11u 2011 clause X.4.2) Request to AP to set up an ES call The call request must use an ES call flow identifier (ES Ethertype, SNAP Headers or 11u UESA bit) Upper layer requirements also need to be defined for the EUT

AP Requirements The access point must be compliant to u and v The AP must provide LOC info (IEEE v 2011) The AP must support access to the ES VLAN to the PONA based on incoming ES Ethertype (or UESA bit or SNAP Header) The AP must be able to bridge ES traffic to the ES VLAN

PONA Router Requirements The router must recognize traffic arriving on ES VLANs as emergency requests The router will routes signaling and bearer traffic arriving over the ES VLAN to only the default SIP proxy/GW. The router will signal the default SIP proxy/GW to set up an ‘emergency context’

Default SIP Proxy/GW Requirements The gateway must support ‘SIP emergency services’ (e.g. 3GPP clause ) The SIP Proxy must forward ES call to the correct local PSAP In 3GPP terminology, this would be the P- CSCF (proxy call session control function)

References IEEE v Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 8: IEEE Wireless Network Management IEEE u Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 9: Interworking with External Network IETF RFC 3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS) Feb 2004 IETF RFC 3361 (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers Aug GPP TS IP Multimedia Subsystem (IMS) Emergency Sessions Release 11 January2011 3GPP TS IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Dec GPP TS General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access June 2010 Draft-ietf-sipcore-location-conveyance-04, Location Conveyance for Session Initiated Protocol Draft-patel-ecrit-sos-parameter-11, SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services