Interoperability Resources

Federal Resources

  • Emergency Communications Governance Guide for State, Local, Tribal, and Territorial Officials

    This guide provides public safety professionals, at all levels of government and disciplines, tools to establish and sustain effective emergency communications governance. It describes functional areas applicable to the state, local, tribal and territorial audience regarding interoperability coordination, and outlines governance challenges, best practices, and recommendations.

  • National Interoperability Field Operations Guide (NIFOG) Version 1.6

    The National Interoperability Field Operations Guide (N I F O G) is a technical reference for emergency communications planning and for radio technicians responsible for radios that will be used in disaster response. It includes rules and regulations for use of nationwide and other interoperability channels, tables of frequencies and standard channel names, and other […]

  • SAFECOM – National Interoperability Baseline Survey

    The goal of the National Interoperability Baseline Survey was to create a national and statistically valid snapshot of the capacity for and use of interoperability. This study was designed to assess the five critical elements — governance; policies, practices, and procedures; technology; training and exercises; and usage—that determine an organization’s capacity for interoperability.

  • Establishing Governance to Achieve Statewide Communications Interoperability – A Guide for SCIP Implementation

    This document presents information about the role, system, and operations of statewide governing bodies that are charged with improving communications interoperability across a state.

State and Regional Resources

A Statewide Interoperability Executive Committee, or SIEC, is a statewide governing body committed to managing and implementing the overarching statewide communications interoperability strategy.

SIEC links may change without notice as they are for third-party websites and are provided for informational purposes only. If the link for your state is not working, please let us know at [email protected]. You might also try searching the internet using your state name and SIEC.

Interoperability Channels

About Interoperability Channels

Interoperability channels as designated by the FCC, are by definition intended to be used for “two or more different entities to interact with one another and to exchange information…” (FCC 90.7 – Definitions for “Interoperability”). As a result, normal frequency coordination to prevent interference is not necessary. To help promote the use of the FCC-designated interoperability channels, APCO has exclusive coordination fees for these channels.

Special Fees for Interoperability Channels

If submitted on an application combined with other chargeable non-interoperability items. No charge.
(See AFC Coordination Fees page for New Station/Major Modifications fees).
If submitted alone as a new license application. $100 minimum per application

(Same fee as Minor Modifications.  See AFC Coordination Fees page. Applies ONLY if the application is submitted via SpectrumWatch.)

Nationwide Interoperability/Mutual Aid Channels

Per 90.20(i), the nationwide interoperability and mutual aid channels are listed below for the VHF, (including 220-222 MHz), UHF, 700 MHz and 800 MHz bands. (See §§90.20(d)(80), 90.531(b)(1), 90.617(a)(1) and 90.720). Any Part 90 public safety eligible entity holding a Part 90 license may operate handheld and vehicular mobile units on these channels without needing a separate authorization. Base stations or control stations operating on these channels must be licensed separately. Encryption may not be used on any of the interoperability or mutual aid calling channels.

