NG911 project status

1
NG911 project status

• Henning Schulzrinne
• (with Jong Yul Kim, Wonsang Song, Anshuman Rawat,
  Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao
  Wu)
• Dept. of Computer Science
• Columbia University

2
Options for location delivery

• GPS
• L2 LLDP-MED (standardized version of CDP
  location data)
• periodic per-port broadcast of configuration
  information
• currently implementing CDP
• L3 DHCP for
• geospatial (RFC 3825)
• civic (draft-ietf-geopriv-dhcp-civil)
• L7 proposals for retrievals
• for own IP address (draft-linsner-geopriv-lcp)
• by IP address
• by MAC address
• by identifier (conveyed by DHCP or PPP)

3
Phase 3 Routing to Correct PSAP
4
IETF ECRIT working group

• Emergency Contact Resolution with Internet
  Technologies
• Solve four major pieces of the puzzle
• location conveyance (with SIPPING GEOPRIV)
• emergency call identification
• mapping geo and civic caller locations to PSAP
• discovery of local and visited emergency dial
  string
• Not solving
• location discovery
• inter-PSAP communication and coordination
• citizen notification
• Current status
• finishing general and security requirements
• tentative agreement on mapping protocol and
  identifier
• later, to work on overall architecture and UA
  requirements

5
Emergency identifier requirements

• Direct user interface, without dialing number
• but do NOT require user to input this identifier
  directly
• i.e., separate user interface from protocol
  identifier!
• Reach emergency help in any country, without
  knowledge of local numbers
• also, universally recognizable by proxies
  regardless of location of caller
• Deployable incrementally
• even if not all entities support the mechanism
• Testable without impacting PSAP (human) resources

6
Defining an (emergency) services URN

• URN universal resource name
• identifies resource, not its network location
• translated by protocol (e.g., DNS) into
  location(s)
• New service URN urnserviceservice
• Identifies a generic service, not a specific
  resource
• Uses mapping protocol
• identifier, location ? URL(s)
• Can be used anywhere a URN or URL is allowed,
  e.g.
• web pages
• result returned by mapping protocol
• request and To URI in SIP
• For emergency services
• urnservicesos, urnservicesos.fire,
  urnservicesos.police, urnservicesos.marine,
  urnservicesos.mountain, urnservicesos.rescue,
  urnservicesos.poison, urnservicesos.suicide,
  urnservicesos.mental-health
• Could also be used for other services
  urnservicedirectory

7
UA recognition UA resolution
location information
mapping
mapping may recurse
DHCP LLDP-MED
9-1-1 (dial string)
leonianj.gov
INVITE sippsap_at_leonianj.gov To
urnservicesos ltlocationgt
INVITE sippsap_at_leonianj.gov To
urnservicesos ltlocationgt
8
UA recognition proxy resolution
mapping
9-1-1
provider.com
INVITE urnservicesos To urnservicesos ltlocat
iongt
INVITE sippsap_at_leonianj.gov To
urnservicesos ltlocationgt
9
UA recognition proxy resolution(proxy location
determination)
mapping
9-1-1
provider.com
INVITE urnservicesos To urnservicesos
INVITE sippsap_at_leonianj.gov To
urnservicesos Location ltlocationgt
10
Proxy recognition proxy resolution
mapping
9-1-1
provider.com
INVITE sippsap_at_leonianj.gov To
sip911_at_provider.comuserphone Location
ltlocationgt
INVITE sip911_at_provider.comuserphone To
sip911_at_provider.comuserphone
11
Phase 1 2 Identifying Emergency Calls
Determining Caller Location
12
DHCP for locations

• modified dhcpd (ISC) to generate location
  information
• use MAC address backtracking to get location
  information

DHCPINFORM 0011209da003
DHCP server
DHCP answer 0US1CA2LOS ANGELES 3LONG
BEACH6HYATT AVE19300
13
DHCP for locations (cont.)

• ip_phone 1
• host sip0011209da003
• next-server ng911serv.irt.cs.columbia.edu
• hardware ethernet 0011209da003
• fixed-address 128.59.17.59
• option tftp-server-name "128.59.19.174"
• option host-name "sip0011209da003"
• 0US1CA2LOS ANGELES3LONG BEACH6HYATT
  AVE19300
• option loc-civil 555321243412b4c4f5320
  414e47454c45533a4c4f4e4720424541
  434869485941545420415645133333030
  

dhcpd.conf
14
Emergency dial strings

• 60 different dial strings in use
• some countries separate fire/police/, others
  dont
• some are used for other services
• PBX, information, prefix,
• Needs to support both home and visited dial
  string when traveling
• Home dial string at home location of traveler
• traveler may not know local conventions
• Visited dial string at visited location
• fellow tourist picks up phone
• babysitter in ex-pat household
• Configure
• via DHCP
• via SIP configuration mechanism
• via location mapping

