802.1AB-Rev Proposal for Device Specific
Location Delivery over Wireless LAN
28-May-07
802.1 Interim - Geneva
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-07
802.1 Interim - Geneva
2
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
28-May-07
802.1 Interim - Geneva
3
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-07
802.1 Interim - Geneva
4
ANSI/TIA-1057 Location TLV
• 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
28-May-07
802.1 Interim - Geneva
5
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
28-May-07
802.1 Interim - Geneva
6
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.
28-May-07
802.1 Interim - Geneva
7
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
28-May-07
802.1 Interim - Geneva
8
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
28-May-07
802.1 Interim - Geneva
9
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)
28-May-07
802.1 Interim - Geneva
10