NENA NG9-1-1 Policy Routing Rules Operations Guide

NENA NG9-1-1 Policy Routing Rules

Operations Guide

NENA NG9-1-1 Policy Routing Rules Operations Guide

NENA-INF-011.1-2014

DSC Approval: 06/15/2014

PRC Approval: 09/10/2014

NENA Executive Board Approval: 10/06/2014

Prepared by:

National Emergency Number Association (NENA) Core Services Committee, NG Data

Management Subcommittee, Policy Routing Rules Working Group

Published by NENA

Printed in USA


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

NENA

INFORMATION DOCUMENT

NOTICE

This Information Document (INF) is published by the National Emergency Number Association

(NENA) as an information source for the designers, manufacturers, administrators and operators of

systems to be utilized for the purpose of processing emergency calls. It is not intended to provide

complete design or operation specifications or parameters or to assure the quality of performance for

systems that process such equipment or services.

NENA reserves the right to revise this Information Document for any reason including, but not

limited to:

Conformity with criteria or standards promulgated by various agencies,

Utilization of advances in the state of the technical arts,

Or to reflect changes in the design of equipment, network interfaces or services described

herein.

This document is an information source for the voluntary use of communication centers. It is not

intended to be a complete operational directive.

It is possible that certain advances in technology or changes in governmental regulations will

precede these revisions. All NENA documents are subject to change as technology or other

influencing factors change. Therefore, this NENA document should not be the only source of

information used. NENA recommends that readers contact their 9-1-1 System Service Provider (9-

1-1 SSP) representative to ensure compatibility with the 9-1-1 network, and their legal counsel to

ensure compliance with current regulations.

Patents may cover the specifications, techniques, or network interface/system characteristics

disclosed herein. No license expressed or implied is hereby granted. This document shall not be

construed as a suggestion to any manufacturer to modify or change any of its products, nor does this

document represent any commitment by NENA or any affiliate thereof to purchase any product

whether or not it provides the described characteristics.

This document has been prepared solely for the use of 9-1-1 System Service Providers, network

interface and system vendors, participating telephone companies, 9-1-1 Authorities, etc.

By using this document, the user agrees that NENA will have no liability for any consequential,

incidental, special, or punitive damages arising from use of the document.

NENA’s Committees have developed this document. Recommendations for change to this document

may be submitted to:

National Emergency Number Association

1700 Diagonal Rd, Suite 500

Alexandria, VA 22314

202-466-3911

or [email protected]

© Copyright 2014 National Emergency Number Association, Inc.

mailto:[email protected]


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

ACKNOWLEDGEMENTS

The National Emergency Number Association (NENA) Core Services Committee, NG Data

Management Subcommittee, Policy Routing Rules Working Group developed this document.

NENA recognizes the following industry experts and their employers for their contributions in

development of this document.

Executive Board Approval Date: 10/06/2014

Members Employer

Roger Marshall, Core Services Committee

Co-Chair

Telecommunications Systems Inc.

Rachel Bello, Core Services Committee Co-

Chair

RCC

Kathy Liljequist, NG Data Management

Committee Co-Chair

GeoComm

Ira Pyles, ENP, NG Data Management

Committee Co-Chair

Hillsborough County, FL

Dan Mongrain, WG Co-Chair Frequentis

Ray Paddock, WG Co-Chair StepFunction Strategies, LLC

Marty Bausano, ENP Saint Clair County, IL 9-1-1 ETSB

Sandra Beitel Ogle County, IL

Theresa Connell State of Oregon

Marlys Davis King County,WA

Jerry Eisner, ENP RedSky Technologies

Anthony Herr North Central Texas Council of Governments

Tony Herr North Central Texas Council of Governments

Glenna Johnson DeKalb County, IL

Jim Lockard, ENP Lockard Strategic Advisors, LLC

Amy McDowell, ENP Greenville County, SC

Christian Militeau, ENP Intrado

Steve O’Conor, ENP Synergem Technologies, Inc

Brenda Pope Greater Harris County Emergency Network, TX

Jay Slater, ENP Bandwidth

Jason Wellonen Cassidian Communications

Mark Whitby, ENP Pinellas County, FL Department of Safety &

Emergency Services

This working group also thanks Pete Eggimann and Jim Shepard, Development Steering Council

Co-Chairs; Roger Hixson, Technical Issues Director; and Ty Wooten, Director of Education and

Operational Issues Director.


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

Table of Contents