15
LUMP Mapping service URNs locations to URLs

• Common problem
• geo or civic location, service ? set of URLs
• e.g., Broadway/NY, 911 ? fire_at_psap.nyc.gov
• also applies to anything from towing service to
  pizza delivery
• Need to be able to validate addresses ahead of
  emergency
• does this street address resolve to a PSAP?
• can the ambulance find the address?
• Service providers dont trust each other (fully)
• e.g., who gets to include Jerusalem in its map
• service may depend which warlord you belong to ?
• cant wait for UN (or ICANN) to create global
  emergency services database
• Suggested approach new distributed mapping
  protocol
• LUMP location-to-URL mapping protocol
• uses SOAP, but special service URLs

16
LUMP overview

• Support global-scale resolution of service
  identifiers (e.g., service URNs) locations to
  other URLs
• Attempts to be reliable and scalable
• borrow concepts, but not protocol limitations,
  from DNS
• Architecture Forest of trees with a cloud
  above
• avoid root as only deployment alternative
• Uses standard web services building blocks

17
LUMP Location-to-URL Mapping
VSP1
cluster serving VSP1
replicate root information
cluster serves VSP2
123 Broad Ave Leonia Bergen County NJ US
root nodes
NY US
NJ US
sippsap_at_leonianj.gov
search referral
Bergen County NJ US
Leonia NJ US
18
LUMP architecture
G
tree guide
G
G
G
broadcast (gossip)
T1 .us T2 .de
G
resolver
T2 (.de)
seeker 313 Westview Leonia, NJ US
T3 (.dk)
T1 (.us)
Leonia, NJ ? sippsap_at_leonianj.gov
19
Caching

• Generally, UA caches lookup results
• query Im at (X,Y), whats my PSAP?
• answer Your PSAP is sippsap_at_town.gov as long
  as you stay in polygon (X1,Y1 X2, Y2 ) this
  is valid for 12 hours
• almost no impact of node mobility on query
  frequency
• same for civic as long as you stay on Main
  Street, your town
• civic only relevant for nomadic users
• actual PSAP coverage area may be larger ? just an
  optimization
• Almost always avoids query during emergency call
• MAY re-query during call
• load distribution via DNS
• given frequency of calls for one resolver, likely
  to be no DNS caching anyway
• Further optimization query with timestamp (or
  etag) of last answer
• answer still the same, thanks for asking

20
Performance notes

• US only about 6 calls/second for whole country
• on average, but may spike during mass casualty
  events
• Use TCP (or TCP/TLS) for reliability
• Expect 1-2 queries/day/client
• Typical gtgt 100 queries/second/server
• almost all rows will be cached in memory
• only about 6,000 rows
• one server ? 8,640,000 queries
• probably N1 spared
• data center cost 300/month/server ?
  0.0003/user/month (1Mq/day)

21
Implementation status

• Prototype implementation at Columbia University
• includes referrals
• both geo and civic coordinates
• from draft WSDL (with minor fixes)
• Server
• Axis (Apache) SOAP server
• Postgres SQL geo database
• does polygon intersection
• Client
• Java app (web page)
• Tcl (for our SIP client)

22
LUMP geo mapping
23
LUMP SOAP request
24
Calltaker Routing

• Using SIP caller preferences/callee capabilities
• Example caller language preference
• automatically route to call taker who speaks
  French
• Accept-Language fr

25
Phase 4 Call Presentation
26
Controller (psapd) Flow
27
PSAP interface
using GeoLynx or Google Maps as GIS
28
Ongoing work (Spring 2006)

• Track LUMP specification
• SIPc
• DHCP support
• DB for CDP
• Call history window for call back
• Determine if call dropped without normal
  termination messaging
• Call taker blocking others from call
• SIPc psapd
• Emergency number determination
• Civic address validation using MSAG
• psapd
• Transfer to another psapd
• TLS support and testing
• Other
• Video push
• sipd must handle 486 Busy from psapd
• Assign unique number to each incident
• Associate multiple calls with an incident

• System-wide
• Pre-determined limit of simultaneous calls
• Incoming Call Queue at the option of the PSAP
• Incident specific announcements
• Prioritize calls in queue
• Overflow calls to designated backup IP PSAP
• Indications of overflow for originating and
  destination PSAP
• Adding information in PIDF-LO
• Call taker re-bids location information
• Caller updates location information
• Re-routing calls when location changes
• Interaction with external elements
• TDD support

29
Conclusion

• IETF ECRIT working group converging on set of
  solutions
• mapping protocol
• emergency identifier
• location conveyance
• to be done UA requirements
• Demo implementation of LUMP
• Multi-call taker PSAP approximation
• Working on solving core I3 PSAP requirements
  from NENA documents