IEEE 802 Emergency Services Tutorial

1. IEEE 802 Emergency Services Tutorial Date: 2007-07-16 Authors: Scott Henderson Manfred Arndt Richard Paine Allan Thomson Matthew Gast Chair: Stephen McCann : stephen.mccann@roke.co.uk

2. Abstract This submission has been formed from the individual presentations made during the IEEE 802 Emergency Services Tutorial on 16th July 2007, San Francisco, California, USA.

3. IEEE 802 Emergency Services Tutorial • 20:00 : Introduction [Stephen McCann] • 20:05 : Regulations (An Engineer’s Viewpoint) [Scott Henderson] • 20:20 : 802.1AB Location [Manfred Arndt] • LLDP-REV • 20:35 : 802.11v Location [Dave Stephenson] • 20:50 : 802.11u [Matthew Gast] • 21:20 : Authority – Authority [Richard Paine] • Questions/Next Steps [Stephen McCann]

4. Emergency Services Regulations (An Engineer’s Viewpoint) G. Scott Henderson Research In Motion

5. Emergency Services Organizations • Government • FCC • UE Commission (Expert Group on Emergency Access (EGEA) ) • ATIS ESIF NGES • ANSI HSSP • US DoT • Emergency Services Project in Austria • Canadian Radio-television and Telecommunications Commission (CRTC) • ES • NENA = National Emergency Number Assoc. • APCO = Assoc. of Public Safety Communications Officials • Standards • IETF ECRIT • IETF GEOPRIV / LoST • WiMAX Forum • WiFi Alliance • ETSI EMTEL • ETSI TISPAN • 3GPP (IMS) • 3GPP2 • IEEE 802.1AB • IEEE 802.11 u, v • IEEE 802.16 • TIA LLDP-MED • TIA TR-45 • OMA • ITU-T • OCG • CTIA

6. Some of the Regulations/Standards • Wireless Communications and Public Safety Act of 1999, Pub. L. No. 106-81, 113 Stat. 1286, § 2(b) (1999) (911Act). • U.S. Senate Bill 2007 S428 (amends The Wireless Communications and Public Safety Act of 1999 (47 U.S.C. 615 et seq.) to include IP services) • FCC • FCC 05-116 FIRST REPORT AND ORDER AND NOTICE OF PROPOSED RULEMAKING • FCC 94-102 Docket no 94-102 including order numbers 96-264, 99-96, 99-245 • FCC DA 05-2945 November 28, 2005 Interconnected VoIP 911 Compliance Letters • EIA/J-STD-034-1997, Wireless Enhanced Emergency Services • TIA-J-STD-036-B Enhanced Wireless 9-1-1 Phase 2, 06/2005 • NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2) • EU Requirements (ETSI EMTEL, TISPAN, EGEA) • ROW requirements

7. Distillation: Requirements as they affect IEEE 802 Now • Location (Automatic Location Identifier) • Initial with MS ES request • Enhanced upon NSAP request • Most regulatory domains require, some are opt in only • Support for callback • Unauthenticated calls • Roaming and non roaming • Multi level priority for calls (not universal) • Multi level priority for LBS (location based services) flows (not universal)

8. Future Requirements • ECALL • Automated emergency calls • NG911 • Support for non voice ES connections

9. Location Issues • FCC 05-116 indicated multiple times that MS assisted location was OK for a start but long term “must include a method for determining a user’s location without assistance from the user” • Further, wireless VoIP should eventually be equivalent to cellular for 9-1-1 services • NENA has indicated that current cellular performance is inadequate and are requesting requirements be tightened • Handover after initiation could affect enhanced location requests, callback

10. Current Location Requirements • Carriers are required to have the capability to identify the latitude and longitude of the mobile units making 911 calls - For network-based solutions: 100 meters for 67% of calls, and 300 meters for 95% of calls; For handset-based solutions: 50 meters for 67% of calls, and 150 meters for 95% of calls

