Sign in Subscribe
Emergency Services

ECRF in Next Generation Emergency Services

Nacho García

• 8 min read
ECRF in Next Generation Emergency Services

The purpose of this post is to teach the basics regarding the systems, tools and services involved in the next generation emergency services regarding Geospatial Information Systems (GIS).NENA elaborated and published a document called i3, where Next Generation Services are defined. i3 is an industry standard document that defines the future architecture of the Emergency Services. The most important functional element regarding GIS in the i3 Spec is the Emergency Call Routing Function (ECRF).

1. I3 ECRF (Emergency Call Routing Function)

ECRF is the most involved function in the I3 GIS context. It is responsible of routing emergency calls to the appropriate PSAP based on the location of the caller. In addition, PSAPs may utilize the same routing functionality to determine how to route emergency calls to the correct responder.

ECRF is a LoST protocol server implementation used in 9-1-1 call routing. The server accepts requests containing:

  • Location information (either civic address or geodetic coordinates)
  • Service URN (Uniform Resource Name) identifies a particular service type such as 9-1-1 Public Safety Answering Point (PSAP), Fire, Medical, Poison Control, or Coast Guard. As an example the service URN for 9-1-1 is urn:service:sos.

It will return a URI indicating the next-hop used to route an emergency call toward the appropriate PSAP. In this context a Uniform Resource Identifier URI is a string of characters used to identify a particular resource, such as a 9-1-1 Answering Point, another ECRF, or an Emergency Services Routing Proxy (ESRP). For example, a URI for a 9-1-1 Public Safety Answering Point (PSAP) might look like sip:psap@region.state.net.

2. LoST Protocol (Location-to-Service Translation Protocol)

It is an XML based protocol for mapping service identifiers and geodetic or civic location information compatible with the Presence Information Data Format Location Object (PIDF-LO) to service contact URIs. LoST messages are carried in HTTP and HTTPS protocols, easing the use of TLS to provide integrity and confidentiality in requests and responses.LoST provides different operations based on mapping locations and service URNs. ECRF in Next Generation Emergency Services uses two main functions: findService and findServiceResponse. This post will be focused on these two functions.

<findService>

The query is the core of the LoST functionality, mapping civic or geodetic locations to URLs and associated data. It can use either civic address or geodetic coordinates:

<?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1"
             xmlns:p2="http://www.opengis.net/gml" serviceBoundary="value"
             recursive="true">
    <location id="6020688f1ce1896d" profile="geodetic-2d">
        <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
            <p2:pos>40.407920 -3.834660</p2:pos>
        </p2:Point>
    </location>
    <service>urn:service:sos</service>
</findService>

<findService> geodetic coordinates query

<?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true"
             serviceBoundary="value">
    <location id="627b8bf819d0bad4d" profile="civic">
        <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
            <country>ES</country>
            <A1>Madrid</A1>
            <A3>Pozuelo de Alarcon</A3>
            <A5>Campus de Montegancedo</A5>
            <A6>Parque Científico y Tecnológico UPM</A6>
            <PC>28223</PC>
        </civicAddress>
    </location>
    <service>urn:service:sos</service>
</findService>

<findService> civic address query text

<findServiceResponse>

Given a query, a server would respond with a service and information related to that service. In the example below, the server has mapped the location given by the client to a “Zaleos PSAP” 9-1-1 Answering Point and it’s instructing the client that it may contact it via the URIs sip:psap@zaleos.net. The server has also given the client some additional information about when this information expires and the last update date.

<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
                     xmlns:p2="http://www.opengis.net/gml">
    <mapping expires="2018-01-01T00:00:00Z" lastUpdated="2017-01-01T01:00:00Z"
             source="ecrf.example" sourceId="00c90b098c711dbb606087e3f4020a66">
        <displayName xml:lang="en">Zaleos PSAP</displayName>
        <service>urn:service:sos</service>
        <uri>sip:psap@zaleos.net</uri>
        <serviceNumber>911</serviceNumber>
    </mapping>
    <path>
        <via source="ecrf.example"/>
    </path>
    <locationUsed id="602ce180688f196d"/>
