emergency services tutorial
TRANSCRIPT
July 2007
Slide 1
IEEE 802
Tutorial
IEEE 802 Emergency Services TutorialDate: 2007-07-16
Authors:
Scott Henderson
Manfred Arndt
Richard Paine
Allan Thomson
Matthew Gast
Chair: Stephen McCann : [email protected]
July 2007
Slide 2
IEEE 802
Tutorial
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.
July 2007
Slide 3
IEEE 802
Tutorial
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]
July 2007
Slide 4
IEEE 802
Tutorial
Emergency Services Regulations (An Engineer’s Viewpoint)
G. Scott Henderson
Research In Motion
July 2007
Slide 5
IEEE 802
Tutorial
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
July 2007
Slide 6
IEEE 802
Tutorial
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
July 2007
Slide 7
IEEE 802
Tutorial
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)
July 2007
Slide 8
IEEE 802
Tutorial
Future Requirements• ECALL
– Automated emergency calls
• NG911– Support for non voice ES connections
July 2007
Slide 9
IEEE 802
Tutorial
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
July 2007
Slide 10
IEEE 802
Tutorial
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
July 2007
Slide 11
IEEE 802
Tutorial
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
July 2007
Slide 12
IEEE 802
Tutorial
802.1AB-Rev Proposal for Device Specific Location Delivery over Wireless LANs
Manfred Arndt - [email protected]
July 2007
Slide 13
IEEE 802
Tutorial
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)
July 2007
Slide 14
IEEE 802
Tutorial
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
July 2007
Slide 15
IEEE 802
Tutorial
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
July 2007
Slide 16
IEEE 802
Tutorial
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)
July 2007
Slide 17
IEEE 802
Tutorial
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
July 2007
Slide 18
IEEE 802
Tutorial
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
Recommend decoupling location determination from acquisition in wireless and use LLDP-MED
July 2007
Slide 19
IEEE 802
Tutorial
• 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
July 2007
Slide 20
IEEE 802
Tutorial
Wireless location
Allan Thomson, Cisco
July 2007
Slide 21
IEEE 802
Tutorial
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
July 2007
Slide 22
IEEE 802
Tutorial
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
July 2007
Slide 23
IEEE 802
Tutorial
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
July 2007
Slide 24
IEEE 802
Tutorial
Typical Location Determination Messages
Channel 1
Channel 6
Channel 11
Presence Request (CH11)
Presence Announce (CH11)
Presence A
nnounce (CH
6)
Presence Announce (CH1)
July 2007
Slide 25
IEEE 802
Tutorial
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
F5
F1
F2
F3
F4
Association
Presence Announces
July 2007
Slide 26
IEEE 802
Tutorial
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
F5
F1
F2
F3
F4
Blg 1
Association
Presence Announces
F5
F1
F2
F3
F4
Blg 2
July 2007
Slide 27
IEEE 802
Tutorial
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
July 2007
Slide 28
IEEE 802
Tutorial
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
July 2007
Slide 29
IEEE 802
Tutorial
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
July 2007
Slide 30
IEEE 802
Tutorial
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
July 2007
Slide 31
IEEE 802
Tutorial
TGv Meets Requirements
Requirement TGv LLDP-MED1
Capability Advertisement
Provides per STA capability advertisement
None
Location Determination
Provides control and high accuracy
None
Location Distribution Provides Secure, Timely, Scalable, Specific
Provides broadcast
1: ANSI/TIA-1057 LLDP-MED
July 2007
Slide 32
IEEE 802
Tutorial
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
July 2007
Slide 33
IEEE 802
Tutorial
802.11u and Emergency Services
Matthew GastTrapeze Networks
Note: This presentation is based on 802.11u-D1.0 and subject to change by future standards activity
July 2007
Slide 34
IEEE 802
Tutorial
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
July 2007
Slide 35
IEEE 802
Tutorial
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
July 2007
Slide 36
IEEE 802
Tutorial
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
July 2007
Slide 37
IEEE 802
Tutorial
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
July 2007
Slide 38
IEEE 802
Tutorial
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 Networke.g. dedicated VLAN, IP filtering, etc.
Note: SSID list is optional; used in multi-SSIDdeployments
ADDTS Request (w/Expedited BW Req.)
ADDTS Response
July 2007
Slide 39
IEEE 802
Tutorial
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
July 2007
Slide 40
IEEE 802
Tutorial
Authority and Emergency Services
Richard PaineBoeing
July 2007
Slide 41
IEEE 802
Tutorial
Authorities
• Police • Fire• Rescue• Emergency Services• Government Organization• Non-Governmental Organization (NGO)• Military• Airport• Airplane• Ship• Bus
July 2007
Slide 42
IEEE 802
Tutorial
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.
July 2007
Slide 43
IEEE 802
Tutorial
PSTN Provider 911
• PSTN Wireless Service Providers offer physical locations
• PSTN Providers have agreements with 911 authorities
July 2007
Slide 44
IEEE 802
Tutorial
Ethernet Provider 911
• Ethernet (802.3) Wired Service Providers offer physical locations
• Ethernet (802.3) Wired Service Providers have agreements with 911 authorities
July 2007
Slide 45
IEEE 802
Tutorial
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
July 2007
Slide 46
IEEE 802
Tutorial
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
July 2007
Slide 47
IEEE 802
Tutorial
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
July 2007
Slide 48
IEEE 802
Tutorial
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
July 2007
Slide 49
IEEE 802
Tutorial
Enterprise VOIP E911
Caution:911 service using this device may be limited or
unavailable.
July 2007
Slide 50
IEEE 802
Tutorial
Use Case: Boeing 1
MPSensor
MPSensor
MPSensor MP
Sensor
MPSensor
MPSensor
MPSensor
MAP
MAP
MPP
MPSensor
MPSensor
MPSensor
MPSensor
Primary RouteSecondary Route
InfrastructureNetwork
July 2007
Slide 51
IEEE 802
Tutorial
Use Case: Boeing 2
July 2007
Slide 52
IEEE 802
Tutorial
Use Case: Boeing 3 – Guns and Hoses Offices
Mesh Points
Mesh Points
July 2007
Slide 53
IEEE 802
Tutorial
Use Case: Boeing 4 – Guns and Hoses Factory
Mesh Points N
Access Points
July 2007
Slide 54
IEEE 802
Tutorial
Large Enterprise E911
July 2007
Slide 55
IEEE 802
Tutorial
Authority Issues
• Authority
• Policy
• Control
July 2007
Slide 56
IEEE 802
Tutorial
Authority
• Governmental Organizations (GOs)
• Non-governmental Organizations (NGOs)
• Legitimacy and Establishment of ES Organizations
• Management of Authorities
July 2007
Slide 57
IEEE 802
Tutorial
Policy
• Policy Creation
• Policy Decision
• Policy Enforcement
July 2007
Slide 58
IEEE 802
Tutorial
802.11 Emergency Services Objectives
• Why have this tutorial?
• What is the problem?
• What do we want to achieve in 802.11?
July 2007
Slide 59
IEEE 802
Tutorial
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
July 2007
Slide 60
IEEE 802
Tutorial
Next Generation 802.11 Wireless Security
• Policy Development
• Policy Decision Points
• Policy Enforcement Points
• Privacy
• Security
July 2007
Slide 61
IEEE 802
Tutorial
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.
July 2007
Slide 62
IEEE 802
Tutorial
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
July 2007
Slide 63
IEEE 802
Tutorial
SMA Elements: PKI
Badgecert
Tempcert
ClientRA
SSL/TLSTunnel
1
2
Boeing PKI
SLDAP
1) Badge used for Client Auth; TempCert request sent to RA2) RA issues TempCert3) Client has TempCert available for up to 8 hours
TempCert Provisioning Process
July 2007
Slide 64
IEEE 802
Tutorial
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
SLDAPClient
Policy DecisionDaemon
Middleboxes
Client
DNSDDNS
Location Server
Directory Information Flow
July 2007
Slide 65
IEEE 802
Tutorial
Concluding Straw Poll
Would you like to see these issues discussed more in November 2007?
1. 802 Ad Hoc (32)
2. 802 Architecture Group (8)
3. Something Else (4)
4. Nothing (0)