11. Other Location Interests • Lawful Intercept (CALEA, RIPA, etc.) • Communications Asssistance for Law Enforcement Act, Pub. L. No. 103-414, 108 Stat. 4279 (1994) (codified as amended in sections of 18 U.S.C. and 47 U.S.C.) • Communications Assistance for Law Enforcement Act, Report and Order, CC Docket No. 97-213, released March 15, 1999 (“First Report and Order”) • Communications Assistance for Law Enforcement Act, Report and Order, CC Docket No. 97-213, released August 31, 1999 (“Second Report and Order”) • Communications Assistance for Law Enforcement Act, Report and Order, CC Docket No. 97-213, released August 31, 1999 (“Third Report and Order”) • Communications Assistance for Law Enforcement Act and Broadband Access and Services, ET Doc. 04-295, 19 FCC Rcd 15676 (Aug. 9, 2004) (“CALEA and Broadband Notice of Proposed Rulemaking and Declaratory Ruling”) • Communications Assistance for Law Enforcement Act and Broadband Access and Services, ET Doc. 04-295, released September 23, 2005 (“CALEA and Broadband First Report and Order”) • FCC regulations: 47 C.F.R (Subpart U) § 64.100 et seq. • J-STD 025B (TIA/ANSI) • Location Based Commercial Services • DFS • Prevent erroneous AP setup • Loss of spectrum in Canada, possibly France

12. 802.1AB-Rev Proposal for Device Specific Location Delivery over Wireless LANsManfred Arndt - manfred.r.arndt@hp.com

13. Key Emergency Service Location Steps1 • Determination - process used to calculate or measure the physical location. For wireless, this involves measurement methods (signal strength triangulation, time of arrival, etc) • Acquisition - protocol mechanism used to deliver location info to clients • Conveyance - protocol mechanism use by clients to deliver location to routing elements and Public Service Access Point (PSAP). This will be PIDF-LO2 elements in the SIP header as defined by IETF Geopriv WG 1. NENA VoIP Location Working Group: Background - Location Requirements 2. Presence Information Data Format (PIDF) for Location Objects (LO)

14. Wireless Location Determination • Let access network interact with drivers and physical layer to determine enhanced location accuracy • Softphone application are user space programs that do not need to be involved with location determination and must not require driver specific knowledge for every access technology on a given device (e.g. GPRS, 802.11, 802.16, etc.) • Use simple low level frames to exchange signal level, channel, etc. • Multiple mechanisms are required, to support clients without 11v capabilities, proprietary vendor specific solutions, etc. • Must keep unnecessary complexity out of driver, since this exposes too many security and buffer-over run vulnerabilities

15. Location Acquisition • Define a mechanism applicable across all IEEE 802 networking technologies for the access network to deliver location info to clients • Must not require softphone application to use a unique interfaces for every technology supported on a given device (e.g. GPRS, 802.11, 802.16, etc.) • This is a management protocol that does not belong in a kernel space • Very low interest in 11v & 11k from several radio chipset manufacturers • Must not require any driver modifications • Must be able to support some level of client location, via user mode SW only • Drivers updates for embedded devices is challenging and in practice rarely done • New location formats, if defined, must not require a new rev of driver (past experience has shown that new formats are likely) • Must align with IETF ECRIT Emergency Call Service architecture and IETF Geopriv location-based services

16. 802.1AB-Rev Applicability to 802.11 • 802.1AB benefits • 802.1AB operates above the MAC service layer, and as such can be easily implemented, without requiring any driver modifications • Reduced complexity with high interoperability potential • Added benefit of supporting any type of location based service (not just ECS) • Applicable to all IEEE 802 networks and would provide common interface across many networking technologies for ECS capable software applications • 802.1AB (LLDP) and ANSI/TIA-1057 (LLDP-MED) applicability • Industry accepted solution, already deployed in many wired IP phones and Ethernet bridges • Believed all interfaces required for ECS location delivery are defined today • Draft IETF Emergency Services Best Practices - all telephone and mobile devices MUST support LLDP-MED location (DHCP and yet to be defined L7 method must also be supported) • DHCP snooping and L7 mechanism not well suited for fine-grain location delivery, since no interface for interaction with access points and servers are defined • 802.1AB-Rev applicability • In the May 2007 Interim, it was decided to allow sending LLDP to unicast addresses specifically to support 802.11 stations • As such, LLDP-MED can provide physical location delivery of the AP (via multicast) as well as station specific location (via unicast)

