170 likes | 387 Views
HELD. Location Acquisition Solution James Winterbottom Andrew Corporation Nov 2006. HELD Background. Based on real-world requirements stemming from work in NENA and other standards bodies. Provides an application layer location acquisition protocol not restricted to SIP
E N D
HELD Location Acquisition Solution James Winterbottom Andrew Corporation Nov 2006
HELD Background • Based on real-world requirements stemming from work in NENA and other standards bodies. • Provides an application layer location acquisition protocol not restricted to SIP • Respects requirements laid out in RFC-3693 • Demonstrated applicability to residential broadband deployments • Recognizes that location requires a solution that operates above layer 3, can support SIP but is NOT SIP specific. • Defines a message exchange protocol for location information. Different bindings can be used, HTTP is described in the HELD draft. • BEEP exists but not specific as an Internet draft at this time.
Basic HELD • Very Simple! • HTTP GET to a URL. • Server-side certificate • Determination based on source IP address. • Security provided through TLS and return routability • Location provided as a PIDF-LO • LIS discovery through: • Provisioning • DHCP discovery (draft-winterbottom-geopriv-held-dhcp-discovery-00) • DNS discovery through reverse DNS and U-NAPTR (draft-thomson-geopriv-held-unaptr-00)
HELD Differentiators • Supports requesting location in the form required by an application. • Supports a response time indicator, CRITICAL in applications where more than one determination technique is available. • Almost all mobile networks today offer more than one location determination technique.
HELD Differentiators (cont) • Supports Target identity extensions(draft-winterbottom-geopriv-held-identity-extensions-00) • necessary where target terminal correlators change through a network (e.g. DSL). • Supports Target to LIS location capability exchanges (draft-thomson-geopriv-held-capabilities-00) • Necessary to make best use of Target based measurements.
Context and Reference Support • HELD supports references by creating a context on the LIS. • When a context is created the Target receives 1 or more URI types that can be used to access the Target’s location. • SIP or HTTP • Context is controlled by Target, not kept open for a pre-determined by the LIS.
HELD Identity Extensions Example locationRequest(E)
HELD Device Capabilities • Often a device can assist in determining or is capable of providing its own location • Timing and signal strength measurements • Satellite pseudo-range measurements • Autonimous location determination • Where a LIS is deployed in a network it may be useful to share determination capabilities between the Target Device and the LIS. • improvements in yield • More precise location information • Reduced time to obtain location
HELD Device Capabilities • Two basic mechanisms • Device specifies capabilities to LIS, LIS responds with supported capabilities • LIS indicates to device what capabilities it can provide
HELD ImplementationsOpen Source Client http://sourceforge.net/projects/held-location
Client Capabilities • Supports all functions of HELD specification • Provides API to applications running on the same PC. 1 Client for multiple applications. • LIS discovery through: • DHCP • DNS reverse lookups and SRV records • Configuration
Open Source LIS • Supports most of the HELD functionality. • Initial implementation by second year engineering student in 2.5 weeks. • EASY TO IMPLEMENT! • Latest version supports multiple Location determination functions full, geodetic and civic assertion, HELD identity extensions. • To be posted sometime after the 17th of Nov. • Basic provisioning interface provided • Standalone/Proxy-LIS implementation in OpenWRT Linksys wireless router available.