1 EXECUTIVE OVERVIEW .............................................................................................................................. 5

2 INTRODUCTION .............................................................................................................................................. 6

2.1 OPERATIONS IMPACTS SUMMARY ......................................................................................................................... 6 2.2 TECHNICAL IMPACTS SUMMARY........................................................................................................................... 6 2.3 SECURITY IMPACTS SUMMARY ............................................................................................................................. 6 2.4 DOCUMENT TERMINOLOGY .................................................................................................................................. 6 2.5 REASON FOR ISSUE/REISSUE ................................................................................................................................. 6 2.6 RECOMMENDATION FOR ADDITIONAL DEVELOPMENT WORK .............................................................................. 6 2.7 DATE COMPLIANCE .............................................................................................................................................. 7 2.8 ANTICIPATED TIMELINE ........................................................................................................................................ 7 2.9 COST FACTORS ..................................................................................................................................................... 7 2.10 COST RECOVERY CONSIDERATIONS ................................................................................................................. 8 2.11 ADDITIONAL IMPACTS (NON COST RELATED) ................................................................................................... 8 2.12 INTELLECTUAL PROPERTY RIGHTS POLICY ...................................................................................................... 8 2.13 ACRONYMS/ABBREVIATIONS, TERMS AND DEFINITIONS ................................................................................. 8

3 POLICY ROUTING RULES OPERATIONAL GUIDE ............................................................................. 10

3.1 GENERAL COMMENTS AND RECOMMENDATIONS ............................................................................................... 10 3.1.1 Perspectives when Dealing with PRRs ..................................................................................................... 10 3.1.2 Comments and Recommendations Regarding First Steps ........................................................................ 11

3.2 COMMENTS AND RECOMMENDATIONS APPLICABLE TO THE PROCUREMENT PROCESSES ................................... 11 3.2.1 Preparation for a procurement ................................................................................................................. 11 3.2.2 Is your Authority organized for success? ................................................................................................. 12 3.2.3 We have gathered the information and analyzed it, now what? ............................................................... 13

3.3 COMMENTS AND RECOMMENDATIONS APPLICABLE TO THE IMPLEMENTATION OF A NG9-1-1 SYSTEM ............. 15 3.3.1 Entering the Rules into System ................................................................................................................. 16

3.4 CONSIDERATIONS APPLICABLE TO THE OPERATION OF A NG9-1-1 SYSTEM, POST-PROVISIONING .................... 16 3.4.1 Required Reports ...................................................................................................................................... 16 3.4.2 Report Distribution ................................................................................................................................... 17 3.4.3 Frequency ................................................................................................................................................. 17

4 RECOMMENDED READING AND REFERENCES .................................................................................. 17

5 PREVIOUS ACKNOWLEDGMENTS .......................................................................................................... 17


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

1 Executive Overview

In today’s 9-1-1 systems, PSAPs enter into mutual aid agreements with other PSAPs to take calls

when they are not able to take calls themselves. Sometimes PSAPs have scheduled maintenance or

after hours coverage, but many times it is unscheduled due to equipment and network outages or

PSAP evacuation.

The mechanism for diverting calls to an alternate PSAP involves routing tables within the selective

routers. This mechanism does not support real-time changes and is very limited with respect to the

options it provides PSAP management.

The need to divert calls for scheduled and unscheduled outages will continue as Next Generation 9-

1-1 systems are deployed. As with today’s E9-1-1 system, the policies and practices for diverting

calls will be made by 9-1-1 Governing Authorities in consultation with PSAPs and will be

memorialized in Inter-Agency Agreements. Unlike today’s E9-1-1 systems, 9-1-1 Governing

Authorities will have significantly more flexibility in defining when and how calls will be diverted

to other PSAPs and changes to the routing rules will approach near real-time.

The mechanism for establishing call diversion in a NG9-1-1 system is known as Policy Routing

Rules (PRRs). PRRs are defined by 9-1-1 Governing Authorities and loaded into a Policy Store to

be used during 9-1-1 call processing. The Emergency Services Routing Proxy (ESRP) is a function

that acts as a switch that sends calls to a target PSAP based primarily on the location of the calling

party. In addition to the location of the calling party, the ESRP examines other aspects of the call

and the status of the target PSAP. The ESRP uses the PRRs to make a final determination as to

where to route the call. PRRs are a powerful tool that empowers 9-1-1 Governing Authorities to

address a wide range of operational situations to ensure 9-1-1 calls are delivered to a PSAP that can