VHF interoperability channel (MHz) Purpose
151.1375 MHz (base/mobile) Tactical.
154.4525 MHz (base/mobile) Tactical.
155.7525 MHz (base/mobile) Calling.
158.7375 MHz (base/mobile) Tactical.
159.4725 MHz (base/mobile) Tactical.
VHF mutual aid channel (MHz) Purpose
220.8025 MHz (base/mobile) Tactical.
220.8075 MHz (base/mobile) Tactical.
220.8125 MHz (base/mobile) Tactical.
220.8175 MHz (base/mobile) Tactical.
220.8225 MHz (base/mobile) Tactical.
220.8275 MHz (base/mobile) Tactical.
220.8325 MHz (base/mobile) Tactical.
220.8375 MHz (base/mobile) Tactical.
220.8425 MHz (base/mobile) Tactical.
220.8475 MHz (base/mobile) Tactical.
UHF interoperability channel (MHz) Purpose
453.2125 MHz (base/mobile) Calling.
458.2125 MHz (mobile)
453.4625 MHz (base/mobile) Tactical.
458.4625 MHz (mobile)
453.7125 MHz (base/mobile) Tactical.
458.7125 MHz (mobile)
453.8625 MHz (base/mobile) Tactical.
458.8625 MHz (mobile)
700 MHz interoperability channel (MHz) Purpose
769.14375 MHz (base/mobile) Tactical.
799.14375 MHz (mobile)
769.24375 MHz (base/mobile) Calling.
799.24375 MHz (mobile)
769.39375 MHz (base/mobile) Tactical.
769.39375 MHz (mobile)
769.49375 MHz (base/mobile) Tactical.
799.49375 MHz (mobile)
769.64375 MHz (base/mobile) Tactical.
799.64375 MHz (mobile)
769.74375 MHz (base/mobile) Tactical.
799.74375 MHz (mobile)
769.89375 MHz (base/mobile) Tactical.
799.89375 MHz (mobile)
769.99375 MHz (base/mobile) Tactical.
799.99375 MHz (mobile)
770.14375 MHz (base/mobile) Tactical.
800.14375 MHz (mobile)
770.24375 MHz (base/mobile) Tactical.
800.24375 MHz (mobile)
770.39375 MHz (base/mobile) Tactical.
800.39375 MHz (mobile)
770.49375 MHz (base/mobile) Tactical.
800.49375 MHz (mobile)
770.64375 MHz (base/mobile) Tactical.
800.64375 MHz (mobile)
770.74375 MHz (base/mobile) Tactical.
800.74375 MHz (mobile)
770.89375 MHz (base/mobile) Tactical.
800.89375 MHz (mobile)
770.99375 MHz (base/mobile) Tactical.
800.99375 MHz (mobile)
773.00625 MHz (base/mobile) Tactical.
803.00625 MHz (mobile)
773.10625 MHz (base/mobile) Tactical.
803.10625 MHz (mobile)
773.25625 MHz (base/mobile) Calling.
803.25625 MHz (mobile)
773.35625 MHz (base/mobile) Tactical.
803.35625 MHz (mobile)
773.50625 MHz (base/mobile) Tactical.
803.50625 MHz (mobile)
773.60625 MHz (base/mobile) Tactical.
803.60625 MHz (mobile)
773.75625 MHz (base/mobile) Tactical.
803.75625 MHz (mobile)
773.85625 MHz (base/mobile) Tactical.
803.85625 MHz (mobile)
774.00625 MHz (base/mobile) Tactical.
804.00625 MHz (mobile)
774.10625 MHz (base/mobile) Tactical.
804.10625 MHz (mobile)
774.25625 MHz (base/mobile) Tactical.
804.25625 MHz (mobile)
774.35625 MHz (base/mobile) Tactical.
804.35625 MHz (mobile)
774.50625 MHz (base/mobile) Tactical.
804.50625 MHz (mobile)
774.60625 MHz (base/mobile) Tactical.
804.60625 MHz (mobile)
774.75625 MHz (base/mobile) Tactical Tactical.
804.75625 MHz (mobile)
774.85625 MHz (base/mobile) Tactical.
804.85625 MHz (mobile)
800 MHz mutual aid channel (MHz) Purpose
851.0125 MHz (base/mobile) Calling.
806.0125 MHz (mobile)
851.5125 MHz (base/mobile) Tactical.
806.5125 MHz (mobile)
852.0125 MHz (base/mobile) Tactical.
807.0125 MHz (mobile)
852.5125 MHz (base/mobile) Tactical.
807.0125 MHz (mobile)
853.0125 MHz (base/mobile) Tactical.
808.0125 MHz (mobile)

Federal Interoperability Channels

Per 90.25, the Commission may authorize non-Federal licensees to operate mobile and portable radio units on the frequencies listed below in Tables 1 and 2, provided the applicant includes with its application to the Commission, written concurrence from the Statewide Interoperability Coordinator (SWIC) or state appointed official stating that the application conforms to the agreement with a federal agency with a valid assignment from the National Telecommunications and Information Administration.

Table 1 – Law Enforcement Plans (MHz)