17. VoWLAN Location Overview • AP can auto-discover it’s physical location via LLDP-MED from wired bridge • Bridges must support LLDP-MED location delivery anyway, for wired IP phones • Wireless stations would quickly discover new physical location on roaming • 802.1AB-Rev “fast-start” provides timely location discovery on roaming • 802.1AB-Rev “rapid transmission” provides timely updates for moving stations with low overhead for stationary devices (e.g. eliminates client “where am I?” polling) • Device location reference point • All APs must advertise ‘AP specific location’ using LLDP multicast (suitable for many cases) • APs capable of higher accuracy can optionally advertise ‘client specific location’ via 802.1AB-Rev unicast mode

18. Summary • 802.1AB provides several advantages for physical location delivery • MAC independent, well defined standard, that can run in user space • Simple and effective with high interoperability potential • Existing industry accepted solution, already deployed on wired Ethernet • Supports both client specific location ("where am I?") and network specific location ("where are you?") to align with 802.11 requirements • Can provide common ECS interface across all 802 networking technologies • Already agreed on 802.1AB-Rev changes beneficial to this proposal • Fast-start supports timely location discovery on roaming • Rapid transmission well suited for timely updates of moving stations and low overhead for stationary devices (e.g. station doesn’t have to continuously poll AP) • Unicast address mode for client specific location Recommend decoupling location determination from acquisition in wireless and use LLDP-MED

19. Enables Physical Location Services, including Emergency Call Service (ECS) Supports NENA E911 and other location services (for example NENA TID 07-501) Multiple Location Formats Supported, and easily extensible Coordinate-based LCI (Location Configuration Information) subtype as defined by IETF RFC 3825 Civic Address LCI subtype defined by IETF RFC 4676 ELIN (Emergency Location Identification Number) subtype, for traditional PSAP Emergency Calls One or more formats may be used simultaneously for different endpoint requirements Two ECS methods supported (End-device & Notification based) Bridge advertises periodic location info for endpoint to use Bridge sends notification whenever a new endpoint is detected or an endpoint moves ANSI/TIA-1057 Location TLV

20. Wireless location Allan Thomson, Cisco

21. 3 Important Presence Requirements • Capability Advertisement • The ability for the infrastructure and STAs to advertisement their capabilities • Location determination • The ability to control and manage location determination features of wireless devices • Location determination is necessary for reliable and accurate location to be distributed • Location distribution • The ability to distribute location information between wireless infrastructure and wireless STAs

22. Capability Advertisement • Requirement to provide unique capability exchange per STA • Not all STAs will require the same information format…etc • AP must respond to location requests if AP advertises capability • STAs advertise their location capabilities in Beacons, Probe Responses, (Re)Association Requests • Capability information includes • Format (CIVIC, Geo, Location by Reference…etc) • Encoding (Binary, XML…etc) • Resolution • Capable of providing • self-location • remote-location

23. Location Determination Requires… • Reliable and timely communication of frames from a STA • STA frames must be detected close-in-time by multiple APs • Appropriate presence policy applied by APs for all associated STAs • Goal: To provide measurements necessary for high accuracy above “associated AP” accuracy

24. Typical Location Determination Messages

25. Determining correct floor is required for in-building presence and emergency services Within buildings devices (e.g. phones) can associate to any AP on any floor Depends on RF Coverage Phone presence announcements seen on multiple floors Location determination resolves appropriate floor based on all measurements Floor Level Accuracy Requirement

26. Building Accuracy Requirement • Determining correct building is required for presence and emergency services • Across buildings: devices (phones) can associate to any AP in any building within RF coverage

