End To End Emergency Services-Part 1 The Functional Elements
NG911 is coming fast and hard. NOW is the time to address the issues.
In Part 1 of this series, we discuss the Functional Elements of a NG911 network. Learn the terms!
I'm Mark Fletcher Chief Architect and Public Safety Solutions at Avaya. Welcome to End-to-End NG Emergency Services. Part One, the Functional Elements. Before we get started today, special thanks and gratitude go to Markus Bornheim for his work on the original graphics and content of this presentation. While this tech will focus on a US implementation, next generation emergency services are applicable worldwide at a High Level Architecture.
And this architecture is called the Emergency Services IP Network, or ESINET. As with anything, the ESINET comes with a completely new vocabulary that you're going to need to learn and be able to interpret. Now the vocabulary is well defined in both Europe by the European Emergency Number Association, as well as in the US by NENA.
The National Emergency Number Association. Common definitions you'll be using are the ESINet, the Border Control Function, the Emergency Services Routing Proxy, the Emergency Services Routing Function, the Public Safety Answering Point, the Legacy Network Gateway, and a Location, and information service. Let's look at the call chain of a next generation emergency communication session to 911 services from an enterprise facility.
A sit call is generated by the user dialing 911 and a session is established with the originating device's calling party number, or CPN, and a service URN destination of SOS. Now, in the CPN Message, a Present Information Data Format Location Object, known as PIDFLO, is attached to the outbound session.
The session's received by the Public Carrier Service Provider, who then inspects the service URN. And upon seeing the SOS destination, knows it's an emergency call, and immediately forwards the call to the ESInet. Now, before allowing the session to enter the ESInet, the border control function analyze the CPN, the service URN, and the civic address, and makes an mission control decision.
If the sessions allowed it's forwarded to the emergency services routing proxy or ESRP. Now, the ESRP then checks with the emergency call routing function, or ECRF, to determine the appropriate public safety answering point, or PSAP. The ECRF uses the geospatial information derived from the civic address provided in the matching it to an area of responsibility for a specific PSAP.
The destination PSAP is then returned to the ESRP, who then forwards the call to the destination that we specify. At this point the PSAP utilizes the information that it receives including geospatial information as well as references to additional data. All contained in the PSAP headers. And that information is applied to their computer aided dispatch.
Now in Europe, Avaya participated in the ETSI Next Gen 112, interoperability plugtests. Specifically, our contributions were the Avaya IP Office, release 10, as an originating enterprise PBX. This directly generated PIDF-LO in the outbound SIP header, that was then processed and routed by the network. After determining PSAP, we use the AVAYA Breeze Platform to extract the SIP headers, and then deliver the call to the AVAYA Aura Session Manager and Communication Manager platforms, delivering next generation emergency services data directly to the call takers.
Now the data extraction was performed through a specialized snapping, built by Avaya developing partner, Engelbart Software, based in Frankfurt, Germany, where it was then displayed on an innovative new web-based call-taking solution, also delivered by Engelbart, using the Avaya telephony SDK. So as you can see, the ESINet is a critical core for next generation emergency communications.
But we need to take a deeper dive inside to better understand the ESINet and determine if it is a service or an infrastructure. The ESINet is a private managed IP network. But it is not a walled garden in any sense of the word. It's important to remember that the ESINet refers to the physical network work such as the routers and the links.
But it's not the actual next generation services that run on it. The key to a resilient ESINet is building a reliable, redundant and secure environment, protected from physical disruption using diversity as well as malicious penetration that can occur from hackers. But wait, there's more. Despite popular belief, the ESInet is connected to the public internet.
But it's done in a manner that's secure and protective of its resources. Now the bulk of this protection is provided by the border control function. BCF in addition to providing external security borders from the ESinet from the nasty Internet itself, internal isolation borders are provided for PSAPs. Effectively keeping them isolated from each other and providing a means of protection should a mass infection get through and infect an end point.
Now BCF contains both firewall and session border controllers, and is designed with functions to block specific call sources that have been identified as suspicious due to the origins or specific levels being generated. And these elements need to withstand the largest of feasible attacks, which today is estimated at about 10Gbit/s.
So in essence the BCF is a firewall and SBC combined into a single functional element. The emergency services routing proxy is simply a SIP base call routing engine that relies in information from the ECRF that allows it to make a determination on the nominal next hop for the emergency session.
Takes into consideration specific policy of the nominal next hop to determine the actual next hop. And specific conditions that will be taken into consideration are things like call taker availability tat the destination PSAP, current active calls, and call types, time of day, or many other factors that would help determine the call routing.
Now, the routing decision that could be made Might be another ESRP, for diversity, the nominal piece app, or a diversion piece app. So in essence, the ESRP is simply a SIP PBX, but it's a PBX that contains trunks only, and no individual users. In many ways, it's very similar to a selective router that exists in the legacy network.
Next in line is the Emergency Call Routing Function, or ECRF. Now the purpose of this functional element is to store the routing database that's used for all call sessions that get presented to the network. Any other functional element can make a query to the ECRF And does so using the IETF loST protocol, or location to service translation.
Elements query with location in addition to a service URN and then receive back an URI or address of where to route the session. Conceptually, the locations a civic address and a specific point within a polygon. The purpose of the element is to provide the route to the correct police, fire, EMS, or other services.
All based on the location of the originating In essence, the ECRF is an automatic call distribution, or ACD. But it's one with special algorithms based on location and other context, used to make the routing decisions. The next functional element in the chain is one that's familiar to many of us.
And that's the PSAP, or public safety answering point These exist on the ESInet and can receive call sessions as well as location information via the network. Now PSAPs can have internal ECRF and ESRP functionality as well as policies that route specific call sessions to specific call queues of call takers that may have specific skill sets.
All call sessions are SIP based and therefore are multimedia capable. Using voice, video, real time text and other messaging. The IP nature of the PSAP means that individual call takers, supervisors or the entire PSAP itself Can be virtualized and located anywhere that network connectivity is available. The core services for the PSAP can reside locally on-site in an equipment room, at a local or remote data center, or even in the cloud.
In essence, the Next Gen 911 PSAP Most be a fully compliant to PBX with users. Need the support SIP location information. Share the status with the ESInet itself, as well as support for MultiChannel communications, and have the ability to be virtual. Now since it would be nearly impossible to forklift an entire network at one point in time, functional elements must exist that allow the natural transition of new networks into the old and of old networks into new.
While a new next-generation 911 PSAP might be constructed in an area that's yet to have a deployment. Of an NG 911 network the Legacy Network Gateway, or LNG, provides a bridge between those legacy networks and the ESInet. The function of the LNG is to provide inner working of location information in the legacy network towards the ESInet.
And is capable of forwarding calls to the ESRP. In essence, the LNG is a gateway at the edge of the ESInet allowing an entry point for TDM, as well as an egress point for SIP-based traffic, all while providing the ability to adopt new features on an incremental basis.
Finally, we have the LIS or Location Information Service. Now, this functional element is designed to store location against the specific key. Now the key can be one of many things, including network address, telephone numbers or even SIP URI. And, originating IP device will query the list as it groups, or whenever a link up, link down condition occurs potentially indicating a move, or if at all possible prior to an emergency call.
Now, the function of a list is to return location that's a civic address or geodetic in nature using either a location by value 123 Main Street or location by reference in the form of a SIP URI. The data's returned using the standard PIDF/LO location objection and placed inside the SIP header.
Now, in a residential deployment, the LIS would typically be provisioned at the carrier or service provider. But within the enterprise, the list services would be provided by the enterprise itself. And in the case of Avaya, we use the Avaya Sentry solution. So in essence, the list is simply an internal or external database keeping track of identities, telephone numbers, and correlating that data with devices and their location.
That concludes the segment of end and emergency services part one, the functional elements. I'm Mark Fletcher, Chief Architect for worldwide public safety in Avaya. Stay tuned next week for part two where we'll dive in the specific, Flows, be sure to check out our podcast side of Avaya.com/APN and check out the rest of our content from the Avaya podcast network.
Do that at your favorite podcast provider, listen on iTunes, Google Play Music, or SoundCloud as well as APN's featured content on the iHeart Radio This is Fletch, thanks for joining us today, we'll catch you next time right here on APN, the Avaya Podcast Network.