provide assistance.

This document is provided to assist 9-1-1 Governing Authorities in using PRRs during the full life

cycle of a NG9-1-1 System. In Section 3 below, we provide considerations and recommendations to

9-1-1 Governing Authorities implementing NG9-1-1 systems during the Request For Information

(RFI) and Request For Proposals (RFP) used to select a vendor, through the implementation phase

where PRRS are initially established, to the steady-state operations of a NG9-1-1 System where

PRRs are refreshed and refined. Using the information in this document the reader will be able to

take full advantage of the power of PRRs defined in the NG9-1-1 Standards listed in Section 4

below.

This document is intended for staff of 9-1-1 Governing Authorities and PSAPs with a baseline

understanding of NG9-1-1. Reading the reference documents listed in Section 4 below is helpful, but

is not a requirement to use this document. Working Group Members listed above representing 9-1-1

Authorities ensured that this Informational Document is appropriate for this target audience.

Note that the ESRP mentioned above is a Functional Element (FE) in the standard. This functional

element can be deployed in a number of ways at the discretion of vendors and still be consistent with

the standard. The Policy Routing Function (PRF) that evaluates policy routing rules is an integral

part of the ESRP functional element. As such, the PRF must be implemented as part of any ESRP.


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

2 Introduction

2.1 Operations Impacts Summary

9-1-1 Authorities must define PRRs for any NG9-1-1 system being implemented. PRRs define how

calls are diverted when a target PSAP is unable to take calls. At a minimum, the PRRs must define

how calls are diverted for the situations defined in the most current version of the PRR Standard.

Per the standard, all PRRs should be based on Inter-Agency Agreements. As such, they reflect the

9-1-1 Authorities policies and procedures. PRRs should be reviewed and updated periodically and

9-1-1 Governing Authority signoff demonstrating awareness and acceptance is required.

2.2 Technical Impacts Summary

When an Emergency Service Routing Proxy (ESRP) is provisioned as part of a Next Generation 9-1-

1 (NG9-1-1) System, the ESRP provider must engage the 9-1-1 Governing Authority to determine

the desired routing scheme, and must ensure that the provisioned Rules are internally consistent.

2.3 Security Impacts Summary

PRRs are held within a NG9-1-1 system. Except for the tool used to create the PRRs and provision

them in the system, there is no external interface to them. The Policy Routing Rules created by a 9-

1-1 Governing Authority must be classified as sensitive (restricted) as defined in NG-Sec.

2.4 Document Terminology

The terms "shall", "must", "mandatory", and "required" are used throughout this document to

indicate normative requirements and to differentiate from those parameters that are

recommendations. Recommendations are identified by the words "should", "may", "desirable" or

"preferable".

2.5 Reason for Issue/Reissue

NENA reserves the right to modify this document. Upon revision, the reason(s) will be provided in

the table below.

Doc # Approval Date Reason For Changes

NENA-INF-011.1-2014 10/06/2014 Initial Document

2.6 Recommendation for Additional Development Work

While drafting this version of the document, the Working Group found several areas that additional

development was warranted. At the time of this writing, the following recommendations were made

by the Working Group:

1. The NENA NG9-1-1 Standard (08-003) defines how PRRs are used to divert calls in a NG9-

1- system. The standards also allows for the Emergency Call Routing Function (ECRF) to be

used to divert calls. The Border Control Function (BCF) can also, to a lesser degree, play a

role in call diversion. The Working Group recommends that work be done to clarify the use

of all three mechanisms for call diversion and recommend best practices for implementation.

Three NENA Issues and Charter forms were submitted addressing this additional work.


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

2. While there is a significant amount of documentation available on NG9-1-1, our WG has not

found a general description intended for 9-1-1 Authorities that explains, at a high level how

NG9-1-1 works and how 9-1-1 Authorities will interact with it. It would be helpful to have

an overview of NG9-1-1 written for the same intended readers of this document to provide an

overall context.

3. The current version of the Inter-Agency Agreement Information Document does not fully

contemplate NG9-1-1. Our Working Group recommends that the Inter-Agency Agreement

Working Group review their document and update as necessary. This effort may already be

under way.

4. The current NG9-1-1 Architecture does not support the testing of PRRs while the system is

in production. In addition, no information document has been developed that provides

guidelines for how to test a NG9-1-1 system during production. Our Working Group has

completed a NENA Issues and Charter form to address this.

2.7 Date Compliance

