A LocationtoService Translation Protocol Lo ST Mapping Protocol

  • Slides: 13
Download presentation
A Location-to-Service Translation Protocol (Lo. ST) & Mapping Protocol Architecture Ted Hardie Andrew Newton

A Location-to-Service Translation Protocol (Lo. ST) & Mapping Protocol Architecture Ted Hardie Andrew Newton Henning Schulzrinne Hannes Tschofenig SDO Emergency Services Coordination Workshop (ESW 06) 1

Overview • Lo. ST is a simple XML-based query and response protocol running on

Overview • Lo. ST 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. 2006 SDO Emergency Services Coordination Workshop (ESW 06) 2

Finding the correct PSAP • Which PSAP should the e-call go to? – Usually

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 SDO Emergency Services Coordination Workshop (ESW 06) 3

Lo. ST Functionality • Satisfies the requirements (draft-ietf-ecrit-requirements) for mapping protocols • Civic as

Lo. ST 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 Lo. ST servers • Indicates errors in civic location data debugging – but provides best-effort resolution • Supports overlapping service regions SDO Emergency Services Coordination Workshop (ESW 06) 4

Lo. ST Properties • Minimizes round trips: – caching individual mappings – returns coverage

Lo. ST Properties • Minimizes round trips: – caching individual mappings – returns coverage regions (“hinting”) • civic (“all of C=US, A 1=NY”) or geo (polygon) • Facilitates reuse of Transport Layer Security (TLS) • Returns emergency service numbers for a region • Query for supported Service URN types SDO Emergency Services Coordination Workshop (ESW 06) 5

Protocol request (mapping) <? xml version="1. 0" encoding="UTF-8"? > <find. Service. By. Location xmlns="urn:

Protocol request (mapping) <? xml version="1. 0" encoding="UTF-8"? > <find. Service. By. Location xmlns="urn: ietf: params: xml: ns: lost 1" validate="false" operation="recursive"> <location. Info> <civic. Location> <country>US</country> <A 1>New York</A 1> <A 3>New York</A 3> <A 6>Broadway</A 6> <LOC>Suite 75</LOC> <PC>10027 -0401</PC> </civic. Location> </location. Info> <service>urn: service: sos. police</service> </find. Service. By. Location> details likely to change SDO Emergency Services Coordination Workshop (ESW 06) 6

Protocol response (mapping) <? xml version="1. 0" encoding="UTF-8"? > <response xmlns="urn: ietf: params: xml:

Protocol response (mapping) <? xml version="1. 0" encoding="UTF-8"? > <response xmlns="urn: ietf: params: xml: ns: lost 1"> <result status="200" message="OK" xml: lang="en" time. To. Live="10000"> <display. Name xml: lang="en"> New York City Police Department </display. Name> <service>unknown</service> <service. Boundary> <civic. Location> <country>US</country> <A 1>New York</A 1> <A 3>New York</A 3> </civic. Location> </service. Boundary> <uri>sip: nypd@example. com</uri> <uri>xmpp: nypd@example. com</uri> <service-number>911</service-number> </result> </response> SDO Emergency Services Coordination Workshop (ESW 06) 7

Validation • Determine if civic location is (partially) valid • Returns XML tag names

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 requested SDO Emergency Services Coordination Workshop (ESW 06) 8

Geo support • Which geo types should be supported? – Point (3 D) –

Geo support • Which geo types should be supported? – Point (3 D) – Polygon? may yield ambiguous answers – more complicated shapes? • Current proposal – always include 3 D-point – may include other shapes SDO Emergency Services Coordination Workshop (ESW 06) 9

Lo. ST: Location-to-URL Mapping VSP 1 cluster serving VSP 1 replicate root information cluster

Lo. ST: Location-to-URL Mapping VSP 1 cluster serving VSP 1 replicate root information cluster serves VSP 2 123 Broad Ave Leonia Bergen County NJ US Lo. ST NJ US sip: psap@leonianj. gov root NY US nodes search referral Bergen County NJ US Leonia NJ US SDO Emergency Services Coordination Workshop (ESW 06) 10

Lo. ST Architecture G tree guide G G G T 1: . us G

Lo. ST Architecture G tree guide G G G T 1: . us G broadcast (gossip) T 2: . de resolver seeker 313 Westview Leonia, NJ US T 2 T 1 (. us) SDO Emergency Services Coordination Workshop (ESW 06) (. de) T 3 (. dk) Leonia, NJ sip: psap@leonianj. gov 11

Conclusion • Mapping is core component of emergency calling problem • Lo. ST fully

Conclusion • Mapping is core component of emergency calling problem • Lo. ST fully international and distributed – tries to avoid “who runs the root” problem • optimized for efficient use in mobile end systems SDO Emergency Services Coordination Workshop (ESW 06) 12

References and Contact Info • IETF ECRIT Working Group http: //www. ietf. org/html. charters/ecrit-charter.

References and Contact Info • IETF ECRIT Working Group http: //www. ietf. org/html. charters/ecrit-charter. html • Lo. ST 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. SDO Emergency Services Coordination Workshop (ESW 06) 13