28-May Interim - Geneva 802.1AB-Rev Proposal for Device Specific Location Delivery over Wireless LAN

28-May Interim - Geneva 2 Supporters and Contributors Manfred Arndt; ProCurve: co-author ANSI/TIA-1057 (LLDP-MED) Peter Blatherwick; Mitel: editor ANSI/TIA-1057 (LLDP-MED) Paul Congdon; ProCurve: 802.1AB-2005 (LLDP) Bernard Aboba; Microsoft Dan Romascanu; Avaya: co-author ANSI/TIA-1057 (LLDP-MED) Hesham Elbakoury; Nortel

28-May Interim - Geneva 3 Scope Define a mechanism to provide automatic physical location delivery to clients applicable across all IEEE 802 networking technologies with a common interface for software applications capable of Emergency Call Service and other location-based services – Must not require any driver modifications or new protocol definitions – Must not require softphone application to use a unique interfaces for every technology supported on a given device (e.g. GPRS, , , etc.) – Must align with IETF ECRIT Emergency Call Service architecture and IETF Geopriv location-based services

28-May Interim - Geneva 4 Objectives Widespread Emergency Call Service (ECS) industry adoption –Simple and leveraged design increases chances of vendor adoption –Simple design leads to low development cost –Alignment on a single L2 location delivery mechanism greatly simplifies ECS deployments and improves reliability Interoperability with all endpoint device types and 802 access technologies –Low complexity higher interoperability potential –KISS !! IP Phones will be just another applications downloaded onto a handheld device –Support basic static vs. fine-grain dynamic location

28-May Interim - Geneva 5 Enables Physical Location Services, including Emergency Call Service (ECS) –Supports NENA E911 and other location services (for example NENA TID ) 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

28-May Interim - Geneva AB-Rev Applicability to AB 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 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 –As currently defined, LLDP-MED can provide physical location delivery of AP, which is suitable for many ECS requirements –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 Limitation –802.1AB is a multicast protocol, and is currently limited to advertise attributes common to all wireless stations in the same SSID broadcast domain

28-May Interim - Geneva 7 Proposed 802.1AB Rev Unicast Mode In order to provide WLAN data confidentiality, i uses unique session keys for every association to create an encrypted logical port between every client and AP for unicast traffic. Essentially, a single shared physical AP segment consists of a number of distinct encrypted logical ports. However; there is also a single logical port used for multicast and broadcast traffic shared by all clients on the same SSID. As such, secure communications over an i logical port requires using the individual MAC address as the destination. Given that 802.1AB-REV is defining multiple destination MAC addresses to support LLDPDU propagation scope over different ranges, it seems like a natural extension to provide a similar operating range capability to support sending LLDPDUs over both the logical and physical ports for i. To run 802.1AB over a single encrypted logical port requires the use of an individual MAC addresses as the destination address for LLDPDUs. A unique set of TLVs can be advertised over the different ranges.

28-May Interim - Geneva 8 VoWLAN Location Overview AP can auto-discover its 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 proposed 802.1AB-Rev virtual-port unicast

28-May Interim - Geneva 9 Summary 802.1AB provides several advantages for physical location delivery –MAC independent –Existing, well defined standard –Simple and effective with high interoperability potential –Industry accepted solution, already deployed on wired Ethernet –Would 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 doesnt have to continuously poll AP) –Concept of various addresses to define propagation scope Recommend adding unicast to support i based virtual port as part of address reachability changes

28-May Interim - Geneva 10 Next Steps Incorporate unicast addressing to support virtual i ports Define behavior rules within new annex, describing rules and usage for unicast LLDPDUs sent and received on i virtual ports Define wireless specific Location TLV format extensions (if needed) in ANSI/TIA-1057 (e.g. optional Azimuth in Draft P802.11k D7.0)