All systems that are associated with the 9-1-1 process shall be designed and engineered to ensure

that no detrimental, or other noticeable impact of any kind, will occur as a result of a date/time

change up to 30 years subsequent to the manufacture of the system. This shall include embedded

application(s), computer-based or any other type application.

2.8 Anticipated Timeline

The recommendations made in this document are applicable to the full life cycle of PRRs within a

NG9-1-1 system. Recommendations below begin with defining requirements for PRRs as part of

developing a Request For Proposals from NG9-1-1 vendors. Other recommendations apply to the

implementation of a new NG9-1-1 system and to the steady-state operations of a NG9-1-1 system.

The anticipated timeline for implementing these recommendations follows the timeline for the

migration to NG9-1-1.

2.9 Cost Factors

PRRs are a component of a NG9-1-1 system. The cost of systems and software required to

implement PRRs is included in the cost of an ESRP. Services to support the PRR aspects of the

ESRP may be an additional charge. Services required by the 9-1-1 Governing Authority should be

specified in the RFP.

The most significant impact on cost may be in the investment in staff training and the allocation of

staff time to PRRs. If only the basic set of PRRs are established in a NG9-1-1 system, staff time and

staff knowledge levels will be greater than in today’s E9-1-1 system. However, as the Authority

begins to take full advantage of the capabilities and sophistication of call diversion in a NG91-1-

system, the staff knowledge level and staff time will increase. The skill set and staff time can be

centralized or distributed within the team responsible for the NG9-1-1 system.


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

2.10 Cost Recovery Considerations

Costs associated with defining, implementing, managing, and updating PRRs will be covered as a

component of the implementation and management of a NG9-1-1 system. Any cost recovery or

sources of funds for an NG9-1-1 system will also cover the PRRs.

2.11 Additional Impacts (non cost related)

The information or requirements contained in this NENA document are expected to have an

operational impact, based on the analysis of the authoring group. At the date of publication of this

document, development had not started. The primary impacts are expected to include:

- Testing PRRs during production of the NG9-1-1 system.

2.12 Intellectual Property Rights Policy

NOTE – The user’s attention is called to the possibility that compliance with this standard may

require use of an invention covered by patent rights. By publication of this standard, NENA takes

no position with respect to the validity of any such claim(s) or of any patent rights in connection

therewith. If a patent holder has filed a statement of willingness to grant a license under these

rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain

such a license, then details may be obtained from NENA by contacting the Committee Resource

Manager identified on NENA’s website at www.nena.org/ipr.

Consistent with the NENA IPR Policy, available at www.nena.org/ipr, NENA invites any interested

party to bring to its attention any copyrights, patents or patent applications, or other proprietary

rights that may cover technology that may be required to implement this standard.

Please address the information to:

National Emergency Number Association

1700 Diagonal Rd, Suite 500

Alexandria, VA 22314

202-466-3911

or [email protected]

2.13 Acronyms/Abbreviations, Terms and Definitions

Some acronyms/abbreviations, terms and definitions used in this document may have not yet been

included in the master glossary. After initial approval of this document, they will be included. See

NENA-ADM-000, NENA Master Glossary of 9-1-1 Terminology, located on the NENA web site for

a complete listing of terms used in NENA documents. All acronyms used in this document are listed

below, along with any new or updated terms and definitions.

The following Acronyms are used in this document:

Acronym Description (N)ew

(U)pdate

http://www.nena.org/ipr

http://www.nena.org/ipr

mailto:[email protected]

https://www.nena.org/?page=Glossary


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

The following Acronyms are used in this document:

CAD Computer Aided Dispatch

CBN Call Back Number

CoS Class of Service

ESRP Emergency Service Routing Proxy

ESZ Emergency Service Zone

NENA National Emergency Number Association

NG9-1-1 Next Generation 9-1-1

PRF Policy Routing Function

PRR Policy Routing Rule

PSAP Public Safety Answering Point

RFI Request for Information

RFP Request for Proposal

The following Terms and Definitions are used in this document:

Term Definition (N)ew

(U)pdate

No new terms were used in this document


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

3 Policy Routing Rules Operational Guide

9-1-1 Authorities must be actively involved with PRRs throughout the life of a NG9-1-1 system.

From the early stages of selecting a vendor for a NG9-1-1 system, through the implementation

phases, and throughout the life of an operational NG9-1-1 System, 9-1-1 Authorities have an

important role to play.