LE VHF plan   LE UHF plan
Identifier Mobile
transmit
Mobile
receive
Identifier Mobile
transmit
Mobile
receive
LEA 167.0875 (S) 167.0875 LEB 414.0375 (S) 414.0375
LE1 162.0875 167.0875 LE10 418.9875 409.9875
LE2 162.2625 167.2500 LE11 419.1875 410.1875
LE3 162.8375 167.7500 LE12 419.6125 410.6125
LE4 163.2875 168.1125 LE13 414.0625 (S) 414.0625
LE5 163.4250 168.4625 LE14 414.3125 (S) 414.3125
LE6 167.2500 (S) 167.2500 LE15 414.3375 (S) 414.3375
LE7 167.7500 (S) 167.7500 LE16 409.9875 (S) 409.9875
LE8 168.1125 (S) 168.1125 LE17 410.1875 (S) 410.1875
LE9 168.4625 (S) 168.4625 LE18 410.6125 (S) 410.6125

(S)—Simplex.

Table 2 – Incident Response Plans (MHz)

LE VHF Plan   LE UHF Plan
Identifier Mobile
transmit
Mobile
receive
Identifier Mobile
transmit
Mobile
receive
NC1 Calling 164.7125 169.5375 NC2 Calling 419.2375 410.2375
IR1 165.2500 170.0125 IR10 419.4375 410.4375
IR2 165.9625 170.4125 IR11 419.6375 410.6375
IR3 166.5750 170.6875 IR12 419.8375 410.8375
IR4 167.3250 173.0375 IR13 413.1875 (S) 413.1875
IR5 169.5375 (S) 169.5375 IR14 413.2125 (S) 413.2125
IR6 170.0125 (S) 170.0125 IR15 410.2375 (S) 410.2375
IR7 170.4125 (S) 170.4125 IR16 410.4375 (S) 410.4375
IR8 170.6875 (S) 170.6875 IR17 410.6375 (S) 410.6375
IR9 173.0375 (S) 173.0375 IR18 410.8375 (S) 410.8375

SIECs & Other Regional Interoperability Bodies

What Are Statewide Interoperability Executive Committees (SIEC)?

A Statewide Interoperability Executive Committees, or SIEC, is a statewide governing body committed to managing and implementing the overarching statewide communications interoperability strategy.

State and Regional Resources

A Statewide Interoperability Executive Committee, or SIEC, is a statewide governing body committed to managing and implementing the overarching statewide communications interoperability strategy.

SIEC links may change without notice as they are for third-party websites and are provided for informational purposes only. If the link for your state is not working, please let us know at [email protected]. You might also try searching the internet using your state name and SIEC.

Interoperability Standards

Standards & IEPDs

APCO has developed the following standards and documents intended to serve as tools for public safety to communicate in a common manner.

Multi-Functional Multi-Discipline Computer Aided Dispatch (CAD) Minimum Functional Requirements

This standard identifies the minimum functional requirements that a computer aided dispatch (CAD) system shall include, broken down by public safety discipline. Also identified are the optional functional requirements that a CAD system should include. Attachment A: the Unified CAD Functional Requirements (UCADFR) provides a comprehensive list of functional requirements for CAD systems that may be used by public safety communications centers to assist with the request for proposal (RFP) process when they need to conduct a solicitation for a new CAD system or an upgrade to an existing CAD system.

PSC Common Status Codes for Data Exchange

This standard provides a standardized list of status codes that can be used by emergency communications and public safety stakeholders when sharing incident related information. Rather than changing their codes internally, each agency should map their internal codes to the standardized list. The agency is responsible for identifying how to map or translate their agency-specific status codes to the common status codes to ensure a clear understanding of the data that is being passed.

Common Incident Types for Data Exchange

This standard focuses on providing a standardized list of Common Incident Type Codes to facilitate effective incident exchange between Next-Generation 9-1-1 (NG9-1-1) ECCs and other authorized agencies, which is a critical component of public safety interoperability. If an agency is receiving information about an incident, a basic level of incident classification will be required to assure they understand the type of situation. Rather than requiring an agency to change the codes they use internally, each agency should map their internal codes to the standardized list.