27. AP Responsibilities Manages setup of STA presence messages for Frequency Stationary and In Motion parameters Interframe Interval Timing Measurements Channel set Channel Numbers and Regulatory Class Policy administration AP can ensure all STAs in BSS conform to presence reporting policies Can disassociate STA if failure to comply Additional measurements in 11k such as Measurement Request/Response help location determination STA Responsibilities Sends presence messages based on AP control Presence Messages include: Radio information including Antenna gain, Transmit Power, Received RSNI, Antenna ID for Rx and Tx Timing Measurements Motion Indication Location Determination Requirements

28. Location Distribution Requirements • Secure • Complies with privacy rules around location • Scalable • Enables network to provide accurate location for large number of clients • Timely • Enables network to provide location very close-in-time to emergency events or other location events • Specific • Enables network to provide location specific for a device in the format and options it requires

29. Location Distribution: Request Based • Meets all requirements • Secure • Sent by either AP or non-AP STA in unicast frame with 802.11w encryption • Timely • Options for one-shot “On Demand” or event-based “subscription” • Specific • STA can request its own location with options • Format (CIVIC, Geo…etc) • Encoding (Binary, ASCII) • Resolution (AP, XY, Building…etc) • Accuracy Estimate • STA can request the AP’s location • STA can provide it’s own location if capable of self-determination • Scalable • Single message when required • Avoids continuous transmission of broadcasts or unicasts

30. Location Distribution: Broadcast • Sent by APs in beacon or probe response • Does not meet all requirements • Not secure • Can be seen by any non-associated STAs, security risk? • For general location distribution, privacy is required • For Emergency Services location distribution, no privacy may be acceptable • Not timely • Broadcast has to be scheduled very infrequently • Not scalable • No way of knowing which clients are using location or not • Adds load to the infrastructure to provide location when unclear who and what is using it • Wastes Over-The-Air bandwidth • Not specific • Broadcast relates to AP position not STAs

31. TGv Meets Requirements 1: ANSI/TIA-1057 LLDP-MED

32. Final Thoughts • Location object format is common across TGv and other protocols • Wireless location requires a protocol that fits a dynamic physical environment • Supporting one protocol for location determination and another for distribution complicates the infrastructure and the client • Location requirements for wireless MAN systems are equally, if not more, challenging • Location security and privacy critical issues • TGv meets all requirements for wireless location and emergency services

33. 802.11u and Emergency Services Matthew Gast Trapeze Networks Note: This presentation is based on 802.11u-D1.0 and subject to change by future standards activity

34. Major Features of 802.11u • External network (“SSPN”) interface for extended authorization • New QoS features • Generic Advertising Service (GAS) • Emergency services recommendations (informative) • Use case #1: open network • Use case #2: public credentials

35. External Network (SSPN) Interface • SSPN = Subscription Service Provider Network • SSP holds user credentials • May build or partner with 802.11 access networks • The SSPN may direct the STA-AN, for example by: • Requiring that a certain encryption type is used (e.g. CCMP only) • Setting allowed access rates for different types of traffic (e.g. 80 kbps voice, no video, and up to 500 kbps best effort) • Specifying a minimum delay bound on transmitted frames • Admission Control • TSPEC processing is subject to authorized data rates as specified by SSPN

36. QoS Signaling in 802.11u • Expedited Bandwidth Request • 802.11 has only four categories (voice, video, best effort, and background) • Many STAs may request high-priority voice service • EBR allows a STA to describe the reason that it is requesting service and the network can act accordingly • Example: emergency calls and first-responder traffic can pre-empt “normal” voice traffic • QoS Map • 802.11 QoS settings only affect last-hop access; QoS Map allows APs and STAs to extend higher-layer QoS settings • Ensures correct QoS treatment of frames even if destination networks use DSCP differently