</findServiceResponse>

<findServiceResponse> answer

3. Creating a dataset using QGIS

We are going to proceed with an example about how to create and edit GIS data for an ECRF instance and check if it is working properly.

To do this, we will introduce QGIS. QGIS is a cross-platform free and open-source desktop geographic information system (GIS) application that supports viewing, editing, and analysis of geospatial data.

We are going to create a new layer containing polygons representing two different areas. Each area is a coverage zone for a different 9-1-1 Answering Point. Then we will associate some information related to each 9-1-1 Answering Point, called attributes, to these polygons. We will name this layer sos because it is going to be associated with the sos service.

Create sos layer

To ease job we are going to use Open Layers Plugin, to add a new layer with OpenStreet Maps information. Then we will pull up sos layer to make it visible. Then we will zoom into the region we want to define PSAP boundaries.

Working area

After that, we will set the layer sos as editable and we will create a new polygon. We can add as many point as we want. After defining the polygon points, the tool will ask us to input attributes associated with this polygon.

Initial Polygon

In order to ensure we don’t leave gaps between areas, we’ll split this polygon in two polygons. To split it we will use the Split Feature tool in the edit menu and we will trace some lines dividing the polygon in two parts. Then if we open the attributes table we will notice we have two rows, representing two features. We will update the new feature to have different values.

Creating a new area

After that we will save the changes and load them into our ECRF instance.

4. Sending queries to ECRF

Now we can select some points in our map to test if for a given geodetic point we receive the proper routing URI to our assigned PSAP. We can create some LoST queries easily using HTTPie or cURL.

4.a) PSAP1 area

Geodetic point (40.4077964358, -3.84431256912) is in PSAP1 area.

Query

POST /ecrf HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 616
Content-Type: text/xml
Host: ecrf.zaleos.net
User-Agent: HTTPie/0.9.3

<?xml version="1.0" encoding="UTF-8"?>
<ns0:findService xmlns:ns0="urn:ietf:params:xml:ns:lost1">
    <ns0:location id="ecrf_1t3b3w" profile="geodetic-2d">
        <ns1:Point xmlns:ns1="http://www.opengis.net/gml"
                   srsName="urn:ogc:def:crs:EPSG::4326">
            <ns1:pos>40.4077964358 -3.84431256912</ns1:pos>
        </ns1:Point>
    </ns0:location>
    <ns0:service>urn:service:sos</ns0:service>
</ns0:findService>

Response

HTTP/1.1 200 OK
Cache-Control: NO-CACHE
Connection: close
Content-Type: application/lost+xml;charset=utf-8
Date: Thu, 06 Jul 2017 18:02:38 GMT
Server: ECRF
Transfer-Encoding: chunked

<?xml version="1.0" encoding="UTF-8"?>
<ns0:findServiceResponse xmlns:ns0="urn:ietf:params:xml:ns:lost1">
    <ns0:mapping expires="NO-CACHE" lastUpdated="2017-07-07T10:00:00.000000Z"
                 source="ecrf.zaleos.net"
                 sourceId="4bd34922-6275-11e7-8222-0800274cee9d">
        <ns0:displayName xml:lang="en">PSAP 1</ns0:displayName>
        <ns0:service>urn:service:sos</ns0:service>
        <ns0:serviceBoundaryReference key="1" source="ecrf.zaleos.net"/>
        <ns0:uri>sip:psap1@zaleos.net</ns0:uri>
        <ns0:serviceNumber>911</ns0:serviceNumber>
    </ns0:mapping>
    <ns0:path>
        <ns0:via source="ecrf.zaleos.net"/>
    </ns0:path>
    <ns0:locationUsed id="ecrf_1t3b3w"/>
</ns0:findServiceResponse>

4.b) PSAP2 area

Geodetic point (40.4051023711, -3.83470764252) is in PSAP2 area.