Common Incident Disposition Codes for Data Exchange

Disposition codes are used by ECCs and public safety to identify the outcome of an event (incidents). These codes typically involve the use of numeric, alpha or alphanumeric characters that are only meaningful to a specific agency or region. This standard provides a list of common disposition codes for use by PSAPs and public safety when sharing incident information with disparate agencies and authorized stakeholders.

Standard Channel Nomenclature for the Public Safety Interoperability Channels

Standard nomenclature for FCC and NTIA-designated nationwide interoperability channels used for public safety voice communications. The public safety community uses spectrum allocated by the FCC and NTIA in multiple bands that is replete with interoperability channels. It is necessary to develop and employ a common set of channel names so that all responders to an incident know which channel to tune their radios to, as well as the band and primary use for the channel.

NG9-1-1 Emergency Incident Data Document (EIDD)

The EIDD provides a standardized, industry-neutral National Information Exchange Model (NIEM) conformant (XML-based) specifications for exchanging emergency incident information to agencies and regions that implement NG9-1-1 and Internet Protocol (IP) based emergency communications systems. Emergency incident information exchanges supported by the EIDD include exchanges between disparate manufacturers’ systems located within one or more public safety agencies and with other incident stakeholders.

Download the EIDD IEPD (zip file), a NIEM-conformant package that describes the construction and content of the EIDD information exchange. It contains all of the schemas necessary to represent and validate the data content of the exchange. It also contains supplemental artifacts, such as documentation, business rules, search and discovery metadata, and sample instances.

Information Exchange Package Documentation (IEPD) FOR "NG 9-1-1 Emergency Incident Data Document (EIDD)"

The EIDD IEPD is a NIEM-conformant package that describes the construction and content of the EIDD information exchange. It contains all of the schemas necessary to represent and validate the data content of the exchange. It also contains supplemental artifacts, such as documentation, business rules, search and discovery metadata, and sample instances.

Project 25

Consensus Standards Embracing Interoperability, Spectrum Efficiency and Cost Economies

Project 25 (P25) develops standards for interoperable land mobile radio (LMR) systems so emergency responders can exchange critical communications across agencies and jurisdictions. P25 standardizes interfaces between the various components of the LMR systems emergency responders’ use.

As a joint effort of APCO and the National Association of State Telecommunications Directors, Project 25 is a long­standing partnership between the public safety communications community, standard development organizations and industry manufacturers. Each group’s end goal is to satisfy the complex and evolving mission-critical communication needs of users for interoperable LMR equipment and systems.

P25 Standardization Process

Users and manufacturers participating in the P25 process develop voluntary, consensus communications standards under the auspices of ANSI-­accredited Telecommunications Industry Association (TIA). The P25 process:

  1. Focuses on the practical realization of the significant benefits inherent to digital radio communications technologies and
  2. Promotes the competitive offering of compliant P25 equipment and systems for effective use by a highly diverse user community on a worldwide basis.

Project 25 is an open, user-driven standardization process, with technical and operational requirements established through the participation of its stakeholders, including public safety practitioners from different countries representing different levels of government. The standards published by TIA establish the basis upon which:

  • Manufacturers develop, implement, and competitively offer P25 equipment and systems
  • Accredited laboratories conduct P25 compliance testing
  • Users specify, procure, and operate P25 radios and communications infrastructure

Project 25 defines system interfaces that are used to build P25 communications networks. TIA-102 standards documents define the messages and procedures required for P25 features to operate across the P25 system interfaces. Project 25 does not define equipment, just the messages and procedures across the P25 interfaces.

P25/TIA-102 system interfaces support multiple air interfaces and wireline interfaces. The wireline interfaces below can be used to support the three different air interfaces.

P25 Air Interfaces
P25 Wireline Interfaces FDMA Conventional FDMA Trunked 2-Slot TDMA Trunked
Fixed Station Interface X
Inter Sub-System Interface X X
Console Sub-System Interface X X
Telephone Interconnect Interface X X X
Data Network Interface X X X
Mobile Data Peripheral Interface X X X
Key Fill Device Interface X X X
Inter Key Management Facility Interface X X X
Network Management Interface No standard development

