• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Emergency Services Tutorial
 

Emergency Services Tutorial

on

  • 511 views

 

Statistics

Views

Total Views
511
Views on SlideShare
511
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page AP - Access Point SSID - Service Set Identifier
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page
  • Page

Emergency Services Tutorial Emergency Services Tutorial Presentation Transcript

  • 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
  • Abstract
    • This submission has been formed from the individual presentations made during the IEEE 802 Emergency Services Tutorial on 16 th July 2007, San Francisco, California, USA.
  • 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]
    • Emergency Services Regulations (An Engineer’s Viewpoint)
    • G. Scott Henderson
    • Research In Motion
  • 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
  • Some of the Regulations/Standards
    • Wireless Communications and Public Safety Act of 1999, Pub. L. No. 106-81, 113 Stat. 1286, § 2(b) (1999) (911 Act).
      • 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
  • 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)
  • Future Requirements
    • ECALL
      • Automated emergency calls
    • NG911
      • Support for non voice ES connections
  • 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
  • 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
  • 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
  • 802.1AB-Rev Proposal for Device Specific Location Delivery over Wireless LANs Manfred Arndt - manfred.r.arndt@hp.com
  • Key Emergency Service Location Steps 1
    • 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-LO 2 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)
  • 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
  • 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
  • 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)
  • 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
  • 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
    • 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
    • Wireless location
    • Allan Thomson, Cisco
  • 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
  • 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
  • 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
  • Typical Location Determination Messages
  • Floor Level Accuracy Requirement
    • 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
  • 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
  • Location Determination Requirements
    • 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 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
  • 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
  • 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
  • TGv Meets Requirements 1 : ANSI/TIA-1057 LLDP-MED Provides broadcast Provides Secure, Timely, Scalable, Specific Location Distribution None Provides control and high accuracy Location Determination None Provides per STA capability advertisement Capability Advertisement LLDP-MED 1 TGv Requirement
  • 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
    • 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
  • 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
  • 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
  • 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
  • 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
  • Emergency Services Use Case #1: Dedicated SSID
    • 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
    AP (11u-capable) STA (11u-capable) Beacon (w/ESO bit) Association Request Association Response Initiate higher-layer call (e.g. SIP) GAS Native Query (SSID list + ES info) GAS Native Query Response Restricted Network e.g. dedicated VLAN, IP filtering, etc. Note: SSID list is optional; used in multi-SSID deployments ADDTS Request (w/Expedited BW Req.) ADDTS Response
  • Emergency Services Use Case #2: Public Credentials
    • 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
    AP (11u-capable) STA (11u-capable) Association Request Association Response Initiate higher-layer call (e.g. SIP) GAS Native Query (emergency public credentials) GAS Native Query Response (credentials) EAPOL/EAP-Identity-Response (credentials) EAPOL/EAP-Identity-Request EAP method authentication 4-Way Handshake ADDTS Request (w/Expedited BW Request) ADDTS Response
    • Authority and Emergency Services
    • Richard Paine
    • Boeing
  • Authorities
    • Police
    • Fire
    • Rescue
    • Emergency Services
    • Government Organization
    • Non-Governmental Organization (NGO)
    • Military
    • Airport
    • Airplane
    • Ship
    • Bus
  • 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.
  • PSTN Provider 911
    • PSTN Wireless Service Providers offer physical locations
    • PSTN Providers have agreements with 911 authorities
  • Ethernet Provider 911
    • Ethernet (802.3) Wired Service Providers offer physical locations
    • Ethernet (802.3) Wired Service Providers have agreements with 911 authorities
  • 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
  • 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
  • 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
  • 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
  • Enterprise VOIP E911
    • Caution:911 service using this device may be limited or unavailable.
  • Use Case: Boeing 1 MP Sensor MP Sensor MP Sensor MP Sensor MP Sensor MP Sensor MP Sensor MAP MAP MPP MP Sensor MP Sensor MP Sensor MP Sensor Primary Route Secondary Route Infrastructure Network
  • Use Case: Boeing 2
  • Use Case: Boeing 3 – Guns and Hoses Offices Mesh Points Mesh Points
  • Use Case: Boeing 4 – Guns and Hoses Factory Mesh Points Access Points N
  • Large Enterprise E911
  • Authority Issues
    • Authority
    • Policy
    • Control
  • Authority
    • Governmental Organizations (GOs)
    • Non-governmental Organizations (NGOs)
    • Legitimacy and Establishment of ES Organizations
    • Management of Authorities
  • Policy
    • Policy Creation
    • Policy Decision
    • Policy Enforcement
  • 802.11 Emergency Services Objectives
    • Why have this tutorial?
    • What is the problem?
    • What do we want to achieve in 802.11?
  • What does 802.11 Want to Achieve?
    • 11k Location - Measurement Request/Response
    • 11u Interworking – E911 using either RRM or NM (non-AP uses AP location if available to SSPN)
    • 11v Location - Management Request/Response
  • Next Generation 802.11 Wireless Security
    • Policy Development
    • Policy Decision Points
    • Policy Enforcement Points
    • Privacy
    • Security
  • Policy – Wiki Definition
    • A policy is a deliberate plan of action to guide decisions and achieve rationale outcome(s). The term may apply to government, private sector organizations and groups, and individuals. Examples of policies include presidential executive orders , corporate privacy policies , or even Wikipedia's policies .
    • Policy may also refer to the process of making important organizational decisions, including the identification of different alternatives such as programs or spending priorities, and choosing among them on the basis of the impact they will have. Policies can be understood as political, management, financial, and administrative mechanisms arranged to reach explicit goals.
  • Conclusions
    • 11k and 11v providing E911 location for WLAN devices and 11u their interworking
    • Future Requirements
      • Policy
      • Next generation of WLAN security
        • Identity
        • IEEE 802.11 Device Security
  • SMA Elements: PKI Badge cert Temp cert Client RA SSL/TLS Tunnel 1 2 Boeing PKI SLDAP
    • Badge used for Client Auth; TempCert request sent to RA
    • RA issues TempCert
    • Client has TempCert available for up to 8 hours
    TempCert Provisioning Process
  • SMA Elements: NDS
    • Support for real-time endpoint mobility & location data
    • Future integration with Boeing DNS and directory (CED, NAMS-ng) infrastructure
    Enterprise DNS Proxy Security Perimeter Virtual Directory SLDAP Client Policy Decision Daemon Middleboxes Client DNS DDNS Location Server Directory Information Flow
  • Concluding Straw Poll
    • Would you like to see these issues discussed more in November 2007?
    • 802 Ad Hoc (32)
    • 802 Architecture Group (8)
    • Something Else (4)
    • Nothing (0)