Next Generation Standards, Transitions and Challenges Brian Rosen Senior Director, Neustar Chair, Long Term Definition WG, NENA

We’re redesigning the system It’s a complete redesign, top to bottom » All new network, protocols, data structures Moving from a telephone network to an IP network The project is called “Next Generation 9-1-1” The initial technical standards are often called “i3” NG9-1-1 is multimedia: voice, video, text NG9-1-1 handles new devices & services easily NG9-1-1 responds better to overload and disasters (and deliberate attack)

NENA Public Review Detailed Functional Element and External Interface specifications (“Stage 3”) NENA is out for public review This is the final technical review, and we expect to publish this year This document provides a complete technical standard for the public safety side of the ESInet, and the service provider interfaces to it The technical standards for NG9-1-1 are colloquially called “i3”

i3 is based on IETF emergency standards NENA does NOT define what origination networks do, but references IETF standards Single international standard for emergency calling IETF “framework” and “phonebcp” (still a draft, but on its way through IETF approval process) defines what endpoints and networks do

Emergency Services IP Network The network that connects all public safety agencies together » Not just a network » Public Safety is broadly defined Managed, private, routed IP network, but not a walled garden Origination networks connect to it, and it’s connected to the global Internet Bottom up county-state-national network design

Some details about location New representation for location: PIDF-LO » RFC4119 updated by RFC5139 » Based on SIP Presence (PIDF) XML data structure accommodates both a civic (street address) or geo (lat/lon) Location can be passed by value (the PIDF itself) or by reference (a URI which when “dereferenced” yields a PIDF New “Location Configuration Protocol” for an endpoint to learn it’s own location New SIP Geolocation header to send location with the call Dereferencing protocols can be SIP (Presence subscription) or HTTP (HELD protocol)

Key fundamentals All calls (without exception) enter the ESInet as SIP, with location, routed by ECRF (LoST server) » Anything that isn’t native SIP is gatewayed to SIP outside the ESInet or on its border Location comes from the ACCESS NETWORK, which may or may not be the calling network Since the ECRF is available from the local Authority, and calls are accepted over the Internet, costs to service providers are minimal All service providers are affected, everything is changing

Compared to the existing E9-1-1 system: New form of location: “PIDF” » Carries either geo or civic » Handles location in a building » Can be sent as a “value” or a “reference” New form of routing database “ECRF” » Inherently point in polygon with geocode from civic » Driven by PSAP map (provisioning of ECRF is directly from their GIS system » Used to route calls, but also used to route to responders New form of routing engine “ESRP” » Direct location based routing (uses ECRF) » Can be multilevel (state, county, PSAP) » Policy Routing Function uses PSAP management written rules to control routing for all normal and abnormal conditions: edit the rule, store the ruleset, and routing changes immediately

Transition from E9-1-1 to NG9-1-1 Starts with the current E9-1-1 system Ends with all PSAPs and origination networks on ESInet » Some origination networks could be on Legacy Network Gateways » Some unupgraded PSAPs could be on Legacy PSAP Gateways When Transition is finished, the Selective Router, and ALI are decommissioned

Legacy Selective Router Gateway Interface between an existing Selective Router/ALI and an ESInet Allows calls originated on one side to terminate on the other Allows calls to be transferred between PSAPs on either side of the LSRG regardless of where the call originated Handles location queries when calls transit the LSRG

Example Call Flow Origination network on SR to i3 PSAP

Transition begins with ESInet and LSRG One PSAP is upgraded to i3 » All origination networks are still on the SR/ALI » All calls transit the LSRG We then can upgrade PSAPs to i3 or move them to LPGs We can upgrade origination networks to i3 or move them to LNGs When the last PSAP and origination networks are transitioned to the ESInet, the SR and ALI are decommissioned

Transition Characteristics Everybody moves, one way or another Moves happen in any order, LSRG allows calls to be answered regardless of who migrated when No fork lift upgrades required – SR/ALI don’t change at all, LNGs and LPGs allow origination networks and PSAPs to migrate without system upgrades, although some data and process upgrades are needed. Of course, if you migrate a PSAP via LPG, you don’t get many NG9-1-1 benefits

Challenge #1 Education PSAP management education » Lots of things change, but the basics of answering calls and helping people don’t » NG9-1-1 is complex, and different, but not hard » There are very significant benefits to NG9-1-1 » It’s happening, and it’s happening now. Head in the sand won’t work State Authority education » Bigger roles for states » Not optional

Challenge #1 Education (cont) Origination Network Education » It’s happening now » It’s not optional » Except for legacy wireline, it costs less for voice Regulator Education » Existing regs often prohibit NG9-1-1 deployment » New origination networks and the access network vs origination network issues are complex

Challenge #2 Speed of Transition We can’t take a decade to do transition in an area It’s not clear we can take more than a year Once transition starts, either the authority has to pay for both the old and new systems, or the current SR/ALI operator has to continue to operate them with declining revenue and customers Neither is sustainable for several years – we have to get transition over quickly

Challenge #3 – Existing Origination Nets is an expense with no revenue is regulated was built for voice, and the network support for was built for voice. Adding support for text/video is expensive » See bullet 1 above Most existing wireless origination networks are also access networks, operators can’t get their head around providing location for other origination networks riding on their raw IP packet service

Challenge #4 Data Location infrastructure is all GIS based – everyone needs a good map Lots of new data sources – need implementation of mechanisms and population of databases Lots of new data means new processes and new user interfaces Special challenge: location accuracy will often be <1m uncertainty within several years » GIS systems need much more accurate data » Lines and points WILL NOT BE SUFFICIENT

Challenge #5 Regulation The simple part is fixing existing regs that inhibit NG9-1-1 deployment Access networks must supply location. Broadband networks must supply location. Wireless networks that are broadband networks must supply location How do you get a MUCH larger constellation of origination networks to implement 9-1-1? How much is regulated vs how much is voluntary? How can we get PSAPs and origination networks to move? Who can compel what? What standards for critical infrastructure is required? Can we PLEASE have a uniform standard for PBXs (and note that enterprises are often access network operators)

Challenge #6 Cost New networks, new equipment, new data = new costs It’s an opportunity for vendors to increase profit margins It’s also an opportunity for new vendors, business models and relationships to lower overall costs

Next Up: Dispatch New data, new processes and new call sources mean changes in dispatch systems This effort is already started Entirely new data interfaces between and dispatch (CAD) systems Will then affect MDTs (mobile data terminals in responder vehicles).