P25 Resources

Introduction to P25

For a P25 introduction, Codan Radio Communications provides the P25 Radio Systems Training Guide.

Tait Radio supports the Tait Radio Academy. They offer a free web-based Introduction to P25 course.

Technical Resources

The Project 25 Technology Interest Group (PTIG) website has many technical resources and documents, including:

The Capabilities Guide can be useful in understanding which P25 features found in the P25 SOR are standardized in TIA-102 Standards documents. The Guide covers all of the P25 system interfaces; e.g., the Common Air Interface (CAI), the Inter Sub-System Interface (ISSI), etc.

The P25 Supplier Matrix lists the many P25 companies that are part of the overall P25 Community and links to the P25 suppliers.

The TIA TR-8 website covers TIA Engineering Committee TR-8, which formulates and maintains standards for private radio communications systems and equipment for both voice and data applications. It offers TIA-102 standards documents free of charge when requested by a public safety user/agency. If you aren’t a public safety user or agency, TIA provides a link to buy or search for TIA-102 Standard documents.

Interested parties should also review manufacturer websites as they have P25 information.

P25 Support Procedure

If an agency using P25 equipment identifies a product that it suspects does not conform to the P25 Standards, or identifies an interoperability issue between manufacturers for functionality covered by published standards, the agency should document the suspected product or system issue and contact the P25 equipment provider(s) for resolution of the problem. This allows the provider(s) to investigate the problem and resolve possible product, system implementation or configuration errors.

If the problem is determined by the P25 equipment provider(s) to be an issue with the P25 standard, then the equipment provider(s) and agency should submit the issue for investigation by TIA-TR8.25 Compliance Assessment Engineering Sub-Committee. The leadership contacts for this sub-committee can be found on the TIA-TR8 website. Once on that TIA-TR8 webpage, find the pull-down window labeled ‘Learn More About Other Subcommittees, Working Groups and Ad Hocs’. Select ‘TR-8.25 Compliance Assessment’ to  see the description of this committee and the leadership contacts. Forward a complete description of the P25 standards-related issue to the committee leadership by email.  Email addresses are provided by selecting the leadership contact name.

 

ASAP to PSAP

What Is ASAP?

The Automated Secure Alarm Protocol (ASAP) is a national service that is the next generation for the processing of information from alarm monitoring stations needing emergency dispatch.

Launched in 2011 as a public-private partnership, ASAP is designed to increase the efficiency and reliability of emergency electronic signals from monitoring companies to emergency communications centers. ASAP uses ANSI standard protocols developed cooperatively by APCO International and The Monitoring Association. Using the ASAP service, critical information about life safety events is delivered digitally directly to the CAD system in seconds through the Nlets nationwide public-safety network. The use of data communications ensures that complete and accurate information is transmitted to the ECC every time.

The ASAP Standard

Alarm Monitoring Company to Public Safety Answering Point (PSAP) Computer-Aided Dispatch (CAD) Automated Secure Alarm Protocol

The Automated Secure Alarm Protocol (ASAP) is a successfully proven data exchange that has demonstrated efficiency and effectiveness in streamlining alarm notifications between alarm monitoring companies and public safety Emergency Communications Centers since 2009. This standard is the product resulting from the joint effort by APCO and The Monitoring Association (TMA) formerly known as the Central Station Alarm Association (CSAA).

Updates include the renaming the introduction of schema version 3.4 including new data fields and message types available to the users of this standard and critical to the mission of public safety. An emphasis on address verification/synchronization between the alarm companies and the ECCs is included. New alarm event types are also introduced as well as methods to indicate that an alarm has been verified positively as a real-life crime, fire, or emergency medical event.

Connected ECCs and Alarm Companies