Query

POST /ecrf HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 616
Content-Type: text/xml
Host: ecrf.zaleos.net
User-Agent: HTTPie/0.9.3

<?xml version="1.0" encoding="UTF-8"?>
<ns0:findService xmlns:ns0="urn:ietf:params:xml:ns:lost1">
    <ns0:location id="ecrf_1t3b3w" profile="geodetic-2d">
        <ns1:Point xmlns:ns1="http://www.opengis.net/gml"
                   srsName="urn:ogc:def:crs:EPSG::4326">
            <ns1:pos>40.4051023711 -3.83470764252</ns1:pos>
        </ns1:Point>
    </ns0:location>
    <ns0:service>urn:service:sos</ns0:service>
</ns0:findService>

Response

HTTP/1.1 200 OK
Cache-Control: NO-CACHE
Connection: close
Content-Type: application/lost+xml;charset=utf-8
Date: Thu, 06 Jul 2017 18:01:00 GMT
Server: ECRF
Transfer-Encoding: chunked

<?xml version="1.0" encoding="UTF-8"?>
<ns0:findServiceResponse xmlns:ns0="urn:ietf:params:xml:ns:lost1">
    <ns0:mapping expires="NO-CACHE" lastUpdated="2017-07-07T10:00:00.000000Z"
                 source="ecrf.zaleos.net"
                 sourceId="11dc57d6-6275-11e7-94da-0800274cee9d">
        <ns0:displayName xml:lang="en">PSAP 2</ns0:displayName>
        <ns0:service>urn:service:sos</ns0:service>
        <ns0:serviceBoundaryReference key="2" source="ecrf.zaleos.net"/>
        <ns0:uri>sip:psap2@zaleos.net</ns0:uri>
        <ns0:serviceNumber>911</ns0:serviceNumber>
    </ns0:mapping>
    <ns0:path>
        <ns0:via source="ecrf.zaleos.net"/>
    </ns0:path>
    <ns0:locationUsed id="ecrf_1t3b3w"/>
</ns0:findServiceResponse>

4.c) Out of coverage area

Geodetic point (40.4054537708, -3.86932051826) it’s outside of our coverage area.

Query

POST /ecrf HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 616
Content-Type: text/xml
Host: ecrf.zaleos.net
User-Agent: HTTPie/0.9.3

<?xml version="1.0" encoding="UTF-8"?>
<ns0:findService xmlns:ns0="urn:ietf:params:xml:ns:lost1">
    <ns0:location id="ecrf_1t3b3w" profile="geodetic-2d">
        <ns1:Point xmlns:ns1="http://www.opengis.net/gml"
                   srsName="urn:ogc:def:crs:EPSG::4326">
            <ns1:pos>40.4054537708 -3.86932051826</ns1:pos>
        </ns1:Point>
    </ns0:location>
    <ns0:service>urn:service:sos</ns0:service>
</ns0:findService>

Response

HTTP/1.1 200 OK
Cache-Control: NO-CACHE
Connection: close
Content-Type: application/lost+xml;charset=utf-8
Date: Thu, 06 Jul 2017 18:03:51 GMT
Server: ECRF
Transfer-Encoding: chunked

<?xml version="1.0" encoding="UTF-8"?>
<ns0:errors source="ecrf" xmlns:ns0="urn:ietf:params:xml:ns:lost1">
    <ns0:notFound message="The server could not find an answer to the query."
                  xml:lang="en"/>
</ns0:errors>

5. Conclusions

In this post we learnt how NENA designs their interfaces using widely extended and well known standards, for example LoST protocol. Then we learnt with a basic example how GIS information looks, how to manipulate it with QGIS and how it’s used in an ECRF instance. Finally, we saw how we can use that information to enhance emergency call routing showing how an ECRF instance works.

In summary, here we illustrate with a very basic example how GIS information is critical in some Emergency Services applications and the huge benefits that it could provide.

Sign up for more like this.

Enter your email
Subscribe