In the sections below, the Working Group offers considerations and recommendations for 9-1-1

Authorities for each of these stages and some thoughts common to all stages.

3.1 General Comments and Recommendations

NG9-1-1 can incorporate emergency calls initiated by dialing the digits “9-1-1” or by dialing a

designated 10 digit number or Alternate Emergency Access Number (AEAN). In addition, PSAPs

not only handle emergency calls but other types of calls as well. As PSAPs consider how to develop

a full plan that addresses outages, all types of calls should be considered. PRRs, and the

recommendations that follow, apply only to calls designated by the 9-1-1 Governing Authority as

“emergency calls”.

The Emergency Service Routing Proxy (ESRP), as its name suggests, is responsible in a NG9-1-1

system for routing emergency calls. ESRPs can route calls to another ESRP or they can route calls

to call handling equipment at a PSAP. If the call handling system serving a PSAP also serves other

PSAPs, it may contain an ESRP to handle the diversion of calls within the call handling system. The

ESRP is defined in the i3 standard by the set of functions it provides including the use of PRRs

within a Policy Store, and not by how or where it is deployed in a NG9-1-1 system. The

recommendations in this document apply to PRRs used by an ESRP independent of where in the

NG9-1-1 system it is deployed

This document anticipates that 9-1-1 Authorities will purchase NG9-1-1 systems as a managed

service and not purchase the necessary components and implement the system themselves. This is

consistent with current purchasing decisions. A 9-1-1 Governing Authority can purchase or even

develop the functional elements of a NG9-1-1 system. If this path is chosen, all of the comments

and recommendations below are valid, but will rest with the 9-1-1 Governing Authority.

3.1.1 Perspectives when Dealing with PRRs

When it comes to dealing with PRR, the activities required depend on which perspective a Public

Safety Agency takes in approaching them. Two different perspectives have been identified:

- 9-1-1 Governing Authority – as the organization having administrative jurisdiction over a

particular 9-1-1 system, the 9-1-1 Governing Authority determines the Policy Routing Rules

for the jurisdiction(s) participating in that system. While a 9-1-1 Governing Authority may

constitute a single PSAP, in the event the 9-1-1 Governing authority governs multiple

PSAPs, the Authority will receive input from the PSAPs under its jurisdiction in determining

the PRRs for those jurisdictions.

- PSAP – as the entity that receives 9-1-1 calls from a defined geographic area, the PSAP

provides input to the 9-1-1 Governing Authority regarding the routing of its calls.


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

An Agency is expected to identify which perspective is a better fit as the rest of this document

assigns different actions to the different perspectives.

3.1.2 Comments and Recommendations Regarding First Steps

Before starting on either procuring a new NG9-1-1 system or coming up with PRRs once a system

has been acquired, the following first steps should be taken.

3.1.2.1 Understanding the Current PRR Environment

A thorough evaluation of the current conditions is essential. The following questions should be

answered:

• How are calls routed today?

• Which are the alternate PSAPs?

• Under what conditions are calls redirected?

• Have any issues with routing been encountered in the past?

• What issues not resolvable today do you wish resolved with NG9-1-1 routing?

3.1.2.2 Understanding the new PRR Environment

Once the current environment is fully understood, next is comprehension of what NG9-1-1 policy-

based call routing can bring to the table. Section 4.4.2 of NENA document 08-003 Detailed

Functional and Interface Specification for the NENA i3 Solution – Stage 3, specifies the conditions

and actions that can be used in drafting Policy Routing Rules in a NG9-1-1 compliant Policy

Routing Function (PRF). In addition, knowledge of what the selected system can actually do is

necessary:

• Does the system fully support the i3 specified conditions and actions?

o If not, what are the limitations?

• Does the system support PRR conditions or actions above and beyond those specified in

NENA 08-003?

• Are there any performance considerations to take into account?

o For example, conditions or actions which perform slower than others?

3.2 Comments and Recommendations Applicable to the Procurement Processes

3.2.1 Preparation for a procurement

In preparing for an RFP, Authorities should collect all the Inter-Agency Agreements and evaluate

the alternative routing in place today. The next step is to identify what limitations imposed by the

selective router can and should be addressed by the new NG9-1-1 system. Some examples include:

• Are there weather patterns that affect all the PSAPs on a selective router making routing calls

during weather-related outages to these other PSAPs problematic?

• Are there large metropolitan PSAPs that have call loads so large that no neighboring PSAP

can handle during outages?