A growing list of CAD platforms have ASAP interfaces and the number of ECCs of all sizes gaining benefit from the ASAP service is steadily growing. The alarm monitoring industry is committed to ASAP, with local, regional and national monitoring companies connected to the service. Seamless deployment is realized through the use of standardized technology and an experienced ASAP technical team.

Federal Report Estimates Extent of Interoperability Challenges for 9-1-1

This won’t come as news to anyone working in public safety communications, but 9-1-1 faces significant interoperability challenges.  While ECCs are generally able to transfer basic voice 9-1-1 calls to neighboring ECCs, they often cannot share other types of communications and data important for emergency response.

What might be surprising is that ECCs face these interoperability challenges even in areas that are making progress deploying Next Generation 9-1-1 technologies.  Perhaps that is why there has been increased attention to solving interoperability for 9-1-1 in recent years.  As consumers, we take for granted that two people can communicate with all kinds of data, regardless of where they live, which companies provide the connectivity, the types of phones they’re using, or even whether one person is on a phone while the other is using a tablet.  You would think that modernizing 9-1-1 technology would result in similar benefits, but that’s not proving to be the case.  Now, a federal report helps to quantify the extent of interoperability problems in 9-1-1.

At APCO’s suggestion, the Federal Communications Commission directed the Communications Security, Reliability, and Interoperability Council (CSRIC) VII to survey the current state of interoperability for the nation’s 9-1-1 systems.  CSRIC’s mission is to provide recommendations to the Commission on a variety of topics.  On March 17, CSRIC adopted a “Report on the Current State of Interoperability in the Nation’s 911 Systems.”  You can download the report on the CSRIC webpage.

The report describes the degree to which ECCs are able to share voice 9-1-1 calls, location data, SMS text-to-911, CAD data, and other types of data with other ECCs and (where appropriate) with emergency response providers.  It relied on publicly available data, as well as responses to surveys distributed by APCO and the National Association of State 9-1-1 Administrators.  APCO’s Chief Technology Officer served on the working group that developed the report.

This graphic from the report tells the story.  Red and orange are bad – they represent zero or limited interoperability between ECCs for each type of communication/data.  Green and blue are good – they represent interoperability statewide and interstate.  There’s a lot more red and orange here than blue and green.  In fact, unless you’re talking about the ability to transfer voice calls, ECCs are more likely than not to have an interoperability problem.  That shouldn’t be the case.

ECCs should be able to receive location information with every transferred 9-1-1 call.  They should be able to transfer texts to 9-1-1, CAD data, and other useful data relevant to an incident.  The red and orange in this graphic represent obstacles to emergency response for public safety telecommunicators, police officers, EMTs, and firefighters.  An already difficult job becomes harder.

What’s standing in the way of interoperability for 9-1-1?  Proprietary technology.  No doubt that the public safety communications community has benefited from some technology providers, including a number of newcomers, who are truly driven to introduce new innovations and make a difference.  But we need to accept the reality that interoperability is a problem and work toward a solution.

One of APCO’s strategies has been to provide a Sample RFP Template for NG9-1-1 Capabilities to assist 9-1-1 directors and authorities with their procurement activities, whether for a statewide or local effort.  The RFP Template covers all aspects of a complete NG9-1-1 deployment, regardless of the stage any state or locality is in concerning the transition to NG9-1-1.  It offers recommendations, guidance, and specific operational requirements toward achieving several goals:

  • Achieving interoperability among NG9-1-1 systems regardless of technology or jurisdiction;
  • Promoting competitive and innovative solutions;
  • Enabling the most cost-effective and operationally efficient solutions; and
  • Ensuring these solutions include more than just an upgrade from analog based voice-only systems to true IP-based, multimedia capable systems and architectures.

Another strategy has been to advocate for federal funding to support the transition to NG9-1-1 nationwide, with requirements on funding recipients to achieve and maintain interoperability.  This approach aligns with legislation that was introduced last year in the House and Senate that would create a $12 billion grant program for NG9-1-1.  It’s worth noting that the definition of interoperability used in that legislation is identical to the definition in the CSRIC report.

