logging in or signing up ESW06 LoST avsar Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINTLite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: Embed: Flash iPad Dynamic Copy Does not support media & animations Automatically changes to Flash or non-Flash embed WordPress Embed Customize Embed URL: Copy Thumbnail: Copy The presentation is successfully added In Your Favorites. Views: 79 Category: Entertainment License: All Rights Reserved Like it (0) Dislike it (0) Added: September 28, 2007 This Presentation is Public Favorites: 0 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript A Location-to-Service Translation Protocol (LoST)& Mapping Protocol Architecture : A Location-to-Service Translation Protocol (LoST) & Mapping Protocol Architecture Ted Hardie Andrew Newton Henning Schulzrinne Hannes Tschofenig Overview: Overview LoST is a simple XML-based query and response protocol running on top of HTTP either “naked” HTTP or SOAP Main Purpose: Return URIs for given location information and service identifier i.e., service URN + location URIs Status: Work in progress Expected WGLC in Nov. 2006Finding the correct PSAP: Finding the correct PSAP Which PSAP should the e-call go to? Usually to the PSAP that serves the geographic area Sometimes to a backup PSAP If no location, then ‘default’ PSAP LoST Functionality: LoST Functionality Satisfies the requirements (draft-ietf-ecrit-requirements) for mapping protocols Civic as well as geospatial queries civic address validation Recursive and iterative resolution Fully distributed and hierarchical deployment can be split by any geographic or civic boundary same civic region can span multiple LoST servers Indicates errors in civic location data debugging but provides best-effort resolution Supports overlapping service regionsLoST Properties: LoST Properties Minimizes round trips: caching individual mappings returns coverage regions (“hinting”) civic (“all of C=US, A1=NY”) or geo (polygon) Facilitates reuse of Transport Layer Security (TLS) Returns emergency service numbers for a region Query for supported Service URN typesProtocol request (mapping): Protocol request (mapping) <?xml version="1.0" encoding="UTF-8"?> <findServiceByLocation xmlns="urn:ietf:params:xml:ns:lost1" validate="false" operation="recursive"> <locationInfo> <civicLocation> <country>US</country> <A1>New York</A1> <A3>New York</A3> <A6>Broadway</A6> <LOC>Suite 75</LOC> <PC>10027-0401</PC> </civicLocation> </locationInfo> <service>urn:service:sos.police</service> </findServiceByLocation> details likely to changeProtocol response (mapping): Protocol response (mapping) <?xml version="1.0" encoding="UTF-8"?> <response xmlns="urn:ietf:params:xml:ns:lost1"> <result status="200" message="OK" xml:lang="en" timeToLive="10000"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>unknown</service> <serviceBoundary> <civicLocation> <country>US</country> <A1>New York</A1> <A3>New York</A3> </civicLocation> </serviceBoundary> <uri>sip:firstname.lastname@example.org</uri> <uri>xmpp:email@example.com</uri> <service-number>911</service-number> </result> </response>Validation: Validation Determine if civic location is (partially) valid Returns XML tag names of components: validated and used for mapping no attempt to validate (and not used) e.g., house number known to be invalid Return (default) PSAP based on validated elements May return list of guesses for correct addresses, if requestedGeo support: Geo support Which geo types should be supported? Point (3D) Polygon? may yield ambiguous answers more complicated shapes? Current proposal always include 3D-point may include other shapesLoST: Location-to-URL Mapping: LoST: Location-to-URL Mapping cluster serves VSP2 NY US NJ US Bergen County NJ US 123 Broad Ave Leonia Bergen County NJ US cluster serving VSP1 replicate root information search referral root nodes Leonia NJ US sip:firstname.lastname@example.org VSP1 LoSTLoST Architecture: LoST Architecture T1 (.us) T2 (.de) T3 (.dk) G G G G G broadcast (gossip) T1: .us T2: .de resolver seeker 313 Westview Leonia, NJ US Leonia, NJ sip:email@example.com tree guideConclusion: Conclusion Mapping is core component of emergency calling problem LoST fully international and distributed tries to avoid “who runs the root” problem optimized for efficient use in mobile end systemsReferences and Contact Info: References and Contact Info IETF ECRIT Working Group http://www.ietf.org/html.charters/ecrit-charter.html LoST draft http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-lost/ Mapping architecture draft: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-mapping-arch Prototype implementation work in progress (see demo) First interoperability tests planned for early 2006 / beginning 2007. You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.