• Do situations routinely occur that could be best handled by diverting calls from a target

PSAP to multiple PSAPs?


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

• What factors, such as inoperability of other elements of Emergency Communications will

affect the routing?

Gathering the existing Inter-Agency Agreements and evaluating limitations imposed by the existing

selective routers is a good start to compiling a set of requirements for PRRs that should be included

in an RFP. It is not the responsibility of the Authority authoring the RFP to understand the technical

details of how PRRs can address its challenges. It is however the responsibility of the Authority to

understand how it wants to operate and address scheduled and unscheduled situations that require

diverting calls to alternative PSAPs. The recommended baseline knowledge of PRRs available to

the process is described elsewhere in this document.

3.2.2 Is your Authority organized for success?

The process of gathering the Inter-Agency agreements described above is the first indication of

whether an Authority is organized for success.

• Were all Inter-Agency Agreements documented and readily available?

• Were all the agreements up to date?

• Were all personnel responsible for implementing the agreements aware of what the

agreements required?

• If agreements weren’t in place, could staff describe the rules they operate under?

Per the PRR Standard, all PRRs implemented in a NG9-1-1 system must be supported by a formal

Inter-Agency Agreement.

After gathering the current Inter-Agency Agreements and /or documenting the rules that are being

observed, the process of analyzing the information and identifying areas of improvement in call

diversion is the second indicator of success.

• Were the personnel that participated in the analysis able to identify limitations in the current

system?

• Were the personnel that participated in the analysis able to describe the optimal or preferred

call diversion options?

• Are the participants cognizant of the repercussions of more diverse call routing?

• Did jurisdictional or other issues interfere with the analysis and identification of alternatives?

• Was there any person or position participating in the process that had the authority (formal or

informal) to prescribe solutions to any issues that arose?

• Were there people in the process that had a baseline understanding of PRRs that could help

support the process? Not technical knowledge of how PRRs are implemented, but the range

of options available to the Authority inherent in the standards.

To be successful in defining, implementing, and managing PRRs, the Authorities participating in the

system must have a governance system including a defined decision making process that has the

following characteristics:


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

Clear roles, responsibilities, and decision making authority should be established within the

governance body.

Each PSAP should be represented to at a minimum provide inputs to the process and accept

decisions made.

The decision-making process should include gathering all perspectives and options, making a

decision on call diversion, and then communicating and implementing the plan.

The decisions made should be memorialized in Inter-Agency Agreements.

The process should be supported by staff that has the baseline skillset defined elsewhere in

this document.

If the process of gathering existing information, analyzing it, and identifying areas of improvement

went smoothly, the Authority is probably organized for a successful implementation of PRRs within

a NG9-1-1 system. If the process did not go well, the Authority should contemplate the challenges

and limitations inherent in the current organizational structure and consider making changes. PRRs

might provide one of the first opportunities to test the Authorities’ organizational structure and

decision making process, however, it is not the only reason that a good structure is required. NG9-1-

1 systems can be implemented by counties (or parishes or municipalities), groups of counties, states,

and even groups of states. For a NG9-1-1 system to be a success, the governance of the system must

be solid. All individual agencies within a NG9-1-1 system must be able to act as one. A number of

organizational and decision-making structures can work including both traditional hierarchical and

peer-to-peer, collaborative structure. It is not important how governance of a NG9-1-1 system is

structured, but it is critical that the structure works. Developing the PRR requirements for

procurement is an excellent opportunity to validate or test the governance process and make

adjustments accordingly.

3.2.3 We have gathered the information and analyzed it, now what?

Fortunately, Authorities have the NG9-1-1 standards to use as a back stop for defining requirements.

NENA standard 08-003 defined Policy Routing Rules and the Policy Store. NENA STA-003

defines the minimum set of situations that a NG9-1-1 system must be able to address. Citing these

standards is a good start at requirements in procurement. However, NENA STA-003 has a limited

scope. Only situations that are currently encountered in an E9-1-1- system were considered. The

ability to address situations that arise for the first time in a NG9-1-1 system and more sophisticated

call diversion options for all situations has been left to the next version of the standard. It is also

important to keep in mind that the standard describes the general functionality that must be available

in a NG9-1-1 System. The standards do not prescribe how an Authority uses the functionality to

implement their policies and practices.

The PRR requirements in procurement can take any form usually following the structure of the rest

of the document. However, at a minimum, it is recommended that the information and questions

detailed below be addressed.


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

3.2.3.1 Information to be provided