Thanks to the FCC’s willingness to examine interoperability for 9-1-1 and the work of CSRIC’s members, we’re in a better position to solve this problem.  APCO will continue working with policymakers at the Commission and Congress and pursuing every opportunity to ensure that ECCs can seamlessly exchange 9-1-1 calls and related data with other ECCs and on to responders in the field, regardless of jurisdictional boundaries, service provider, or other factors.

 

About the TabletopX Blog

A “Tabletop Exercise,” often shortened as “TTX,” is a discussion-based exercise frequently used by emergency planners. Led by a facilitator using a planned scenario, TTX participants describe the actions they would take, and the processes and procedures they would follow. The facilitator notes the players’ contributions and ensures that exercise objectives are met. Following the exercise, the facilitator typically develops an after-action report and conducts a debrief discussion during which players and observers have an opportunity to share their thoughts, observations, and recommendations from the exercise without assigning fault or blame.

Many of the attributes of a TTX are the same we seek to promote in the discussion generated from our blog posts. The goal is to capitalize on the shared experiences and expertise of all the participants to identify best practices, as well as areas for improvement, and thus achieve as successful a response to an emergency as possible.

TabletopX blog posts are written by APCO’s Government Relations team and special guests.

What Does Interoperable Mean in the Real World?

By Steve Leese

In the field of public safety, interoperability has several specific meanings that apply to the tools used in our profession.  For instance, fire apparatus hose fittings are commonly standardized so that departments from different jurisdictions can provide mutual aid effectively.  Merriam Webster defines interoperability as the “ability of a system to work with or use the parts or equipment of another system.”  This article will focus primarily on communication tools such as land mobile radio (LMR) and computer aided dispatch (CAD) in addition to illustrating the overall need for an interoperability-based approach to any communications technologies intended for use by public safety.

Emergency incidents can occur anywhere, and do not respect jurisdictional borders.  When this happens, responders from more than one agency have to respond and work together.  Agencies set themselves up for failure and put lives at risk when interoperability is not carefully considered and built into the purchase and implementation of equipment and programs they utilize to communicate, both with the public and with other agencies.

Providing a few real-world examples of problems that public safety faces today may help illustrate how vitally important interoperability is.  The following examples are drawn from a career that has spanned over thirty years as a first responder and a director of two Public Safety Answering Points (PSAPs).

When I was a law enforcement officer, our jurisdiction, like many across the country, was bordered on three sides by another jurisdiction that had a disparate LMR system.  Some LMR systems in the United States are typically referred to as proprietary, meaning that they do not talk to systems of a different brand or frequency range.  Our jurisdiction had such a system, as did those that bordered and responded with us.  During an incident that required multi-jurisdictional response, our only solution was to partner with another patrol vehicle from the neighboring agency and manually relay the necessary information over the air to the disparate system.  This occurred frequently and had the undesirable side effects of taking two scarce patrol units away from the primary task of responding to the incident.  In addition, because communications were relayed, it was easy to miss important information.  This costs time and efficiency and it can put both the responders and the public at risk.

Serving as a communications director, my centers faced a similar challenge to the previous example.  What made it different, was that the officers in the jurisdictions that commonly worked together across a jurisdictional border personally purchased commercial cellphones with a push to talk feature.  While this allowed them to communicate with each other, their solution had many shortcomings: they did not connect to our recording system in the PSAP; they were not monitored so if the responders were using personal phones instead of department radios to communicate emergency information, the communications center would not know about the emergency traffic; and the handsets were not mission critical.  While this solution was problematic at best, the fact that responders tolerated these shortcomings illustrates the level of frustration public safety experiences with the inability to seamlessly connect.

My final case in point is again derived from my time as a communications director.  Because public safety responder jurisdictions sometime overlap PSAP boundaries it became necessary to implement a CAD to CAD solution to dispatch fire department incidents.  When the agencies developed the plan everything seemed simple because both PSAPs purchased CAD from the same vendor, and had the same version running on the same type of equipment.  Imagine our surprise when the vendor required both PSAPs to purchase very expensive interfaces for our CADs to exchange information.  Of course, there were also expensive maintenance contracts for the interfaces every year after we made the purchases.  Ultimately the only options were to pay the price, or spend literally millions of dollars to change vendors.

