802.1AB-Rev Proposal for Device Specific Location Delivery over Wireless LAN

1. 802.1AB-Rev Proposal for Device Specific Location Delivery over Wireless LAN

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

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, 802.11, 802.16, etc.) • Must align with IETF ECRIT Emergency Call Service architecture and IETF Geopriv location-based services

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

5. 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

6. 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 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

7. Proposed 802.1AB Rev “Unicast Mode” • In order to provide 802.11 WLAN data confidentiality, 802.11i 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 802.11i “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 802.11i. • To run 802.1AB over a single encrypted 802.11 “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.

8. 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 proposed 802.1AB-Rev ‘virtual-port’ unicast

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 doesn’t have to continuously poll AP) • Concept of various addresses to define propagation scope Recommend adding unicast to support 802.11i based virtual port as part of address reachability changes

10. Next Steps • Incorporate unicast addressing to support virtual 802.11i ports • Define behavior rules within new 802.11 annex, describing rules and usage for unicast LLDPDUs sent and received on 802.11i 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)