• Possible major natural and man-made events (state fairs, major sporting events, etc.) or

disasters (hurricanes, typhoons, forest fires, etc.) that should be included in the planning and

the desired call diversion plan for each.

• The authority’s position on using Multi-Media Interactive Response units. Does the

authority support using any form of automated response to 9-1-1 calls? If so, under what

circumstances?

• The governance plan including structure and decision making process.

• Are there any equipment situations needing explanation?

3.2.3.2 Suggested questions to ask or requirements to state:

• The system being proposed should be consistent with the i3 standard (NENA 08-003) and the

PRR Standard (NENA STA-003). Specifically, all 6 of the call diversion capabilities must

be available.

• How are ESRPs, and therefore PRRs deployed in the NG9-1-1 system being proposed?

• What forms or processes does the vendor use to gather the policy routing rules?

• How are PRRs tested for correctness during the implementation of a NG9-1-1 system?

• How are PRRs re-evaluated and updated during the life of the system?

• What metrics, reports or notifications are provided by the system?

• If and when a call is diverted in an unintended way, what support will the vendors provide?

• How quickly can changes to PRRs be implemented?

• Can the vendor system support the Authority managing the PRRs in the system? Please,

describe the interface provided to facilitate the process.

• What level of knowledge does the 9-1-1 Governing Authority need to work with the vendor

in defining, implementing, managing, and updating PRRs?

• What training is available for staff involved in developing PRRs?

This sample set of questions is a good list that qualified vendors should be able to respond to.

However, vendors need the information described above as input to guide their responses. Many

vendors have staff that have worked at a PSAP and are very capable of working with the Authority

in developing PRRs. A knowledgeable vendor staff cannot and should not define policies and

practices for the PSAPs. This information must reflect the requirements of the management within

the Authority.

Evaluating responses to the questions in the RFP:

The answers to the questions above and any other questions the Authority poses to vendors should

be evaluated from at least two perspectives; (i) Can the vendor deliver the required functionality and

support in a standards compliant manner, and (ii) Can the vendor explain to the Authority staff how

they will accomplish this in a way that the staff can understand?

Many Authorities use consultants to help procurements and to evaluate the responses especially from

a technical perspective. This makes sense, however, with respect to Policy Routing Rules; the


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

Authorities themselves must understand the responses. Authorities will be required to provide the

underlying policies and practices that are implemented in PRRs. At some point the consultants will

go away. The Authorities will need to maintain and evolve the system. It is imperative that

Authority staff be able to understand a vendor’s capabilities as it applies to their situation!

Final procurement considerations:

The PRR function in NG9-1-1 systems can be very flexible. Flexibility is typically followed by

complexity. It’s easy to ask vendors to describe the range of flexibility their systems can provide in

the area of PRRs. It’s harder to do the work required to define what the Authority actually requires.

The Working Group that developed the first version of the PRR Standard chose to focus on

situations that are present in today’s E9-1-1 system. This was done to help focus the work on what

is required for any NG9-1-1 system to operate. The second version of the standard will address new

situations and suggest ways of utilizing the power of 08-003, but it will still be somewhat

constrained. This “crawl before you walk before you run” approach has worked well for the

Working Group and should be adopted by Authorities implementing a new NG9-1-1. Make sure

the Authority gets the functionality it needs today but selects a vendor that can provide what it needs

in the future.

3.3 Comments and Recommendations Applicable to the Implementation of a NG9-1-1

System

Fully armed with information regarding PRRs of the current and of the new systems, it is time to

draft the Policy Routing Rules with the assistance of all parties involved in the handling of the calls.

This is not the time when rules are actually entered in the new system; that time will come later.

This step is to put down on paper the rules necessary to route calls to a destination, taking into

account the capabilities and resources available, not only at the target PSAPs but also at the

alternates. Special care must be taken when drafting alternate routing rules. Does the alternate

PSAP have sufficient capacity to handle the redirected calls? For example, if an urban PSAP fails,

can a single suburban PSAP take over the entire call load? If not, how many suburban PSAPs are

required to do so? If more than one alternate PSAP is required to handle the volume, how are calls

supposed to be distributed among the backup PSAPs? Possible criteria are location of caller,

information found within the signalling of the call or even randomly. Another consideration is the

technology used at the alternate PSAP, is it i3 compliant or do calls need to be adapted?

Part of this process is ensuring that the Inter-Agency Agreements are in place that explicitly