These examples are not unique.  Every day public safety officials and responders deal with similar issues, and it strains the operations and puts lives in danger.  Less important, but significant, are the burdensome costs associated with connecting disparate systems.  When consumers are faced with an unexpected or undesirable cost, they turn to a competitor.  Public safety agencies don’t have that luxury.  They are typically locked into contracts that package multiple services with proprietary solutions, making a change to a competitor a major expense.

These technology challenges seemed difficult to overcome years ago, but today it is common to see inexpensive commercially available devices that can transfer multimedia seamlessly to disparate devices on different platforms.  If this technology and capability is in the hands of the consumer today, why can’t public safety benefit in a similar way?

The vision for seamless interoperability that I’m trying to explain is described in the APCO P43 report on “Broadband Implications for the PSAP” in the following way:

Fully interoperable voice and data communications allow the units who arrive first on scene to provide up to date, real-time information to additional units responding to the scene regardless of which agency they are from. PSAPs, though they have different CAD and radio systems, can communicate and receive common updates via interoperable, standardized CAD interfaces.

Pushback to this vision demonstrates how entrenched we are in the sometimes regressive traditional thinking.  Approaches that worked in the past will no longer work today.  Engaging the public safety community to help define the problem and providing innovative solutions is essential.  Public safety was not somehow put in this precarious position overnight.  These concerns are not new, and have been real-life concerns for several decades.  Entire careers have started and ended with the attitude that this problem is too large to ever overcome.

While FirstNet offers promise on the responder communications front, and solutions are being deployed to address much of what has been problematic, challenges still remain for the full emergency communications ecosystem, including LMR and 9-1-1 systems.  APCO, with the help of the US Department of Homeland Security and industry partners, will continue to work to fix interoperability problems for LMR.  However, it is critical that we take the same approach to Next Generation 9-1-1 and ensure that it includes requirements for interoperability at all levels.[1]  From the ability of the public to send multimedia communications to PSAPs, to the ability of PSAPs to process and share that data with each other – regardless of vendor, equipment, and jurisdiction – we cannot afford to ignore the importance of interoperability in this realm.  Working together, the public safety community, technology designers, manufacturers, network and service providers, and fellow standards development organizations can assure that both citizens and responders are made safer by addressing this important concern.   As our industry moves toward Next Generation 9-1-1 and IP based systems and services, now is the time to learn from the past and move forward in a positive direction.  Anything less is a disservice to our profession and the public we serve.

[1] APCO President Martha Carter recently authored a member message with an update on efforts to achieve fully interoperable NG9-1-1, including questions to consider asking of NG9-1-1 equipment and service providers.

 

Steve began work with APCO International in 2013, and served as the Director of Communications Center and 9-1-1 Services until 2020.  Steve has worked in public safety for 34 years as a Telecommunicator and Police Officer in Dearborn, MI, Emergency Management Director, and 9-1-1 Director in Huron and Eaton County MI.  Steve is a University of Michigan graduate, a Marine Corps veteran having served as a Military Police Sergeant, and Presidential Guard at the White House.  Steve is a former President of the Michigan Communication Directors Association.

About the TabletopX Blog

A “Tabletop Exercise,” often shortened as “TTX,” is a discussion-based exercise frequently used by emergency planners. Led by a facilitator using a planned scenario, TTX participants describe the actions they would take, and the processes and procedures they would follow. The facilitator notes the players’ contributions and ensures that exercise objectives are met. Following the exercise, the facilitator typically develops an after-action report and conducts a debrief discussion during which players and observers have an opportunity to share their thoughts, observations, and recommendations from the exercise without assigning fault or blame.

Many of the attributes of a TTX are the same we seek to promote in the discussion generated from our blog posts. The goal is to capitalize on the shared experiences and expertise of all the participants to identify best practices, as well as areas for improvement, and thus achieve as successful a response to an emergency as possible.

TabletopX blog posts are written by APCO’s Government Relations team and special guests.