37. Generic Advertising Services (GAS) • Interface to external information sources • Example: Carrier of 802.21 data • Extensible for types beyond 802.21 • “Native” query mode • Assists STA with information stored in the 802.11 access network • Example: enhances scan for multi-SSID use, so that a secondary SSID can be used for emergency services • Operational details (in brief) • Multicast/unicast operation • Query size limits: administrators can configure response limit size • Emergency Services native query: type of authentication

38. Uses “emergency services only” (ESO) bit to signal that the SSID can support emergency services without any 802.11-level security Network must enforce appropriate security (out of scope for 802.11) Network is “locked down” to emergency calls only e.g. dedicated VLAN, IP firewall Emergency Services Use Case #1: Dedicated SSID STA (11u-capable) AP (11u-capable) Beacon (w/ESO bit) Note: SSID list is optional; used in multi-SSID deployments GAS Native Query (SSID list + ES info) GAS Native Query Response Association Request Association Response ADDTS Request (w/Expedited BW Req.) ADDTS Response Restricted Network e.g. dedicated VLAN, IP filtering, etc. Initiate higher-layer call (e.g. SIP)

39. ESO calls have no cryptographic protection (tampering, injection, forgery) To provide cryptography, 802.11i security must be used Pre-shared key for all emergency networks is not feasible 802.11u provides a way for a network to set up an “emergency public credential” to use EAP methods EAP method needs clarification Emergency Services Use Case #2: Public Credentials STA (11u-capable) AP (11u-capable) GAS Native Query (emergency public credentials) GAS Native Query Response (credentials) Association Request Association Response EAPOL/EAP-Identity-Request EAPOL/EAP-Identity-Response (credentials) EAP method authentication 4-Way Handshake ADDTS Request (w/Expedited BW Request) ADDTS Response Initiate higher-layer call (e.g. SIP)

40. Authority and Emergency Services Richard Paine Boeing

41. Authorities • Police • Fire • Rescue • Emergency Services • Government Organization • Non-Governmental Organization (NGO) • Military • Airport • Airplane • Ship • Bus

42. Definitions • http://psc.wi.gov/apps%5Cvia%5Cdocument%5C5TI1076%5CUSC%20Cellular-PCS%20E911%20Emer%20Svcs%20011504.pdf “E911 Authority" means a municipality or other State or Local government unit, or an authorized agent of one or more municipalities or other State or Local government units to whom authority has been lawfully as the administrative entity to manage a public emergency telephone system for emergency police, fire, and emergency medical services through the use of one telephone number, 911.

43. PSTN Provider 911 • PSTN Wireless Service Providers offer physical locations • PSTN Providers have agreements with 911 authorities

44. Ethernet Provider 911 • Ethernet (802.3) Wired Service Providers offer physical locations • Ethernet (802.3) Wired Service Providers have agreements with 911 authorities

45. Cellular Service Provider E911 • Cellular Wireless Service Providers offer GPS and Cellular location • GPS location not generally avbl in-building • Cellular location accuracy must be within 100m • Providers have agreements with FCC

46. 802.11 Service Provider E911 • 802.11 Service Providers need to have 11k location (any source) • 802.11 VOIP providers will have 11k or 11v location • GPS location not generally avbl in-building • WLAN RTLS location accuracy will be within 10m • Enterprises with 802.11 have agreements with E911 authorities

47. Large Enterprise E911 • Boeing has ~60,000 seats of VOIP • Awarded contract to supply E911 services via GW • Future is VOIP over the WLAN • Need to provide E911 locations via WLAN • Labels on portable and mobile computing devices

48. IEEE 802.11 E911 Issues • Guns and hoses security • Business Locations (mobile equipment and people) • Assurances that identities are authentic • Dumbing down technology to fit switched telephony

49. Enterprise VOIP E911 Caution:911 service using this device may be limited or unavailable.

50. Use Case: Boeing 1 MP Sensor MP Sensor Infrastructure Network MAP MP Sensor MP Sensor MP Sensor MPP MP Sensor MP Sensor MP Sensor MAP MP Sensor MP Sensor Primary Route Secondary Route MP Sensor