document under what conditions calls will be redirected and what notifications (if any) are required.

Rules should not be implemented unless prior Inter-Agency Agreements have been made. Refer to

the NENA Standard for NG9-1-1 Policy Routing Rules [2] and the NENA Mutual Aid

Standard/Model Recommendation [4] for additional guidance.

It is recommended to start with a blank slate instead of using the existing rules as a base. The reason

is to avoid any preconceptions which may lead to forgetting something. Once the PRR rules are

drafted, they can be compared to the existing rules to validate that current applicable rules are still

covered.

While drafting of the rules can be accomplished by non-agency personnel (for example a consultant

or the vendor providing the new system), the 9-1-1 Governing Authority personnel must approve the


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

final set of rules before they are allowed to be provisioned in the new system. PSAP personnel must

approve the rules related to routing calls to their PSAP, which include rules for other PSAPs that

divert calls to their PSAP.

Part of drafting Policy Routing Rules is to draft a test plan that will be used to test the rules. These

tests will be executed before putting the system into production but also regularly when in

production to validate not only that the call routing equipment functions properly but to also validate

that the proper training and procedures are in place. The test plan must specify how to replicate

conditions necessary to cause the appropriate rule to be executed. It is unacceptable to modify a rule

in order to force another rule to be executed instead. The test plan must also specify the expected

results of each test.

3.3.1 Entering the Rules into System

Once the Policy Routing Rules have been agreed to, they can be entered in the new system. Care

must be taken to ensure that the rules entered are identical to the rules devised above. Any deviation

required halts this step of the process and returns to the previous step to reassess the affected rules,

possibly requiring updated Inter-Agency Agreements.

Once entered, each and every rule must be tested per the test plan to validate that the policy routing

operates as expected. Every error encountered must be assessed to determine the cause: equipment

failure, error in entering the rule, etc.

3.4 Considerations Applicable to the Operation of a NG9-1-1 System, Post-Provisioning

When a Next Generation 9-1-1 system has been provisioned, it is essential that PSAPs and 9-1-1

Governing Authorities monitor call diversions to ensure that the Policy Routing Rules continue to be

effective and appropriate. To ensure that proactive monitoring of PRRs is taken into account,

reporting provisions must be included in procurements.

Accessing reports on a regular and continuing basis will assist in validating the existing Rules and to

identify the need for new Rules. This analysis should be done on a regular and continuing basis to

ensure that existing rules continue to be valid and mutual aid agreements are up to date.

Reports could be made available to users via a web interface through the ESInet, or as determined

upon system provisioning.

3.4.1 Required Reports

3.4.1.1 Call Routing Report

The following information should be provided on PRR Reports for both diverted and non-diverted

calls to ensure that PRRs are up to date and Inter-Agency Agreements are valid:

• NENA Call Tracking Identifier

• Date

• Time

• Caller location

• Policy Rule


NENA-INF-011.1-2014, October 6, 2014

10/06/2014 of 17

3.4.1.2 Policy Rule Report

The following information should be provided:

• Comprehensive list of all policy rules

• Route target

3.4.2 Report Distribution

Reports should be provided to the following individuals/entities attached to the ESRP Service

providing the local service:

• Sending & receiving PSAPs and/or

• 9-1-1 Authorities

• ESRP provider

3.4.3 Frequency

The frequency of reporting should be determined and agreed upon at System provisioning, with one

or more of the following options selected:

• Daily (best practice for Call Routing Report)

• Weekly

• Monthly

• Quarterly (best practice for Policy Rule Report)

• Automatically when there is a rule addition/deletion/change (applicable to Policy Rule

Report)

• On Demand

4 Recommended Reading and References

1. Detailed Functional and Interface Standards for the NENA i3 Solution - NENA Standard 08-003

2. NENA Standard for NG9-1-1 Policy Routing Rules - NENA Standard STA-003

3. An Overview of Policy Routing Rules for Call Routing and Handling in NG9-1-1 - NENA

Information Document 71-502

4. NENA Mutual Aid Standard/Model Recommendation NENA 53-002

5 Previous Acknowledgments

None – original document

http://www.nena.org/?page=i3_Stage3

http://www.nena.org/?NG911RoutingRules

http://www.nena.org/?page=NG911_Policy_Rules

http://www.nena.org/?page=MutualAidStandard

NENA NG9-1-1 Policy Routing Rules Operations Guide

Documents

Transcript of NENA NG9-1-1 Policy Routing Rules Operations Guide