U.S.

Department of Justice
Office of Community Oriented Policing Services

tEcH GUIDE for

communications
Interoperability
A Guide for Interagency Communications Projects
Copyright © 2006 SEARCH Group, Incorporated. The U.S. Department of Justice
reserves a royalty-free, nonexclusive, and irrevocable license to reproduce, publish, or
otherwise use, and to authorize others to use, this book for Federal Government purposes.
This document may be freely distributed and used for noncommercial and educational
purposes. No part of this book may be reproduced in any form, by any means (including
electronic, photocopying, recording, or otherwise) for commercial purposes without the
prior permission of the U.S. Department of Justice or the author(s).
U.S. Department of Justice
Office of Community Oriented Policing Services

tEcH GUIDE for

communications
Interoperability
A Guide for Interagency Communications Projects

By Dan Hawkins

This publication was supported by cooperative agreement #2003CKWXK054 awarded

by the U.S. Department of Justice Office of Community Oriented Policing Services to
SEARCH Group, Incorporated, 7311 Greenhaven Drive, Suite 145, Sacramento, CA 95831.
The opinions or recommendations contained herein are those of the author(s) and do not
necessarily represent the official position or policies of the U.S. Department of Justice.
References to specific organizations, products, or services should not be considered an
endorsement of the product by the author(s) or the U.S. Department of Justice. Rather,
the references are illustrations to supplement discussion of the issues.
 U.S. Department of Justice

Office of Community Oriented Policing Services

Office of the Director

1100 Vermont Avenue, NW
Washington, D.C. 20005

Dear Colleague:

Collaboration is the key to successful interoperable communications. The same practices that pertain to planning,
purchasing, and managing traditional information technology systems apply to interoperable communications
systems. What makes interoperability projects inherently more difficult are the various needs, capabilities,
and operational practices of the participating agencies. Interagency collaboration is as important to achieving
interoperability as developing the appropriate technological infrastructure.

Having awarded millions of dollars to help metropolitan regions throughout the nation establish and enhance
their interoperable communications systems, the U.S. Department of Justices’ Office of Community Oriented
Policing Services (COPS Office) is keenly aware of the challenges that confront agencies working toward
interoperability. At the same time, through its work on the SAFECOM Program, the Office for Interoperability
and Compatibility (OIC) within the Department of Homeland Security has worked directly with emergency
responders from across the Nation to identify best practices in communications interoperability. It also
has provided the practitioner community with invaluable tools and information, such as the Statewide
Communications Interoperability Planning (SCIP) Methodology, to make the process of improving
interoperability more manageable.

This Tech Guide for Communications Interoperability: A Guide for Interagency Communications Projects shares what
we have learned and assists you with planning, procuring, and implementing your new communications system. This
publication is targeted at the entire emergency response community, not only the Law Enforcement community.

This guide is intended to provide you with practical information to support your effort to successfully establish
interagency, interdisciplinary, and inter-jurisdictional voice and data communications systems. By increasing
interoperability and information sharing among the nation’s emergency response communities, the safety of both
practitioners and the citizens they serve can be better secured.

We trust that you will find this guide helpful, and encourage you to visit www. cops.usdoj.gov and
www.safecomprogram.gov to learn more about the other numerous resources offered by the COPS Office
and the OIC.

Sincerely,

Carl R. Peed Dr. David Boyd

Director Director
COPS Command, Control and Interoperability
U.S. Department of Justice U. S. Department of Homeland Security
 vii

Contents

Acknowledgments .................................................................. xv ­
About the Author .................................................................. xvi ­

About the Guide About the Guide ....................................................................... 3 ­

Assumptions…About You......................................................... 4 ­
Assumptions…About Your Project ........................................... 5 ­
How this Guide Is Organized.................................................... 5 ­
Definition of Icons ................................................................... 6 ­
Where to Go From Here ........................................................... 8 ­

Part I: Chapter 1 ­
What Is Communications Introduction—A Changing Environment ...................... 13 ­
Interoperability? Public Expectations ................................................................ 13 ­
Evolving Communications Needs........................................... 14 ­
Developing Technologies........................................................ 15 ­
The Interoperability Equation ................................................ 16 ­
What Will Tomorrow Bring? .................................................. 18 ­

Chapter 2 ­
Key Challenges and Critical Elements ............................ 21 ­
Recent Findings: Why Public Safety Can’t Talk ...................... 22 ­
Incompatible and Aging Communications Equipment ..... 23 ­
Limited and Fragmented Funding ..................................... 24 ­
Limited and Fragmented Planning .................................... 25 ­
Lack of Coordination and Cooperation............................. 25 ­
Limited and Fragmented Radio Spectrum......................... 26 ­
Critical Elements to Achieving Interoperability...................... 28 ­
Governance ....................................................................... 28 ­
Standard Operating Procedures ........................................ 28 ­
viii

Training and Exercises ....................................................... 29 ­

Frequency of Use ............................................................... 29 ­
Technology ........................................................................ 29 ­
One More Time: It’s the Planning and Coordination ............. 30 ­

Chapter 3 ­
Operability—Job #1 ....................................................... 35 ­
A Proportional Perspective..................................................... 36 ­
Extreme Operations—9/11 .................................................... 37 ­
Important Conclusions...................................................... 38 ­
National Incident Management System ................................. 39 ­
Common Terminology ...................................................... 40 ­
Integrated Communications.............................................. 40 ­
Operational Building Blocks................................................... 41 ­

Chapter 4 ­
Interoperability in the Integrated Enterprise ................ 45 ­
What is the “Enterprise”? ....................................................... 45 ­
A Complex System of Systems ............................................... 46 ­
The Call Arrives ................................................................. 46 ­
The Call Is Dispatched....................................................... 46 ­
First Responders Respond ................................................. 47 ­
Service Is Delivered ........................................................... 47 ­
Enterprise Integration ............................................................ 48 ­
How Did Communicating Get so Complicated?................ 48 ­
A Vision of Information Sharing............................................ 49 ­
Information Sharing Concepts: SOA What?........................... 50 ­
Common Terminology Aids Communication ................... 51 ­
Stating Requirements for Information Sharing ...................... 53 ­
The Good News on Stating Requirements......................... 54 ­
Leadership Rules .................................................................... 54 ­
See the Big Picture ............................................................. 55 ­
 ix

Part II: Chapter 5

How Is Interoperability Build an Interagency Foundation ................................... 63
Achieved? The Heart of It: Partnerships, Planning, and
More Partnerships ............................................................... 64 ­
Foundations 101: Decision-Making Structure ........................ 64 ­
Foundations 102: Project Management .................................. 73 ­
Foundations 103: Project Charter ........................................... 74 ­
Footings on Bedrock ............................................................... 77 ­

Chapter 6 ­
Conduct a Needs Analysis............................................... 81 ­
Needs Analysis 101: Assess Current Business
Processes .............................................................................. 83 ­
Needs Analysis 102: Determine Stakeholder Needs ............... 89 ­
The Goals .......................................................................... 89 ­
Techniques ........................................................................ 90 ­
Needs Analysis 103: Develop General System
Requirements....................................................................... 92 ­
Describing Requirements .................................................. 92 ­
Needs Analysis 104: Evaluate Buy-Versus-Build Options ........ 98 ­

Chapter 7 ­
Scope the Work To Be Done ......................................... 103 ­
Commonly Contracted Services ........................................... 104 ­
Project Management ....................................................... 104 ­
System Design ................................................................. 104 ­
Detailed Engineering Design ........................................... 104 ­
System Installation and Optimization............................. 105 ­
System Integration .......................................................... 105 ­
Quality Assurance............................................................ 105 ­
Acceptance Testing .......................................................... 105 ­
Other Work To Be Done ....................................................... 106 ­
Training ........................................................................... 106 ­
Radio Site Development .................................................. 106 ­
Frequency Coordination and Licensing ............................111 ­
Assessing the Scope of Work To Be Done..............................113 ­
What Are the Choices? .....................................................113 ­
What Will You Handle Internally? ...................................113 ­
Recommendations............................................................114 ­
x

Develop Your Own Recommendations and Get

Approval .............................................................................114 ­

Chapter 8 ­
Create a Project Plan .....................................................117 ­
Project Planning 101: Set the Scope and Objectives...............118 ­
Project Planning 102: Develop the Timeline......................... 123 ­
Project Planning 103: Estimate and Deliver a Budget........... 123 ­
Project Planning 104: Create a Risk Management Plan ........ 129 ­
Project Planning 105: Communicate Plans and Progress...... 130 ­
Communicating Across Agencies: ­
The Project Web Site ....................................................... 132 ­
Graphically Communicating Roles: The RACI Matrix..... 134 ­

Chapter 9 ­
Acquire the System Components.................................. 137 ­
System Acquisition 101: Groundwork .................................. 140 ­
System Acquisition 102: The Art of Procurement ................ 145 ­
System Acquisition 103: Create the Contract(s) ................... 148 ­

Chapter 10 ­
Implement the System.................................................. 155 ­
Prologue to an Implementation............................................ 156 ­
Further Define Roles........................................................ 156 ­
Establish the Implementation Team................................ 158 ­
Create the Implementation Plan........................................... 158 ­
Implementation Plan Elements ....................................... 158 ­
Sign, Seal, and Deliver!.................................................... 162 ­
Manage Documentation....................................................... 162 ­
Use Quality Assurance and Acceptance Tests ....................... 164 ­
Testing ............................................................................. 165 ­
Create Standard Operating Procedures and Train ................ 172 ­
An Example .......................................................................... 173 ­
Delta River County: As-Is ................................................ 173 ­
Delta River County: To-Be ............................................... 175
Delta River County: The Implementation ....................... 176 ­
Delta River County: Acceptance ...................................... 178 ­
 xi

Chapter 11 ­
Transition to Long-Term Governance .......................... 183 ­
A System of Systems ............................................................ 184 ­
Project Closeout.................................................................... 185 ­
Hold a Transition Meeting............................................... 185 ­
Conduct an Open Review Meeting .................................. 185 ­
Write a Final Report ........................................................ 186 ­
Govern and Manage ............................................................. 186 ­
Build Long-Term Governance Structures ........................ 186 ­
Build a Sustainable Financial Structure ........................... 190 ­
Create a Review Process ................................................... 193 ­

Chapter 12 ­
Develop Policies and Procedures ................................. 197 ­
Integrate NIMS into SOPs .................................................... 198 ­
Focus on Routine and Targeted Capabilities......................... 198 ­
Targeted Capabilities ....................................................... 199 ­
Establish and Use a Standard Method.................................. 200 ­
Shared Systems in the Twin Cities ................................... 200 ­
Shared Channels Under the Big Sky ................................ 201 ­
Create Technical Policies and Procedures ............................. 201 ­
Create Operational Policies and Procedures ......................... 202 ­
ICS Communications Unit............................................... 202 ­
Incident Dispatch Teams ................................................. 203 ­
Emergency Traffic............................................................ 203 ­
Channel Span of Control................................................. 204 ­
Standard Language.......................................................... 205 ­
Communications-Order Model ....................................... 205 ­
Operational Unit Reporting............................................. 206 ­
Build Incident Communications Plan Templates ................. 206 ­
ICS 205 ............................................................................ 207 ­
Tactical Interoperable Communications Plans ................ 209 ­
xii

Chapter 13 ­
Train and Exercise ........................................................ 213 ­
Focus on Both Routine and Targeted Capabilities ................ 213 ­
Train in Context.....................................................................214 ­
Use Standardized Exercise and Evaluation Processes.............214 ­
Discussion-Based Exercises.............................................. 215 ­
Operations-Based Exercises ............................................. 215 ­
Evaluations ...................................................................... 216 ­

Chapter 14 ­
Maintain the Technology ............................................. 219 ­
Identify Responsibilities ....................................................... 219 ­
Create a Technical Continuity of Operations Plan................ 220 ­
Do Regular and Preventive Maintenance ............................. 220 ­
Test at Least Monthly ...................................................... 221 ­
Maintain System Security..................................................... 221 ­
Prepare for System Changes ................................................. 222 ­
Evaluate Potential System Upgrades................................ 222 ­
Prepare for Regulatory Changes ...................................... 222 ­

Chapter 15 ­
Measuring Interoperability.......................................... 227 ­
Why Measure Interoperability?............................................ 228 ­
Cautious Measures .......................................................... 228 ­
The Interoperability Assessment Scorecard ......................... 228 ­
SAFECOM Interoperability Baseline Assessment............ 229 ­
Conduct a Self-Assessment ................................................... 230 ­
The Interoperability Self-assessment Scorecard .............. 230 ­
Using the Self-Assessment Scorecard............................... 232 ­
On the Horizon: Performance Measures .............................. 234 ­
Measuring Effects, Not Capabilities ................................ 235 ­
Performance Measurement Improves
Communications ............................................................. 236 ­
Conclusion....................................................................... 237 ­
 xiii

Part III: Chapter 16

Exploring the Technologies Voice Communications ................................................. 243
Understanding the Technologies .......................................... 245 ­
FCC Classification of Radio Systems ............................... 245 ­
Analog and Digital Radio Technologies........................... 246 ­
Conventional and Trunked Radio Systems...................... 251 ­
Communications in Buildings and Tunnels..................... 259 ­
Satellite Communications ............................................... 261 ­
VoIP in Voice Systems...................................................... 263 ­
Approaches to Interoperability ............................................ 266 ­
Technology Approach: Swap Radios................................ 267 ­
Technology Approach: Gateways .................................... 269 ­
Technology Approach: Shared Channels......................... 274 ­
FCC Designation of Shared Channels.............................. 275 ­
Technology Approach: Shared Systems........................... 276 ­
Security................................................................................. 278 ­
Advanced Radio Features for Physical Security ............... 279 ­
Encryption and Key Management ................................... 279 ­

Chapter 17 ­
Data Communications.................................................. 285 ­
Common Protocols and Standards....................................... 285 ­
The Internetworking Effect.............................................. 285 ­
XML—Universal Language of the Internet ..................... 287 ­
Building Blocks for Interoperability ................................ 292 ­
Wired Data Networks........................................................... 292 ­
A Whole Lotta *AN Going On! ....................................... 292 ­
Data Networking Evolution ............................................. 294 ­
Wired Networks Keep On Keeping On ............................ 296 ­
Wireless Data Networks ....................................................... 296 ­
Common Principles......................................................... 297 ­
Private Radio Technologies.............................................. 298 ­
Commercial Radio Technologies ..................................... 299 ­
Wireless Local Area Networks ......................................... 302 ­
Rent or Own?................................................................... 309 ­
xiv

Security................................................................................. 312 ­
FBI Criminal Justice Information Systems ­
Security Policy ................................................................. 313 ­
Securing Data Networks .................................................. 316 ­
On The Horizon.................................................................... 319 ­
Wireless Metropolitan Area Networks ............................ 319 ­
Broadband Wireless Access for Public Safety .................. 320 ­
Wideband Wireless Standards for Public Safety ............. 321 ­
Project MESA .................................................................. 322 ­
Standards: A Necessary, But Insufficient Condition........ 323 ­

Epilogue ....................................................................... 324 ­

Appendixes A. Sample Agreements ....................................................... 327 ­

B. SOP Example.................................................................. 343 ­
C. ICS Communications Position Duties ............................ 349 ­
D. Interoperability Self-Assessment Scorecard ................... 359 ­
E. Bibliography and Resources ........................................... 377 ­
F. Glossary ......................................................................... 389 ­
G. SAFECOM Interoperability Continuum......................... 413 ­
 xv

Acknowledgments
This publication was prepared by SEARCH, The National Consortium for Justice
Information and Statistics, Francis X. (Paco) Aumand III, chair, and Ronald P. Hawley,
executive director. The project director was Kelly J. Harris, deputy executive director
of programs. Dan Hawkins, director of public safety programs, wrote this publication.
Twyla R. Putt, manager, corporate communications, and Linda Townsdin, senior writer/
editor, edited this publication. Jane L. Bassett, publishing specialist, provided layout
and design. Chris Roebuck, webmaster, provided web site coordination. The federal
project manager was Debra Cohen, Ph.D., of the U.S. Department of Justice Office of
Community Oriented Policing Services (COPS).

We would especially like to acknowledge the contributions of the U.S. Department of

Homeland Security Science and Technology Directorate’s Office for Interoperability and
Compatibility’s SAFECOM Program. The presence of the SAFECOM logo on the front
cover of this Guide serves to demonstrate its support of the information offered here and
use of tools created by the program, including the Interoperability Continuum and baseline
assessment.

Suggested Citation
Dan M. Hawkins, Law Enforcement Tech Guide for Communications Interoperability: A Guide
for Interagency Communications Projects, Washington, D.C.: U.S. Department of Justice
Office of Community Oriented Policing Services, 2006.

About Us
SEARCH, The National Consortium for Justice Information and Statistics, is dedicated
to improving the quality of justice and public safety through the use, management, and
exchange of information; application of new technologies, and responsible law and
policy, while safeguarding security and privacy.

We assist local, tribal, county, regional, and state agencies and organizations—including
law enforcement and public safety; first responders; prosecution; defense; adjudication;
detention; corrections and probation; and other disciplines, such as transportation,
drivers’ licensing, vehicle registration, public health, and social services—through a
broad array of activities, resources, and products. Our focus is on criminal history
systems, integrated justice information systems, information technology (planning,
purchasing, managing), and cybercrime investigation. Our services include in-house and
on-site technical assistance and training, resource development (web sites, publications,
white papers, conferences, workshops), public policy assistance, and model development
xvi

(model legislation, standards and procedures, best practices) in these focus areas.
SEARCH online resources provide information on law enforcement IT, integrated justice,
justice software solutions, and IT acquisition at www.search.org.

About the Author

Dan M. Hawkins leads Public Safety Programs for SEARCH, The National Consortium
for Justice Information and Statistics, where he directs technical assistance to public
safety agencies nationwide in automated systems development, planning, and
integration of justice information systems, and communications interoperability.

Dan has 25 years of experience in the public safety field, most recently as
communications technology manager for the state of Montana, where he managed the
development of a statewide radio system. Prior to that, he served in several positions for
the state, including Information Technology Operations bureau chief for its Department
of Justice, manager of the state’s Public Safety Communications Program, and training
officer for its Criminal Justice Information Network. He served as the FBI information
security officer for Montana and as adjunct faculty for both the Montana Law
Enforcement Academy and Fire Services Training School. Dan began his public safety
career as a deputy sheriff in a rural Montana county.

Dan is a life member of the Association of Public-Safety Communications Officials–

International (APCO) and associate member of the International Association of Chiefs
of Police (IACP). He has served in various roles within APCO over the years, including
chapter president, member of its International Executive Council, chair of the Advisory
Committee overseeing its frequency coordination subsidiary, and as a member of
several task forces. He represents APCO on Project MESA, an international partnership
developing digital mobile broadband standards worldwide. He also serves on IACP’s
Communications and Technology Committee and on the Advisory Group to the
Department of Homeland Security SAFECOM Program.

As a U.S. Forest Service-trained incident command system (ICS) communications unit

leader, Dan has served during several large law enforcement operations, wildfires and
disasters, including two large train derailments resulting in serious hazmat incidents. He
worked as a lead geographic information systems specialist in Colorado during the 2002
wildfire season.

Dan holds a bachelor’s degree in criminal justice from Montana State University and
has completed advanced management programs with the state of Montana and IBM’s
Advanced Business Institute. He has held basic and intermediate Peace Officer Standards
and Training certificates, as well as several other certifications from the Montana Law
Enforcement Academy.
 xvii

Review Committee
SEARCH extends its deepest thanks and appreciation to the following members of the
Communications Interoperability Tech Guide Review Committee, who participated in an
advisory capacity during the preparation of this Guide.

Steve Proctor, Executive Director

Utah Communications Agency Network

John Powell, Sr., Consulting Engineer

Advanced Communications Technologies and Interoperability
U.S. Department of Homeland Security

Harlin McEwen, Chairman

Communications & Technology Committee
International Association of Chiefs of Police

Marilyn Ward, Executive Director

National Public Safety Telecommunications Council

Joe Noce, 800 MHz Project Manager

Mesa (Arizona) Police Department (Retired)

We would also like to thank members of the following agencies for contributing their
time and expertise to a review of this Guide: the Bureau of Justice Assistance and U.S.
Department of Justice’s (DOJ) Global Justice Information Sharing Initiative; the DOJ’s
Office of the Chief Information Officer; the U.S. Department of Homeland Security’s
(DHS) Office of Grants and Training, Preparedness Directorate; and the DHS Science
and Technology Directorate’s Office for Interoperability and Compatibility’s SAFECOM
Program. We are grateful to their efforts toward providing a unified federal voice to
agencies across the country seeking guidance on interoperability.
About
the
Guide
 A Library of Tech Guide Resources
This Tech Guide on interoperable communications projects is intended
to serve as a companion guide to Law Enforcement Tech Guide: How to plan,
purchase and manage technology (successfully!). The original Tech Guide was
published in 2002 by the U.S. Department of Justice Office of Community
Oriented Policing Services (COPS) and was developed as a step-by-step guide
to help law enforcement agencies as they implement new technologies.

This Communications Interoperability Tech Guide is intended to complement

and be used along with the original Tech Guide. As such, this Guide makes
frequent references to content in the original Tech Guide. It may help to keep
the original Tech Guide close at hand so you can refer to particular pages and
sections as needed.

This Tech Guide is one of a series of four topic-specific Tech Guides funded
by the COPS Office. The four companion Tech Guides that will form a
comprehensive library of technology resources, along with the original Tech
Guide, are:
n Law Enforcement Tech Guide for Small and Rural Police Agencies: A Guide
for Executives, Managers, and Technologists
n Law Enforcement Tech Guide for Creating Performance Measures that Work:
A Guide for Executives and Managers
n Law Enforcement Tech Guide for Communications Interoperability: A Guide
for Interagency Communications Projects
n Law Enforcement Tech Guide for Information Technology Security: How to
Assess Risk and Establish Effective Policies

See Page 8 for details on how to download or order your copy of the original
Tech Guide.
 About the Guide
Communications interoperability is such a big issue; how do you get your arms around the topic?
In recent years the term has been used in a variety of ways to mean different things to different
people. Most important, what does it mean to your agency and how do you approach it practically
and systematically to best serve the public?

Well, whether you’re replacing your entire radio system, replacing bits and pieces, or just looking
to improve communications with other agencies without spending money, the basics are the same.
Interoperability is built on solid foundations of leadership, cooperation, and care in understanding
just what you’re trying to accomplish. No amount of money can build a system allowing police,
fire, and emergency medical services agencies across different jurisdictions to talk to each other if
operational plans and procedures don’t support it. Usually we end up talking together only as
well as we’ve planned to.

Communications projects can be big and costly. Too often, their complexity has forced agencies
to focus on internal needs without paying enough attention to how they will communicate with
others. It’s easy to fall into the trap of considering your new voice or data system to be an isolated
project, unaffected by other systems that your agency and neighbors use. The result is usually
a system that is integrated with the agency’s other internal information and communications
systems, but incapable of interoperating with cooperating neighbors.

This Guide is designed to give you, an agency executive or project manager, background on the
subject of communications interoperability and tools to carry out technology initiatives that make
this interoperability possible. It is intended as a companion to the Law Enforcement Tech Guide:
How to plan, purchase and manage technology (successfully!), A Guide for Executives, Managers and
Technologists.

Many references are made to the “original Tech Guide”; you may want to have it handy to refer
to. Better yet, read it first and get an understanding of how technology projects in general are
successfully carried out!

HOW TO USE THIS GUIDE

This Communications Interoperability Tech Guide is intended to provide background information,
strategies, best practices, and recommendations for public safety radio projects. This Guide should
not be construed as specific legal advice for any particular factual situation. This publication is meant
to serve as a guideline for situations generally encountered in radio planning and implementation
environments. It does not replace or supersede any policies, procedures, rules, and ordinances
applicable to your jurisdiction’s procurement and contract negotiations. This Guide is not legal
counsel and should not be interpreted as a legal service.
  About the Guide

Assumptions…
… About You
This Guide is intended for staff of law enforcement or other public safety agencies
who are responsible for carrying out a successful radio project. A good team is made of
many players doing their own part.

If you’re a chief executive of the agency, welcome aboard! Your contribution to the
project is going to be critical. If you’re a technical services manager, we’re happy to
have your expertise in both the business of your agency and how technology is aligned
with its goals. Since your daily responsibility is to ensure that all systems work together,
understanding the added complexities of interagency communications is vital. And if
you’re a technical expert who gets the calls in the middle of the night to fix the pieces
that have taken an unexpected holiday, we empathize! Your interest in these systems
over their lifecycles hits right at home, doesn’t it?

Maybe you’re the officer or communications manager who has been assigned
responsibility within your agency to oversee a new voice or data radio system that
must be compatible with other agencies with which you work. Every bit of project
management experience you’ve gathered will probably be put to work to make sure
these critical and often expensive systems come together on time, within budget, and
offering the capabilities everyone expects. You’ll need a broad understanding of how
your agency uses radio communications to provide services, how technology is chosen
to support them, and why the efforts of a cross section of people in your agency are
needed to bring about a successful project.

Or maybe you’re the project manager dedicated solely to this effort. If so,
congratulations! Not many folks get to concentrate on a single project. More likely, your
skills are valued elsewhere in the agency, too, and you have no shortage of projects on
your desk. This may be only one of several technology initiatives you’re working on that
demands your skills in combination with a decent understanding of the technologies
involved, business practices affected, and common pitfalls others have faced.

You might think that your agency is too small or your project too tightly funded to have
a full-time project manager. That certainly might be the case and if you’re managing
FYI:
We tell you how to
projects in such an agency, you’re most likely to have other routine duties—and maybe
get your own copy even other projects. This Guide is especially useful to you because it provides a how-to
of the original Tech guide with tips, checklists, and recommendations for your efforts—large or small!
Guide on Page 8. This Guide will provide important background for all team members on how
interoperability in communications systems is achieved. Its companion Law
Enforcement Tech Guide will also be indispensable in your efforts. Get your own copy!
 About the Guide

… About Your Project
We assume that you already have voice radio capabilities in your agency and are either
replacing systems nearing the end of their useful lives or carrying out a project to
improve communications between existing systems. Maybe you’re implementing a
data radio system to augment voice communications and add new field capabilities
or provide direct access to important computer systems. While this Guide doesn’t
address mobile data or computer systems in depth, it does address important aspects
of the radio environment for both voice and data projects. Its central focus is on how to
improve interagency communications across your jurisdiction.

How this Guide Is Organized

This Guide is split into three parts to help you navigate to areas of greatest interest
to you. Each part builds on preceding ones, but if you’re in a hurry to get to work
improving interagency communications, jump right to the second part. If you’re just
interested in how technology is applied to achieve interoperability, the third part may
be most useful to you.

However you approach it, please take time at some point to read the entire Guide. You
will find useful background for current, as well as future, projects.

Part I What Is Communications Interoperability?

Part I takes a look at what interoperability is and where we are today, as of the printing of
this Guide. While we talk briefly about how and why interoperability has become a national
issue, our focus is on what it means for local public safety agencies that have to talk with their
neighbors.

Part II How Is Interoperability Achieved?

Part II delves into how to achieve interoperability within your jurisdiction or region. It
addresses steps to successful projects that were first introduced in the original Law
Enforcement Tech Guide. The original Tech Guide dedicated multiple chapters to each step, so
in this Guide we’ll focus on additional aspects of interoperability projects or ones that require
a bit more attention. The final chapter of this part takes a look at how we can measure our level
of interoperability.

Part III Exploring the Technologies

Part III examines the different technological approaches to interoperability and specific types
of communications equipment used in each. Since security plays an increasingly important
role in public safety technology, we’ll examine it with both voice and data systems.
 About the Guide

The Guide concludes with an important appendix and fold-out with the Department of
Homeland Security SAFECOM Program’s Interoperability Continuum. This tool provides
a standard set of success elements for interoperability. It also provides a snapshot of
how progress is made from limited to highly interoperable public safety services. These
elements are addressed from a project perspective throughout this Guide.

Our hope is to provide tools to help with your project. Icons are used in the margins
as they were in the original Law Enforcement Tech Guide, to highlight areas of specific
interest to particular project team members. Executive sponsors, for example, should
keep an eye out for the shield icon shown below that is used to mark key points for
project champions. Elsewhere, you will also find tips, checklists, and definitions along
the way that will be useful in your quest to improve communications interoperability.
In appendixes at the end of this Guide, we have included a glossary, resource materials,
and sample documents.

Definition of Icons
Executive Sponsors
Executive sponsors are the project spokespersons, decision makers, and leaders of
the agencies involved in the interoperability effort. Generally, they are the highest
ranking decision makers within their organization. This icon is used to highlight
recommendations and advice directed particularly at them.

Operational Experts
Operational experts are those communications users who understand the business
processes of their respective agencies and how operations are conducted with others.
Typically, these persons are senior line supervisors with experience in interagency
operations. They should keep an eye out for this icon in the margins.

Technical Experts
Technical expertise is critical for analysis of the current communications technology
environment and evaluation of the technical aspects of proposed solutions. This icon is
used to draw attention to material that will benefit technical experts.

Project Manager
Since the project manager has such a pivotal role, we could have used this icon on every
page of the Guide. We have limited ourselves to using it to highlight aspects most
commonly handled by the project manager.
 About the Guide

Stop Sign
Every technology project is challenged to navigate in a veritable minefield of
obstacles. When you see this icon, carefully read about pitfalls that we are hoping you
will avoid.

Grant Requirements
This icon is used to draw your attention to interoperability aspects that may be
affected by requirements of the grants funding your project. Even if your project is
funded by other means, one of your neighbors is probably relying on grants for some
part of its system and you will want to learn how grant requirements are shaping its
interagency communications plans.

Regional
Multijurisdictional, regional efforts bring the highest level of communications
interoperability. This icon is used to draw your attention to advice and
recommendations on how to make those efforts most successful.

Tips
This Guide is full of tips, but some need particular attention. We’ll use this icon for
ideas you might find immediately useful.

Checklists
We all need lists to organize a collection of thoughts or tasks. Part II of this Guide has
a number of checklists to help you keep track of the recommendations that we have
provided.

Interoperability Continuum
As mentioned, the SAFECOM Interoperability Continuum is an important and useful
tool for understanding how communications systems evolve from minimal to optimal
levels of interoperability. It is included in this Guide as a back cover foldout preceded
by an appendix describing its elements in depth. This icon is used to highlight those
elements as they are addressed throughout the Guide.

TECH GUIDE
Original Tech Guide Reference
ORIGINAL

The parent Tech Guide contains many useful tools, charts, and instructions for
conducting various tasks. When you see this icon, you will be directed to a specific
s
page, or range of pages, in the original Tech Guide.
 About the Guide

Where to Go From Here

Communications interoperability projects are technology projects. If you don’t have
a copy of the original Law Enforcement Tech Guide, download or order one. Since this
Guide on interoperability is intended to complement the original, we’ll often refer
to it rather than repeating advice. There’s a wealth of material in it about planning,
purchasing, and managing technology (successfully!) that you will want to use for all
sorts of projects.

If you’re with a fire, emergency medical services, or other nonpolice agency, don’t get
hung up on the “Law Enforcement” part of the Tech Guide’s title. It was produced for
that audience, but the principles and practices provided are applicable across public
safety technology, generally. It has been used as a textbook by the U.S. Department
of Justice and U.S. Department of Homeland Security to train dozens of jurisdictions
from around the country in managing their interagency projects.

Sources of the “Law Enforcement Tech Guide”

The U.S. Department of Justice Office of Community Oriented Policing Services
(COPS) published the Law Enforcement Tech Guide in 2002. It is available electronically
from the COPS web site: http://www.cops.usdoj.gov/default.asp?Item=512.

There it is broken down into its separate parts as Portable Document Format (PDF) files
so you can download or read one at a time.

If you’re anxious to download the whole document at once—all 14 megabytes—the

complete version can be found at SEARCH’s web site:
http://www.search.org/files/pdf/TECHGUIDE.pdf.

And finally, hard copy versions are distributed by the COPS Office. To request one,
contact the COPS Office Response Center at 800.421.6770 or e-mail
[email protected].
 Part I:
What is
Communications
Interoperability?
 CHAPTEr 1
InTrODUCTIOn—
A CHAnGInG EnvIrOnmEnT
 Chapter 1:
Introduction—
A Changing Environment
In recent years, dramatic criminal, terrorist, and natural disasters—and seemingly
endless post-incident inquiries—have seared into the public mind the importance
of seamless emergency services. Today more than ever, the public expects those
services will be delivered regardless of long histories of turf battles between agencies
and jurisdictions. Public safety as an entity—the collective of police, fire, emergency
medical services (EMS), and supporting agencies—is challenged to integrate services
across these boundaries to serve a public that’s not easily separated by administrative
Interoperability
lines or simple classifications of calls.
is the ability of
agencies to work
together toward Interoperability is the ability of agencies to work together toward common ends. It
common ends. depends on a common vision of what those “ends” are and how separate capabilities
are combined to serve them. As with most government services provided in this
day and age, public safety response to emergencies is enabled by technology.
Telecommunications and information services, more specifically, are key enablers to
effective emergency services.

Communications interoperability is changing in an environment with strong public

expectations, evolving communications needs, developing technologies, and a
growing understanding of how all of these parts work together.

Public Expectations
What does the public expect? That’s not an easy question, but when Mrs. Smith calls
9-1-1, she doesn’t want to hear about turf issues and technological incompatibilities.
She expects that services will be delivered promptly and effectively to address her
emergency. No amount of explanation of jurisdictions, policies, or radio failures will
matter (or be acceptable) in time of need.

The public expects that emergency responders are able to communicate with one
another. Expected outcomes of that ability, in management terms, include:
• ­Responder accountability – That those brave souls who “face the elephant”
aren’t lost in the fog of battles.
• ­Coordinated incident management – That response to incidents isn’t “sliced
and diced” by administrative, operational, or jurisdictional boundaries.
1 Part I: What Is Communications Interoperability?

• ­Shared information – That what is available or known to one is shared, as

needed, with others.
• ­Coordinated information management – That the ever-present threat of
“TMI” (too much information) doesn’t cause the message to be lost among
the noise.
• ­ Economies of scale – That public funds are efficiently used for effective
systems supporting all emergency response. ­

Evolving Communications Needs

Changes in how we manage resources and expect services to be delivered
cooperatively have caused communications needs to evolve internally within
organizations and externally between them. This has not occurred without
great challenge.

For example, decentralized decision making and accountability—key principles in

community policing—require that information be readily available to officers who
are often widely dispersed throughout jurisdictions. Likewise, community oriented
policing requires problem-solving partnerships among police, fire, EMS, and other
public safety agencies. Those partnerships are strengthened when first responders
have ready access to information from within their own organizations and elsewhere.
Most often, that information is delivered to the field wirelessly.

One challenge that follows is simply how to provide radio coverage. It’s an
unfortunate, but inescapable, fact of today’s public safety environment that the more
widely dispersed the responders, the more difficult it is to provide them with reliable,
high-quality voice and data network services. Officers in shopping malls, firefighters
in large office buildings, and mountain rescuers alike are too often in the unreliable
margins of radio networks where any information exchange is difficult. Increasingly,
we rely on the lowly handheld radio to connect responders, making coverage an even
greater challenge.

Public safety agency managers have to work hard to assure that field personnel are
reliably connected for safety purposes and for management of operations. While
Communications
interoperability
first responders are ideally always connected to the organizational infrastructure
is critical for that supports their supply of and demand for information, the emergency
information environment doesn’t always cooperate. Dense urban canyons, tunnels, and ever-
sharing. rising electronic noise are just a few examples of modern life that increasingly affect
the radio environment.

Information powers the modern police officer, firefighter, and EMS provider. Whether
working individually or in tandem with others during a response, first responders
have to receive timely information about the incident, including location, scope,
 Chapter 1: Introduction—A Changing Environment
1
who else is responding, and tactical plans. Likewise, the information they provide in
response can mean the difference between life and death for citizens, not the least of
whom are the responders themselves.

Integration of information and communications systems—both between agencies and

throughout field operations—is an essential part of interoperability today.

Developing Technologies
Radio communications is a venerable staple in the arsenal of public safety tools. It has
only become more so in modern times.

Since the earliest systems built more

than 80 years ago, radio has been the
primary means of getting information
to the field. The first Detroit Police
Department system was licensed with
the Federal Radio Commission in
1922 as KOP, an AM broadcast station
required to transmit music between
all-points bulletins and administrative
messages, with no ability for field units
to acknowledge receipt or reply to
broadcasts (at times, that might still
seem to be an advantage!). By 1928,
the radio car was a key part of Detroit’s
policing environment.

How times have changed! While the Figure 1-1: Detroit Police Department
melodious sounds of today’s dispatches Station KOP (1928)
Cooperators:
Any agency,
are hardly entertainment, our radio
organization, systems have come far from those one-way days. Gone is the time when radio simply
or person that served to connect responders and dispatch. Today, modern police, fire, and EMS
operates jointly agencies around the country rely on voice and data networks that share information
or cooperates wirelessly in all directions: vertically among levels of command, horizontally between
with your agency functional subdivisions, and further yet across jurisdictional boundaries.
and with which
you need to
communicate by
Science and industry regularly improve our ability to make different technologies work
radio. together. Indeed, it’s getting more difficult to distinguish radios from computers and
wireless networks from wired pieces strung among them. Technological interoperability
first achieved through integration of internal voice and data capabilities now allows us
to connect similarly integrated systems with external cooperators.
 1 Part I: What Is Communications Interoperability?

This advancing technological environment makes it easier to share underlying parts

of systems to take advantage of economies of scale, sharing what might otherwise
be wasted capacity. Shared coverage and services are possible where completely
separate systems were cost-prohibitive. Even though voice and data networks
may be separate as they reach into the patrol car, many of the components up to
that “last mile” can now be shared between agencies and systems. Both voice and
data communications can pass over the same backbone network from dispatch to
the transmission site. There they may share power, environmental, and antenna
combining subsystems before parting company on separate frequencies destined
for different radios in the car.

Elsewhere, developing technology has given us the means to get more users on
a frequency, more data through channels, and the ability to assign “talkgroups”
dynamically based on the needs of the moment. Technology has evolved so that
we can now link disparate radio systems, allowing users on one type of network to
talk with those on another across their shared operational areas. And it has given us
the ability to leverage the capabilities of wireless data to reduce demand for critical
voice channels.

There’s no doubt that technology advancements have dramatically changed public

safety communications, particularly in the past 25 years. They have also challenged
us to adapt business practices along the way, sometimes successfully, sometimes not.
The growing array of choices we have will further challenge us to manage technology,
rather than have it manage us.

The Interoperability Equation

An electronic In response to dramatic failures in interagency communications, government entities
government
from Main Street to Pennsylvania Avenue have taken up the challenge of improving
initiative housed
within the U.S.
the situation. The term “communications interoperability” has come to mean
Department of different things to different people, especially following well-publicized breakdowns.
Homeland Security
(DHS) designated In order to bring focus to the subject, the national SAFECOM Program1 was initiated.
as the umbrella Communications interoperability is defined by SAFECOM as follows:
program to
coordinate Federal
The ability of public safety agencies to talk across disciplines and jurisdictions via
Government
efforts to improve radio communications systems, exchanging voice and/or data with one another on
communications demand, in real time, when needed, and as authorized.
interoperability.

1
See http://www.safecomprogram.gov.
 Chapter 1: Introduction—A Changing Environment
1
This ability to talk is the sum total of interagency operational plans, common
procedures, and enabling technologies, multiplied by the effects of training and
exercises. The best interagency plans and procedures are a complex function of
standardized incident management systems and common terminologies. Funding
and other resource limitations are often confounding factors in efforts to solve
this equation.

Further federal and state efforts are helping with this bit of algebra. The U.S.
Department of Justice, through its Office of Community Oriented Policing Services
(COPS), and the DHS, through the Federal Emergency Management Agency (FEMA),
have cooperatively granted hundreds of millions of dollars to local agencies since the
terrorist attacks of September 11, 2001, to improve communications interoperability.
In addition, the DHS Office of Grants and Training has distributed billions of dollars
to public safety agencies through State Homeland Security and Urban Area Security
Initiative (UASI) grants, much going to improve communications in response to
terrorist events. Even funds provided through pre-existing federal grant programs
are in large share today being used to update and enhance the country’s public safety
communications infrastructure.

At the state level, statewide interoperability executive committees—generically known

as SIECs—have evolved in recent years to focus state and local efforts. First defined
by the Federal Communications Commission (FCC) in 2001 for the administration
of interoperability channels in the 700 MHz frequency band, SIECs have become
increasingly pivotal in steering grant funds and growing multijurisdictional efforts in
many states. Efforts in Washington2 and Virginia,3 for example, have provided models
for how first responders across disciplines and jurisdictions can work together toward
common goals. State homeland security agencies have began to look to SIECs to
connect their strategic plans with real-world interagency communications needs.

Efforts to solve the interoperability equation are probably affecting your work,
whether you’ve been aware of it or not.

2
See Washington’s SIEC web site at http://isb.wa.gov/committees/siec/.
3
See Virginia’s interoperability web site at
http://www.interoperability.publicsafety.virginia.gov/.
1 Part I: What Is Communications Interoperability?

What Will Tomorrow Bring?

This is the environment faced by agency and project managers who are working to
improve communications within their own jurisdictions. Perhaps you’re reading this
because you’re responsible for making those improvements. How will it change over
the period of your projects, the lifecycles of your systems, or your career?

Well, it’s easy, if sad, to imagine that emergencies and disasters capturing national
attention will continue to occur. Communications needs will evolve as our response
capabilities become more complex and sophisticated. Technology will surely continue
to offer opportunities for greater interagency communications and challenge our
ability to employ it without disrupting what’s already been achieved. And our
collective efforts will help solve the interoperability equation.

In the chapters ahead, we’ll look further at challenges to achieving interoperability—

right after taking a brief look at how information flows in organizations with
technology well integrated into services being delivered.
 CHAPTEr 2
KEy CHAllEnGES AnD
CrITICAl ElEmEnTS
 Chapter 2:
Key Challenges and
Critical Elements
A changing environment for public safety agencies has brought a range of challenges
to achieving the communications interoperability necessary for emergency services.
Nationally, the key challenges and critical elements for success have been documented
through the collective attention of local, state, and federal officials. This high level
of attention arose in concert with a growing public awareness of interoperability
problems. Though dramatically highlighted by recent tragic events, communications,
particularly interagency communications, have long been a problem.

At the heart of public safety communications is first responder radio capabilities.

Radio communications—or the lack thereof—can and has contributed directly
to first responder deaths. This Guide stresses that integration of voice and data
technologies is necessary for interoperability, but we recognize from direct experience
the importance of first responder voice communications. Radio is the most critical
information technology tool for officers investigating a “hot” burglary, firefighters on
interior attack during a structure fire, and paramedics providing basic life support.
Given its importance in basic emergency operations, there’s no surprise that first
responder radio capabilities are also at the heart of interoperability needs.
22 Part I: What Is Communications Interoperability?

Recent Findings: Why Public Safety

Can’t Talk
Following that fateful September day in 2001, the National Institute of Justice
(NIJ), Office of Science and Technology, organized the National Task Force on
Interoperability (NTFI). This task force of leaders from 18 national associations
representing state and local officials addressed the problem of communications
interoperability.

NTFI reported out five key reasons why public safety can’t talk.4 From a policy and
operation perspectives, they are as follows:
• ­Incompatible and aging communications
equipment ­
• ­Limited and fragmented funding
• ­Limited and fragmented planning
• ­Lack of coordination and cooperation
• ­Limited and fragmented radio spectrum.

Every effort to improve interagency communications

faces these same challenges, though to different degrees. For example, some
jurisdictions have long histories of productive planning and coordination, but are
desperately short of needed funds for system upgrades to connect responders across
agencies. Other jurisdictions face such a severe shortage of radio frequencies that
interoperability efforts are stymied, regardless of available funding. Each group of
agencies seeking to improve interoperability faces a different combination of these
basic challenges.

We’ll get into how these challenges can be addressed in Part II of this Guide, How
is Interoperability Achieved? Let’s take a look here at how these challenges have
developed into national problems.

4
Why Can’t We Talk? Working Together to Bridge the Communications Gap to Save Lives, National Task
Force on Interoperability, February 2003. Available at
http://www.ojp.usdoj.gov/nij/topics/commtech/ntfi_guide.pdf.
 Chapter 2: Key Challenges and Critical Elements
23
Incompatible and Aging Communications Equipment
The lifecycle for radio systems has traditionally been very long, sometimes
exceeding 20 and even 30 years. Equipment used in these systems is customarily
expected to have an 8-to-10-year service life, yet more than one-half of agencies
currently exceed that.

A survey of 1,334 state and local law enforcement agencies conducted in 1998 by
the National Law Enforcement and Corrections Technology Center for NIJ showed a
60 percent of
direct correlation between the age of systems and respondents’ assessment of their
state and local
law enforcement
radio communications effectiveness.5 Sixty percent reported aging equipment to be
agencies report a moderate to major problem. Local law enforcement systems averaged 9 years in
that aging radio service, while state systems averaged even longer—15 years. According to reports
communications issued by Public Safety Wireless Network (PSWN), a joint initiative of the U.S.
equipment is a Departments of Justice and Treasury that is now part of SAFECOM, local fire and
problem. emergency medical services (EMS) systems average 10 years.6

When characters Roy Desoto and Johnny Gage showed us (well, at least some of us)
just how exciting communications could be during the 1970s hit television show
“Emergency!”, radio technology choices were few and compatibility was high. Their
call sign, KMG365, was and still is assigned to a VHF (Very High Frequency)-high
band, analog FM (frequency modulated) base station. The call sign and station
are still in use by Los Angeles County, although probably with equipment of more
recent vintage!

Unfortunately, some agencies are still using radios purchased new when “Emergency!”
Options for police,
debuted. The simple fact that the radios still work is amazing. It says something
fire, and EmS radio
have blossomed about the quality of equipment manufactured for lengthy public safety use, but more
in relatively recent about historically limited technology choices that lead (or force) agencies to upgrade.
history. Options for police, fire, and EMS radio have blossomed in relatively recent history,
much as we’ve seen wireless technologies explode in the consumer sector.

5
Taylor, Mary J., et al., State and Local Law Enforcement Wireless Communications and
Interoperability: A Quantitative Analysis, NCJ 168961 (Washington, D.C.: U.S. Department of Justice,
Office of Justice Programs, National Institute of Justice, January 1998). Available at
http://www.ncjrs.org/pdffiles1/168961.pdf.
6
PSWN Program Analysis of Fire and EMS Communications Interoperability, Public Safety Wireless
Network Program Management Office, prepared by Booz, Allen & Hamilton Inc., April 1999.
Available at http://permanent.access.gpo.gov/websites/safecomprogramgov/www.
safecomprogram.gov/admin/librarydocs9/fireems_interop_study.pdf.
2 Part I: What Is Communications Interoperability?

Regional incompatibilities have grown as agencies have upgraded one by one to meet
pressing internal needs. Because lifecycle needs vary, separate agencies within a single
jurisdiction often end up replacing systems at different times, making needed changes
that result in additional interoperability challenges. The costs of supporting old
equipment and technologies dropped by manufacturers have led agencies across the
country to upgrade systems. In many cases, their partners and neighbors were unable
to do likewise.

The result today is that we have, for example, rural fire departments using radio
technologies pioneered more than half a century ago while larger, neighboring
jurisdictions have migrated to higher frequency bands, digital channels, and trunked
systems. Incompatibility is the result.

Limited and Fragmented Funding

Across all levels of government, limited and fragmented funding has contributed to
all other interoperability challenges by:
• Hindering replacement of aging and incompatible equipment
• Restricting human resources available for interagency planning
• Forcing agencies to focus on their most pressing internal operational needs
• Limiting access to scarce radio spectrum resources.

There has never been a national strategy for funding public safety radio costs.
Local radio systems for police, fire, and EMS are funded by every means available
to government, from general appropriations and bonds to grants and bake sales.
Local, tribal, and state systems, alike, are most often funded as one-time projects.
Their ongoing costs—including maintenance, licensing, network services, training,
replacements, and other operating expenses—are annually shoehorned into tight
budgets. By contrast, basic and enhanced 9-1-1 services around the country are
funded similarly from state to state. Recent congressional action will standardize 9-1-1
The value of
funding further. ­
America’s public
safety radio It’s no wonder such fragmented funding for public safety radio has evolved over time.
infrastructure is The value of America’s investment in it is staggering. In 1998, it was estimated to be
staggering. worth $18.3 billion7—and that’s just for equipment and fixed infrastructure. This

7
LMR Replacement Cost Study Report, Public Safety Wireless Network, prepared by Booz, Allen &
Hamilton Inc., June 1998. This report and figure is currently the most comprehensive available for
the replacement costs of land mobile radio (LMR) equipment owned by local, state, and federal
governments. Available at http://www.safecomprogram.gov/NR/rdonlyres/B69361FA-9AC6-
4126-B971-83DF30FED932/0/lmr_coststudy.pdf.
 Chapter 2: Key Challenges and Critical Elements
2
commonly cited figure does not include system installation, testing, training, or other
implementation costs. Complete replacement of existing public safety radio systems,
with all associated costs, would total two or more times this figure.

The net effect of limited and fragmented funding for public safety radio systems is
great diversity between systems and long replacement cycles across the country.

Limited and Fragmented Planning

The NTFI report identified historically limited and fragmented planning as a third
key reason for interoperability problems. Agencies at all levels of government
competing for limited funds have provided few resources for interagency planning
efforts. This competition has compounded interoperability problems by discouraging
partnerships necessary for joint operating plans that define communications needs.

Lack of Coordination and Cooperation

Likewise, NTFI identified a lack of coordination and cooperation between agencies
in funding and managing systems as an impediment to interoperability. Changing
the pattern of isolated spending, and increased sharing of management and control,
were noted as necessary steps. While multiple solutions to meet varying needs are
inevitable, portions of infrastructure, such as towers, and even full systems can be
shared in some cases.

We’ll have more to say about the importance of operational planning and
coordination shortly.
 2 Part I: What Is Communications Interoperability?

Limited and Fragmented Radio Spectrum

radios on
Agencies seeking to expand or upgrade their systems are increasingly being forced to
widely separated move to higher frequency bands to find available channels. Because radio equipment
frequencies are is typically built to operate on a single one of the 10 bands open to public safety,
incapable of being systems using different bands are technologically incompatible at a fundamental level.
tuned from one to That is, the radios talk on frequencies widely separated and are incapable of being
the other. tuned from one to the other. See Figure 2-1.

History and operational needs have crowded users to the lower ends of the spectrum.
more than half of all The vast majority of public safety radio systems—both voice and data—operate
agencies operate in in four of the lower bands. More than half of the agencies in the country operate
vHF-high band. their primary voice systems in a single one: VHF-high band.8 Additional channels in
current bands are virtually unattainable in many parts of the country.

mHz 450-470 764-776* 806-824 4940

25-50 150-174 220-222 470-512 794-806* 851-869 4990 microwave

Figure 2-1: Radio Spectrum

Source: U.S. Department of Homeland Security, SAFECOM Program

8
VHF-high band for local and state agencies runs from 150 to 174 megahertz (MHz). According to
supporting documents for PSWN’s LMR Replacement Cost Study, almost 57 percent of agencies make
primary use of it, while fewer than 6 percent used 800 MHz. See footnote 7, page 24.
 Chapter 2: Key Challenges and Critical Elements
2
When an agency moves its radio communications to a “new” band, the technological
divide of operating across bands brings fresh challenges to talking directly with
previous cooperators. Other technologies, such as console patches, have been used for
years to link agencies on different bands, but these bring their own limitations and
require additional planning. Remember the planning challenge? Such approaches
to resolving the effects of fragmented spectrum are, to put it simply, just patches.
They’re less than ideal, but unfortunately necessary.

Interoperability would certainly be an easier nut to crack if all agencies operated in

the same range of radio spectrum. Unfortunately, each band offers a limited number
of channels—the real estate of wireless communications. Each geographic region
(neighborhood) only has a certain number of channels (residential lots).

“Location, location, location,” they say in the world of real estate. Location in the
wireless world is equally critical, but here we’re not just talking about geography.
We are also referring to where a system operates within the radio spectrum! Each of
the 10 bands is best suited for different purposes and the highest ones are entirely
unsuited for unit-to-unit voice systems as we know them today; they’re used for
microwave links. And needs vary across the country. For example, urban areas
have great demand for channels in the higher bands offering the best building
penetration. By contrast, wide-area systems necessary in rural and statewide
jurisdictions are most economical in the lower bands where range is greatest.
Remember the funding challenge?
The highest
frequency bands The net effect is best described as increasing fragmentation that reduces
are unsuited for interoperability. The NTFI report also noted that public safety has a growing need
voice systems as for wireless services beyond traditional voice operations. Mobile data, automatic
we know them vehicle location, and other types of systems increase demands on a finite public
today. safety spectrum. Beyond that, growing commercial and private demands for wireless
services brings intense competition for limited resources that otherwise might be used
for public safety.

Limited and fragmented radio spectrum is a fundamental cause of

interoperability problems.
 2 Part I: What Is Communications Interoperability?

Critical Elements to Achieving Interoperability

Since 2003, the Department of Homeland Security SAFECOM Program has been
working to bring a practitioner’s focus to the problem of interoperability. Through
SAFECOM, public safety leaders have identified five critical elements to solving
interagency communications problems:
1. Governance.
2. Standard operating procedures.
3. Training and exercises.
4. Frequency of use.
5. Technology.

They have also identified stages along each element, recognizing that interoperability
isn’t an either/or proposition—it’s a matter of degree. Interoperability improves as
agencies progress with each of these elements. SAFECOM’s Interoperability Continuum,
found here as the foldout rear cover, depicts these elements and stages. Briefly, these
ideas are summarized here and incorporated throughout this Guide.

Governance
As noted by NTFI, limited coordination and collaboration between agencies is a
key reason why we can’t talk. Regular collaboration between key staff members of
agencies and across disciplines improves this situation, but formal committees serving
regional needs and working with statewide efforts are best.

Standard Operating Procedures

The level of All public safety agencies have established standard operating procedures (SOP)—
interoperability whether these are verbal or written. The level of interoperability between agencies
between agencies increases as they create joint SOPs, typically first for planned events, then for
increases as emergencies. Interoperability improves as joint planning moves to serve regional
they create joint
SOPs, typically
needs, producing communications SOPs. Optimal levels are reached as the National
first for planned Incident Management System (NIMS) is integrated into procedures.
events, then for
emergencies. We’ll talk further about the NIMS in Chapter 3, Operability – Job #1.

The National Incident Management System (NIMS)

[A] consistent nationwide approach for Federal, State, and local governments to work
effectively and efficiently together to prepare for, respond to, and recover from domestic
incidents, regardless of cause, size, or complexity.
Homeland Security Presidential Directive (HSPD)-5
February 28, 2003
 Chapter 2: Key Challenges and Critical Elements
29
Training and Exercises
The importance of training and exercises cannot be overstated. Communications
interoperability improves in small amounts through simple internal orientations on
communications equipment. Tabletop exercises provide further improvements, but by
necessity these limit the number of people involved, typically to key field and support
staff. Multiagency tabletop exercises produce a higher level of interoperability than
single agency ones, of course. Full functional exercises between agencies involving
all staff are optimally second only to regular, comprehensive training and exercises
incorporating the regional SOPs described previously.

Frequency of Use
Interoperability improves as agencies use their adopted techniques, procedures,
and technologies more frequently and broadly. A minimal, but important, level is
reached as those methods and means are used for planned multiagency events. It is
further improved by common use during localized emergencies and further yet as
incorporated into regional incident management systems. Optimal levels are reached
as they are used on a daily basis throughout the region.

Technology
There are five identifiable technological means of interagency communications,
particularly by radio:
1. Swapping radios.
2. Using gateways between independent systems.
3. Sharing channels.
4. Sharing proprietary systems.
5. Sharing standards-based systems.
Higher levels of interoperability are reached as the predominant means progresses
toward shared systems.

A minimal level of interoperability is achieved when agencies resort to providing

Technological cooperators one of their radios, and vice versa during incidents. This is what we refer
Means to to as “swapping radios.” It’s not ideal for a number of reasons, but has often been
Interoperability relied upon.
Swap radios
Use gateways
Share channels “Gateways” are electronic, often automated devices for taking the audio from one
Share proprietary radio channel and patching it to another—and vice versa. In the past, the most
systems common form of gateway was provided by the dispatch console patch mentioned on
Share standards- Page 27. Since September 11, a great many of these have been purchased to improve
based systems interoperability. We’ll delve further into these devices in Part III of this Guide,
Exploring the Technologies.
 30 Part I: What Is Communications Interoperability?

A higher level of interoperability is provided when agencies using compatible

technologies designate common channels between them for interagency
communications in joint operations. This is referred to as “sharing channels.”

The final two technological means of interoperability are more self-explanatory.

Interoperability through “shared proprietary systems” occurs when multiple agencies
jointly use a common system based on proprietary—or vendor-specific—technology.
This is considered to be a less optimal means than shared use of a system built from
standards-based—or nonvendor-specific—technology. Again, we’ll go further into
detail on these and other technologies in Part III.

It’s important to note that the steps from minimal to optimal levels of interoperability
along each element in SAFECOM’s Interoperability Continuum are progressive. That is,
they build on one another and don’t necessarily exclude preceding steps. For example,
individual agency communications SOPs are still important when joint or regional
ones are in place. Ideally, the two closely mesh. Likewise, in-service orientations on
equipment are still important, even when regular, comprehensive regional training is
in place.

One More Time: It’s the Planning and

Coordination
There’s a lot more to be said about planning and coordination for interagency
communications. As a matter of fact, that’s what all of Part II is about! Well, it’s
mainly about how to achieve interoperability, but we’ll give you a brief preview and let
you know that’s what it takes to get from here to there.

If it isn’t already apparent, planning and coordination between agencies are basic
principles behind the Interoperability Continuum’s critical elements.

Planning for interagency operations, generally, varies greatly from one part of the
no communications country to another and between levels of government. Where inadequate operational
system can make plans exist, communications suffer tremendously and interoperability is practically
up for inadequate impossible. Poor communications can and unfortunately often do hinder operations,
operational plans. but no communications system or set of interoperable systems can make up for
inadequate operational plans.

In Part II of this Guide, we’ll show how communications interoperability is

achieved through a common incident management system, technologies linking
responders, and operational plans brought to life before they’re needed through
training and exercises.
 Chapter 2: Key Challenges and Critical Elements
31
The mcKinsey
reports were McKINSEY REPORT
prepared for
new york City’s … [T]o be fully prepared to face the threats posed by terrorism and other major incidents,
police and fire the city or state governments must establish a much broader, detailed and more formalized
departments in interagency planning and coordination process. The process would include:
the year following – Establishment of common command and control structures and terminology,
the World Trade and agreement on the roles and responsibilities of each agency for managing the
Center attacks on response to any incident.
September 11,
2001. They include – Deployment of interoperable communications infrastructures and protocols to
detailed analyses improve response coordination and exchange of information.
of response to – Implementation of joint training exercises to ensure that agencies can and will
the disaster and cooperate effectively during incidents, e.g., by operating under a unified command
recommendations and control structure.
for improving
preparedness in the
“Increasing FDNY’s Preparedness,” McKinsey & Company
future. August 19, 2002, Executive Summary, p. 21.
We’ll refer Available at http://www.nyc.gov/html/fdny/html/mck_report/toc.shtml
elsewhere to
these reports on
matters important
to agencies of all
sizes.
 CHAPTEr 3
OPErABIlITy—JOB #1
 Chapter 3:
Operability—Job #1

Command and Control within First Responder Agencies.

For a unified incident management system to succeed, each
participant must have command and control of its own units and
adequate internal communications.
— The 9/11 Commission Report
(Page 319)

Throughout this Guide, we refer to the events of September 11, 2001 and after-action
reports to highlight issues of interagency communications. The sheer magnitude
of those events provides a powerful microscope for examining not only internal
operational demands on agencies under such extraordinary circumstances, but also
interoperability needs.

We all owe a huge debt of gratitude to the agencies rich with experience and history
that hardly volunteered, but valiantly responded, that day and now share their lessons
learned. We use those lessons here not critically, but to share the benefit of quality
analyses arising from the World Trade Center and Pentagon maelstroms.

Though the magnitude of those events and scale of response, we hope, are beyond what
any jurisdiction will face in the future, our belief is that lessons highlighted here apply
to public safety operations at all scales.
 3 Part I: What Is Communications Interoperability?

The level of attention brought to the national issue of communications

interoperability has, at times, drawn the spotlight from this fact: Day in and day out,
radio is critical in delivery of all sorts of public safety services. As “operability”
is the root of the word, it’s also what makes interoperability possible.

The interoperability Interagency communications are, at best, a distraction if an agency is unable to

puzzle is solved provide for its own operations. At worst, they can bring chaos to emergency response
by first resolving if they interfere with internal operational demands. No agency administrator, chief
operational officer, or incident commander wants to worry about how the troops are going to talk
communications to other agencies when their own internal radio communications are inadequate. The
needs. interoperability puzzle is solved by first resolving operational communications needs.

Before moving on to Part II, which focuses on how interoperability is achieved, we

want to emphasize the importance of beginning with an operational perspective.
We’ll look at some of the operational lessons learned during the 9/11 attacks and
conclude with how standardized incident management systems provide tools to battle
both operational and interoperability challenges.

A Proportional Perspective
In trying to understand what communications interoperability is and how it relates
to daily requirements, it’s important to note that radio is first and foremost used for
delivering services day-by-day to Mrs. Smith. Her emergency services are primarily
provided by local agencies—usually by a single one for any given call. Consequently,
the lion’s share of public safety radio communications take place internally between
units of individual local agencies.

Operations, particularly the intersection of operational responsibilities between

agencies, drives interoperability needs. That is, two agencies responsible for providing
services at the same place and time need to work together to serve their missions. See
Figure 3-1. However, internal agency communications demands overshadow
interagency requirements even in large incidents because the bulk of traffic is
still tactical within responding units, typically from the same agency.

In terms of sheer volume, communications demands across all types of public safety
response stack up like this:
1. Internal communications within individual local agencies.
2. Interagency communications between like agencies from adjoining
jurisdictions, such as between city police and county sheriff or between
neighboring fire companies. ­
3. Interagency communications between different types of responders, such as
police and fire, in the same jurisdiction.
 Chapter 3: Operability—Job #1
3
4. Interagency communications between different types of responders in
neighboring or distant jurisdictions. ­

This isn’t to say that any

particular type of radio Operability
exchange is insignificant or
expendable. It is important
to note, however, that
day-to-day internal
communications needs
drive requirements for
radio systems. After
all, there’s no need to
interoperate if you can’t Interoperability
operate to begin with!

While this might seem

obvious, we’ve seen plenty
of technology projects
where basic needs are
forgotten in the rush to Operability
find a “silver bullet” for a
smaller set of problems. It
simply boils down to the fact Operability
that internal operational
needs are appropriately the Figure 3-1: Operations Drive Interoperability Needs
central focus of agency radio
projects. However, those
needs can be defined, satisfied, and incorporated into standard operating procedures
(SOP) while assuring interoperability, as we’ll see shortly.

Extreme Operations—9/11
A great deal has been written about emergency response in New York City during
the World Trade Center attacks of September 11. In the year following the attacks,
the New York Police Department (NYPD) and the Fire Department of New York
(FDNY) collaborated with McKinsey & Company, business and organizational
performance consultants, to produce reports on improving the agencies’
preparedness. Though the reports contain much information on response during
the incidents and detailed recommendations, we just want to touch on operational
communications aspects they addressed.
3 Part I: What Is Communications Interoperability?

At the time of the attacks, the NYPD was operating with a new radio system that
offered great capacity and resiliency over its previous systems. The police system
also was significantly more modern than the FDNY’s, which had been struggling to
implement a new one of its own.

According to McKinsey & Company, the police department’s radio infrastructure did
not fail on 9/11. Less than 15 percent of responding officers reported experiencing
“dead air” failures. On the other hand, radio traffic was “cluttered” early in the
incident. Fewer than half of the officers reported being able to clearly decipher traffic
early on.

One of six critical recommendations made to the NYPD focused on its radio
communications. It recommended adoption of radio procedures that optimized
information flow, producing a radio discipline that would minimize demand for
channels and provide a capability to push critical information ahead of other traffic.9

FDNY communications were affected directly by the attacks themselves. Overall,

their radio system was inadequate for the scale of the incident. McKinsey &
Company found that the department urgently needed to improve its communications
capabilities and ability to pass critical incident information. Information management
improvements were also noted as urgently needed, particularly in tracking responders
and patients.10

Important Conclusions
Two important conclusions can be drawn from these findings:
Conclusion #1: An agency’s internal operational capacity to receive, digest,
disseminate, and act on information can be overwhelmed, even if technically its
communications systems aren’t. Operability is directly affected by nontechnical pieces
of response systems that define, among other things, rules for moving information
around and what constitutes a manageable span of control. Technology can deliver
information overload as well as it can solve problems.
Conclusion #2: The great bulk of information sharing needs between first
responders—and thus communications capacity of one form or another—are
internal.

9
Improving NYPD Emergency Preparedness and Response, McKinsey & Company, August 19, 2002.
Available at http://www.nyc.gov/html/nypd/pdf/nypdemergency.pdf.
10
Increasing FDNY’s Preparedness, Executive Summary, McKinsey & Company, August 19, 2002.
Available at http://www.nyc.gov/html/fdny/html/mck_report/toc.shtml.
 Chapter 3: Operability—Job #1
39
Judging from these reports, communications operability was a greater
problem in New York City on 9/11 than interoperability. We believe this would
be true in most any jurisdiction under comparably taxing circumstances, mainly
because the agencies’ own management needs become critical as they struggle to
maintain a manageable span of control and accountability of responders.

National Incident Management System

Thankfully, national disasters of this magnitude are rare. Terrorist attacks and
weapons of mass destruction have captured the nation’s attention, but natural
disasters and large-scale emergencies like wildland fires and hazardous materials
incidents are more likely across the country. Communications operability and
Procedures for day­ interoperability needs have to be accommodated to support response to all scales
to-day interagency of emergencies.
operations are
usually well- Incident response systems have been built to meet the daily public safety demands, as
established. well as the more predictable emergencies. Incident management systems vary widely
across the country, but procedures for day-to-day interagency operations are usually
well-established because they’re used relatively often.

Similarly, planned events and task force operations, such as political

conventions or joint drug interdiction efforts, give incident command teams
the opportunity to build solid plans beforehand. This includes plans necessary
for interagency communications.

But when large-scale emergencies and disasters occur, response and communications
systems are stressed. Informal incident management systems dissolve.

The National Incident Management System (NIMS) was introduced in March

2004. It is first and foremost a common set of concepts, principles, terminology,
and technology to improve emergency response. It also provides standard resource,
organizational, and operational definitions. One of its components is an incident
command system familiar to many first responders across the country.

The NIMS Incident Command System (ICS) is built from 30 years of experience with
large-scale emergencies. Based on military models, early incident command systems
emerged in the public safety world through efforts of California firefighting and
emergency management agencies to deal with devastating wildfires. It broadened and
evolved over the years to serve emergencies and disasters of all types.

Two key ICS management characteristics are particularly notable when it comes to
communications interoperability. NIMS ICS is based on:
 0 Part I: What Is Communications Interoperability?

1. ­Common terminology covering organizational structures, operational

resources, and facilities. ­
2. ­Integrated communications, including development and use of a common
communications plan covering processes and technology.11

Common Terminology
Common terminology is clearly important in interagency communications since it’s
not much use to talk to your cooperating neighbors if you can’t understand them! But
the concept goes much further.

As mentioned earlier, lack of planning and coordination is a prime cause of

Interoperability is
built upon common
communications interoperability failures. Planning and coordination requires a
terminology. common language to articulate needs, describe processes, establish policies, craft
joint SOPs, and command resources during interagency operations. Interagency
communications SOPs are particularly unlikely without a means of describing the
“who, when, why, where, what, and how” of operations.

We deal with practical and important aspects of common terminology in Chapter 12,
Develop Policies and Procedures.

Integrated Communications
How we play at Under ICS, communications and incident action plans have to be integrated to
the occasional capture management goals and operational objectives. This notion of integration is
“big one” will be more than just lip service, too. Since responder safety and effectiveness are usually
determined mostly closely related to how well communications supports them, the capacity of the
by how we play at
communications systems to support operations is continuously taken into account
the frequent little
ones that occur in action planning. A separate communications unit is often established early in
every day in our multiagency and large-scale responses managed under ICS to support the integration
local place. effort. This is to bring all communications functions close to incident management,
— Fire Command rather than having them managed far from pressing operational considerations.
Chief Alan
Brunacini, Communications plans and technology can be used to reinforce the command
Phoenix (Arizona) structures and operating principles embodied in incident management systems.
Fire Department
Use of a NIMS-compliant incident command system is critical in large-scale response.
It can be equally important during smaller emergencies that provide the opportunity

11
National Incident Management System, U.S. Department of Homeland Security, March 2004.
Available at http://www.fema.gov/pdf/nims/nims_doc_full.pdf.
 Chapter 3: Operability—Job #1
1
to perfect response. Common terminologies and principles of communications
integration take root in routine response. They provide the building blocks of
interoperability through better operability.

Operational Building Blocks

Interoperability is built up from separately operable systems. It’s a defining quality
of a system of systems. For example, the modularity and scalability of modern
incident command systems mean they are useful from small incidents to large-scale
emergencies. Separate command teams can even be folded into one as incidents
merge. Components can be mixed and matched as demands ebb and flow. See Figure
3-2.

Communications systems meant to serve such command systems have to be equally

modular and scalable. Those capable of supporting an agency’s operations have to be
built to “plug and play” during multiagency responses, so it pays to build them with
NIMS principles in mind.

While operations come first, interoperations are inevitable. Building command and
communications systems for interoperability across jurisdictions and disciplines is
just good business.

Figure 3-2: Interoperability Built on Separately Operable Systems

Source: U.S. Department of Homeland Security, SAFECOM Program
 CHAPTEr 4
InTErOPErABIlITy In THE
InTEGrATED EnTErPrISE
 Chapter :
Interoperability in the
Integrated Enterprise
readers may Public safety services are provided across all levels of government, through local,
be interested tribal, state, and federal agencies. The vast majority of existing communications
in Chicago’s infrastructure for delivery of these systems, however, is owned by local and state
burgeoning
agencies—an ownership level estimated at more than 90 percent.12 Cities, towns,
enterprise
criminal justice and counties use their systems to provide essential police, fire, and EMS services at
information system. all hours of the day, every day of the year. For the most part, it seems that public
See Policing satisfaction with these services is good, but there is certainly the expectation that
Smarter Through agencies can work together when needed—in effect, that they’re interoperable.
IT: Lessons
in Enterprise To understand the demand for interoperability, we have to look at a picture
Implementation,
of emergency services greater than individual agencies and their separate
northwestern
University, U.S. responsibilities. In wrapping up our discussion of just what communications
Department of interoperability is, we want to describe the public safety enterprise, its complexity
Justice Office of across systems, and what integrating it entails. We’ll look at why information sharing
Community is at the heart of communications interoperability, how justice integration efforts
Oriented Policing laid a foundation for understanding needs, and the importance of stating functional
Services, 2004. and operational requirements to integrate systems. Your contribution to achieving
See
http://www.cops.
interoperability is our central focus, so we’ll conclude by looking at the role of
usdoj.gov/default. leadership in the integrated enterprise.
asp?Item=1331.
What is the “Enterprise”?
The term “enterprise” is more and more commonly used to describe government
An enterprise and individual agencies organized to deliver particular services. For example, we
is a collection speak of police, prosecution, courts, and corrections across local, tribal, state, and
of agencies or federal levels of government as the justice enterprise. Recognizing that each level of
organizations government and most of its branches are defined in law, it still has been useful to
created to provide look at justice agencies as a single entity dealing with a related set of services for a
related services to common constituency. Integration of services and technologies across the justice
a common set of
enterprise allows each agency to better serve its customers, while minimizing costly
customers.
redundancies and technological roadblocks.

12
U.S. Government Accountability Office, Homeland Security: Federal Leadership and
Intergovernmental Cooperation Required to Achieve First Responder Interoperable Communications, GAO-
04-740 (Washington, D.C.: July 2004) p. 8.
  Part I: What Is Communications Interoperability?

FACTS:

• Interoperability is achieved when services are delivered seamlessly across

organizational subdivisions and between jurisdictions.
• An enterprise view of public safety services—for example, across a city, county,
or metropolitan region—uses a citizen-centered, results-focused definition of
services provided to define, among other things, necessary interagency information
exchanges.
• With services and these interagency junction points defined, a technological
framework can be built that leverages existing investments and capabilities, reduces
redundancies, and establishes de facto standards for future systems.
• Both services and supporting systems have to be integrated for the public safety
enterprise to have communications interoperability.

A Complex System of Systems

Modern agencies have a staggering array of systems supporting their services. How
All the policies,
complex? Consider a typical call that’s handled thousands of times each day across the
procedures, skills, country: A landline telephone call reporting a motor vehicle accident with injuries.
and technologies
that go into The Call Arrives
delivering effective
From the 9-1-1 call, an automatic call distributor may first direct the connection
emergency
response need to to an open attendant position, providing automatic number identification (ANI)
come together at information from the call. In the background, call-logging recorders track the source,
that moment, at routing, and conversations. An instant playback recorder may begin to capture the
that spot. conversation for the operator’s subsequent use while an audio logging recorder
elsewhere makes a more permanent record. Where enhanced 9-1-1 (E9-1-1) is
available, the caller’s address is automatically retrieved and provided to the operator.
The call to the public safety answering point (PSAP) is then either dispatched by the
operator or transferred to a dispatcher across the room or perhaps even across town.
These acronyms
And that’s all before response is initiated. E9-1-1, ANI, ALI, PSAP, MSAG... there’s
and others are
defined in certainly no shortage of acronyms in the public safety communications business!
Appendix F. Wait, there’s more.

The Call is Dispatched

If the call-taker hasn’t already done so, the incident might automatically be queued
to a computer-aided dispatch (CAD) system at this point—or maybe even separate
CAD systems for fire medical and police response. The CAD system itself is a complex
 Chapter 4: Interoperability in the Integrated Enterprise

animal. From this point, it may interface through a general purpose console with
telephone, alarm, paging, voice radio, mobile data, and logging systems. It might be
fed mapping information in the background for geographic display of call source,
responder location, and street closure indications. For later use, it might feed incident
information to an agency’s records management system (RMS) or simply drive a run
card printer in a distant fire station.

First Responders Respond

From dispatch, let’s imagine that fire medical responders are alerted by a page
and police officers by a message sent wirelessly to the squad car’s mobile data
computer. Fire paramedics grab the run card, jump in their vehicle, and transmit
acknowledgment of the call over a voice radio system. By way of a couple of key
presses, the police officer acknowledges receipt of the alert and notifies dispatch of an
impending response with lights and siren. En route, automatic vehicle location (AVL)
systems in each unit transmit current location information to dispatch from a Global
Positioning System (GPS) receiver for display on a geographic information system
(GIS)-powered map in dispatch. On scene, the officer quickly transmits an arrival
status message and turns to a shared radio channel to direct paramedics in from an
alternate direction because the roadway is blocked by backed-up traffic.

Service is Delivered
Response is well underway, with a great deal of technology enabling it. A transporting
ambulance may have been dispatched by this point and street maintenance alerted
to divert traffic around the accident. Medical control may have been established
through a nearby hospital and its emergency room notified of the impending arrival
of patients. More systems are tied in. Eventually patients are delivered, cars towed,
accident and run reports filed, and responders returned to routine duties.

This complex system of emergency services is linked through an integrated

mesh of communications and information systems.

The hapless victims of our hypothetical accident don’t know—and probably don’t
care at the time—about all that goes into delivering emergency services to them. All
they know is that they need help. All the policies, procedures, skills, and technologies
that are involved in delivering effective emergency response need to come together at
that moment, and at that spot.
  Part I: What Is Communications Interoperability?

Enterprise Integration
This example provides a snapshot of the public safety enterprise. It shows the
complexity of technologies used to support emergency operations generally, and
interagency operations in particular. Information flowing across wired and wireless
networks, through computers and voice systems, allows interagency services to be
delivered seamlessly. It allows them to be integrated across the public safety enterprise.

Information is moved from place to place through different systems and modes of
sharing. For example, the location of this hypothetical incident most likely would
have initially been reported by voice over the telephone. Nearly simultaneously,
the call-taker received an idea of the general vicinity of the accident from the
caller’s location information retrieved digitally with the call. That street address
was displayed textually and later, perhaps, also graphically for the dispatcher. More
and more commonly these days, a precise location may have been automatically
transmitted wirelessly via satellite by one of the involved vehicles, and then relayed
via telephone to dispatch by a telematics operator, such as OnStar.® In our example,
the incident location was subsequently passed wirelessly to the field using both voice
and data.

Perhaps you have already faced the challenge of integrating systems to deliver
information so complexly. If so, you’re one step up on the broader challenge of
When providing communications interoperability. You understand that a lot more than
communications technology goes into making systems talk to one another. And if you’ve been
break down, who
responsible for connecting services across agencies, you probably already recognize
are you going to
call? 9-1-1?
that no amount of interoperable technology will bring responders together when
their operations are fragmented. All the king’s horses and all the king’s men can’t
make one response out of many if procedurally agencies aren’t “interoperational”
already. This, quite frankly, has nothing to do with technology.

How Did Communicating Get so Complicated?

Historically, communications interoperability has diminished as technology has
advanced. This might seem counterintuitive, but think about it. When there were
few choices for communications technology, the odds of any two agencies having
compatible technology were relatively high. Advancing technology, which brought
more communications choices, has come up against long radio system lifecycles
and widely varying needs. Agencies have built advanced radio systems to solve
serious coverage and capacity needs, inadvertently introducing new interoperability
challenges. In effect, our technological options have expanded, spotlighting the
“disintegrated” enterprise that previously had been able to hang together due to fewer
demands and greater technological homogeneity.
 Chapter 4: Interoperability in the Integrated Enterprise
9
As noted earlier, aging and incompatible equipment is just one of several challenges
to achieving interoperability. Suffice it here to say that a lot more than technology is
needed for success.

Recent events and disasters have highlighted greater needs for sharing information
and coordinating incident management across all emergency services. This requires
communications interoperability. Ultimately, an enterprise view of services integrated
across procedures and technology is necessary to satisfy these needs.

A Vision of Information Sharing

Information sharing is a measurable outcome of communications interoperability.
On a daily basis, critical information most often passes between first responders by
voice over radio. It can also originate from CAD, RMS, GIS, disaster management,
state motor vehicle, and other systems. From these systems, the information may be
transferred to the first responder wirelessly to a mobile computer system or it may
make the leap from mere data to true information through the time-proven radioed
voice of dispatch.

In the public sector, some of the greatest advancements in information sharing have
occurred through the U.S. Department of Justice’s Office of Justice Programs and
its Global Justice Information Sharing Initiative—generally referred to simply as
“Global.” The Global Advisory Committee (GAC) has served as an advisory body to
the U.S. Attorney General since 1998. Its mission is to support broad exchange of
justice information across jurisdictions and levels of government. It “seeks to improve
the administration of justice and protect the nation’s public by promoting practices
and technologies for the secure sharing of justice information.” 13

Since September 11, Global’s scope of advice has expanded to the broader public
safety enterprise. For example, the Global Justice XML Data Model14 has had a
significant impact on how CAD and RMS are being designed for information sharing.
Information-sharing concepts have evolved greatly through efforts to integrate justice
systems. Global has provided a simple vision of information sharing that is very
applicable to communications interoperability.

13
Global Justice Information Sharing Initiative Advisory Committee Charter, October 15, 2002.
14
For further information on the Global Justice XML Data Model, see the U.S. Department of
Justice, Office of Justice Programs web site at http://it.ojp.gov/jxdm/.
0 Part I: What Is Communications Interoperability?

Sample Vision Statement

Emergency responders can access the information they need to do their jobs,
at the time they need it, in a form that is useful, regardless of its location.15

Such a vision would be followed by more specific goals laying out how the project will
improve procedures and systems to ensure that the needed information is shared.
The Global Infrastructure/Standards Working Group has established requirements
for justice information sharing16 that are equally applicable to interoperable
communications systems:
• ­ The architecture must recognize innumerable independent agencies and
funding bodies from local, state, tribal, and federal governments. ­
• ­ Information sharing must occur across agencies that represent divergent
disciplines, branches of government, and operating assumptions. ­
• ­ The infrastructure must be able to accommodate an infinite range of scales,
from small operations with few participants in a rural county to national
processes that reach across local, state, tribal, federal, and even international
boundaries.
• ­Information sharing must occur among data sources that differ widely in
software, hardware, structure, and design. [And uniforms worn, we might add.
– Ed.]
• ­Public-sector technology investment must reflect and incorporate the lessons
and developments of the private sector.
• ­The infrastructure design must be dynamic, capable of evolving as the
information sharing requirements change and the technology is transformed.
These are worthy strategic goals for all communications interoperability projects.

Information Sharing Concepts: SOA What?

For such a simple term, “information sharing” can be a complex subject. Some of
the concepts and terms are simply too important to pass up, though. Notions of
communications interoperability are being influenced by lessons learned through
justice integration efforts, and familiarity with these ideas will help you understand
the “big picture.”

15
Adapted from A Framework for Justice Information Sharing: Service-Oriented Architecture (SOA),
Global Infrastructure/Standards Working Group, December 9, 2004. Available at
http://it.ojp.gov/documents/20041209_SOA_Report.pdf.
16
Ibid., pp. 2–7.
 Chapter 4: Interoperability in the Integrated Enterprise
1
For example, work conducted by SEARCH in recent years in the field of justice
information exchange modeling has produced a conceptual framework for
understanding the flow of information between agencies, a methodology for
analyzing and reengineering processes, and tools for modeling information
exchanges. Work is now underway using these means for characterizing, classifying,
and quantifying first responder interagency communications.17

One goal of the modeling methodology is to produce a reference model—a set of

exchanges common across most jurisdictions. This has been done for integrated
justice information systems, resulting in a significant savings in effort and cost for
subsequent users. Such a model can be customized by individual jurisdictions to
reflect their operations, as-is, and portray their systems to-be, requiring a fraction of
the effort needed to create one from scratch.

Common Terminology Aids Communication

Shared concepts and terminology have advanced the abilities of researchers and
practitioners, alike, to describe dimensions and modes of information exchange.18
In addressing functional components of integration, we now talk about query, push,
pull, publish, and subscription/notification modes of communications. In integrated
systems, queries make a specific request for information. Information is pushed
automatically to other systems following triggering events. Likewise, it may be
automatically pulled from others in anticipation of need. Information is published
for general authorized consumption as a proactive measure. A subscription/
notification process combines push and pull modes of information sharing on a
more ad hoc basis controlled by the eventual user.

The importance of these terms and concepts is not so much that they bring some
great revelation of how we might share information, but rather in providing a
common terminology useful for stating requirements in a standardized manner
through which a system of systems can be designed. For example, we may require that

17
SEARCH has undertaken two projects to develop information exchange package documentation
for tribal, law enforcement, and other first responders. These projects were funded by the COPS
Office under Cooperative Agreements #2002CKWXK006 and #2002CKWXK047. For a description,
see http://www.search.org/programs/info/xml-iep.asp.
18
Roberts, David J., Integration in the Context of Justice Information Systems: A Common Understanding
(Sacramento, Ca.: SEARCH, The National Consortium for Justice Information and Statistics,
updated 2004). Available at http://www.search.org/files/pdf/Integration.pdf.
 2 Part I: What Is Communications Interoperability?

stolen vehicle information is pushed to an officer whenever a traffic stop is made. That
tells a business process analyst or system designer that certain exchanges are required
without further, overt action by the officer. However the information is ultimately
provided—whether it is wrapped in standard operating procedures by voice from
dispatch or encoded in the rules of a mobile data system—is a subsequent matter of
design, and is probably influenced by additional requirements.

A final concept of growing importance in justice integration, as well as the larger

Service-oriented world of automation, is service-oriented architecture (SOA). Properly speaking, it is
architecture (SOA) simply a collection of services that communicate with one another. Most generally
is a collection used in the design of web-based information systems, SOA includes the concept that
of services that well-defined services are able to find and work with one another using standardized
communicate with
one another.
means of communications. For example, Wisconsin is already using an SOA-based
message switch to move information from different sources to and between law
enforcement agencies across the state. 19

SOA means a great deal more in the design of integrated systems than is addressed
here, but its influence on developing enterprise information systems is important.
Public safety information and communications systems will increasingly be built
upon SOA, as broader governmental systems are today. The integrated enterprise
increasingly relies on this architectural framework.

These accepted guiding principles of integrated justice information systems influence

our conception of what’s possible with communications interoperability:
• Information exchange modeling
• Functional components of integration
• Service-oriented architecture.

They can help us understand information sharing needs across a complex enterprise
to achieve interoperability.

19
See http://www.doj.state.wi.us/les/TIME/eTIME.htm.
 Chapter 4: Interoperability in the Integrated Enterprise
3
Stating Requirements for Information Sharing
Our success in creating communications interoperability is directly related to our
ability to describe operational requirements for interagency exchange of information.
Projects to improve interoperability may be well-guided from the start with a broad
vision statement, such as that presented above, but they have to develop operational and
When information functional requirements to yield communications systems that meet day-to-day needs.
sharing works, it is
Unfortunately, system procurement documents often focus on technical requirements
a powerful tool.
rather than operational needs, which limits proposed solutions and forces acceptance
—The 9/11
merely based on technological measures. ­
Commission report
(Page 419)
In seeking to improve interoperability, we talk about police department ‘A’
needing to talk to fire department ‘B’ or something similarly broad. Left with no
better description of the processes, events, conditions, and content of the needed
communications, system designers get a one-dimensional picture of what’s needed.
Interoperable systems design is driven much more by operational requirements when,
for example, the need is described as follows: ­

During a barricaded suspect operation, the police tactical team leader notifies the fire
interior attack crew leader that suppression efforts are needed within a secured portion
of the building.

It may seem obvious that the need would be satisfied by a common radio channel
or talkgroup readily available for a voice exchange between portable radios.
Our success
in creating That may be the most common way to carry the exchange today, but it may be
communications equally well accomplished by status and location data burst across a network
interoperability established just for the incident. Over-specification of how needs are met ends up
is directly related limiting options and is often used as a substitute for a clear statement of business
to our ability practices. The point is that the “how” should come long after operational and
to describe the functional requirements are established.
operational
requirements
for interagency It may also seem that describing interagency communications needs in such detail
exchange of could be painfully tedious. Frankly, it can be. Unfortunately, the likely alternative is
information. acquiring systems that are designed based on gross and largely unshared assumptions
of the “who, what, when, why, and how often” aspects of interoperability. If
procedures don’t exist to describe how police operations communicate a need for
help when a diversionary device ignites a fire, then the presence of the technological
capability to talk is unlikely to be used effectively.

Broad statements of need that lack functional and operational requirements

often result in technology project failures.
  Part I: What Is Communications Interoperability?

Efforts in information exchange modeling have shown that voice communications

are not as neatly describable as data exchanges. But because voice and data are so
intimately intertwined in the integrated enterprise, we’re called to do our best in
describing all types of exchanges so the boundaries between different modes of
communications are clear. As important, voice exchanges may prompt subsequent
data exchanges under certain conditions and vice versa. It’s important to recognize
these interactions—at least in operational procedures, if not also in technology.

The Good News on Stating Requirements

A good deal of work in recent years has been done to both define information sharing
requirements broadly, and to improve our understanding of them.

In March 2004, SAFECOM released a report establishing current and future

requirements for public safety wireless communications and interoperability. This
“Statement of Requirements” (SOR) established operational requirements for
police, fire, and EMS services, as well as their wireless communications functional
requirements. An updated version was released in January 2006.20

The SOR is a foundational document describing current and future requirements

Despite the to the year 2019. We’ll turn to it for more detail in Chapter 6, Conduct a Needs
problems that Analysis.
technology creates,
Americans’ love
affair with it leads Leadership Rules
them to also regard Integrating the enterprise for interoperability sounds daunting, doesn’t it? It can
it as the solution. be—and often is. The interoperability landscape is littered with a landfill’s worth of
But technology acronyms camouflaging a confusing jumble of bits, bytes, megahertz, and gamma
produces its best
results when an or­
rays. Agency managers looking at the challenge of integrating a larger enterprise for
ganization has the interoperability often exercise the first prerogative of management: Delegation!
doctrine, structure,
and incentives to It’s a mistake, however, to allow a fascination with technology to overrun the agency’s
exploit it. business headlights. Public safety practitioners have enough problems to deal with
— The 9/11 daily without technology adding new ones. Their collective job is to deliver solutions
Commission report to people in need, not carry a load of battery-powered problems along for the ride.
(Page 88)

20
U.S. Department of Homeland Security, SAFECOM Program, Statement of Requirements
for Public Safety Wireless Communications and Interoperability (Washington, D.C.: Version 1.1,
January 26, 2006). Available at http://www.safecomprogram.gov/SAFECOM/library/
technology/1258_statementof.htm.
 Chapter 4: Interoperability in the Integrated Enterprise

Corporations and other large organizations with clear visions of their missions
have long grappled with the problem of technology growing to be an end in itself.
They’ve established the roles of chief information officer (CIO) and chief technology
officer (CTO) as upper-management positions with responsibility for ensuring that
technology directly and measurably serves the mission. Those positions bear the
responsibility of understanding the business so well that no effort is wasted in putting
technology to work.

It’s rare in public safety to see the CIO or CTO role formally designated by name.
Whether so titled or not, the role of the chief officer responsible for information
technology, including the inseparable communications that make information
sharing possible, is simple. First, it is to be focused on the organization’s mission.
If that officer succumbs to the siren songs of technology wizards and vendors,
focus is lost.
Chapter 15,
Measuring If only you could spec, buy, and install a system that ran indefinitely with a minimum
Interoperability, of care and feeding, life would be simpler. Or at least work would be simpler. By their
delves into very nature, complex systems used for sharing information within and between public
performance safety agencies are increasingly evolutionary. That is, they grow, changing over time.
measures.
Understanding your needs is key to success.

TECH GUIDE
See the Big Picture
Chapter 4 of the Law Enforcement Tech Guide is devoted entirely to assessing current
ORIGINAL

67
business processes for all technology projects. In Chapter 6 of this Communications
s Interoperability Tech Guide, Conduct a Needs Analysis, we will provide tools
specifically targeted for planning communications interoperability projects.

If all this business about integration, enterprise, and architecture seems a bit
abstract when all you came to do was make sure your police, fire, and EMS
agencies can talk together—well, okay, it is a bit. But consider how complex these
systems can be, especially when you start lashing them together (see Figure 4-1 on
page 58). And consider that many big, well-funded projects have become lost in a
forest of technologies because the ultimate requirements were forgotten or never
even recorded.

Out of respect for our colleagues around the country, we’re not going to name
names—and we promise the same to you! Just don’t forget the big picture. In the
following chapters, we’ll get into just how this elephant can be eaten one piece at a
time . Step by step, interoperability can be achieved if it is built on a solid foundation.
 Part I: What Is Communications Interoperability?

Integrated Systems at Work in 2002 Wildfire Disaster

The devastating 2002 wildfire season in the

western United States included the largest
in Colorado history, a blaze that threatened
Denver suburbs and seriously damaged the
primary watershed providing its municipal
supply. The Hayman Fire* originated in the
mountains west of Colorado Springs near
lake George. It burned actively for 20 days,
involved 138,000 acres, burned 132 homes,
cost an estimated $28 million to suppress, and
an additional $13.3 million for rehabilitation Photo courtesy of netWest Communications Group, Inc.

of the burn area in efforts to save the critical Satellite links to the Internet enabled the
watershed. A U.S. Forest Service employee was wireless transfer of field and planning data.
implicated and later pled guilty to arson for starting the fire.

Geographic information systems (GIS) played an

important part in this emergency, as the technology
has in many wildland fires of recent years. managers
of these large and often dramatic incidents rely on
the graphic and analytic power of GIS for many facets
of their work, from pre-incident response planning
through initial and sustained attacks, and on to burn
area rehabilitation.

The Hayman Fire was large and threatening enough

to bring a well-equipped GIS crew in a camp trailer
that operated from 18 to 24 hours a day, every day for
more than 2 months. Two analysts typically worked
long hours collecting data from and distributing data
©2002 Kenneth Wyatt, www.wyattphoto.com to field units, the incident command team, and then
to outside cooperators who kept the public and key
A variety of cooperators were involved
in providing operational support to the external decision makers informed through web sites
Hayman Fire. and more traditional media. A great deal of time was

*note: The author of this Guide was lead GIS specialist for 2 weeks on the Hayman Fire.
 Chapter 4: Interoperability in the Integrated Enterprise


spent with more uncommon cooperators

in wildland fire response, such as arson
investigators, public water supply
authorities, wildlife management teams,
and burn area rehabilitation contractors.

The 2002 fire season may have been the

first to see bidirectional transfer of GIS
data wirelessly for continuous operational
purposes. According to Burn Area
Evaluation and rehabilitation (BAEr)
teams that worked the Hayman Fire, this
was the first time that information was
transferred back and forth on a daily
basis to contractors for management
of reseeding efforts. The fire severely
damaged Denver’s primary watershed,
putting it at great risk from post-fire
erosion sedimentation. Consequently, ©2002 Kenneth Wyatt, www.wyattphoto.com
scarification of the incinerated watershed A well-equipped GIS crew supported critical
and reseeding was critical. information sharing between field units, the
incident command team, and others.
Aerial reseeding is an intensive and
expensive process. The Hayman GIS trailer used its satellite link to the Internet to transfer field
and planning information wirelessly to contractors who were immediately able to incorporate
it into their own navigational systems for subsequent passes through the area. The power of
GIS analysis, combined with an ability to transmit large amounts of information wirelessly
over wideband links, allowed BAEr teams to communicate in intricate detail where they
needed different types of reseeding. This would not have been possible through traditional
means of information sharing from remote locations.
 Part I: What Is Communications Interoperability?

Cellular calls with/without automatic location information (ALI)

INCIDENT
Landline calls with automatic location information (ALI)

PAGING
SYSTEM
FIRE
PAGED
COMPUTER­
ALERT
AIDED REMOTE
DISPATCH RUN CARD
(CAD) PRINTING
SYSTEM
VOICE RADIO
SYSTEM
CALL-TAKING
SYSTEM CALL
REGIONAL, STATE, AND ACKNOWLEDGEMENT
NATIONAL INFORMATION
SYSTEMS

RESPONSE
ANOTHER VOICE RADIO COORDINATION
AGENCY SYSTEM
CAD

RECORDS MOBILE
MANAGEMENT DATA MDT
GEOGRAPHIC SYSTEM SYSTEM
INFORMATION (RMS) AUTOMATIC
SYSTEM VEHICLE LOCATION
(GIS) (AVL)

DATA DISPATCH
CRIME MAPPING
RECORDS QUERY
SYSTEM

Figure 4-1: Systems Galore

 Part II:
How is
Interoperability
Achieved?

If you have built castles in the air, your work

need not be lost; that is where they should
be. Now put the foundations under them.
— Henry David Thoreau
 CHAPTEr 5
BUIlD An InTErAGEnCy FOUnDATIOn
 Chapter :
Build an Interagency Foundation

What Communications interoperability projects and initiatives are like houses built for an
extended family. They have to be built on a solid foundation. Your foundation will
be poured in the form of a decision-making structure, project management, and a
charter for shaping partnerships.

As with building a home, the stability and longevity of your initiative depends on a
Why foundation of leadership, cooperation, management, and consensus, which must be
built from the start.

Who Agency executives and senior managers build these foundations. Only they can
provide the leadership necessary to articulate a vision and carry out the project. They
have the responsibility to set agency or jurisdiction goals and the authority to commit
human and financial resources.

When Immediately, before disaster strikes or money is spent to solve an ill-defined problem.
Delaying this strategic step endangers all other parts of the project.

Part II of this Guide is intended to provide a step-by-step process and tools for
your interoperability project. This and the following five chapters mirror parts of
the original Law Enforcement Tech Guide with a specific focus on the special, often
challenging, aspects of interagency communications projects. The final chapter
of Part II offers ideas and current best practices for measuring communications
interoperability that you will find useful in gauging progress toward making sure radio
is an enabling, rather than disabling, technology for public safety.

This chapter presumes you are starting or managing a communications

interoperability initiative focused on improving the delivery of your agency’s services
that entail cooperating with other agencies. Your project is probably part of or
influenced by larger interoperability initiatives—maybe within your own jurisdiction,
but very likely in nearby ones, elsewhere across the state, and even nationally.

Build your interoperability project foundation as follows:

• Establish a decision-making structure
• Hire or assign a project manager
• Develop a project charter.

We’ll deal with these step-by-step.

  Part II: How Is Interoperability Achieved?

He who has Projects to improve communications interoperability are fundamentally multiagency

not first laid his in nature. Before we get into these pieces of your project’s foundation one by one,
foundations may consider what’s at the heart of multiagency, regional projects.
be able with great
ability to lay them
afterwards, but The Heart of It: Partnerships, Planning, and
they will be laid
with trouble to More Partnerships
the architect and Consider the analogy of interoperability as the house your extended family chooses
danger to the to live in for everyone’s mutual benefit. Now, before that scares you off, consider that
building. economic or other necessities make this not only unavoidable, but desirable for all
—niccolo involved. If you were building that house, you would have to start with deciding how
machiavelli you are going to live with each other—setting rules of engagement, some might say.
Each party’s private space (jurisdiction, responsibilities) would have to be respected
and accommodated. Your common space (interoperations) would have to be carefully
planned to meet everyone’s needs to live together without dysfunction (without
disabling needed internal command, control, and communications).

Before this analogy causes you to run screaming away from your interoperability
project, think what a challenge building that house would be. Think about the
interagency communications challenges (and successes!) that you have today, how
hard it will be to improve interoperability without partnerships and some serious
planning, and the level of cooperation necessary to keep that household together long
after it’s built.
Interoperability is
co-operating.
Interoperability is the ability to work together. It is conducting effective joint
operations. It is co-operating.

Men often oppose Foundations 101: Decision-Making Structure

a thing merely The decision-making structure for your interoperability project provides leadership
because they have and accountability. It defines the joint business of agencies that unite in a project
had no agency
to improve communications between their operations. It ensures that the project is
in planning it, or
because it may
effectively managed, and meets identified goals in a timely and cost-effective manner.
have been planned
by those whom When you officially create a structure and announce it to internal and external
they dislike. stakeholders, you’ve drawn an organizational blueprint for building a house that is
—Alexander respectful of individual agencies’ roles and responsibilities, yet allows each agency the
Hamilton communications necessary for cooperation.
 Chapter 5: Build an Interagency Foundation


PROCESS – PROjECT – PROCESS

The term “governance” is sometimes used to describe a decision-making structure.
Most appropriately, governance is the body or organizational structure guiding a
larger interoperability process, as opposed to a specific project. For example, a
multijurisdictional region may have an overarching initiative to improve communications
interoperability. Or a state may have an interoperability executive committee (SIEC).
Within those processes, there may be multiple projects being undertaken by a variety of
involved partners.

We use the term “decision-making structure” here specifically for projects that have an
identifiable beginning and end. Governance bodies generally serve ongoing initiatives or
oversee management of multiagency systems after implementation.

Processes to improve interoperability lead to projects and back to processes for

managing underlying systems—organizational and technical —over their lifecycles. As
systems become long in the tooth, processes to improve them arise again.

Follow these six steps to create your project decision-making structure:

1. Identify Executive Sponsorship.
2. Identify Stakeholders.
3. Create the Structure.
4. Involve Other Subject Matter Experts.
5. Conduct Effective Meetings.
6. Decide on Project Staffing.

We’ll explain later in this chapter how to wrap up all the details of these steps into a
document—the project charter—to record everything for posterity and make it easy to
share these keys to success with others.

Step 1
Identify Executive Sponsorship
Start your project by identifying the top champion (or champions) for the initiative.
This person(s) defines what the project will achieve. You may be reading this Guide
because you will be that champion. Or you may be in a steering function for your own
agency, but know the project will need higher leadership to bring other agencies and
jurisdictions to the table. Or maybe you’ve already been assigned to manage the project
and recognize the importance of building this part of the foundation.
  Part II: How Is Interoperability Achieved?

Executive sponsorship is best provided by a single individual ultimately responsible

for services provided by core stakeholders. In many cases, that isn’t possible because
interoperability projects involve multiple agencies, by definition, and often span legal
jurisdictions. There either isn’t a single person with such responsibility or the project
has to go on without the active, ongoing support of the single individual in that role
(e.g., mayor, chief county executive, chair of a regional board).

Ideally, sponsorship is provided by three or fewer executives. The fewer, the better,
from the perspective of leadership and decision-making. With too many sponsors,
political factions are more likely to arise: city versus county, police versus fire, etc.
There’s always a risk of parochial decision-making, of course, but the more people
involved, the easier it is to duck responsibility for decisions. Accountability is key
for sponsorship.
Identify three or
fewer sponsors.
This begs the question of who, exactly, are the core stakeholders? There’s no
easy answer to that. You’ll have to make that decision. Remember this: There’s a
difference between sponsorship and the project’s Steering Committee, which
will have broader representation.

Find sponsors with sufficient stake in the outcome to be able to lead from a position
of authority, yet with the skill to draw others together. For example, we’re familiar
with one major city whose director of homeland security oversees both the police
and fire departments, has responsibility for emergency management, and has
considerable interest in EMS. This person is a strong and natural executive sponsor
for that city’s interoperability initiatives.

The executive sponsor’s key role is to communicate a vision. For communications

Executive sponsors interoperability, this vision paints a picture of what success looks like when radio
communicate seamlessly connects parts of an emergency response. For every project, there is a
vision. nugget, an acorn from which everything else grows. The sponsor’s main job is to
regularly impart a succinct vision of success to all stakeholders.

This vision is captured in the project charter. We’ll have more to say about the vision
statement of your project charter near the end of this chapter.
 Chapter 5: Build an Interagency Foundation


INTEROPERABILITY SUMMIT
In early may 2005, the U.S. Department of Justice (DOJ) convened a summit
on communications interoperability. representatives from major projects and
initiatives around the country came together for 2 days in Seattle to share
lessons learned. Through discussion and consensus, some best practices
were developed.

Sponsorship
3 Get the right project sponsors by showing the public policy and political
impact of problems to be solved.

(See http://www.cops.usdoj.gov/Default.asp?Item=1495.)

Step 2
Identify Stakeholders
The process of identifying executive sponsorship leads directly into the next step:
Identify stakeholders in this effort to improve interagency communications.
TECH GUIDE
The Law Enforcement Tech Guide provides a discussion of the internal and external
ORIGINAL

24
stakeholders common to technology projects of all sorts—law enforcement and
s otherwise. Take a look in that Guide for some you may not have thought of!

Your early efforts to identify stakeholders and consider their role in the project will pay
dividends long after switches are flipped to warm the airwaves. Some have a central role
in steering the project, some define critical requirements, and others decide whether
the initiative thrives or dies on the vine. This is your first step in figuring out how to
keep stakeholders informed and engaged from their respective realms of interest.

Typical stakeholders for communications interoperability projects:

• Field operations radio users
• Field operations command staff
Know thy
stakeholders. • Fire, police, and EMS chief executive officers
• Dispatch management
• Technical support staff
• Emergency management officials
• Elected officials
• Media
• Public.
  Part II: How Is Interoperability Achieved?

THE RELUCTANT STAKEHOLDER

All stakeholders are going to be equally enthusiastic about this initiative to
improve their interagency communications, right? Wrong. Most projects of any
We’ve heard size “enjoy” a range of buy-in across the wide variety of stakeholders discussed
from more here. From the comfortably noncommunicative to the incurably cynical to the
than one region painfully frugal, interoperability projects have their share of stakeholders who
where organized won’t wildly embrace change.
labor groups
were ignored as It’s a big mistake to proceed by simply labeling these folks, pigeonholing them, and
stakeholders—to stacking committees with cheerleaders. We see this most frequently where a “solution”
the great detriment arises before problems are well understood.
of the project. By
contrast, we’ve
also heard success
By bringing dissenters to the table, issues get aired and the group—as a whole— can
stories where labor make the commitment to move forward. Even those whose ideas or objections were
has been central in considered and decided against have to acknowledge that a deliberative, consensual
identifying needs process delivered the results. Often enough, these folks understand real challenges that
and managing need to be faced.
expectations—both
of which are A good project manager can use the art of facilitation to move stakeholders from simply
definite keys to reacting, to problem solving, and on to creative choices.
project success!

These last two groups are increasingly identified as stakeholders. The profile and
cost of radio projects, in general, has grown dramatically and public attention
Plan to to interoperability problems is at an all-time high since September 11. Critical
communicate with
the public and
media attention is increasingly drawn to costly public technology failures, further
media. influencing public perceptions. Less commonly recognized is growing opposition
to new radio towers. The first time you plan to erect a new one in a residential
neighborhood, you’ll learn about new stakeholders!

Including the media and public in plans to honestly communicate the project’s
If two men agree goals, successes, and even failures is important to any high-profile project. Consider
on everything, you
including representatives of each as ex officio members of your committees.
may be sure that
one of them is
doing the thinking.
—lyndon B.
Johnson
 Chapter 5: Build an Interagency Foundation
9
Step 3
Create the Structure
The time has come to formalize your project’s decision-making structure.
Doing so and making it widely known ensures all involved will know where
responsibility and authority falls. Leadership and accountability roles are made
clear, as are reporting roles.
TECH GUIDE
ORIGINAL

28
Figure 5-1 on page 70 is a typical structure for multiagency, multijurisdictional efforts.
s
The different elements are discussed in detail in the Law Enforcement Tech Guide, but
we’ll cover some twists common to communications interoperability projects.

With executive sponsorship in place, a Steering Committee can begin to take

form. Multiagency steering committees are like police interceptors or firefighting
Steering Committee helicopters: They are high-performance tools that can lead to trouble if misused. Like
missteps with any committee, the mix of members and their individual talents determine how well
vendors can be work proceeds. Members must have the authority to commit resources and the ability
costly—or worse. to work collaboratively. They must be strategic thinkers and comfortable managing
the work of others. Ideally, Steering Committee members are adept with large
procurements or can be made so through early committee work.

Project management is the next piece of your decision-making structure. It is such a

critical piece; we’ll talk about it in detail shortly.
TECH GUIDE
The final pieces depicted in the chart are two important working bodies—the User
ORIGINAL

29
Committee and the Technical Committee—and perhaps several topic-focused work
s groups that will be created to address particular tasks and dissolved when they’re no
longer needed.

The User (or operational) Committee is made up of stakeholders familiar with the
business and operations of the agencies they represent. Some of the most effective
Users know committee members are line supervisors and managers of field resources. A shift
best. sergeant or fire company commander is generally better in tune with intra- and
interagency radio communications needs of their organization than anyone else. In
some cases, individual officers, firefighters, and paramedics may have to translate
their own experience to broader operational needs.

The Technical Committee is charged with taking the project’s vision, folding in
operational needs, and analyzing the current technical environment. Potential
solutions may be examined to craft technical requirements for eventual procurement.
Here, most of all, “requirements tunnel vision” has to be avoided because it can easily
produce restrictive requirements that slip through into procurement documents,
leading to bid protests about foregone conclusions.
 0 Part II: How Is Interoperability Achieved?

We’ll discuss how to focus working committees and further flesh out their roles in
Avoid attention
Chapter 6, Conduct a Needs Analysis, and Chapter 7, Create a Project Plan.
creep!
A caveat: Remember that each element of the decision-making structure has its
own role, expertise, and responsibilities. Resist the idea that, for example, the
Steering Committee collectively knows more about operations and technology than
the working committees formed to address those issues. Use the decision-making
structure to delegate responsibility and concentrate each group’s attention on its
A classic sign of
own role.
attention creep
in radio projects
is technology
debates in the User ExECUTIVE SPONSORS
Committee—or Ultimate decision-making authority
worse yet, in
Provide leadership and accountability
the Steering
Committee. The
former body
should be focused STEERING COMMITTEE
on defining Provides leadership
the project’s Adopts a shared vision
operational and removes obstacles
business needs,
and the latter on
PROjECT MANAGER
executing a shared
vision, committing responsible for all project-related
tasks and deliverables
resources, and top-
down management. Directs working committees

USER COMMITTEE TECHNICAL COMMITTEE

Subject-matter/business process experts Communications and IT support staff of
line supervisors for field operations and participating agencies
dispatch

AD HOC AD HOC AD HOC AD HOC

WORKING GROUP WORKING GROUP WORKING GROUP WORKING GROUP
Focused on particular Focused on particular Focused on particular Focused on particular
tasks, e.g., tasks, e.g., tasks, e.g., tasks, e.g.,
standard operating identifying coverage documenting current mapping coverage
procedures, training needs, final acceptance radio environment needs, initial field
plans, exercises testing testing

Figure 5-1: Sample Decision-Making Structure

 Chapter 5: Build an Interagency Foundation
1

INTEROPERABILITY SUMMIT
More notes from the U.S. DOJ Interoperability Summit

Decision-Making Structure
3 Ensure committee members have authority to speak for their agencies.
3 Get buy-in from labor unions and ask them to recommend their own
representatives.
3 Manage competing stakeholder demands between larger and smaller agencies by
creating a balanced decision-making structure with documented conflict-resolution
processes.

Step 
Involve Other Subject Matter Experts
Outside subject matter experts can be involved in your decision-making structure at
several levels. Some ideas:
• Bring in organizational and strategic management experts early on to sit down
with your Steering Committee and get it started on the right foot.
• Ask representatives from outside projects or interoperability initiatives to
address steering and working committee meetings.
• Rely on legal and procurement expertise within your agencies or elsewhere in
government to keep your project out of trouble.
• Have incident management specialists work with your User Committee to
define interagency communications needs in terms consistent with the National
Incident Management System and its Incident Command System (ICS).
• Use technology experts to help your Technical Committee frame available
opportunities to use or extend existing infrastructure. ­

Consider the range of expertise that may be brought to bear on your project. You
may have to hire new staff in some areas, but will likely find internal staff nearby
Use free technical who are involved in related projects and available to assist with yours. For example,
assistance organizational and project management expertise might be available within
resources. your stakeholder agencies or others outside of the project, such as other units of
government. Help might also be available at no cost through federal assistance
programs for public safety agencies.
 2 Part II: How Is Interoperability Achieved?

Nationally, both the U.S. Departments of Justice and Homeland Security maintain
assistance programs that can be tapped at no cost. If your project will receive grant
funding, talk with your assigned grant specialist for guidance on assistance that may
be specifically available under the funding program.

Some of these programs bring peers together for training. Whether you’re in a
project sponsorship, management, or technical role, recognize that the opportunity
to network with your peers can be tremendously valuable. There are others who may
have faced and overcome challenges you’re up against right now. Some of the best
network
and least expensive subject-matter expertise available to your project can come from
with peers.
peers in other jurisdictions. Take advantage of this broad and inexpensive resource.
Consider asking them to address your committee meetings and share experiences.

Step 
Conduct Effective Meetings
TECH GUIDE Meetings are inevitable, so you might as well make them effective. “Fun” meetings are
something of an oxymoron, but there are ways to make them less dreadful. Food and
ORIGINAL

35
refreshments always work, as do pleasant surroundings with plenty of space and good
s acoustics so people don’t struggle or become uncomfortable while helping the project
move forward.

The key to good meetings is organization and brevity. People resent their time being
wasted and know intuitively when it’s happening. Consider using a trained meeting
Use a trained facilitator during initial group meetings to get them started on the right foot. If you’re
facilitator early on. the project manager, work carefully with the facilitator so he or she knows your goals,
process, and group dynamics. Observe carefully and learn what you can do to make
future meetings effective.

The Law Enforcement Tech Guide provides some great tips for keeping your project on
track by making the most of the inevitable meetings that most everyone dreads. These
are rules that can be used in projects of all types.

Step 
Decide on Project Staffing
TECH GUIDE The last step in establishing your project’s decision-making structure is one of the
toughest: Decide how the project will be staffed and where resources are going
ORIGINAL

37
to come from. Once again, the Law Enforcement Tech Guide provides most of
s what you need to know about staffing your technology project—whether it’s for
communications interoperability, voice or data, or even for technology far outside the
law enforcement business.
 Chapter 5: Build an Interagency Foundation
3
The bottom line is this: Don’t handicap your project—or worse—by ignoring
the fact that managing an interoperability project of most any size is a lot of
work! Multimillion-dollar communications projects are becoming increasingly
common. One large, populous western state is considering building a multiagency
communications system estimated to cost $5 billion. Project staffing for such a project
would be immense!

Consider this rule of thumb: Consulting services, including project management,

will commonly take 10 to 15 percent of a technology project’s budget. Consider both
how much organizational, process, and technical expertise you’ll need for this project
and how much you have at hand. If you have all the expertise internally that will be
needed, recognize that while you may not be spending that 10 to 15 percent, you will
be taking resources worth that much from elsewhere in the agencies.

Plan accordingly. Staff the project appropriately. Resist the temptation to save that 10
percent for more radios, sacrificing good management of all resources in the process.

Foundations 102: Project Management

Our discussion of project staffing leads to the next key ingredient of the project
“Management”
means, in the foundation mixture—project management.
last analysis, the
substitution of The choice is simple: You have to hire, assign, or train somebody to be the project
thought for brawn manager. If the project will cost more than a few hundred thousand dollars, your
and muscle, practical choices are reduced to hiring an existing, experienced project manager or
of knowledge assigning one from within participating agencies. Assign inexperienced staff in
for folklore and
larger projects at your own risk.
superstition, and
of cooperation for
force. . . No single person or function in a project has the potential to make or break success
—Peter F. Drucker like the project manager. Because this person is a single point of contact between
upper management, all work being done, and vendors, the project manager has
great responsibility. The best project managers have an uncommon combination
of business process, management, operations, procurement, and technical skills.
Combined with distinct project management skills, they have the uncanny ability to
assume temporary ownership of results, while delivering permanent ownership of
final products to stakeholders.

Good project managers make things happen, but don’t usurp the roles of others in the
decision-making structure.
TECH GUIDE
The project manager’s responsibilities, skills, and personal attributes are well
ORIGINAL

43
addressed in the Law Enforcement Tech Guide. Use that Guide as a practical
s tool regarding all the project manager’s responsibilities in a public safety
technology project.
  Part II: How Is Interoperability Achieved?

Smaller Communications interoperability projects may be some of the most difficult to

jurisdictions, as a manage. They are typically:
group, are slowest
to hire or assign • Large, expensive projects
full-time project • Inherently multiagency in nature, bringing inevitable conflict and compromise
management. While
• Critical to the delivery of core services affecting life and death
other technology
projects are often • Built using a variety of complex technologies
proportional to the • Involve civil construction and permitting
size of the agency,
radio projects • Require environmental, historical, and cultural assessments for sites
generally aren’t. • Completely dependent on federal licenses and permits for frequencies and
For example, a towers
computer-aided
dispatch system is • At risk of planned (and unplanned!) obsolescence.
simpler for a small
agency than larger If you’re in an executive sponsorship or steering role, do yourself a favor and
ones, requiring hire or assign someone full-time to manage the project if it’s much more than
less project an effort costing a few hundred thousand dollars. Don’t make the mistake of
management. radio
figuring that project management is a sideline job for someone with other
projects, on the
other hand, are
responsibilities. That’s a sure road to failure. A full-time assignment will get the
generally large and job done better and faster.
expensive—even
for smaller
jurisdictions. For Foundations 103: Project Charter
specific guidance Okay! You have lined up the designers, architects, foreman, and eventual occupants
on small and of this house for an extended, interoperable family. Now it’s time to create an
rural agencies, architectural drawing of what it will look like.
you may want to
refer to the Law The project charter is the single most important document you can create for your
Enforcement Tech
interoperability project. It is a written document presenting a vision of what is to
Guide for Small
and Rural Police be accomplished, defining scope, goals, and objectives. It includes a description of
Agencies (http:// the decision-making structure to be used, project management approach, and initial
www.cops.usdoj. resource requirements. Plan to distribute it widely after approval by the project’s
gov/mime/open. executive sponsors and have it used by all members of the project. Typically, it’s put
pdf?Item=1619). together by the project manager and Steering Committee with input from working
committees, if they’ve been formed.
TECH GUIDE
The Law Enforcement Tech Guide covers development of a charter in detail. We’re not
ORIGINAL

51
going to re-create that wheel here, but we do want to touch on a couple of high points,
s with special applicability to interagency and communications projects.
 Chapter 5: Build an Interagency Foundation

The Law Enforcement Tech Guide provides a 12-step program for creating the charter.
The steps are:
1. Write the Vision Statement.
2. Give the Project a Name.
3. Get the Big Picture, Conduct an Environmental Scan.
4. Build the Business Case.
5. Include Background or Historical Information, if Relevant.
6. Establish the Project Scope.
7. Establish Preliminary Project Objectives.
8. Note Major Project Assumptions and Constraints.
9. Develop Initial Timelines and Preliminary Budget.
10. Include Project Planning Methodology.
11. Provide Project Team Organizational Chart and Membership Roster.
12. Sign, Seal, and Deliver.
Interoperability
is all about The vision statement may be crafted entirely from scratch, or it may be provided to
relationships and the Steering Committee by the executive sponsors or even by some larger planning
working toward a process outside this project. For example, the vision may come from a homeland
common vision. security or technology strategic plan describing the need for the project. It may come
Perhaps the first from legislation, decree, or interoperability coordination bodies at the regional or
step in ‘breaking state level.
the ice’ might be
to collectively
develop a catchy Adoption of a project name is an opportunity to develop some teamwork within the
acronym, such Steering Committee. A simple, descriptive name provides an easy way to identify the
as DIRT (Disaster initiative. This provides a “brand” inside and outside the project. Some have even had
Interoperable a bit of fun with it.
Response Techno­
communications). The environment scan is a process more unfamiliar in name than practice to folks
—Chief Charles outside of the project management business. We’ve touched on the fact that your
Werner project is probably affected by others going on in nearby jurisdictions. Your project
Charlottesville
will be planned and executed in context with other technology, interoperability,
(virginia)
Fire Department management, and operational changes taking place around you. For example, your
jurisdiction may have a related project underway to build a microwave backbone to
carry all forms of information for agencies, including audio and control signaling for
radio systems. You should be aware of that initiative in your own initial planning.
Plan in
context. Building the business case is often difficult for public safety practitioners
unaccustomed to marketing ideas and products. It’s easy to describe the need for new
technology in dire terms of apocalyptic proportions. Or conversely, to promise World
  Part II: How Is Interoperability Achieved?

Peace and Eternal Harmony among police, fire, and EMS agencies. That sounds a lot
Explain the
operational benefits more like a charity pitch than a business case. Resist if you find yourself writing, “If
to be achieved in it saves one life, it’s worth the millions of dollars.” While a worthy sentiment, such
specific terms. hyperbole doesn’t help explain why this project and that amount of money will make
a difference.

Explain the operational benefits to be achieved in specific terms. For example, “A new
shared radio system will support consolidated incident action planning necessary
during events involving six or more police, fire, and EMS units, as well as avoid
estimated replacement costs of $13 million for each of the three separate radio
systems over the next 5 years.”

Relevant background or historical information is easy to find for most

communications projects since radios have been used by generations of responders.
There’s usually good background on how the involved agencies ended up with the
systems they currently have and how interoperability problems arose. Remember
that the goal in this portion of the project charter is to explain how this project came
about.

In creating the charter, the team has its first opportunity to establish the project
scope. It’s fairly general at this point, but should clearly define what’s in and what’s
Scope: out of the project. For radio systems, relevant factors to describe are involved
What’s in, what’s agencies, whether the project replaces existing capabilities and/or provides new ones,
out? and the geographic area to be affected. We’ll have more to say on scope planning in
Chapter 7, Create a Project Plan.

Project objectives have to be specific and measurable, so take time with the Steering
Committee and User Committee, if it’s in place, to identify key objectives that can be
Focus on quantified and measured for completion. As with the business case, remember these
operational
are being written with others in mind—both internal and external stakeholders. Since
outcomes, not
technology. you’re planning to improve communications interoperability, take time to describe
the “who, when, where, and what” of new interagency capabilities. Be specific. Focus
on operational outcomes—not technology. For example, “Provide all police officers
across the county with a communications channel that is immediately available for
coordinating pursuits at all times.” There are many ways to meet this objective, but
the “how” is left for later determination.

Project assumptions and constraints should be documented to explicitly note

for all team members and stakeholders what is expected, not only of them, but
conditions under which the project may have to take one turn or another. This is an
important part of your charter because it captures conditions participants tend to
forget—but which shaped the project. For example, if the project is to create different
degrees of interoperability over time or between different partners in phases based
 Chapter 5: Build an Interagency Foundation

on available funding, do the best you can to identify priorities and contingencies.
Similarly, your project may move faster, slower, or not at all based on continued
funding under special revenue programs. This section is the best place to state
assumed contributions by cooperating agencies to ongoing systems operations and
maintenance.

Everyone wants Initial timelines and preliminary budgets are specific, central assumptions and
to know how long constraints placed on the project. Unlike the preceding section, these may be mainly a
it’s going to take matter of choice between participants. Take the opportunity to put a stake in the sand
and how much it’s to describe these key components of project management.
going to cost.

Your project planning methodology may still be in development as the charter is

developed, but include plans for steps that will be taken along the way to improving
interagency communications through this project. How will needs be assessed?
How will progress be communicated to stakeholders? When will a project plan be
developed? Large and costly interoperability projects will likely require outside
expertise in one or more steps along the way. What will be done internally and what
will be outsourced?

The project organizational chart and roster find their first formal home in this
document. Accept that they will change over time and commit to keeping this portion
of the charter up-to-date.

The final step is to sign, seal, and deliver the charter. Typically, sponsors and
Steering Committee members sign the charter. Don’t be shy about distributing the
finished charter to stakeholders everywhere.

Footings on Bedrock
Follow these steps and your interagency project will have a foundation with footings
on bedrock. You’ll have a decision-making structure that reinforces roles and
responsibilities while accommodating the variety of needs brought to the table. Your
A good home project manager—maybe you—will have the necessary room to work and resources
must be made, not
to accomplish this most important task. A project charter captures all these initial
bought.
operating details and much more.
—Joyce maynard

Altogether, this foundation will provide much more than just the basis for a successful
project: It may be the foundation for better interagency communications well beyond.

The extended family may not be ready to move in yet, but you know they’re coming!
 CHAPTEr 6
COnDUCT A nEEDS AnAlySIS
 Chapter :
Conduct a Needs Analysis

What A needs analysis is the organized process of collecting information on what’s

happening today, the technological environment in which it happens, supported and
unsupported needs, and generally what’s required of an interoperable system.

Why Since communications interoperability is achieved through a system of systems—

both technological and operational—needs are many and varied. Project success
pivots on meeting well understood and defined needs. Needs analysis feeds
acquisition, implementation, maintenance, and most other system development
efforts.

Who The project manager is primarily responsible for needs analysis. The User and
Technical Committees define operational needs and the current technological
environment.

As soon as a decision-making structure and a charter are in place, but before

When preconceived, often competing, notions of solutions start to build fan clubs. Needs
analysis can proceed in parallel with creation of a project plan.

Needs analysis provides the means to link measurable outcomes to

the use of technology. It combines a structured process to define
TECH GUIDE
operational requirements with an interactive one to build stakeholder
ORIGINAL

involvement. The products of this phase of your project prove their

s value in operational terms.

Chapters 4 through 7 of the Law Enforcement Tech Guide deal with needs
analysis for technology projects in general.
 2 Part II: How Is Interoperability Achieved?

Your project to improve communications interoperability is well underway. It

has the necessary foundation for decision-making and stakeholder ownership.
It has the project management in place that’s needed to keep efforts focused.
And it has a semi-formal agreement—the charter—to assure a clear strategy for
what is to be accomplished. The next step is to delve into the details of what
your project will accomplish.

Public safety agencies don’t need radios. They need the operational capabilities
generally and historically supported through wireless communications. This might
seem like a play on words, but too often a focus on the means of meeting a functional
need puts requirements, themselves, out of focus. This is a common pitfall in using
technology of all sorts, not just radio.

The need for interoperability is widely recognized today. Unfortunately, once past the
sound bites and impassioned speeches, agency leaders are left with the more difficult
task of coming up with more than just interoper-ability: They need interoperations.

needs analysis Since emergency response is the business of public safety, the business case for
details what has to interoperability today describes why police, fire, EMS, and other agencies have to
be accomplished communicate with one another and what the “costs” are when it’s done poorly. A
to achieve needs analysis details what is necessary to meet the project charter’s business case. It
interoperability.
describes exactly what has to be accomplished for interoperability to be achieved.

Conduct your interoperability needs analysis as follows:

• Assess current business processes
• Determine stakeholder needs
• Develop operational requirements
• Evaluate build-versus-buy options.

Development and design of shared systems follow the same

interagency processes described here, though necessarily with
more time spent in understanding each agency’s internal processes,
collecting their needs, and finding common requirements. User and
technical committees for such development efforts should use ad hoc
work groups from each participating agency to develop requirements that can be rolled
up for systemwide needs analysis.

Whether your project is simply to improve interoperability among users of existing

systems or to build a broad, new shared system, understanding communications needs
between agencies requires the specially focused efforts detailed here.
 Chapter 6: Conduct a Needs Analysis
3
It is impossible to
design a system so
Needs Analysis 101:
perfect that no one Assess Current Business Processes
needs to be good. Needs analysis begins with an assessment of current business processes. Often we
—T.S. Eliot work together, but have no formal statements of how that will happen in detail
sufficient to plan complex systems. Complexity is managed by breaking the problem
down into small pieces (Figure 6-1). This is how a business process assessment is done.

Working committees are key to completing a good assessment. Both User and
Technical Committees have reams of information to provide from their respective
perspectives that has to be captured. The results of their work feed the next phases of
Working needs analysis—and the project well beyond.
committees are
key to a good
assessment. Keep the committees focused on their roles. The User Committee represents
operational expertise. It must define the business processes that make interoperability
so critical. Don’t let it stray into the realm of technology—the Technical Committee’s
specific area of expertise. Resist the temptation to see interoperability as primarily
a technical problem; it isn’t. The User Committee must have ownership of the
operational needs and requirements for interoperability.

Your business process assessment will be an iterative process. That is, draft reports
will generate further important information that should be incorporated. Not only
will new bits of information arise step by step, but mistakes will be discovered that
need to be corrected. Conduct the assessment accordingly, keeping draft reports,
diagrams, charts, and maps in front of the project decision-making structure for the
very purpose of getting details accurate and complete.

Assess
Interoperability
Baseline

Draft Business Create Finalize Business

Process Baseline Technology Process Baseline
Report Baseline Report Report

Fix
Obvious
Problems!
Figure 6-1: Business Process Assessment Steps
  Part II: How Is Interoperability Achieved?

Step 0
Assess the Interoperability Baseline
As the project manager, you can get started with real needs analysis by assessing the
existing state of interoperability among project partners. This interoperability baseline
assessment provides a snapshot for future comparison. It’s an entirely optional step
that can serve as a useful tool to start subsequent conversations.

Chapter 15, Measuring Interoperability, describes a method for conducting an

interoperability baseline assessment. Read and follow the process described there if
you choose to kick off your needs analysis with one. It shouldn’t take more than an
hour or two to complete, at the most. The objective is not to conduct a scientific study,
Use a stake in
the sand to draw but to have a stake in the sand to draw feedback about the state of interoperability in
feedback. your project area. The assessment can be used with the Steering Committee and all
working committees to frame issues, elicit feedback, and achieve some consensus on
challenges faced.

For diplomatic purposes, assess interoperability up to the start of this project;

measures of leadership and governance of your current project, among other things,
are yet to be proven!

Step 1
Define Interagency Business Processes
The first formal step in analyzing needs is to define regular, authorized, planned,
or otherwise existing interagency response processes that are already in place.
Start by collecting interagency standard operating procedures (SOP) that describe
how partners plan to or already work together. These describe interagency
business processes.

With existing SOPs in hand, it’s time to convene the User Committee and have it
define processes requiring communications between agencies. If interagency SOP
pickings are slim, the User Committee may be the only place you’ll find out just what
interoperations are currently being enabled by communications. We’ll talk about
techniques for collecting stakeholder needs shortly. Some detective work may be
necessary to discover business processes that must be supported by current and future
communications systems—particularly undocumented ones.

For example, there may be a general, but unwritten, practice that police units respond
Unwritten business to structure fires of a certain size for traffic control. Or, quick response units from two
processes are jurisdictions are automatically dispatched to injury accidents on a bridge spanning
important to
them. These are interagency processes, perhaps coordinated through a mutual
document.
dispatch channel or common tactical talkgroup.
 Chapter 6: Conduct a Needs Analysis

Even if unofficial, existing business processes must be documented.

n Product: A Draft Business Process Baseline Report

Business processes are documented in a report describing the “who, what, when, why,
where, and how much” of interagency communications. This describes work that
agencies do together. It’s the “as-is” of your business processes. Leave the “how” for
the next report on the technical environment.

Make special note of physical, electronic, and procedural security processes.

Increasing threats and technological complexity call for attention to the security of
communications resources, as well as to information exchanged through them.

The project manager is responsible for producing this report. Plan to release one or
more complete drafts and distribute across all stakeholders. Seeing conversations
rolled up into a summary report intended to describe all relevant business
Use diagrams to
processes will certainly produce comments and corrections. It’s important to have
make work models
clear. a draft report complete enough to be readable and understandable, but make sure
everyone knows it is a draft. Emphasize that this is an iterative process and feedback
will be incorporated.

Use diagrams to make work processes more understandable. They are key to depicting
work. Two types of diagrams are particularly useful:
TECH GUIDE
ORIGINAL

69 • Sequence work models show processes, subprocesses, and activities. The Law
Enforcement Tech Guide uses sequence work models for report filing and suspect
s
booking processes.
• Flow work models show information flows from person to person, organization
TECH GUIDE
to organization, or function to function. For example, the Law Enforcement
ORIGINAL

71 Tech Guide uses such a model to depict information flowing from dispatch to a
sergeant and on to several officers.
s

Not only do these work models graphically depict business processes for needs
analysis, they will be useful later in your project for describing functional
requirements, creating acceptance tests, developing training and exercises, and for
assessing the effects of system outages. Design, implementation, operations, and
maintenance stages of your project all benefit from accurate assessment and depiction
of work models.
 Part II: How Is Interoperability Achieved?

Step 2
Define the Current Technology Environment
Draft business process materials will be useful in the next step: Defining the technical
radio communications environment that enables interagency work. Typically, the
Technical Committee is charged with collecting the variety of information about
technology currently in use. The project manager is again responsible for collecting
the information and presenting it in a form suitable for distribution.

Information collected may include the following:

• A matrix showing existing means of interagency communications. List all
agencies on both the side and top, with each cell indicating how communications
occur. Use the five Interoperability Continuum technology categories to characterize
how communications between each pairing of agencies occurs today. The
standard categorized approaches are: Swapped Radios, Gateway, Shared Channel,
Proprietary or Standards-based Shared System.
• General descriptions of radio systems in use by jurisdiction and agency for both
voice and data. As a hypothetical example:
“Northland County uses an 800 MHz trunked radio system for all police, fire, and
EMS voice communications. Information from a common mobile data system is
carried by commercial services from Horizon Wireless.”
• An inventory of responder radio equipment owned by participating agencies.
This information can be detailed. Summarize it in reports, but put details such
as make, model, and frequency band into appendixes that can be referenced
when needed.
• An inventory of supporting infrastructure, including the following:
— Detailed descriptions of radio systems in use listed by jurisdiction and
agency, for both voice and data
— Caches of radios to be swapped between agencies
— Gateways that connect voice radio audio or mobile data switches
— Shared channels (frequencies)
— Established interagency talkgroups
— Radio sites (location, ownership, size, current occupants, available space,
primary and backup power, receive and transmit frequencies in use, etc.)
— Physical and electronic security measures
— Wired and wireless backbone interconnecting parts of various systems,
with particular emphasis on parts shared between agencies
— Commercial services (vendor, capabilities, cost, availability by area)
 Chapter 6: Conduct a Needs Analysis

— Radio coverage (footprints of existing systems)
— Technician services either available internally or contracted.

This collection of information is not only important for your needs analysis, but
also will be invaluable in the likely event that your project leads to procurement of
additional technology.

n Product: A Technology Baseline Report

The technology baseline report is produced by the project manager through heavy
contributions from the Technical Committee. It’s important to capture all the detail
described above, yet present it in summary at the front of the report.

Remember that “how” questions can be answered in varying levels of detail. Provide
Simple explanations the simplest one first. Again, use diagrams and charts to make information more
of “how” are understandable. Because of the geographic nature of radio systems, maps are an
indispensable. effective means of getting much of this information across, too.

Step 3
Fix the (Newly) Obvious Problems
As mentioned, developing a better understanding of business processes often
Take advantage
suggests immediate fixes that could be made. They may be fixes to processes and
of quick fixes for
momentum.
procedures or simply to use some existing technology more fully. Take advantage of
these opportunities for improvement, but keep up the momentum with your needs
analysis. Properly done, quick fixes can actually help generate enthusiasm for the
next steps.

More often than not, multiple stakeholders will have an interest in even these
relatively painless quick fixes. Be sure to include them in a discussion of
recommendations. If the Steering Committee expects to approve such changes,
be prepared when presenting recommendations to request and justify resources
necessary to make the changes.

Typical quick-fix examples we’ve seen include changes to dispatch procedures to

announce staging area channels during multiagency incidents, new automatic
aid agreements or formalization of existing practices, and consolidation of radio
system components in shared sites. For the sake of progress, avoid changes that
will take more than a week or two to implement, however. Carefully evaluate what
constitutes a quick fix, leaving anything more involved for inclusion in your functional
requirements and the formal project plan.
  Part II: How Is Interoperability Achieved?

Upon completion of these quick fixes, initiate the practice of celebrating milestones
along your path to communications interoperability. This is a great time to start a
habit of taking advantage of visible steps of progress. A small ceremony of thanks to
key participants and even press releases to claim your project’s success more publicly
are good moves that help to boost morale and build momentum.

Step 
Describe How Current Technology Is Used to
Accomplish Work
With the technology baseline in hand and quick fixes complete, the business process
baseline can now be finalized. Get the Technical Committee’s assistance to take
descriptions of interagency processes and add simple “how” statements. For example:
“Midland City FD and Stillwater RFD have an automatic aid agreement for structure
fires in the Norwalk Subdivision. This typically requires one channel of common
communications for command coordination and another between the command post and
staging areas. VHF-high band shared channels are used directly between responders.”
“Midland City PD and State Highway Patrol units are jointly dispatched to injury
accidents on I-5 within the city limits. The PD uses a dedicated channel on its UHF
conventional system to talk to SHP on its Division 1 operations channel—a 150 MHz
conventional repeater—connected by a permanent gateway operated by the city.”

n Product: A Final Business Process Baseline Report

Complete your assessment of current business processes by finalizing the baseline
report. This report captures both operational processes and details of the
technologies currently supporting them. If you completed one, the interoperability
baseline assessment should be included, along with any adjustments due to feedback
received along the way.
This is your as-is
report.
This as-is report is very important for needs analysis. As the title states, it is the
baseline describing what you have today in the way of interagency operations and
how radio communications support them. It’s not uncommon in this process to run
across immediate changes that could be made to improve operations. Take advantage
of these opportunities by including them as recommendations in the final baseline
report.

Depending on your governance structure, the Steering Committee may wish to review
the report before adopting it as final. It’s great to have that level of support, but make
sure to take into account the added time needed for review, changes, and approval
when creating the project plan.
 Chapter 6: Conduct a Needs Analysis
9
Needs Analysis 102:
Determine Stakeholder Needs
You have the as-is. Now you can move on to the to-be. Project buy-in hinges on how
well stakeholder needs are determined. The project manager guides this process,
A human being has meeting with stakeholders at all levels, across all agencies.
a natural desire
to have more of a
Start the process of collecting needs shortly after documenting business processes
good thing than he
needs. and the technology environment. This takes advantage of any momentum created
and captures ideas that arose in discussing things the way they are.
—mark Twain

While baseline assessments can be conducted relatively quickly through efforts of the
working committees, collecting information on stakeholder needs requires that time
be spent with a lot more people across essentially all agencies—and probably among
various groups within each.

The Goals
There are several goals to be achieved in collecting stakeholder needs. The obvious
Goal #1:
one is to obtain a better understanding of interagency communications needs. Often
Capture operational these needs are camouflaged behind ideas about how best to resolve them. While the
needs. solution to a given problem may revolve around new or innovative uses of technology,
technology isn’t ever the need. Work to capture the interagency operational needs to
assure success and the ability to accurately recognize those needs.

A secondary, but equally important, goal is to open organizational and management

lines of communications about needs. Often these needs aren’t new and have had
some time to “mature.”

Can we talk? Many interoperability problems masquerade as technical problems

when in reality they’re organizational or management dysfunctions—or originated
Goal #2:
there and now really are technical problems. More than one agency has built a
Open lines of
communications. new radio system without regard to compatibility with neighbors. They reduced
interoperability by introducing incompatible technology, not seeing a need for
interagency communications at the time.

The fact that your project is progressing proves agencies are willing to move beyond
organizational dysfunctions, if they ever existed. The best way to pave over those
potholes is to focus on the operational or functional needs of participating agencies.
Get input not only on how they can communicate better with partners, but also how
organizational change will flow from better interagency communications.
90 Part II: How Is Interoperability Achieved?

Goal #3: The final goal is to get all stakeholders involved in the process and invested in creating
Get invested solutions. This occurs when they’re involved in defining requirements and recognize
stakeholders.
that the outcomes will address their operational needs.

Techniques
As we’re alluding to, the project manager or other facilitator’s challenge in collecting
needs often amounts to digging through surface layers to reach underlying needs.
It’s really not all that hard to do. What’s tough is doing it without losing stakeholder
confidence and buy-in along the way! The project manager’s communications skills—
and we don’t mean radio—are going to make or break this share of the project.

Objectivity is one of the project manager’s sharpest tools at this point. It yields the
credibility necessary to elicit honest statements of need and facilitate discussion. If
you’re in that role, recognize that your preconceived notions will be picked up far
away. Guard your credibility by remaining objective!

n Be Prepared: Collect Artifacts

Before going to stakeholders to solicit the needs that will shape your interoperability
project, search for materials from the involved jurisdictions that may already
document what those needs are. Several likely sources may turn up artifacts
establishing de facto requirements, stating unmet needs, or otherwise exposing
interoperability holes. Formal or anecdotal, these artifacts are invaluable in exposing
stakeholder needs.

The business process baseline often highlights a number of these and commonly
draws attention to neglected or unnecessary ones. Other likely sources include the
following:
• ­ Existing strategic plans, both business and technology, establishing
requirements that agencies have to meet ­
• ­ Debriefings and after-action reports on incidents, particularly multiagency
incidents
• ­ Evaluations of tabletop and full-scale exercises.

Make written or mental notes of needs and requirements apparent in these sources
that otherwise may not surface during interviews or focus groups. Use them to elicit
discussion, perhaps validating or tempering issues raised.
 Chapter 6: Conduct a Needs Analysis
91
n Be Prepared: Collect Scenarios
Emergency response scenarios used in planning, training, and exercises provide a
ready-made source of examples that can be presented during interviews and focus
group sessions. With any luck, agencies involved in your project already regularly
conduct multijurisdictional exercises. Those scenarios can be tapped. Emergency
management officials can provide other suitable ones.

Other good sources include the SAFECOM Statement of Requirements21 and the
Department of Homeland Security’s National Planning Scenarios. Both are rich
sources of examples of everything from natural disasters to improvised nuclear
devices. Check with your local or state emergency management offices for details of
the National Planning Scenarios.

A ready supply of scenarios provides fertile ground for eliciting needs while talking
with stakeholders.

n Conduct Interviews and Focus Groups

Once prepared with background, you’re ready for direct interviews and focus group
sessions with stakeholders to uncover needs related to project goals. Interview and
facilitation skills can be learned, but they require practice. If this is your first project,
you’re definitely jumping in feet first!
TECH GUIDE
ORIGINAL

79 Interagency projects generally bring more stakeholders, many of whom should be

interviewed or involved in focus groups for collecting needs. Whether this is your
s
first project or you’re a veteran, read Chapter 5 of the Law Enforcement Tech Guide. It
provides a wealth of information on interview and focus group techniques. You’re
bound to pick up a few pointers!

n The Product
By the completion of interviews, the needs analysis process will have produced an
abundance of information. This Guide has concentrated heavily on data collection
so far; next, we’ll turn to distilling all that has been collected into general system
requirements to be included in design documents.

21
U.S. Department of Homeland Security, SAFECOM Program, Statement of Requirements for Public
Safety Wireless Communications and Interoperability (Washington, D.C.: Version 1.1, January 26,
2006). Available at http://www.safecomprogram.gov/SAFECOM/library/technology/1258_
statementof.htm.
 92 Part II: How Is Interoperability Achieved?

Life was simple

Needs Analysis 103:
before World War
II. After that, we
Develop General System Requirements
Business process baseline development, stakeholder interviews, and focus groups
had systems.
yield three kinds of needs: organizational, operational, and technical. Each will
—Admiral Grace
develop into requirements separately. Some will naturally be used for procuring
Hopper
technology to improve interoperability; others will be acted upon by the agencies
themselves, individually or collectively.

For a complex system of interoperable systems, requirements will span agencies,

response disciplines, modes of service delivery, and radio systems. They rightfully
describe everything from training and proficiency of users to availability and
reliability of radio coverage.

These requirements are used in a conceptual design that incorporates action plans
for organizational and operational change, as well as in technology procurement
and implementation documents. The iterative process of collecting baseline (as-
is) information, assembling needs across stakeholders, and generating system
requirements (to-be) requires repeated participation, review, and comment by
working committees—both operational and technical.

Describing Requirements
Understanding and articulating your requirements is key not only to any successful
procurement of technology, but also to organizational and operational changes
necessary for improved interoperability. Requirements have to be described in terms
directly linked to the interagency business processes to be supported. Operational
requirements are best stated in simple terms, avoiding constraining definitions of
how requirements will be met.

Describe requirements using consistent terms and categories that help make sense
of what otherwise might be a confusing jumble of data. Fortunately, common
terminology and basic categories have evolved in recent years. SAFECOM’s
Statement of Requirements provides some of the most useful standardized
descriptions specifying with whom, for what purpose, and under which special
conditions a series of typical communications may occur. While forward-looking to
future development of technologies, the document uses a complete and consistent
style of description. We’ve used elements in business process examples above that
would roll into requirements documents.

Communications requirements can be described from several different angles. We

can look at the type of communications, the technological modes traditionally used to
provide them, and the operational modes of response when they’re used. We can also
describe them in terms of their scope, scale, and priority.
 Chapter 6: Conduct a Needs Analysis
93
Use the following categories and terminology shown in Figure 6-2 in stating
requirements. Quantification and qualification are both appropriate.

Categories and Terminology to Use for

Stating Requirements

Type Technological Mode

Dispatch Voice—Interactive
Command Voice—Noninteractive
Operational Data—Interactive
Tactical Data—Noninteractive
Support or Logistical
Priority
Scale Extreme Emergency
One-to-One Urgent, Safety of LIfe
One-to-Many Urgent, Safety of Property
One-to-All Planned Events
One-to-Any Exercises
System Administration Training

Operational Mode
Routine
Planned Events
Large Emergencies

Figure 6-2: Categories and Terminology

These methods of describing communications—either as they currently are or as

they should be—serve to categorize them. Categorization is useful for understanding
different requirements and being able to explain them. This is necessary not just for
specifications when buying radio systems, but more important, for understanding
internally what we’re doing with communications. Simply adopting common terms
to describe communications goes a long way in communicating—no pun intended—
what’s going on when writing standard operating procedures, training, conducting
exercises, and working with other agencies to improve interoperability.

Note that these ways of describing communications aren’t mutually exclusive and, in
fact, definitions are bound to vary across jurisdictions and disciplines.
9 Part II: How Is Interoperability Achieved?

Step 1
Define General Functional Requirements
Requirements are next defined in functional terms and compiled into a report
presenting them along with a conceptual design that illustrates how they fit together.
The first step in pulling together that report is to compile requirements from
preceding work. Functional requirements are defined in terms of just how the “system
of systems” will work to accomplish your project’s goals and meet its vision.

Don’t allow preconceived “solutions” to slip into your requirements. The price to pay
in noncompetitive bids that are challenged is just too high—and you may not get the
best solution for your operational needs. The project manager bears the responsibility
for identifying conclusions that may have slipped in under the guise of requirements.

Sort requirements into organizational, operational, and technical categories.

n Organizational
Interoperability needs analysis generally produces a number of requirements for
organizational change or development. Some examples include needs to create the
following: memoranda of understanding for sharing costs, mutual aid agreements
for sharing resources, policies for incident management during multijurisdictional
emergencies, and procedures for interagency operations. Requirements may also
include standard practices for lifecycle funding of systems, minimum staffing of
deployable communications resources, security, and standard training on interagency
communications across all partners.

The project’s executive sponsors and Steering Committee bear the responsibility for
preparing their organizations for changes necessary to improve interoperability. Most
organizational requirements that arise will require changes only possible through
their leadership.

Give some thought to what has been documented through the process up to this
point. Separate those requirements that have been expressed that can best be
addressed by management. They’ll be used in the conceptual design.

n Operational
Collect the processes and needs that have been expressed in operational terms. If you
followed our advice in completing the business process baseline, you’re well on your
way. Additional operational requirements arising from interviews and focus groups
must be folded in, but they should be obvious if you focused on operational outcomes
of interoperability.
 Chapter 6: Conduct a Needs Analysis
9
Beware of operational needs that extend the scope of your project. The primary
reason for establishing scope early in the project under the direction of the
Steering Committee is to draw some boundaries around what specifically is to be
accomplished. One hopes that you were able to use the project scope to keep the needs
analysis focused, but in case some discussions veered off track, now is the time to start
paring back.

Remember: It’s all about interoperability. Operational outcomes are the whole reason
why your project was undertaken. Take the business process descriptions and needs
that have been developed and massage them into statements of requirements that
describe how the pieces must function together.

A good technique is to use scenarios that you collected to facilitate stakeholder

interviews and focus groups to describe operational requirements, highlight
technology already in place, and state technical constraints. Realistic examples always
serve to clarify.

n Technical
Technical aspects of functional requirements address how operational needs are
to be met through technology. Don’t confuse them with the technical details of
existing systems that went into the baseline reports and will go into requirements
for interfacing or integrating those systems with any new technology. Because
few agencies maintain communications engineering staff, consultants are often
hired in radio projects to examine the technical environment, document technical
requirements, and then define interface and integration requirements described in the
next step.

Communications technical requirements are often expressed as a matter of one or

more qualities, such as the following:
• Capability – services provided for emergency responders (what, who)
• Availability – how well the system covers the area served (where)
• Reliability – how well the system delivers its services (when)
• Scalability – how well the system accommodates surge conditions
• Survivability – how resistant the system is to failure
• Restorability – how easily the system is restored upon failure.

The Technical Committee may not have defined its needs using these terms, but
Use terms of quality we’re certain the terms were touched on in principle. Use these qualities to further
to state technical
categorize technical requirements. State them in ways that can be tested and validated
requirements.
by system users.
9 Part II: How Is Interoperability Achieved?

Avoid requirements that are essentially technical specifications. When

system vendors deliver technology accordingly and it doesn’t meet operational
needs, the technology or vendor is usually faulted. In reality, the failure was in not
stating requirements so that operational tests could prove whether the solution
was acceptable.

While a simple idea, stating requirements in functional terms takes work. It’s
tempting to adopt specifications as requirements, and then be forced into using
technical performance measures for acceptance. Within your project, work to
assure you understand operational requirements well enough to decide whether any
proposed solution—technological or otherwise—meets needs.

The Technical Committee may have expressed needs to meet federal and other
regulatory regulatory mandates. For example, the Federal Communications Commission (FCC)
mandates often
spur system
has recently released rules regarding rebanding (moving existing channels within a
upgrades and band to reduce interference)22 and narrowbanding (reducing the amount of radio
replacements. spectrum used for a given channel).23 The committee may also have identified limited
radio spectrum as constraining expansion of systems to meet other needs.

These types of mandates provide the primary impetus for many radio system
upgrades and replacements. Note that, properly speaking, they don’t represent
requirements for your interoperable systems, but rather are part of the
environment in which realistic solutions have to be implemented. For example,
there is a difference between a requirement to meet FCC narrowbanding regulations
and a conclusion to migrate systems to the 800 MHz frequency band. While that
might be the eventual solution, there’s a difference between making it a possibility
and making it a requirement.

22
In August 2004, the FCC initiated the process of relocating most public safety 800 MHz users
within the band to reduce interference suffered from commercial wireless systems.
23
In December 2004, the FCC released long-awaited rules that will force eventual changes to all
radio systems operating below 512 MHz—all the commonly-used public safety bands below 700 and
800 MHz. By January 1, 2013, all radio channels used by these systems must be reduced in width by
half or be capable of passing at least two voice conversations in the same amount of radio spectrum.
 Chapter 6: Conduct a Needs Analysis
9
Step 2
Define General Interface and Integration
Requirements
All systems have geographic, functional, and technical boundaries that have to be
bridged and every interoperability project has internal points of interface between
communications systems and subsystems. Very few projects are initiated to uproot
all communications components for all agencies—from voice radios, to backbone
networks, to consoles and beyond—so integration of the old with the new is
generally inevitable.

Your own project probably encompasses components that won’t be replaced in this
effort to improve interagency communications. Ideally, they can all be integrated to
the extent they can honestly be called a “system of systems.”

This step in defining requirements establishes what parts of existing systems will
stay and which may go. It defines required points of interface between those that stay
and any new technology that may be implemented. This is the place to document
specifications that will shape proposed technology solutions.

Start by describing the core systems and subsystems that exist and will be built
upon. Establish provisional requirements for using them in concert with any new
interagency communications capabilities.

For example, consider the popular gateway devices that connect audio between
different radio systems, effectively patching two or more channels together. In
some areas of the country, these are critical resources for enabling interagency
communications. Many have been placed in fixed locations and have limited
capacity for expansion, either because of some inherent limitation on the number of
channels that can be interconnected or because the radio site is otherwise congested.
Requirements for connecting the gateway into any new means of interagency
communications should be spelled out.

Or consider that advanced radio systems are connected by sophisticated backbone

networks carrying all sorts of voice, data, and other forms of communications.
Quietly in the background, the network is probably carrying supervisory control
and data acquisition (SCADA) information that’s used to manage the network itself,
radio sites it interconnects, and maybe even radio tower lights! (Don’t laugh. The cost
of burned-out tower lights can be high—federal fines and worse!) Any new systems
added to such a backbone may be required to interface with the SCADA subsystem.
 9 Part II: How Is Interoperability Achieved?

Now is the time to establish any requirements on integrating other systems through
these and other resources. By nature, interface and integration requirements are very
technical. Internal or contract engineering expertise can be put to work in defining
these requirements.

Step 3
Create a Conceptual Design
The final step in developing general system requirements is production of a
conceptual design. This document illustrates how interoperability goals are to be
realized through both technical and nontechnical means. It demonstrates a vision
incorporating major assumptions and constraints, highlighting functional outcomes
of your project.

Create the conceptual design from the requirements statements you’ve assembled.
While much of the document will be essentially a narrative of what your needs
This is your to-be
report.
analysis produced, don’t forsake the pictures! Maps and diagrams are particularly
important components to include because they capture a great deal of information
in one place and show relations difficult to explain without a lot of verbiage. Use
sequence and flow work models from the business process baseline assessment to
illustrate what exactly will be supported by any new systems to be implemented.

Once again, the project manager is responsible for this product, but don’t feel bad if
the whole needs analysis process has left you exhausted! It’s not uncommon for it to
be contracted out. Some of the best work we’ve seen in this regard has been done by
system integrators strong on business process reengineering and less interested in
communications systems engineering.

As mentioned, this is a conceptual design for improved interoperability that most

likely will require a lot of organizational development, as well as technology. Don’t
confuse it with more detailed engineering designs that will come with responses to
any significant request for proposals and technology implementation plans. Those
come later—if at all—and address technical aspects of interoperability solutions.

Needs Analysis 10:

Evaluate Buy Versus Build Options
We’ve come to a decision point: What share, if any, of your new interoperable system
Don’t buy the of systems do you want to own and what share are you willing to outsource?
house; buy the
neighborhood.
This is a difficult decision that must be made before procuring any services.
—russian proverb
Traditionally, public safety agencies have built, owned, and operated their own
radio systems. Whether for voice or data purposes, police, fire, and EMS agencies
 Chapter 6: Conduct a Needs Analysis
99
have traditionally chosen to “roll their own” systems to provide known levels of
Public safety security and services, manage long-term costs, and guarantee priority access during
agencies have emergencies. However, agencies increasingly use commercial services for data and
traditionally rolled even some voice traffic.
their own radio
systems.
Voice push-to-talk communications is considered the most sacred technology owned
and operated by public safety agencies. While very few have resorted to completely
outsourcing radio needs, every day more and more move traffic off traditional voice
Commercial radio channels to data systems, cellular telephone, and other commercial radio
networks are services. Hybrid systems, owned and operated by private companies but leased to
increasingly used
public safety, are also increasingly common.
in mobile data
systems.
Some share of this migration is due to the lack of available radio spectrum for
new and growing uses, but the trend is also seen in areas where frequencies aren’t
so scarce. We expect this trend to be cyclical as the costs of building, operating,
and maintaining systems are weighed against the costs of sharing access, opaque
commercial capabilities that can’t be examined in detail, and less control over services
received.

An important choice about joining shared radio systems may also be in your cards.
These regional or statewide systems are being built to take advantage of economies of
Shared systems
bring high levels scale, gain strength through numbers with vendors, make use of otherwise duplicated
of technological system components, and improve technological compatibility that can lead to better
compatibility. interoperability. In many ways, they offer a good compromise between buying and
building new radio systems.

If the option is available, use of a shared system may be a partial or possibly a

complete solution to your project’s technology needs. This may result in similar
deliberations about guaranteed levels of service, long-term costs, and priority access
that you would have when using commercial systems. Approach participation in
shared systems in a manner similar to procuring a new system or commercial services,
recognizing the “added partners” you get at no additional cost!

This completes your needs analysis. The products will have been presented in large
part to stakeholders and accepted as formal project documents. Now is the time to
complete a project plan.
 CHAPTEr 7
SCOPE THE WOrK TO BE DOnE
 Chapter :
Scope the Work To Be Done

What A scoping exercise examines the extent of organizational and technological work to
be done through procurement and implementation. It concludes with the decision of
what work to contract out and what to complete in house.

Why Voice and data communications projects include work that you may wish to undertake
directly or contract out. Understanding the work involved allows a choice of what
will be included in the procurement process and who will be responsible for different
aspects of the system.

Who The project manager needs to understand both the work to be done and internal
resources available to complete it. The Steering Committee ultimately has to decide
what will be done internally and what will be procured externally.

When Following the needs analysis, the work to be done should be examined and decisions
made on what services and equipment will be procured.

We left the needs analysis phase of your project with a conceptual design in hand and
a “buy or build” decision on how to improve communications interoperability. The
conceptual design described at a high level how the various system components—
technological and otherwise—will fit together for interagency operations. In
preparing a project plan, look at the scope of work to be accomplished and decide
who will accomplish what.

The remaining phases of your project are procurement, implementation, and

maintaining the systems and processes. Each phase requires a good deal of work from
the project team, but you will soon be at the crossroads of deciding what to hand over
to contractors and what to do internally.

In order to best make that decision, it’s useful to understand what has to be
accomplished, particularly tasks that are most commonly contracted out.
 10 Part II: How Is Interoperability Achieved?

Commonly Contracted Services

Radio systems involve a number of specialized services. Those discussed below are
broad categories of work commonly contracted out—either separately or together.

Project Management
Obviously, there has been and remains plenty of project management work yet to
be done. This whole book and the original Law Enforcement Tech Guide are dedicated
to helping with that work. Project management probably seems like more and more
work as you read along!

Keeping with prior assumptions, we’ll continue to assume you are reading this
as the designated or soon-to-be project manager. In moving toward system
implementation, you have to work ahead to create a project plan, develop teams,
carry out a procurement, lead contract negotiations, and build an implementation
plan. You’ll need help, but we’ll assume the job of project management will be held
pretty close to home.

System Design
Do you need further You may already be facing a conundrum that many others developing complex
system design at systems have grappled with: Do you need further system design before proceeding
this point? to procurement?

Many projects proceed to procurement with little more than a conceptual design,
functional specifications, and some boilerplate language. This is done to leave the field
open for innovative vendor proposals. Other projects proceed through an engineering
design that yields very detailed specifications for bid.

Don’t limit your For interoperability projects, our recommendation tends more toward the former
choices by over- approach than the latter. Interoperability projects involve many existing systems and
designing technical complex needs that may best be addressed by technologies you haven’t anticipated, so
elements. it’s best to remain flexible.

Alternately, you may choose to hire a system designer before embarking on a

general system procurement process. This may become a more common process for
interoperability projects as funding becomes predictable, but now is used more often
for complete, new radio systems.

Detailed Engineering Design

Complex systems require a detailed engineering design that is very dependent on the
technology chosen. For this reason, the most detailed designs are usually left as an
early deliverable for the contracted system vendor.
 Chapter 7: Scope the Work to Be Done
10
System Installation and Optimization
Commonly done by the primary equipment or system vendor, the task of systems
installation and optimization occurs during implementation. Projects without a
predominant vendor or those using multiple technologies may require independent
contractors. Each may install and optimize different parts of the system, such as its
voice radio infrastructure and its microwave backbone. In this situation, your project
could require system integration services.

System Integration
The role of a systems integrator is to take the variety of electrical, electronic, and
physical system components and (surprise!) integrate them into a coherent whole.
Integrators often also serve in system design, acceptance testing, and quality
assurance roles.

Turnkey This is a role you may choose to handle with project staff, contract independently, or
procurement: leave up to a system vendor as a turnkey procurement. A turnkey procurement is one
One in which in which a general system vendor or equipment manufacturer serves as the system
a general
designer, integrator, and equipment provider.
system vendor
or equipment
manufacturer We’ll provide recommendations on how to proceed with these particular choices near
designs and the end of this chapter.
integrates the
system, and
provides the
Quality Assurance
equipment. Often used to refer to a broad range of acceptance testing (see below), quality
assurance is defined as a systematic process for assuring that a project meets its
objectives. Quality management is formally part of project management and is most
commonly seen in large system implementations.

Independent quality assurance contractors are occasionally used for radio projects.
For example, the Illinois State Police hired a quality assurance consultant to evaluate
proposals for a statewide system for the state police and other state and local agencies.

Acceptance Testing
In implementing technology, acceptance tests are planned and conducted to
Acceptance testing determine whether specifications and performance requirements are being met.
is dealt with The larger the project, the greater the effort involved in acceptance testing. Complex
in more detail
measures of performance, such as radio coverage, may be included in the acceptance
in Chapter 10,
Implement the process.
System.
While it’s always valuable for the customer to be involved in acceptance testing, part
or all of the effort is occasionally contracted out to an independent party due to the
work involved.
 10 Part II: How Is Interoperability Achieved?

Other Work to Be Done

There are three additional areas of work involved in implementing radio systems
where agencies typically choose to retain greater control: Training, radio site
development, and frequency licensing. Each of these areas can be completely
outsourced, of course. However, it’s more likely that you would keep a tighter rein on
them than you would, for example, on microwave path analysis.

Let’s take a look at each of the areas in some depth to provide more background for
your choices in delegating or contracting project work.

Training
Training will be the key to your successful system of systems. Anticipate that
Training is the key several types and levels of training will be necessary. Consider what may best be
to your successful
system of systems.
done in house, what can be contracted from your system vendors, or even solicited
independently from training companies and organizations.

n Technical Training
Your radio equipment vendors can be expected (under contract!) to provide training
on the technical operation and maintenance of equipment. This is appropriately
provided to agency radio technicians. Ongoing training should be anticipated for new
staff members and to maintain the skills of existing staff.

n Dispatcher Training
Dispatchers are Many means of improving communications interoperability will rely on that central
professional resource for most emergency response: the public safety communicator or dispatcher.
systems The dispatcher’s role requires his or her own personal integration of so many
integrators. communications systems that you shouldn’t underestimate the need for carefully
designed and executed dispatcher training.

n User Training
no technology is so Last, but not least, first responders who will use the system to communicate across
simple that training agencies and jurisdictions need training. Plan a comprehensive program for all
is unnecessary agencies planning to use the system that provides initial training of existing staffs,
for people who basic training of new staffs, and coordinated interagency exercises. Consider that such
will use it during training won’t appropriately come from system vendors, but from your own agencies’
emergencies.
staffs or even specially contracted assistance.

Radio Site Development

One technical consideration that agencies often maintain some control over is the
selection of radio sites for systems. Vendors rarely know as much as your users do
about how well sites serve current needs. There’s a good deal of “give and take”
 Chapter 7: Scope the Work to Be Done
10
between project technical committees and vendors in the process of radio site
selection for new and expanding systems.

Include staff on If you anticipate much radio site development in your project, make sure to include
the Technical people on the Technical Committee who have the knowledge and background of
Committee who what’s currently in use. There’s usually a lot of history behind why a particular site is
know what’s in used and why a better one is unavailable. This sort of “corporate knowledge” is the
use—and why. type that you don’t want to pay a contractor or consultant to rediscover.

Basically, radio sites are real estate. The three most important aspects of their
selection are location, location, and location (we’re sure you’ve heard this before about
residential real estate!). If your project requires site work or development, you’re faced
with using current system sites as-is or with improving, buying, or leasing access to
other existing sites, or developing entirely new ones.

The overriding The overriding consideration for radio sites is the coverage they will provide. This is
consideration affected by physical location relative to the involved jurisdictions, height relative to
for sites is the the area to be covered, surrounding natural or man-made clutter that will block radio
coverage they will waves, and other electromagnetic factors. While there are always compromises to be
provide. made, coverage is king.

Considerations for existing and new sites differ a bit.

n Considerations for Existing Radio Sites

Public safety — Physical access. Is the site constructed for safe, secured access for all tenants?
radio sites are How does the site manager provide for installation of new equipment on towers
considered critical and in shelter space? Is there a security system to keep out unwanted visitors,
infrastructure for
yet not impede legitimate maintenance?
homeland security.
— Physical space. Is there “prime” tower space available for antenna systems?
Does the shelter rack have expected space for radios and antenna system
combining equipment?
Federal Aviation
Administration
— Services. Is commercial and backup power suitably sized for all users?
(FAA) permits Is an adequate lightning protection system in place? Do the electrical
often require tower and radio frequency (RF) grounding systems meet electrical codes and
lighting. not only industry standards?
are tower owners — Maintenance and monitoring. Is the site well maintained to minimize the
liable for lighting
inadequacies
tenants’ costs and reduce their liabilities? Does it have an adequate monitoring
or failures, but system for tower lighting, power systems, and security controls? Has the site
tenants’ leasing manager instituted an acceptable plan for minimizing exposure to incidental
space have been electromagnetic radiation, as required by the Federal Communications
fined, as well. Commission (FCC)?
 10 Part II: How Is Interoperability Achieved?

— Electromagnetic compatibility. Are there other users of the site whose

systems will make it impossible or expensive for your systems to work? Is there
a powerful radio paging service operated nearby that may interfere?

n Considerations for New Radio Sites

For the uninitiated, building a new radio site is an education. Many an initiate has
begun the process to develop a seemingly crucial location and ended up regretting
getting started in the first place! While not impossible to do and do well, of course,
new site development requires a lot of work that you may have not anticipated.
Be aware of grant Consider all that is involved before insisting on doing it yourself.
limitations on
purchasing sites Here are some initial questions regarding a system design involving new sites:
or permanent
construction! many — Property ownership. Do project partners already have suitable locations for
won’t cover them new radio sites or access to other publicly owned property? Is there potential
outright, but will private property that can be purchased or leased?
accept the costs as
an allowable match. — Physical access. Are good roads available nearby for construction and
maintenance of standalone sites? Is facility access adequate for those being
put up on buildings, water towers, and other existing structures? Is there an
adequate road right-of-away to the property? Is it accessible throughout the year
or will seasonal conditions affect needed maintenance?
— Physical space. Is there sufficient space available to put up a tower and
equipment shelter? ­
One jurisdiction — Security. Can the site be adequately secured from vandalism and unauthorized
had to resort to access? What level of access control is possible? Can systems be monitored for
condemning private damage or failure?
property for right­
of-way access to — Utilities access. Are commercial power and telecommunications available or
an important radio economically accessible?
site.
— Existing backbone networks access. Will connections to other backbone
networks owned by the agencies be practical from the site?

Some additional considerations in implementing radio systems with new sites:

Buying or leasing real estate. For government agencies, this inevitably requires a
lot of legal and financial consideration by staff elsewhere in the affected jurisdictions.
If you hadn’t included suitable expertise in an ad hoc working group, you will want to
add it if you plan to acquire new site real estate.

Zoning and variances. You may run into zoning issues for a given location that
require navigating the thorny path of property use variances. Even if a formal
 Chapter 7: Scope the Work to Be Done
109

One jurisdiction ran head-first into a “Save Our Mountain” committee

when trying to site a new tower. They ended up compromising on the
location—going with a marginal bench on the side of the mountain
rather than the top to avoid tower lighting requirements—and ended up
suffering coverage problems in critical areas for more than 20 years.

variance is unneeded, plan on a careful, measured public hearing and education

process if you plan to put up a new tower. There’s a wide and strong current of
NIMBY (“Not in my backyard”) running nationwide. Not everyone sees the beauty in
radio towers and there’s always concern about the potential health effects of nearby
radio transmitters. Plan to use a public relations team to help if you choose to get into
the business of building new radio sites.

Construction permits. It should come as no surprise that all the work going into a
new site generally requires studious attention to obtaining building permits. As public
agencies are often under great scrutiny, your partners will expect that all necessary
and appropriate permissions are received before construction begins. This needn’t be
a difficult process, but it does take time and often affects site design.
Increasing use
of “mesh” radio
Tower size. A tower’s height above ground or above the average terrain surrounding
networks for data
requires many a site dramatically affects the coverage of radios in all frequency bands. While there
more sites, though are technical design trade-offs—too much height, too much coverage, the effects
generally simpler of distant interference aggravated by being in “too good” of a location, and general
ones. practical construction considerations—greater height for antennas is generally
preferred to maximize the coverage.

Building new sites brings up additional engineering considerations before real estate
is ever purchased. Tall towers require guy wires that run to ground anchors well away
from the towers, necessitating larger sites and additional construction, including
security fencing. In 2004, a Florida jurisdiction suffered a dramatic and dangerous
tower collapse when a service truck backed into guy wires at one of its sites. Such total
loss of a site can have a dramatic effect on system capabilities.

FAA permits. Radio towers and antennas can be serious aviation hazards. The FAA
has strict regulations regarding their location, size, painting, and lighting. Don’t plan
on putting up new towers without scheduling time for the FAA permitting process.
Antennas or mounting structures that don’t extend more than 20 feet above existing
structures don’t require additional approval, but when it is necessary, plan on 6 to 8
weeks for completion of permitting.
 110 Part II: How Is Interoperability Achieved?

Environmental and cultural assessments. A common “gotcha” in building new

radio sites is the need to conduct assessments of the environmental impacts of
new sites. Many potential sites are in environmentally sensitive areas and may be
subject to the National Environmental Policy Act (NEPA). Environmental impact
statements are time-consuming and can bring public contention. Similarly, potential
sites may have historical or other cultural significance that can quickly exclude their
consideration or require careful assessment.

Rely on expertise in your jurisdictions’ building, construction, and zoning divisions,

as well as legal staff, to help decide whether environmental and cultural assessments
will be necessary for new sites. Be aware that there are private companies that
specialize in doing this work, as well.

n Other Radio Site Work

If you choose to be involved in the selection of any radio sites to be used in your new
system, be aware of the additional work this typically involves.

Site inspections are important and typically required by vendors when existing sites
vendors look
for adherence will be used for new or extended systems. Inspections may be conducted by a joint
to commercial team of your project’s technical members and the vendors, or it may be stipulated
and public safety in contracts as being done by a third party. Commonly, vendors look for adherence
standards in to commercial or public safety standards before accepting sites offered by agencies
evaluating existing for use. Conversely, you may have nontechnical requirements for sites identified by
sites. vendors, such as access for maintenance and physical security.

Tower inspection and validation is related to site inspection, but considered a

separate task because of the engineering expertise needed to evaluate the structural
integrity of towers and validate their acceptability within the engineering design.24

Site design is a separate, but important task. For new construction, it starts with
layout of the tower, shelter, guy wires, grounding systems, utilities, access, and
For new or existing security. For new or existing sites, floor plans have to be developed and documented
sites, adequate
to assure adequate space for equipment and its proper identification later on.
floor space has
to be available Similarly, equipment rack layouts are an important part of site design. Radio
for expected sites are dependent on adequate, quality electrical service that typically has to be
equipment. converted from the utility company’s alternating current (AC) to direct current
(DC). An electrical design is needed that accounts for AC service to some pieces
of equipment, DC to others, and backup power when commercial service is lost.

24
The National Association of Tower Erectors (NATE) works with federal agencies and standards
organizations to establish tower safety practices. See http://www.natehome.com.
 Chapter 7: Scope the Work to Be Done
111
Proper documentation of all these site design elements is a critical deliverable during
implementation, too.

Antenna system installations are generally part of any implementation of new

fixed radio infrastructure. More than likely, this responsibility will be defined in
your procurement documents as either your responsibility or the vendor’s. In either
event, both parties have an interest in using certified crews for the sake of safety
and quality.25 If you require the vendor to use existing antenna systems or ones your
agencies provide, expect the vendor to require their own verification of suitability.

Frequency Coordination and Licensing

most public safety
The final area we want to address in scoping work to be done is licensing of any
transmitters have required radio frequencies. Not all projects will require additional channels, but
to be licensed with licensing is generally required for any addition of new sites, even on existing
the FCC. frequencies. Don’t make the mistake of planning to put in new transmitters of any
form without assessing FCC licensing requirements.

There are a multitude of considerations about RF spectrum availability. It’s beyond

Spectrum the scope of this Guide, but suffice it to say there are very definite limitations in
congestion forces most areas of the country, using predominant frequency bands, in adding new
agencies to move frequencies to systems for interagency use. Since compatibility with existing systems
to new frequency and surrounding partners is a central issue in communications interoperability, there
bands to get new
capabilities.
is rarely the ability to uproot all systems and move to new, typically higher, frequency
bands to find “green space.” 26 Projects of the type we’re addressing in this Guide are
more incremental in nature, typically not requiring large numbers of new frequencies.

Whether new frequencies will be required or existing ones used in new ways, the
FCC requires frequency coordination and licensing. The application process itself
is alien to most agencies and uncomfortable even for most technicians. Many
agencies have technical staff adept at preparing applications and navigating
the frequency coordination process. Both activities have become more complex
in recent years, however, and agencies are increasingly outsourcing the whole
process in systems acquisitions.

25
The Occupational Safety and Health Administration (OSHA) and National Institute for
Occupational Safety and Health (NIOSH) have increasingly stringent standards affecting tower
construction and antenna system installations. See NIOSH Publication No. 2001-156,
http://www.cdc.gov/niosh/2001156.html.
26
SAFECOM has produced a publication addressing the subject, Public Safety Radio Spectrum: A
Vital Resource for Saving Lives and Protecting Property. See http://www.safecomprogram.gov/
SAFECOM/library/spectrum/1102_publicsafety.htm.
 112 Part II: How Is Interoperability Achieved?

For purposes of planning, be aware that the cost of license application preparation
can range from a couple hundred dollars to several thousand for larger, more complex
systems. The FCC doesn’t charge fees for licensing by public safety agencies of their
A couple of certified
land mobile radio systems,27 so no cost is to be anticipated there. It does, however,
coordinators use
local advisors, allow certified frequency coordinators to charge for their services.
people within the
state or region who Frequency coordination is the process of selecting appropriate frequencies for the
typically work in a applicant agency, while balancing the needs of other eligible users and minimizing
technical capacity interference between all.28 Since practically all licensing that public safety agencies do
for a public safety requires frequency coordination, you can anticipate using the services of a certified
agency that
coordinator. The FCC maintains a list of coordinators and contact information on its
volunteers their
time. web site.29

We increasingly see projects where certified frequency coordinators are brought on

under contract to help guide this aspect of design, and then subsequently prepare
applications, coordinate frequencies, and submit everything to the FCC. Fees are
typically based on the number of frequencies and sites used in a system. Again, the
cost varies according to the size and complexity of the system. It varies from a couple
hundred dollars for a simple modification to an existing license to tens of thousands
of dollars for new systems with many sites and frequencies. For planning purposes,
contact the certified frequency coordinators for cost estimates.

GATEWAYS AND FREqUENCY LICENSING

Gateways that interconnect multiple radio systems bring additional licensing
requirements when used to directly control transmitters. Requirements vary based on
whether the device is used to connect fixed radios or is deployed as a mobile device.

Check with the FCC-certified frequency coordinators on what additional licensing will
be required for transmitters connected to your gateway.

27
Land mobile radio (LMR) is a particular classification of radio systems that includes common
dispatch, car-to-car, and portable communications used by public safety agencies. License fees are
required for other types of wireless systems, such as microwave links.
28
The Association of Public-Safety Communications Officials – International, Inc., provides
an explanation of frequency coordination on its web site. See: http://www.apcointl.org/
frequency/WhatisFC1.html.
29
See http://wireless.fcc.gov/publicsafety/coord.html.
 Chapter 7: Scope the Work to Be Done
113
Assessing the Scope of Work to Be Done
You have reached a decision point. Just how big is the project and how much of it
do you want to take on? That might seem like a philosophical question (particularly
if you were, well, assigned to manage the project), but from a more practical and
less personal standpoint, there’s a consideration. Do your agencies want to have the
fine-grained control over all system acquisition and implementation activities that
yields the most customized and highest performance system, or are you comfortable
handing off some or all of that responsibility for manageability?

What Are the Choices?

It’s not an easy decision and not necessarily black and white. At one end of the scale
Don’t rely on are agencies that have relied on a single radio vendor for so long that they will buy
vendors’ measures whatever the vendor offers as an interoperability solution. Not only will they buy it,
of “interoperability.” but they’ll use the vendor’s functional and performance specifications to evaluate
“success.” This is an abrogation of responsibility that leaves real needs unsatisfied.

At the other end of the scale, some agencies proceed with large systems design
and acquisition by being the general contractor, so to speak, themselves. They take
Consulting for
on all responsibility for engineering design, construction, acceptance testing, and
major systems
design and
integration of the diverse subsystems that make up modern communications systems.
implementation What they can’t do in house, they contract out piece by piece. The advantage is better
can be expensive needs-based design and project accountability. The disadvantage is that it can be a
because there’s huge amount of work.
a lot of work
involved. In between these extremes is the rest of the world. Few agencies have the internal
resources to take on all these duties, so they usually end up contracting out some or all
of the tasks that have to be accomplished in a big system implementation. The trade-
off is in finding the right contractors to take them on. And, of course, every project is
going to have a different combination of the required tasks.

What Will You Handle Internally?

How do you decide what share to handle internally? Start by looking at the
participants’ willingness to define the scope and level of work required. By this point
in your project, you should have a pretty good idea of internal resources available for
the work ahead.

Of course, major system vendors are very willing and usually quite interested in
taking care of all your needs. While this comes at a cost, don’t forget there is a good
reason for this: Vendors will undertake tasks that you may not have adequate or
appropriate resources to do. As you proceed, consider which roles are best managed
closely for your project and with your resources.
 11 Part II: How Is Interoperability Achieved?

Recommendations
Our recommendations on proceeding through procurement to implementation are
based on the scope of the project as reflected in its anticipated cost.

Independent For systems expected to cost less than $500,000, plan to act as your own general
integrators can contractor. Rely on either internal engineering expertise or contract for it. Little site
be more objective development is expected for projects this size, so engineering is reduced. For projects
in advising
of this size and smaller, agencies often rely on regional radio service companies with
you of needed
organizational,
whom they have existing contracts.
operational, and
management For systems up to a few million dollars, consider using a turnkey procurement where
changes. the winning vendor will take care of all the system design and implementation
work. Projects of this size are generally larger than what agencies can comfortably
take on themselves and small enough to make contracting for the parts separately
unnecessarily time-consuming and costly. A project management or quality assurance
consultant may be a good investment to improve your project’s odds of success.

Our recommendation for systems costing more than a few million dollars is to hire
a systems integrator separate from the primary technology vendor or vendors. This
gives you more direct management control of the project. Good integrators can help
not only in moving your project from conceptual design through implementation
and on to full operations, but also by bringing a wealth of experience in dealing with
technology vendors. Their reputations are built on assuring project quality for their
customer—your agencies—by getting the most for your dollars.

Develop Your Own Recommendations and Get

Approval
These recommendations are just rules of thumb, of course. You and your project team
are the best judges of what can reasonably be accomplished internally and what can
affordably be outsourced.

With the consensus of the User and Technical Committees, seek Steering Committee
approval to move forward with further project planning and procurement based on
the agreed-upon scope of work.

With that approval in hand, you’re ready to create the project plan!
 CHAPTEr 8
CrEATE A PrOJECT PlAn
 Chapter :
Create a Project Plan

What The project plan is a document that guides the entire design, procurement,
implementation, and future operation of an interoperable system. It provides
the detail necessary to manage each phase of the project and the multitude
of activities involved in each. It includes components for controlling the
critical Scope-Budget-Timeline relationship,30 as well as managing risks and
communicating about the project with stakeholders. This document will evolve
over the life of your project.

Why Project planning—the dynamic process of creating a project plan—dramatically

increases the chances for success of interoperability projects. Plans keep both
internal and external stakeholders informed in varying levels of detail. They
provide the means to control activities, detect problems early on, and respond to
changes along the way.

The project manager and the User and Technical Committees are involved in
Who discussions, decisions, and research. The project manager should be responsible
for project plan documentation. The Steering Committee and executive sponsor
must endorse and sign the plan.

Following formal development of the decision-making structure (Chapter 5) and in

When conjunction with the development of the needs analysis (Chapter 6).

Project planning is the focus of Part III of the Law Enforcement Tech
Guide. The topics of scope, timelines, budgets, risk management,
TECH GUIDE
and project communications are dealt with in depth through its six
ORIGINAL

chapters. This chapter draws heavily from them, while emphasizing key
s
aspects for interoperability projects.

Chapters 8 through 13 of the Law Enforcement Tech Guide deal with

project planning for technology projects in general.

30
As mentioned in the original Tech Guide, throughout your project, you will need to constantly
balance the constraints of time (length of time the project takes to complete), scope, and cost.
Should any one of the three “triangle” components grow, there is a direct effect on the other
“corners” of the triangle. Thus, as scope grows, so does the project costs and its scheduled
completion time.
 11 Part II: How Is Interoperability Achieved?

“Planning” is such a painful word in some public safety circles that the thought of
creating another plan—or set of plans—may not be particularly appealing in your
The project plan current quest to improve communications interoperability. On the other hand, few
is a working of us would dream of sending carpenters, plumbers, and electricians out to build
document. us a new house without an agreed-upon set of blueprints in the general contractor’s
hands. Properly done, your project plan won’t be one of those documents that are
quickly shelved—it will be a dynamic, evolving document that is continuously used to
manage the project.

Before getting started with creating a project plan, recognize that multiagency
technology efforts are particularly at risk of failure. Institutionalized barriers to
communications across organizations affect our ability to jointly manage projects,
requiring careful and practical definition of the scope of projects, timelines, budgets,
and how risks typical to technology projects will be managed. Obviously, these
barriers contribute to the very “first responder” interoperability issues you’re working
to resolve.

The project planning process, itself, improves the odds of success by bringing
Project planning stakeholders to a common agreement on details. It produces a detailed, actionable
improves odds of plan to achieve the project’s objectives. A plan developed by the project manager with
success. input from working groups and accepted by the project’s Steering Committee is a
powerful tool to manage the complexity of interagency initiatives.

Throughout the following, we are assuming you are or will be the project manager.
Your project plan will establish the scope of what will be accomplished, set a timeline
and budget, and include subplans for managing project risks and communicating
project activities and statuses. The cyclical process of creating and maintaining one
throughout the life of a project makes assumptions explicit and decisions binding.

Project Planning 101:

Set the Scope and Objectives
With a firm understanding of the interoperability goals to be achieved and a broader
understanding of the needs existing across agencies to meet those goals, you can
now document and define the project’s detailed scope and objectives. Scope planning
fleshes out your charter’s initial scope statement with requirements developed during
needs analysis and details from the conceptual design. It provides the most basic
elements of the project plan.

The three pieces of a good project plan that deal with scope are as follows:
1. Scope statement
2. Project objectives
3. Scope management plan.
 Chapter 8: Create a Project Plan
119

PREPARING FOR CHANGE

Technology projects generally accompany and lead to lots of organizational change.
Communications interoperability projects can lead to even more upheaval because they
affect not only internal processes, but also relations between organizations. Voice and
data radio communications are such critical tools for emergency responders that any
disruption of current capabilities, in particular, threatens to cause some serious push-
back on the project from the field.

Executive sponsors: Change management is an integral part of project

management. Prepare your organizations for change by requiring a formal plan that
controls the project scope, budget, and timeline to achieve the interoperability goals
and objectives you have set out. It should include a section on how the risks inherent in
large projects, in general, and your project, in particular, will be managed. It should also
include a plan for communicating progress realistically to all stakeholders, including
line staff, supervisors, management, and any stakeholders beyond your organizations.
Manage the expectations of your employees and make sure they have reason to share
ownership of the project’s success.

Follow these steps to establish your project scope and objectives.

Step 1
Draft a Scope Statement
As project manager, your first scope-planning task is to assemble a draft statement
with definitions of what’s in and out of the project, supporting detail for the project’s
business case, and the assumptions and constraints that will shape its outcomes. Be
sure to include any grant requirements that you already know about. They will have a
definite effect on the project.

The scope statement serves in this form as an incomplete working document for the
next steps. Add an initial work breakdown structure31 to describe the phases and
individual activities in sequence that will take the project from conception through
design and implementation to ongoing operations (see Figure 8-1). At this point, focus
more on what the activities will be, their interdependencies, and how they proceed in
sequence than on how much time they will take. Your timeline will be set a bit later on.

31
Work breakdown structure is a “deliverable-oriented grouping of project elements that organizes
and defines the total work scope of the project. Each descending level represents an increasingly
detailed definition of the project work,” according to the Project Management Institute. It is
typically represented as a timeline of related activities, in sequence, and showing visible outcomes
(deliverables). A Guide to the Project Management Book of Knowledge, 2000.
120 Part II: How Is Interoperability Achieved?

ExAMPLE SCOPE STATEMENT

The communications interoperability project will establish one interagency
voice channel for all police, fire, and EMS agencies in the county for on-
scene command coordination. Interagency command communications are
necessary only within a 1-mile radius of an incident command post, which
may be established anywhere in the county. Funding limitations suggest that
complete replacement of all disparate systems in use will not be possible.

Console patching of agency dispatch channels will not be an acceptable

means of meeting this need. Use of gateway devices linking existing channels
or systems may be acceptable if specifically designated agency tactical
channels or talkgroups are used. No new radio frequencies will be licensed.

Training and exercises for county communications technicians and all

responders will be conducted.

INTEROPERABILITY PROjECT

Project Management

System Design

Equipment Procurement

Equipment Installation

Communications Technician Training

Responder Training

Tabletop Exercises

Full-function Exercises

Figure 8-1: Sample Work Breakdown Structure

 Chapter 8: Create a Project Plan
121
Step 2
Draft Project Objectives and a Scope Management
Plan
Bring the User Committee together in a working session to take preliminary project
objectives from the charter and adjust them based on the results of your needs
analysis, documenting the rationale for later justification to the Steering Committee.
This statement of objectives should establish specific, detailed measures of success.
Use any objectives implied in the scope statement and provide additional details, if
necessary.

TECH GUIDE
The Law Enforcement Tech Guide includes further advice on defining practical, yet
ORIGINAL

124 measurable project objectives. For the example project above, objectives might include
the following:
s
3 Communications between responders for command purposes should be possible at any
location within the county that is otherwise suitable for an incident command post.
3 Communications should be possible within a 1-mile radius of an incident command
post.
3 The interagency command channel should be available to responders without
requiring the intervention of other personnel.

With draft objectives in hand, the project manager and User Committee can draft the
final part: A plan for managing the scope. Ultimate approval for scope changes should
be left to the project’s executive sponsors to make sure that the original vision isn’t
being compromised.

TECH GUIDE
The Law Enforcement Tech Guide provides details on the issues to be addressed in a
ORIGINAL

125 scope management plan. Relevant statements for our example above include:
s 3 Project scope changes must be approved by the city police and fire chiefs, as well as the
county EMS director.
3 Proposed limitations to the geographic availability of the command channel will
be evaluated by the Technical Committee. Recommendations with estimates of
cost for overcoming the limitations will be provided to the Steering Committee for
consideration and comment before submittal to the police chief, the fire chief, and the
EMS director.

Scope changes will occur. Project participants learn more as the project proceeds,
affecting their ideas about what’s possible. Agency needs may shift, affecting the very
real definitions of what has to be made “interoperable”; or market changes may bring
new technological options to meeting needs.
122 Part II: How Is Interoperability Achieved?

PERFORMANCE MEASURES
For interoperability projects, performance measures may include such things as the
availability of interagency channels, the speed with which gateways are activated or
deployed, the required coverage of systems linked together, and much more.

Focus on operational measures of success: The observable effects of good interagency

communications. We’ll have more to say about measurable improvements to
interoperability in Chapter 15, Measuring Interoperability. Just remember:
Performance measures are a key part of your project plan and must be contemplated at
the earliest stages of a project.

Your ability to identify when the project scope is changing, how it will be dealt with,
and who has authority to approve changes is critical to project success.

Step 3
Get a Technical Reality Check
Your Technical Committee should review the scope statement and project objectives
at this point. The committee will have valuable input to assure that technological
barriers, such as unachievable levels of radio coverage, haven’t been inadvertently
inserted into the project. The purpose of working the draft through the User
Committee first is to focus objectives on operational measures of success.

This doesn’t mean there aren’t important technical aspects to scoping your project.
Because your interoperability project will most likely involve adding new technology,
the Technical Committee will have particularly valuable input on the work breakdown
structure defining implementation activities and their sequence. Have the committee
help establish meaningful milestones in the implementation phase to include as
deliverables in vendor contracts that can be used for incremental payments.

Step 
Get it Approved!
The final step in scoping the project is getting sign-off from the Steering Committee
and, finally, the executive sponsors. Because this key piece of the project plan puts
meat on the sponsors’ strategic skeleton and defines what everyone will follow, their
formal approval is important.

Use the occasion of presenting the scope statement, project objectives, and
management plan to the Steering Committee and executive sponsors as an internal
milestone to rightfully mark its importance in moving from planning to action. Note
 Chapter 8: Create a Project Plan
123
the intent to require executive sponsor or designee approval of any scope changes to
keep the project focused.

Project Planning 102:

Develop the Timeline
With the scope now defined in detail, a timeline can be built as the next step in project
planning. It can usually be drafted by the project manager in near final form based on
TECH GUIDE
the definitions of activities and work breakdown structure arising from the scoping
process (see Figure 8-2 on page 124).
ORIGINAL

129

s The Law Enforcement Tech Guide dedicates a chapter to this project-planning step and
the material doesn’t need to be duplicated here. Remember that the timeline includes
not only the sequence and the amount of time individual tasks will take, but also how
they’re grouped into meaningful phases and further demarked by milestones and
deliverables. Sound project management practices require clearly identifiable points
of progress. This is most practically, often graphically, depicted in a project timeline.

Keep in mind that interagency projects of any type are notoriously “delicate,” often
depending on the leadership of key individuals and a regular supply of goodwill.
Broken schedules and overdue projects strain the tightest project teams. Stakeholder
frustration and skepticism can boil over when unrealistic expectations inevitably
crash into reality.

Manage your project timeline well to maximize tangible resources and—more

important—to maintain that intangible cooperative spirit. From the timeline
submitted in the first project plan to closing out the project, the project plan revolves
around the timeline. Update it regularly and keep it before the project team.

Project Planning 103:

Estimate and Deliver a Budget
It’s inevitable. At some point, it comes down to money.

Actually, some project managers are excited by the money aspect of their projects.
There’s some vicarious pleasure to be had in spending large amounts of money
effectively to help public safety responders. Nevertheless, it can be challenging to be
a responsible steward of taxpayers’ hard-earned money. The budget portion of your
Costs are initial and project plan can be completed once the scope is defined and your timeline in place.
recurring, internal
and external. Technology projects of almost any size face initial and recurring costs, incurred both
within the participating agencies and through external procurements. Initial costs are
12 Part II: How Is Interoperability Achieved?

Take into Account the Following Special Time Aspects for

Interoperability Projects:

The inherently multiagency character of communications interoperability

projects requires that additional time be built into schedules for all aspects
that involve formal approvals, such as memoranda of understanding and
cost-sharing agreements. Agreements can take an extended amount of time,
particularly as more legal review across affected agencies takes place.
Manage this time aspect by ensuring that Steering Committee members
have delegated decision-making authority. Use a regular meeting scheduling
process where issues requiring further internal agency review are announced
prior to a meeting, presented for consideration during it, and scheduled for
decision at a subsequent one. Regularly used, this structured process will
help your project move steadily forward.

voice and data communications projects, alike, are often expensive,

span multiple budget and grant years, and require time-consuming
competitive procurements.
Create an ad hoc committee of agency fiscal, grant management, and
procurement specialists to make sure your timeline takes into account
the cyclical and often time-critical aspects faced by these important
partners. Their buy-in to the project can yield benefits long after the
timeline is in place!

radio projects often involve civil construction, public hearings, zoning

variances, environmental assessments, permits, and licenses. In many areas
of the country, seasonal weather even determines when building can occur.
Every one of these aspects can throw a monkey wrench into the gears of a
finely tuned timeline.
Manage these schedule killers by building in plenty of time for their
completion. Start the related tasks early and pad the timeline with
contingency activities that can be moved in to take advantage of delays.
Carefully analyze and define dependencies between activities in the work
breakdown structure to compress the timeline where possible by carrying
out tasks in parallel. These techniques are all tools in the project manager’s
kit for dealing with such monkey wrenches.

Figure 8-2: Special Time Aspects for Interoperability Projects

 Chapter 8: Create a Project Plan
12
all those that come about before the system is put into operation, while recurring costs
arise afterwards. Internal costs are those over which the project participants have most
direct control, while external costs generally come in the form of hardware, software,
and services.

Cost estimation along these two dimensions is key to a sound project budget. You will
probably begin by focusing on initial external expenses. As the costs of outsourcing
everything from project management to radio installation start to add up, look for costs
that may be covered and managed most effectively within the participating agencies.
Don’t make the mistake of assuming that internal costs—initial or recurring—will
be covered without documenting and quantifying those assumptions. From a project
manager’s perspective, that’s a good way to get shortchanged when you turn to project
partners and find they have no means of carrying their share of internal costs.

Begin by identifying the costs of which you are aware. Use a chart to categorize them
according to when they’ll come about and where they arise (see example in Figure 8-3).

$ COST SOURCE
COST

INTERNAL ExTERNAL
Project workspace Property
Project management labor Radio site infrastructure
Remodeling of central facilities Network infrastructure electronics
New intranet drops User radios
INITIAL

Overtime for training Network management software

Mobile radio installer labor Controller computers and software
COST TIMEFRAME

Acceptance testing costs System engineering

Internal cost recovery fees Construction services
Integration services

Physical infrastructure maintenance Maintenance contracts and updates

Internal network cost recovery fees Radio site and tower leases
Refresher training and exercise costs Software license fees
RECURRING

Technical support labor Electrical service to radio sites

Radio reprogramming Backbone network services
New fleet installation costs Tower inspections
Infrastructure repair
User radio repairs and replacement

Figure 8-3: Example Cost Identification Chart

 12 Part II: How Is Interoperability Achieved?

Follow these four steps in developing your budget:

Step 1
Gather Internal and External Cost Data
Pull together cost estimates for each of the items you have identified. Often it’s
difficult to quantify all these costs because details are embedded in budgets
spread across multiple agencies. Still, estimates are important to show
contributions by all project participants even if they’re made in the form of costs
most grant avoided. For example, significant initial and recurring costs for radio sites and
programs being tower space can be avoided at times through sharing of existing facilities owned
tapped today for
communications
by one project participant or another.
interoperability
projects require External cost estimation is more art than science. Obviously, you’re in the earliest
that local funds stages of defining your project at this point and have few ideas of what will ultimately
be used for have to be purchased. Most agencies are in regular conversation with their current
property, towers, communications vendors and can get budgetary estimates without running afoul of
and permanent
procurement rules, but check with your own purchasing officials before doing so.
construction.
remember that
many grant funding Alternately, you can turn to other agencies, issue a formal request for information
programs for (RFI), and even hire consultants regularly working in the field to help create budgetary
technology will estimates. The original Law Enforcement Tech Guide provides more information on
pay for up-front these options.
start-up costs, but
will not pay for
recurring costs. Step 2
Protect your budget Create a Project Budget of Initial Costs
by thoroughly
Your budget of initial costs will necessarily include many figures, small and large,
understanding all
grant limitations! spread across the project timeline. While detail will be important later on, recognize
that estimates are bound to be rough at this point. Don’t create an artificial level of
budget detail by including costs down to the last nut and bolt. You may know the
average height of antennas above ground level at your radio sites and the going rate
of feedline, but there is no sense in detailing that cost when the variance in major cost
TECH GUIDE
categories will be orders of magnitude greater than anything spent to connect radios
ORIGINAL

141 to antennas.
s
Use a spreadsheet with low and high cost estimates for each of the budget categories
you choose to use. Budget detail beyond first and second levels will become important
in later, updated versions of the project plan, but this should be sufficient to move
forward with your initial version.

Common first- and second-level budget categories for initial costs may be categorized
as shown in Figure 8-4.
 Chapter 8: Create a Project Plan
12

Common first- and second-level budget

categories for initial costs
Personnel services Multiplexers and channel banks
Project management Gateway systems
Technical support Leased-line installation
Training and exercises Installation and optimization

Professional services Radio frequency (RF)

Project management infrastructure
Needs analysis Antenna and combining systems
Conceptual design and engineering Site voice and/or data radios
Procurement management Supervisory control and monitoring
Systems integration systems
Construction management Central electronic banks and network
Radio license application hub equipment
preparation and coordination Control station radios
Acceptance testing Installation and optimization
Training
End-user hardware and software
Physical infrastructure Portable radios
Real estate Mobile radios
Site construction Mobile computers
Site heating, ventilation, and air Vehicular modems
conditioning (HVAC) Dispatcher console equipment and
Primary and emergency power software
systems Application software
Tower erection
Other
Backbone network Contingency
infrastructure Bonding
Microwave radios

Figure 8-4: Common First- and Second-Level Budget Categories for Initial Costs
12 Part II: How Is Interoperability Achieved?

A BUNDLE OF COSTS
Large radio system vendors will prefer to act as your systems integrator, bringing all
the complex pieces of a modern radio system together. They’re very capable of doing so
and generally can better guarantee that their own products will perform if they do. The
downside is that the service doesn’t come free and you’ll probably pay a premium for
commodity items that you could buy “off the shelf.”

Prepare yourself to be a good consumer. Take the time early in your budgetary planning
to break out cost estimates for services and subsystems. This will give you needed
detail later on for the procurement process and beyond to contract negotiations.

Information is your primary tool in managing vendor relationships. Don’t give

away the farm by ignoring costs that can be buried in system integration and
implementation services.

Step 3
Estimate Recurring Costs
Recurring costs for your project will be highly dependent on the amount and cost
of new technology implemented. Today, radio systems are priced much more
like computer systems, with maintenance packages offered by vendors that cover
incremental software upgrades and even remote monitoring. Hardware upgrades may
be necessary for certain software upgrades, much as they are with computers. If your
system is as successful as you hope, recurring internal and external costs may actually
be greater than initial costs.

The rule of thumb for estimating annual software and hardware maintenance
contracts is 10 percent of the original purchase price. Other recurring costs, such
as internal technical support, training, and site leases, can be significant, too. For
example, monthly site leases for prime radio tower real estate are $1,000 a month and
more. One Virginia county had been quoted $13,000 per month for three commercial
radio sites that its vendor had chosen. It’s important to have a sense early in this stage
of your project if such recurring costs will be faced.

Step 
Plan for Ongoing Budget Updates
Just like the other part of the project plan, your budget needs to be maintained
TECH GUIDE
throughout the project lifecycle. The Law Enforcement Tech Guide points out that the
ORIGINAL

145
entire project team needs to understand that a budget is a projection. Through regular
s updates, the project manager communicates this reality while providing current best
estimates. As the project proceeds, adjustments will be offered and adopted or altered
by the Steering Committee to ensure that its goals are met.
 Chapter 8: Create a Project Plan
129
Project Planning 10:
Create a Risk Management Plan
The term risk management is common enough in modern parlance, but the
formal process of a plan to deal with risks in technology projects is unfortunately
uncommon. Proactive identification and evaluation of risks is a proven means of
keeping projects on track when the inevitable happens. Think of it as an insurance
policy to deal with contingencies.

Risk management isn’t a one-time effort, though. It starts once the project scope is
defined and continues through the life of the project as phases are completed and
milestones met. It’s of such importance that the entire decision-making structure
should be involved in creating and ultimately accepting the plan.

TECH GUIDE A four-step process for creating a risk management plan is presented in the Law
Enforcement Tech Guide. The process of identifying risks, categorizing and quantifying
ORIGINAL

150
them, determining your tolerance level, and creating a response plan is the same in
s
communications interoperability projects as it is in others dealing with technology. It
comes down to understanding and preparing for problems that may arise. (Figure 8-5)

Loss of key staff or participants

Loss of an executive sponsor or the project manager has the greatest
impact on projects.

Loss of funding
Given the expense of communications projects, several funding
sources usually have to come together to make them
possible. Loss of a key funding stream or the inability to
match a grant can require huge scope changes.

Bid protests
In a competitive field for high-stakes contracts, vendors
are often willing to play hard for business. Bid protests can
result in significant time delays.

Construction delays
Any number of events can delay necessary building. Given narrow funding windows, delays can put
funding at risk.

Frequency licensing problems

Radio frequency spectrum may be one of the most scarce resources that has to be managed in the
project. Licensing delays or disputes can have a serious impact on schedules.

Public protests
There’s nothing like a new radio tower going up in someone’s backyard to cause public protests.

Figure 8-5: Common Risks in Interoperability Projects

130 Part II: How Is Interoperability Achieved?

Examples of risks in radio projects abound. A statewide project in Alaska struggled

through the replacement of its entire executive sponsorship council and two project
managers over a 2-year period. A large California city experienced a 1-year delay in its
interoperability project when it couldn’t come up with the required match for a grant.
In New York, a losing vendor protested an award that was several times the agency’s
initial estimates, yet still one-third of the cost of its own bid. A Pennsylvania project
faced serious delays when its radio tower vendor went bankrupt. Frequency licensing
mistakes cost a Nevada agency its entire $14 million system when the FCC forced it
off the air and another $10 million for equipment to operate on a pre-existing system
of another agency. A Michigan agency spent $200,000 for a study to determine why
migratory birds collide with its towers after being challenged by wildlife groups for
not doing environmental assessments on the towers.

Every project will have a different set of risks, likelihoods, and impact areas, just as
every project team will have a different assessment of the severity of the risks and its
own tolerance for them. For example, of two jurisdictions facing difficulties obtaining
radio channels, one might choose to proceed with work that can still be done, while
another might temporarily halt the project to avoid putting more money at risk.

Risk evaluation and management decisions should involve the whole team.

Project Planning 10:

Communicate Plans and Progress
It shouldn’t come as a surprise that any project to improve interagency
communications can, itself, benefit by strategies to communicate with stakeholders.
The process of documenting everything from initial project meetings to the charter
and beyond provides the raw materials for good project communications. It also
yields the historical information that should be kept in case of personnel changes, for
grant reporting, and for future project planning.

The last piece of your project plan is a formal plan for how you as the project manager
will report in various directions to all stakeholders—internal and external.

The Law Enforcement Tech Guide provides an example chart showing how the variety
of stakeholders can be kept appropriately informed. It describes by team member
TECH GUIDE
what information is needed, the amount of detail required, the frequency of
ORIGINAL

161 communications, and the methods of delivery. Appropriately, you will have been
doing a good bit of communicating along these lines by the time this part of your
s
project plan is in place, but now’s the time to formalize it.
 Chapter 8: Create a Project Plan
131
Focus your communications plan on getting accurate and complete, yet succinct,
information to stakeholders at all levels. Each group represented in the project team
and outside of it will want different information. Plans and the progress being made
to achieve them will be of general interest, but from different angles. For example,
upper management is much more interested in budgetary details and personnel
assignments than the general public will be.

Think like a The different messages have to be communicated in the form best suited to the
wise man but audience, focused on their areas of interest, and in appropriate terminology. Focus
communicate in general information on the operational outcomes of the project and practical matters
the language of the of progress, such as phases and milestones, making spare use of technical terms and
people. jargon.
—William Butler
yeats We’re convinced that traditional oral and written reports are still invaluable. Well-
delivered in person, they persuade and assure like no e-mail or other electronic
process can. Make the most out of your opportunities as project manager to present
the project in person.

INTEROPERABILITY SUMMIT
More notes from the U.S. DOJ Interoperability Summit

Communications
3 Establish a communication plan that creates a reporting structure with and between
committees and uses graphic depictions to show reporting responsibilities.
3 Use daily briefings between key project team members to manage information flow.
3 Keep agency public information officers informed about the project.
3 Limit who communicates with vendors.
132 Part II: How Is Interoperability Achieved?

Communicating Across Agencies:

The Project Web Site
Communications interoperability projects are challenged by the fact that
stakeholders are spread across multiple jurisdictions, often separated greatly
by their respective agencies’ information systems. While it’s not impossible to
communicate well with team members who are widely dispersed, some common
collaboration and office productivity tools aren’t as available as they might be if
everyone were in the same building.

Because of this, we’ve been encouraged in recent years to see growth in the use
of project web sites to communicate with stakeholders, including the general
public. One good example that can’t be done justice on the printed page is the
Louisville (Kentucky) MetroSafe web site (Figure 8-6). Louisville Metro, the area’s
consolidated city and county government, uses the site to provide information on
its communications projects.32

Figure 8-6: Louisville (Kentucky) MetroSafe Web Site

Elsewhere, the state of Hawaii has found that web technologies can be used to create
an internal network (“intranet”) portal where employees can collaborate, create their
own web pages, and otherwise share information. It’s particularly interesting in that

32
See http://www.louisvilleky.gov/MetroSafe/.
 Chapter 8: Create a Project Plan
133
it’s built from freely available software components. The Hawaii Information and
Communication Services Division offers a short video demonstrating the portal.33

Commercial products drive most project portals that we’ve come across, however.
Microsoft SharePoint® web collaboration software is popular in agencies that use the
company’s office productivity and server applications. SharePoint is easily integrated
with those other applications, intuitive, and well supported by an army of value-
added resellers. There are even interagency collaboration tools for incident response
Hosted web sites built on the platform.
can be cost-
effective and simple As with any open source or commercial software of this complexity, initial setup
to manage. of web portals and system administration requires trained IT specialists. On the
other hand, there are an increasing number of portal hosting services. These online
businesses will provide World Wide Web access to your project web site hosted on
their computers.

Portal-hosting companies typically provide all the services you would have with
similar software purchased and installed on your own systems and networks,
although they can’t easily take advantage of any internal e-mail, calendaring, and
other office productivity services your agency has in place. This isn’t a critical factor in
choosing to use hosted portal services for interoperability project participants spread
across multiple jurisdictions. Costs are reasonable, too. Hosted SharePoint services,
for example, currently run from $20 to $75 and higher per month, depending on the
amount of document storage and network bandwidth needed.

Freely available Portals of any type still take considerable time to configure and manage—hosted
web services or otherwise. If that’s beyond your interest, skills, or available time, there are still
can help with options. At least one agency is using the popular web service Yahoo!® and its “groups”
interagency project feature for its multijurisdictional project to create a shared e-mail and chat services,
communications. file storage space, calendar, and even poll-taking capabilities.

If you need a few more project management capabilities, check out the simple hosted
services34 at Basecamp™. A single project for an unlimited number of participants can
be set up at no cost. Messaging, to-do lists, task assignments, and milestone calendars
are available, but you will have to pay a modest fee to get file exchange capabilities,
encrypted network access, and multiple project support.

33
See http://www2.hawaii.gov/dags/icsd/content/video/higovdemo_250k.asf. The state
of Hawaii portal is built on the freely available open source products COREblog™, Zope®, and
ZWiki™.
34
See http://www.basecamphq.com/.
 13 Part II: How Is Interoperability Achieved?

Graphically Communicating Roles:

The RACI Matrix
To be prepared is One final communications technique we would like to share is the use of a RACI
half the victory. Matrix—a matrix of processes and project roles (see example in Figure 8-7). The
—miguel De matrix itself is simply completed by entry of the letters R, A, C, and/or I to further
Cervantes indicate work duties or roles for listed activities. The initials stand for:

R Responsible Who does the work or owns the problem?

A Accountable Who signs off on or approves the work?

With these
C Consulted Who has information needed to do the work?

five pieces in
place—the scope I Informed Who needs to be notified of the results?

statement,
timeline,
budget, risk The work roles may be shared and an individual may have more than one. For
management, and example, the Steering Committee is broadly accountable for most project activities,
communications but in some cases also has to be consulted in depth for further information on a
plans—your subject. Implicit in the chart is that anyone accountable or consulted on work is also
project plan is informed of results.
complete…for
now! While it will
surely be a good Procurement Staff
Project Manager

User Committee

plan with all these

Matter Experts
Other Subject

Agency Legal

Agency Grant
elements, a great
Committee

Committee

Managers
Executive

Technical
Sponsors

plan is the one that

Steering

Agency

is up to date.
Staff

Activity
Create a decision-making structure A R
Create a project charter I A R I
Assess current business processes A, R C I C
Determine stakeholder needs A A, R C C C
Develop general system requirements I A, C R C I I
Evaluate buy versus build options I A, R C C
Set the project scope A C R C C
Develop the timeline A, C R C C I
Estimate and deliver a budget I A, C A, R C C C I C
Create a risk management plan A A, C A, R C C I
Communicate plans and progress I A R I I I I I

Figure 8-7: RACI Matrix Example

Courtesy of the 5 Star Team, http://www.5starteam.net
 CHAPTEr 9
ACqUIrE THE SySTEm COmPOnEnTS
 Chapter 9:
Acquire the System Components

What The structured, iterative process for acquiring the services and physical components
to create an interagency communications system, whether voice or data.

Why Communications interoperability usually requires new or additional systems

that have to be designed and procured. Lack of a well-organized process leads
to wasted time, money, opportunity, and goodwill between partners who are
dependent upon cooperation.

Who The project manager is at the center of system acquisition. Members of the Steering
Committee serve in additional roles, as do members of the working committees.
Special ad hoc teams are often necessary for legal, community relations, and
procurement assistance.

When Acquisition occurs once needs are defined and the initial project plan
is created. It proceeds through design and functional specifications to
procurement and contracting.

How is communications interoperability different from other types of

technology projects? While it’s rarely recommended for agencies to
create their own computer-aided dispatch (CAD) systems or records
management system (RMS) software from scratch, it’s inevitable that
radio projects require lots of detailed design and engineering. As with
any kind of technology project, multiagency efforts naturally add layers
of complexity through complex interaction of needs, financial abilities,
and procurement rules.
TECH GUIDE
This chapter builds on the Law Enforcement Tech Guide’s Part IV,
ORIGINAL

Acquiring the Technology. Chapters 14 and 15 of the original Tech

s Guide provide procurement and contracting advice that will serve you
well in your project. We won’t rehash those equally applicable details
here, but instead will focus on the unique aspects of interoperability
systems acquisition. Be sure to read and use the Tech Guide’s advice!
13 Part II: How Is Interoperability Achieved?

Public safety technology projects, in general, and communications interoperability

projects, in particular, are put at severe risk when they are approached merely as
a procurement exercise. The complexity of these projects requires an organized,
structured process for proceeding from the needs you’ve collected to a detailed design
and on to the often-expensive process of acquiring services and the physical parts of
your system.

There’s a direct correlation between how rigorously this phase of your interoperability
project is approached and its chances of success. Even if a large share of the
technology to improve interoperability between agencies will be purchased
from a single vendor, a solid process of defining, designing, specifying, and
buying the system is needed to manage both the project and the vendor.

One key way to manage such complexity is through iterative steps of design,
procurement, and implementation. Through a process of decomposing the work to be
done, more detail about the “system” is developed. All stakeholders learn more about
the components of the system and how they fit together. This progressive process
allows the project to be broken down into manageable pieces—some may be executed
entirely by the participating agencies and others through the help of communications
systems vendors and service providers.

Assumptions: We have to make some assumptions about your project. Not all
interoperability initiatives require massive system changes or new radio purchases.
Your project may be focused on the simple process of swapping radios between
agencies during an incident so each may talk to the other. It may be to program
channels commonly available between agencies in everyone’s radios. Here we’re
looking primarily at projects that eventually require that some additional or new
technology infrastructure be put into place.

Both voice and data systems follow the processes described here, though with data
systems there’s also an additional effort to find and implement software applications.

The process diagram (Figure 9-1) depicts the steps that have been recommended
that would lead your project up to this point. It shows the progressive process of
system development.
 Chapter 9: Acquire the System Components
139
Conception
Foundation Vision
Building Charter

Process Business Case

Interoperability
Baseline Needs Analysis
Assessment

Business Process Technology

Baseline Report Baseline Report
“As-Is” “As-Is”

Technical

Operational
Interface &
Organizational Integration
Functional
Requirements
Requirements

Needs Conceptual Design

Analysis “To-Be”

Process

Buy services
or
Build a system?

Build

Hire an Acquire an
Turnkey? No Yes
integrator? integrator

Buy
No

Engineering
Construction
Design and
Yes Implementation engineer
Acquire the
Quality Assurance
services and
Acquisition Acceptance Testing design products
Process
Develop functional specifications
for procurement

Procure the
technology

Figure 9-1: Design and Acquisition Processes

10 Part II: How Is Interoperability Achieved?

If they didn’t seem so before, the processes have to seem daunting now! Don’t worry.
We will break down the work needed to get from beginning to end into steps and
decisions to be made along the way.

It’s tempting to turn the checkbook over to the first vendor who offers big promises
to solve your interoperability problems. Don’t do it! As we’ve been saying all along,
interoperability isn’t primarily a technology problem. There are many organizational,
operational, and technical function changes to be made to improve interagency
communications in most regions of the country.

A final note before we get down to it: Improved interoperability results from improved
communications (in both technical and nontechnical senses) and cooperation. It
truly requires a system of related technical and nontechnical systems. The system
definition and acquisition phase of your project is one requiring particular attention
to managing relationships—not only between your operational partners, but also
with the communities being served by and paying for this initiative, as well as the
equipment and professional services vendors you’ll need as partners.

Manage the relationships. Don’t let the new system of systems ever become a divisive
influence, which happens when participants lose sight of the goals.

System Acquisition 101:

Groundwork
Any sufficiently There is a bit of groundwork to be laid before moving into actual acquisition of
advanced system components. Not every project will require all the work we’ll discuss, but large
technology is voice or data systems require most, if not all, because of their complexity. Indeed, if
indistinguishable your needs analysis discussed in Chapter 6 led to a decision to simply buy services to
from a rigged improve interoperability, as opposed to building new systems, then you’re moving
demo.
directly to the procurement steps described near the end of this chapter and in added
—James Klass detail in Chapter 14 of the original Law Enforcement Tech Guide.

Generally, you move into the acquisition phase of your project by first understanding
relevant procurement and contracting rules and how the project teams will be
structured and staffed. Through these steps, you’ll move from a conceptual design to
procurement and contracting.

Step 1
Research the Rules
Moving into any procurement, project decision-makers need to be aware of the rules
that govern it. The project manager bears particular responsibility. This can be quite a
challenge in large interoperability projects that span organizations, jurisdictions, and
 Chapter 9: Acquire the System Components
11
Don’t work yourself sometimes even state boundaries. They are increasingly funded through a complex
into an acquisition mix of grants, tax revenues, and fees that bring special challenges to management
corner by failing of the project budget. Not only do funding stipulations limit what can be purchased,
to understand under which processes, and in particular timeframes, but they also limit how
your agency’s
purchasing and
ownership can be shared across organizations. It’s easy to imagine how difficult
contracting rules, agreements between jurisdictions can be when joint or equitable ownership of shared
as well as those of system components for interoperability is impossible.
your partners.
There is a way to deal with the complexity: Get help!

We’ll touch on the array of teams that may be needed in a moment, but you can start
Today’s competitive by creating an ad hoc team of financial advisors from purchasing staff in each of
procurements are the key involved agencies. With their help, create a broad plan on how to meet all
so technologically agencies’ rules or, alternately, the project’s goals and objectives through financially
and administratively
complex that they
discrete procurements. For example, it may be clear that one set of rules applies
require advice from across the partners or that a couple key participants in the initiative can take on all
a multiplicity of purchasing responsibility.
sources, including
legal counsel and Before deciding how to proceed with system acquisition, consider that large
financial advisors. procurements can rack up significant internal costs—up to 5 percent of the
There are very
system cost.
real costs for this,
too—as much as
five percent of the Step 2
procurement, in our
experience. Form the Teams
With an idea of the amount of work involved and what share will be accomplished
—Steve Proctor
Executive Director internally, create the teams to carry it out. Consider and select members from
Utah across the participating agencies as broadly as you can. This requires knowledge of
Communications individuals and their abilities that you, the project manager, may not have. Turn to
Agency network Steering Committee members to help find talent from among their agencies. Talking
with them also provides the opportunity to get their agreement to commit staff time
to the project.

A suitable proposal All or none of these teams may be necessary, depending on the size and scope of
evaluation team your project. Keep in mind that project participants can wear multiple hats—if
for a turnkey they’re not already!
procurement would
comprise the same Two working teams are particularly useful at this point: The procurement and
members, but policies/procedures teams.
include fewer of
them.
n Procurement Team
Presuming there will be some purchase of services or technology for your project,
create a procurement team that will take responsibility for shepherding the process
 12 Part II: How Is Interoperability Achieved?

through selection of a procurement method, specifications development, proposal

evaluations, vendor selection, and contracting. The team may bring in expertise for
particular tasks—such as additional operational experts for developing functional
specifications or legal counsel for contract negotiations. However, they have a central
role to provide continuity through the entire process.

Select members who have some background with purchasing. The ins and the outs
of navigating a significant procurement aren’t skills most people are born with; they
come from experience. Ideally, that comes with real operational experience of using
radios as emergency responders, too.

n Policies/Procedures Team
The second team that can be kicked off right away is one to collect and meld
policies and procedures between partnering agencies. Start this process early
How agencies will because the learning process involved can well affect functional specifications for
work together any procurement. For example, if the agencies have or want a policy stating that
drives many a dispatcher must always be at the control point for connecting agency channels
procurement
physically or logically through a gateway device, that establishes a functional need to
functional
specifications. be specified. Alternately, if they would require that a communications technician, as
defined under the Incident Command System (ICS),35 be deployed during incidents
of a particular size or larger, a transportable gateway may eventually be chosen in
response to that functional requirement.

Clearly, the procurement and policies/procedures teams overlap. They may

share some members, but define them separately and have their work proceed in
parallel—both to make the most of available time and because the work does not
completely overlap.

MAKE A NOTE OF IT!

In order to keep your project focused on improvements in operations,
limit vendor access to team members. If necessary, use an agreement for
individual team members that requires them to direct all vendor inquiries
through the project manager or designee. Don’t risk team members
becoming advocates for particular technologies!

35
The Incident Command System, a key part of the National Incident Management System
(NIMS), will be discussed further in Chapter 12, Develop Policies and Procedures.
 Chapter 9: Acquire the System Components
13

SELECT TEAM MEMBERS CAREFULLY

In our experience, one key quality of a good project manager is the ability to pick the
right people for the right teams. Not all potential project participants have the people
skills necessary for good teamwork. Be careful with the engineering team; some of
the most technically adept technicians struggle in teams. Select members for the
engineering team who have no preconceived notions of the “best” technology and
who work well with their peers in other agencies. Avoid dogmatic members of the
engineering team—or of any team for that matter!

Other teams may be necessary through the acquisition process. Set these into motion
depending on what work you choose to take on internally and what you intend to
contract out.

n Engineering Team
Whether or not you contract for system design engineering, consider establishing an
engineering team, typically comprising those involved in the Technical Committee.
These people will either be responsible for or guide the engineering necessary for
radio projects much larger than a single voice repeater or wireless data access point.
Even in projects making new or additional use of existing systems, there is often an
engineering and optimization aspect involved that requires technical steering. In the
procurement process, the engineering team plays an important role in establishing
technical specifications, eliminating those that unnecessarily limit choice, and serving
later in the evaluation process.

n Construction Team
As you might guess, a team to deal with the peculiar design, procurement, and
implementation aspects of new physical radio facilities isn’t necessary in all projects.
look elsewhere in When it is, the skills of members are distinct. We’ll touch on the civil engineering
the participating aspects of some radio projects in the next section, but not every interior designer is
jurisdictions for qualified to excavate for a foundation or frame up a house.
civil engineering
and construction In addition to Technical Committee members who will have your best institutional
expertise.
knowledge of currently used and other potential radio facilities, look to your
jurisdiction’s construction and building divisions for additional expertise. In
many cases, the construction team has to oversee the work of contractors selected
specifically for radio site development, permitting, and navigating zoning mazes.
 1 Part II: How Is Interoperability Achieved?

n Public Relations Team

We looked previously at the importance of communicating with the public about
your interagency project to improve critical interagency communications. In the
acquisition phase, community relations are critical when you start building new
radio facilities. Try to put up a tower near an elementary school and learn a bit about
“contract negotiations”!

Turn to individuals within participating agencies who already serve this function.
It requires another distinct skill set and persons already doing the work no doubt
already have contacts and procedures for dealing with a multitude of community
relations issues. Your Steering Committee members may also be in management
positions suitable to help in this regard.

n Acceptance Team
We’re all looking for acceptance, right? Well, maybe so, but in the acquisition and
Use key members implementation phases, acceptance is the process of using mutually predetermined
of other project measures between contracting agencies and contractors to determine when work has
teams for the
been successfully completed. While this is naturally seen as an activity taking place
acceptance
process.
well into the process of building systems, there are at least two reasons for setting an
acceptance or quality assurance team into motion early on.

First, conditions for acceptance of work, whether services and/or technical

implementation, should be spelled out in the procurement process. Your vendors are
going to make sure they are spelled out in one form or another. It pays to go into the
procurement process with clearly defined measures of what successful completion of
an engineering design, construction management, or system optimization will be.

quality Second, the acceptance team can be seen as providing a quality assurance function.
management In the world of technology project management, quality assurance is the recurring
is a distinct process of guaranteeing in each phase that a project’s objectives are being followed
responsibility of and incremental measures of quality are being met. Ultimately, given the tools
project managers
developed through early project definition, conceptual design, detailed design, and
and is sometimes
outsourced in large functional specification, the acceptance team also functions in this role.
projects.
 Chapter 9: Acquire the System Components
1

THE HEAD COACH’S CHALLENGE

If you’re the project manager of a sizeable interagency communications
project, you may be looking at this list of potential teams beneath the carefully
crafted decision-making structure you’ve already created and think the project
might drown in a sea of organization charts. Don’t despair! While formal and
ad hoc working teams are brought together to do specific, task-level work,
they’re often composed of the same project participants—often most from the
project’s standing committees.

Your project management challenge here is to help team members understand

that they’ll wear different hats while working in separate teams, but the team’s
purpose is to take a focused task and carry it to completion. Distinguishing
specific teams emphasizes distinct areas of work to be done and helps
participants navigate the maze of tasks involved in large technology projects.

Manage the project’s timeline by carefully having these teams work in parallel to
one another. Clearly, the amount of overlap between members is going to affect
how much can be accomplished by them, but good project managers compress
timelines by having work done in parallel as much as possible.

System Acquisition 102:

The Art of Procurement
Throughout the previous sections of this chapter, we have been talking about
the work to be done to acquire a new system for improved communications
interoperability. Understanding what has to be accomplished and how to organize
the work will guide how you procure services and equipment. As we’ve mentioned, a
detailed examination of what’s involved—to the extent of designing a good share of
the system—guides your decisions on what tasks can or should be done internally and
what needs to be contracted.

The original Law Enforcement Tech Guide provides a veritable tour de force on the
subjects of procurement and contracting. Guidance there is entirely applicable to
radio systems and interoperability. We will step through its guidance in the following,
referencing specific locations for your broader review.

If your project is large or complex, you may have already chosen to contract out
some services. Systems design, integration and management services, and site
development can account for half or more of some systems, but for most projects, the
largest procurement effort is for equipment. Costs include its purchase, installation,
optimization, training, and initial operations.
1 Part II: How Is Interoperability Achieved?

The procurement process proceeds through four steps: Selecting the right
procurement tool, developing functional specifications, building criteria for
evaluation of expected vendor responses, and executing the process.

Step 1
Select the Tool
TECH GUIDE The most common procurement tool used for radio systems is the request for
proposals (RFP). The tool under one name or another is available to all jurisdictions.
ORIGINAL

176
It allows you to state requirements and functional specifications, and then allows
s
interested parties to propose solutions. The RFP is distinguished from an invitation
for bid (IFB) in the flexibility it allows vendors to propose solutions for evaluation and
the agency’s ability to negotiate costs based on what they learn.

The request for information (RFI) is occasionally used by agencies in radio systems
procurement, particularly to learn about technologies that can be considered.
The RFI process is less formal and time-consuming than an RFP because they
aren’t complete replacements for one another. An RFI may lead into a negotiated
procurement, but is most appropriately used to collect information for the more
formal process. In the rare cases where the RFI yields enough information to
conclude there is a single, suitable approach, your procurement rules may allow you
move to actual procurement.

Step 2
Develop Functional Specifications
We have talked about the need for functional specifications for acquiring
interoperable systems. In the procurement phase, these specifications are put to paper
in a form that will encourage thoughtful, often innovative proposals, yet allow you to
evaluate whether the proposed solutions will meet your needs.

TECH GUIDE
The degree of specification will hinge on how you’ve chosen to proceed with the
project. If you’ve chosen to go for a turnkey system, then functional specifications
ORIGINAL

179
will be limited to operational aspects of how the system will be used and managed.
s If you’ve chosen to bring in a systems integrator independent of equipment
manufacturers, you will have a standard set of specifications from the integrator to
work through and select from.

Functional specifications naturally flow from the organizational, operational, and

technical requirements developed in your needs analysis phase. The Law Enforcement
Tech Guide provides further guidance on how specifications for the procurement are
chosen and worded.
 Chapter 9: Acquire the System Components
1

SOLE-SOURCE PROCUREMENT
While it’s often tempting to go straight to a single source based on what you already
know about radio systems, recognize that there’s great value in maintaining competition
and options in any procurement. Use them to your advantage. Don’t rely on expected
goodwill alone to deliver your agencies the best options at the best prices. Recognize
that grants place significant additional procurement burdens on any sole-source
purchases they are used for. See the original Law Enforcement Tech Guide, Page 178,
and/or the Law Enforcement Tech Guide for Small and Rural Police Agencies: A Guide
for Executives, Managers, and Technologists, Chapter 5, Understanding Procurement
and Contracting http://www.search.org/files/pdf/SmallRuralTechGuide.pdf.

Step 3
Build Evaluation Criteria
Criteria for evaluating proposals and selecting the winner likewise flow from your
specifications. They also arise from the value your agencies place on other factors.
For example, your functional specifications may not have anything to say about the
vendor’s qualifications, but experience, stability, and record of success are key criteria
for evaluating radio system vendors that will provide critical technology for your
interagency communications needs.

You hope that the operational needs you’ve outlined and the functional specifications
you’ve stated will lead to evaluation criteria that are carefully aligned with your
agencies’ standard operating procedures (SOP) and incident response plans. For
example, your policies/procedures team may have brought requirements to the
table as to how the system has to work. They may have brought specific functional
requirements for how a piece of equipment works, its electrical characteristics (such
as “Intrinsically Safe” portable radios for use in potentially explosive atmospheres), or
other physical characteristics. It’s also possible that your agencies have performance
standards for particular work, such as the amount of time and effort required of
dispatch to set up a patch between two channels.

TECH GUIDE These SOPs and elements of response plans should guide evaluation criteria. Other
ORIGINAL

181 examples of appropriate criteria and how they are presented are included in the Law
Enforcement Tech Guide. These criteria are carried into a weighted evaluation process
s
where particular, predetermined factors are accorded greater value than others based
on your own sense of what is important.
1 Part II: How Is Interoperability Achieved?

Step 
Carry Out the Process
Whew! With all this work out of the way, it’s actually time to carry out the
procurement! Unless you’ve been involved in similar projects before, the amount
of work involved in getting to this point may have come as a surprise. Trust that it’s
all important to get you where you want to be: better interagency communications
through your voice and data systems.
TECH GUIDE
Your jurisdiction’s procurement rules, those of partnering agencies, and those
ORIGINAL

182
brought as conditions of other funding sources determine the actual steps taken to
s release the procurement, await responses, collect proposals, step through evaluations,
and make a selection.

Cost is bound to be one of your greatest considerations, of course, although RFP rules
for most jurisdictions don’t require that it is necessarily the predominant factor in
making a selection. As a matter of fact, that’s a key reason why you created detailed
evaluation criteria. It’s not uncommon for cost to be half of the total points accorded
proposals for radio systems.

Recognize that prices can be brought down 5 percent, 10 percent, and even more
through negotiations, which we will talk about next. Through a formal and detailed
procurement process, you will get sufficient information in responses to your RFP
to decide how to proceed, even if the total proposed cost is well beyond what you
expected. Believe us, it happens!

Though you may have to go through a process known as “best and final offers” to
further winnow out the selection, eventually you get to the point of identifying an
apparently successful proposal. This will lead to negotiation of one or more contracts.

System Acquisition 103:

Create the Contract(s)
You’re almost ready to move to implementation, which is what you have probably
been anticipating since being asked to take on this project. However, the contracting
process is perhaps the most delicate part of your entire project, so proceed carefully.
It’s entirely possible for a poor contract not only to put your whole project at
dire risk, but also the money, work, and goodwill that agencies have brought to
the project up to this point. Don’t risk everything by either forcing through a bad
contract or accepting one out of haste.
 Chapter 9: Acquire the System Components
19
TECH GUIDE The Law Enforcement Tech Guide dedicates an entire chapter to this subject. It is
ORIGINAL

187 entirely applicable to your interoperability project. We’re not going to repeat its good
lessons here, although we do have a few tips to pass on when it comes to dealing with
s
these specific types of projects.

Learn to negotiate or use professionals. It surprises us to see law enforcement

agencies that are adept at the very serious process of hostage negotiations simply
cave in when it comes to negotiating with technology vendors! Take the contract
negotiations process seriously and turn to professionals, if necessary, to look out for
your best interests.

Know your vendor. More than other types of information technology, radio systems
are dominated by relatively few vendors. While this limits your options in some
cases, it does provide better opportunities for understanding them. This provides for
both better management of the project on your part and negotiation of contracts, in
general.

Find out all you can about their marketing and sales cycles. All have particular
Know your vendors’ strategies for product lifecycles and managing sales. These strategies affect how you
marketing and sales will deal with the vendor, one hopes to your advantage. Since they will most certainly
cycles. affect the cost and capabilities of your system over time, it pays (literally!) to know
about them at this point in your project.

In real estate, there are “motivated” buyers and sellers. From the contract negotiation
standpoint, it’s invaluable to know your vendors’ “motivations.” The sales staff
assigned to your procurement will undoubtedly be paid in part on commission. The
amount of your contract has a significant impact on what they, personally, take home
through the contract.

A common motivation of all vendors is, of course, maximizing profit and

vendors prefer avoiding costs. One they prefer to avoid is the hard cost of bonding. Your agencies’
penalty clauses procurement rules may require it, but vendors would much rather be compelled
to bonding under contract by penalty clauses than bonding requirements because they can
requirements that
avoid costs by carrying out the contract well—which is in both parties’ interests. Any
increase costs
even for successful invocation of penalty clauses typically gets lots of attention through a vendor’s chain
projects. of command. Knowing that the vendor’s staff are subject to that level of scrutiny can
be useful during implementation.

In the process of managing the project, any situation that requires invocation of
bonding clauses and collection on the agencies’ part ultimately removes the ability
of the respective agency and vendor project managers to negotiate. Do all you can in
managing the project to avoid ending up in this circumstance.
 10 Part II: How Is Interoperability Achieved?

Prepare to transition maintenance of the technology. The larger your project,

the more likely it is that you will enter into some form of maintenance agreement with
your vendor. If you plan on maintaining some or all the system yourself, recognize
that vendors that offer maintenance services have a natural interest in selling those
services. Carefully define maintenance responsibilities and any eventual transition of
responsibility to your staff. Include specific language in the contract about expected
skill levels of staff to maintain the system if the vendor provides that training.

The best deals Use your knowledge of the vendor’s sales cycles to negotiate the best deal.
can be negotiated Typically, better deals can be made if you time the proposal release, evaluation, and
in December. award cycle to mesh with the calendar year. Contracts signed in December often
Equipment prices yield the best prices because vendors and sales people are nearing the end of the tax,
can vary by 5
corporate reporting, and sales commission year. They are typically more motivated to
percent based on
the time of year.
sell at the end of calendar quarters, especially the end of the year.

Recognize that vendors do not want to come back to the bid table multiple times if
they can include more under a larger procurement. Some large systems’ vendors pay
commissions based on “tonnage”—the total cost of the procurement. They also have
more pricing flexibility on soft costs. It may seem odd, but the cost of the system and
its profitability to the vendor are only loosely related. The effect is that in negotiation,
you may be able to get concessions on more profitable items in exchange for ones with
less “markup” as long as the bottom line isn’t greatly affected.

Recognize how quotes are assembled. Look for costs that are added as extras or
vendor-provided
that could potentially be done by someone else. An example is training. There is often
training can be very
expensive—check flexibility built into these cost quotes and the potential for good profitability on the
quotes carefully. vendor’s part. Consider if you really need their particular training for all proposed
aspects and be prepared with the costs of alternatives when you go into negotiations.

Similarly, look for costs that are split out separately, but couldn’t possibly be
contracted separately. Our favorite example is system installation, configuration, and
optimization. While it’s logical to use these as separate milestones for payment, for
most radio systems it’s hard to separate them out as independent tasks that could be
accepted or rejected in the contract negotiations process.

Recognize your vendors’ internal processes. For better or worse, large commercial
organizations have a lot of bureaucracy. Sometimes this can work to your advantage.
First, so much of contract negotiations has to do with the vendors’ and the agencies’
internal rules of procurement that there’s a lot of work to be done between
contracting professionals and legal counsel. Don’t use a lot of your procurement
team’s time and energy in that process; break it out as separate work in actual
negotiations.
 Chapter 9: Acquire the System Components
11
Second, recognize that the vendor’s bottom line profitability on your project may
not be affected by concessions their project manager is able to make. For example,
at least one manufacturer of equipment has a standard markup on portable radios
of approximately 10 times. That is, the retail cost will be approximately 10 times the
cost of manufacture. During the project, the vendor’s project managers are afforded
the ability to bring additional equipment to the customer to compensate for delays,
disputes, and the other typically unpleasant details of projects.

To avoid invocation It’s particularly valuable for you to know if your vendor accounts for this cost in
of penalty clauses, the project’s bottom line at retail or at the cost of manufacture. At least one large
vendors may manufacturer accounts for it at the cost of manufacture and without significant
provide additional impact to the project. This provides the vendor’s project manager great flexibility in
equipment at cost.
avoiding penalties that may be built into the contract.

With any luck, you will get through negotiations with an agreement that keeps both
your project and the vendor’s interests intact. The contract will be the basis for much
work yet to come, so make sure it serves your purposes and gives you the project
management leverage you need to succeed in successive steps.
 CHAPTEr 10
ImPlEmEnT THE SySTEm
 Chapter 10:
Implement the System

What System implementation is the process of installing, integrating, testing, and accepting
procured technology. Training users and support personnel is key to integrating
technology into agency response procedures.

Why A formal implementation process provides all project participants, including vendors,
a clear blueprint for building an interoperable system of systems. Failure to follow
an implementation plan leaves the procurement and entire project at risk of failure
through miscommunications and divergent expectations.

Who The implementation plan is created by the project manager in cooperation with the
vendor’s project team and through further effort from working groups. The Steering
Committee reviews, approves, and submits the plan to executive sponsors for final
approval before implementation begins.

When Formal implementation starts as soon as a contract has been negotiated and project
teams are in place.

Part V of the Law Enforcement Tech Guide addresses implementing

technology acquired through the preceding procurement phase. The
format and elements of implementation plans are dealt with in depth
in its chapters, as is acceptance testing. Here, we will address specific
TECH GUIDE
aspects of implementing communications technology for improved
ORIGINAL

interagency communications and its integration into existing systems.

s
Chapters 16 and 17 of the Law Enforcement Tech Guide cover the
implementation process in technology projects.

Implementation is the most exciting time for project managers. Many plans and much
work comes together during implementation to actually improve communications.
Up to this point, there has been a lot of envisioning, but few tangible results outside
of paper. Implementation is the time when technological and operational pieces come
together to create systems.
 1 Part II: How Is Interoperability Achieved?

Prologue to an Implementation
Implementation of the system of systems we have described requires that you,
your vendors, and your project teams all work together toward well-defined ends.
In the implementation phase, definition of those ends requires clear roles and
responsibilities, an implementation plan, detailed documentation, and an acceptance
test plan. Because the value of any system is directly related to how well it is used,
training according to established or newly created procedures is a critical part of
implementation.

Further Define Roles

The implementation process has two sets of roles: Yours and the vendor’s. This final
phase of the project really does entail a partnership. Previously, you managed vendor
relationships from a distance to keep the focus on operational outcomes of the project
and to protect the integrity of the process. Now is the time for their efforts to bring
technology to your interagency communications needs.

How you approached procurement drives implementation. If you contracted for a

turnkey system, most responsibilities have been left to the vendor. If, on the other
hand, you chose to handle system integration yourself, the implementation plan will
contain many more tasks for you and the project teams.

n Your Roles
As the project manager, consider yourself the CWO (chief wellness officer). You’re
vendors become responsible for assuring the project is well-founded, well-defined, well-planned, well-
stakeholders once communicated, and now well-implemented. Consider that in this phase you have new
contracts are
signed.
stakeholders: Your vendors. Obviously, their stake in the project is clear, but like other
stakeholders, they depend on your success in carrying out these responsibilities.

You have one primary and three oversight responsibilities in implementation:

Creating the implementation plan comes first, followed by oversight of
documentation processes, acceptance testing, and training. Of course, you also have
the ongoing role of managing the project in its entirety. As we’ve mentioned, that
entails continued communications with stakeholders, managing timelines, budgets,
and scope, and now contract management. If it seems like a big job, well, it is!

Your implementation plan details how the project’s work is going to get done. That
requires a number of decisions about who takes care of what. While you may be tired
of plans by now, rest assured that most of the work for the implementation plan is
already complete. We will talk further about creating the plan in the next section.
 Chapter 10: Implement the System
1
Documentation should be planned and managed throughout a project. In the
implementation phase, documentation created by vendors and your project teams
will serve project goals long after the system is up and running. Your added project
management role during this phase is to oversee its completion.

Acceptance testing is the process of verifying that components and the system, as
a whole, function as specified. You may have considered requiring an acceptance test
plan as part of the request for and evaluation of proposals. We didn’t recommend it
earlier because most procurements for communications systems proceed as requests
for proposals (RFP), which implies that a good deal of flexibility in proposed solutions
is allowed. Acceptance plans may be very different across solutions offered, making
them difficult to comparatively evaluate.

We do recommend, however, having vendors develop acceptance plans as an early

deliverable. They can be built in parallel to creation of the implementation plan.
Details to be considered and some examples are presented later in this chapter.

Training is absolutely critical to successful implementation of any technology. Too

Training is the often technology is bought and left underutilized due to a lack of training on it for
key to successful users and those who would maintain it. It is the project manager’s role to include
implementation. training in the implementation plan. This includes training for both technicians who
will maintain the systems and for users who will put it to work.

n Vendor Roles
Your vendor or vendors will appropriately participate in creating the implementation
plan. Their roles will have been made very clear through execution of contracts, but
Details of vendor
work will be set
further details of work will be left until now to establish. There are further tasks to
primarily by your define, activities to coordinate, and resources to schedule.
contracts.
Of course, the central vendor role is to install, customize, and activate the technology
it is providing. Since you may have contracted for other vendor services, such as
engineering and quality assurance, roles between vendors are important to define in
the implementation plan.

Both you and your vendors have roles in implementation planning.

1 Part II: How Is Interoperability Achieved?

TECH GUIDE
Establish the Implementation Team
As discussed in the Law Enforcement Tech Guide, the implementation team consists of ­
ORIGINAL

207
both your project manager and those of the selected vendors. In effect, they have their
s own projects that now intersect with yours. Remind the team, if necessary, that there
is one central project—yours.

Other teams may be needed for different parts of the implementation. Common ones
include policies and procedures, construction, training, and acceptance. Depending
on your project, these and other working teams may be needed to focus work where
specific expertise is needed.

There’s no need to create separate teams just for the sake of creating teams. Do so
to maintain a reasonable span of control. Management texts stress that, as a rule of
thumb, one manager can oversee three to six direct reports. As project manager, you
have demanding communications roles in all directions, so don’t make the mistake of
failing to delegate work through teams when needed.

Your Steering Committee and executive sponsors are ultimately part of the
implementation team. The Steering Committee should play an active role in reviewing
the implementation plan and evaluating contractor performance. Executive sponsors
must approve this very critical plan and make the final acceptance. In most agencies,
final signoff on incremental payments for large contracts will be required of agency
chief executives.

Create the Implementation Plan

As you might guess, the implementation plan is central to, well, implementation.
You’ll be pleased (relieved?) to know that we suggest using parts of other project
documentation completed in previous steps to populate the implementation plan.
This plan will mainly be a collection of parts from previous work brought together in
a focused format for implementation.

Implementation Plan Elements

TECH GUIDE The Law Enforcement Tech Guide lays out a basic implementation plan that is
ORIGINAL

207 fully useful for voice and data interoperability projects. It suggests organizing
the plan into four chapters that summarize the project, laying out its
s
organization, the implementation management process, and then details of
work, schedule, and budgets.

The radio aspects of communications interoperability projects bring additional plan

elements. Figure 10-1 lists the standard topics of each chapter.
 Chapter 10: Implement the System
19
Chapter 1 Chapter 2 Chapter 3 Chapter 4
Project Summary Project Management Work, Schedule,
Organization Process and Budget Tools
Overview Plan approval process Project objectives Select contract exhibits
Definitions Organizational structure Assumptions/ Logistical
Deliverables Responsibilities Constraints considerations
Audit trail Relationships between Risk management plan
vendors Staffing plan
System management
transition

Figure 10-1: Implementation Plan Outline

n Project Summary
This first chapter of your implementation plan includes a simple overview
paragraph, definitions of key terms that could be misinterpreted, and a list of
deliverables taken from your contracts. The overview and definitions could be taken
from your procurement documents as well, if you previously fleshed out an RFP or a
request for information (RFI) in that level of detail. Include an audit trail block at the
beginning of this chapter to log changes to this document over its lifetime.

n Project Organization
The second chapter details the plan approval process. Address how it is approved
initially and how changes will be managed through implementation, with a statement
of authorities and responsibilities. The approval process can be lifted largely from
your project plan.

Address how project changes will be requested and approved. Clearly describe the
approval process for change orders! Unmanaged, changes can creep into projects,
Clearly describe the
approval process distorting your original plans. One of our favorite project managers refers to change
for change orders! orders as ka-ching orders—as in the sound of a cash register racking up another sale.
You’ll want to carefully manage project changes during implementation because they
will have an impact on its timeline and/or cost.

Remember that you have new players who will also need to know your project
structure. Provide them with your organizational structure for this phase, adapted
from the project plan. Request and include the vendors’ organizational charts for the
project as well.
10 Part II: How Is Interoperability Achieved?

Describe implementation team member responsibilities and roles, including those

between various contractors, if more than one is used. As mentioned in the original
Law Enforcement Tech Guide, carefully lay out relationships between vendors and
responsibilities for subcontractors as defined in your contracts.

Conclude the project organization chapter by addressing system management

transition. Describe how a transition of responsibilities from the vendor(s) to
your team will occur. Computer and radio systems of ever increasing complexity
go through a cycle of installation, integration, and optimization during which
vendors initially take all responsibility for system management. That responsibility is
transitioned to your staff or whoever will manage it over time—sometimes another
contractor, such as a regional radio service company. The transition process should be
documented here.

n Management Process
Use the third chapter to document details of how the project—and this phase—will
further be managed. Pull the objectives from your project plan for inclusion here.
They serve to inform others in the team about what is being accomplished through
this implementation of technology.

Also include assumptions and constraints from your project plan with any changes
that have arisen through the procurement process. For example, the proposed system
design may have required compromises on coverage in order to remain within the
project’s budget. This would lead to constraints on original objectives that will change
acceptance tests.

If you’ve followed our recommendations, you will be able to insert an up-to-date risk
management plan in this chapter from your broader project plan. It’s fair to advise
all team members, including contractors, what you have considered as potential risks
to the project, how serious you consider them, and what your strategy is for dealing
with them. Include appropriate information out of your contracts on any penalties
clauses and dispute resolution processes.

The final piece of this chapter is a staffing plan. Include information consistent
with your project organization chart that shows who will be assigned to various tasks
during different periods. Because the timing of your personnel resources for meeting
with contractors, escorting them to radio sites, conducting acceptance tests, and such
will be heavily dependent on vendor timelines, you will need firm ones from them
before being able to document your own commitments.
 Chapter 10: Implement the System
11
n Work, Schedule, and Budget Tools
The final chapter of the implementation plan is dedicated to the details of work to be
accomplished. If your contract is with an established vendor and the project is of any
significant size, this detail will have been negotiated prior to signing contracts.
Budget Tip: The
Final Payment Include here select contract exhibits, such as the initial project schedule, the budget
Contractors will and payment schedules, and an outline of the acceptance testing process. Keep in
appropriately mind that not all members of the implementation team will have ready reference to
expect to be paid actual contracts, so it is useful to include these items in the guide that they’ll be using.
for labor and
materials as parts
Since acceptance testing can be a very detailed process as we discuss in the next
of the system
are accepted.
section, an outline here will serve to describe it for the general understanding of all
Part of your duty team members.
during contract
negotiations was Unless you are proceeding with a turnkey implementation, use this opportunity to
to arrange fair define the process of handoff of responsibilities between vendors. Add milestones
compensation in your project schedule describing these events. For example, a consultant hired to
for work while
prepare an engineering design will go through a draft, review, and finalization process
protecting the
agencies from with you before the design is handed off to contractors to build the systems.
paying for an
incomplete Conclude this chapter and the implementation plan by addressing logistical
product. Payment considerations that will be faced. Large voice and data projects can involve a lot
milestones should of equipment that needs to be shipped to various sites. The logistics of who, when,
be linked to and where equipment is received, inventoried, stored, and eventually staged for
acceptance and at
installation are important details for a smooth-running project. Take the time to deal
least 10 percent of
the contract should with these details now before you get behind the curve.
be held until after
final acceptance.
This prevents BudgEt tip: BEnEficial usE
implementations
from dragging on Contractors will also appropriately expect to be paid when you put the technology
when there is only to the work it was intended for. This doctrine—probably a contractual element—of
a bit more work beneficial use is used to trigger payment milestones, as well as to start the warranty
necessary to have a and maintenance cycle clocks ticking. The trouble is that it’s rare with complex systems
functional system, to just “flip a switch” and make everything come live.
as specified by the
contract.
Implementation more often proceeds in fits and starts. Some functionality exists before
the complete system you contracted for is available. Obviously, you don’t want warranty
clocks ticking for 100 percent of your equipment when only 10 percent of it is in use.
Use of multiple
vendors requires Careful definition of “beneficial use” during contract negotiations
additional hand-off will provide leverage during implementation and better value from
milestones in the your equipment.
project timeline.
12 Part II: How Is Interoperability Achieved?

Sign, Seal, and Deliver!

That’s it for the implementation plan. It should pass to the Steering Committee for
review before submittal to the project’s executive sponsors. If you have involved
the project’s working committees and built teams to assist with the variety of work
discussed, the approval process will be smooth. Once approved, the plan is ready for
delivery to all implementation team members.

Manage Documentation
The volume of documentation that can be generated with technology projects is
amazing. You’ve probably already had to buy a new bookshelf just to hold the project
planning documents! It’s only just begun, though, because documentation is critical in
the implementation phase to assure both its proper management and your agencies’
ability to use the system over its lifecycle.

Six sets or categories of documentation are completed through the implementation

phase: Project, as-built, system, equipment, procedures, and training.

n Project
It probably comes as no surprise that project documentation would be mentioned
here first. The implementation plan is the central piece from this phase. Since you can
expect it to change during implementation—that’s inevitable!—anticipate capturing
the details of changes proposed, accepted, or rejected in the audit trail of your plan.

Other important project documentation to capture is all communications with

contractors, particularly those involving decisions by one party or the other. Rely on
a disciplined process of capturing all paper and electronic communications for the
project record. In larger projects, create a formal communications plan and keep a
log. Contractual changes can generate a lot of documentation that’s important—and
probably required by your procurement and legal advisors.

n As-built
Depending on your project, as-built documentation includes engineering diagrams,
site plans, shelter floor plans, equipment rack layouts, and other depictions of
technical aspects of your system. Narrative and other textual information is
usually combined with a multitude of diagrams to literally draw pictures of what
your system looks like, as built. While much of this information may have been
developed during system engineering, its completion during implementation is an
important deliverable.

Vendors are typically tasked with completion of as-built documentation. Plan to

prepare similar documentation if you take on some responsibility in technical
 Chapter 10: Implement the System
13
implementation. For example, if you have retained responsibility for providing sites
that a radio vendor will use, be sure to include up-to-date site and shelter floor plans
in your final system documentation. You will thank yourself later for having done so!

n System
System documentation is related to as-built, but focuses on the system’s technical
aspects more broadly. It may include the following:
— Logical system diagrams and process flow charts
— Backbone connectivity diagrams
— Disaster recovery procedures
— Maps of sites relative to the involved jurisdictions
— Documentation of predicted and measured radio coverage
— Installation and maintenance standards
— Electrical power service procedures and contingencies
— Location of and procedures for using spare equipment
— Logical mapping of channels and talkgroups
— User radio programming and channel assignments
— Other hardware and software configuration and tuning parameters
— Site permits and frequency licensing information.

n Equipment
Vendor documentation of all equipment procured and used in the system should
be collected, cataloged, and distributed as needed. Quick reference materials either
available from the vendor or created by the project team fall into this category.
Original equipment specifications, warranties, and installation information can be
kept as separate pieces of the broader system documentation.

Portable and mobile radios often arrive en masse, are unpacked, inspected,
inventoried, and prepared for installation or distribution. Collect user guides from
end-user equipment to distribute during training.

n Procedures
Both technical and operational procedures are included in implementation
SOP development documentation. On the technical side, equipment installation and programming
and management is procedures are important, as are preventative maintenance schedules and procedures.
covered in
Chapter 12. Standard operating procedures (SOP) for both technical and operational use
of the technology are an important part of documentation. We will discuss
development of operational use of procedures in more detail in Chapter 12,
Develop Policies and Procedures.
 1 Part II: How Is Interoperability Achieved?

n Training
If training is the key to your successful implementation, then you have to expect
rely on the to document up front what is to be done and what has been done. Training plans
project working
encompassing technician, dispatcher, and field user needs are often outlined in
committees
for training procurement documents and further detailed during implementation. Your training
documentation. documentation during the implementation phase should also include all materials
used by vendors in their contracted training.

Rely on your User and Technical Committees to create training plans and organize
ongoing documentation. Documentation of who received what training, and when, is
important for all emergency services skills, including communications.

Use Quality Assurance and Acceptance Tests

The next major step in preparing for implementation is developing acceptance tests.
TECH GUIDE These tests are part of a quality assurance (QA) process that verifies the project is
meeting its objectives. They provide a signoff that a vendor has met some term or
ORIGINAL

213
terms of its contract. The Law Enforcement Tech Guide provides a chapter dealing
s with developing QA tests that evaluate vendor and product performance. Acceptance
testing is the process of assuring that quality measures have been met through
discrete tests of hardware, software, subsystems, and ultimately the system as a
whole.

make acceptance Establish creation of acceptance plans as early vendor deliverables. While most
plans as early testing and all acceptance is your responsibility, of course, you may be able to adapt
vendor deliverables.
standard test plans that your vendor provides.

Evaluate the standard plan, then take the time to develop these plans further by
removing any elements unrelated to your implementation. Add others central to your
Adapt canned functional specifications. Through an iterative effort, you will be able to establish
test plans to your an acceptance test plan that meets your needs and provides project QA. A good test
project. plan adequately and accurately tests the technology as proposed by the vendor and as
contracted for.

In large projects, it makes sense to refine acceptance tests through multiple phases.
For example, an early phase of a wireless local area network (WLAN) implementation
may target the central facilities of the involved agencies, while leaving outlying
stations for later. Development and use of the acceptance plan in the first phase will
likely lead to changes for subsequent phases. If you choose that option, make note of
it in your implementation plan. Remember: the more money involved, the more is
riding on the acceptance process, and the more planning that is needed.
 Chapter 10: Implement the System
1
Testing
In conducting the acceptance tests, user involvement is important for successful
implementation—and a successful project. Your acceptance team will probably be
composed of some project participants who have been involved from the beginning.
It should include members of the User and Technical Committees who will be
responsible for verifying that the project’s requirements are met.
TECH GUIDE
As discussed in the Law Enforcement Tech Guide, there are three common benchmarks
ORIGINAL

214
for testing technology: Functionality, reliability, and performance. Systems
s implemented for communications interoperability that make use of radio technology
also usually include special performance testing for coverage.

n Functional Testing
Functional tests are designed to ensure that the equipment and subsystems work
as advertised and proposed. It may take place when the system is staged, after it
Staged testing is installed, or both. Large system implementations commonly require that the
helps minimize equipment vendor stage, or assemble, equipment at the vendor’s facilities where it is
costs for large then tested for functionality. This provides some integrated testing of the vendor’s
systems.
offerings. Staged testing helps minimize costs for large systems by providing a
controlled environment where subsystems are immediately accessible—as opposed to
being on a mountaintop somewhere!

Final functional testing takes place once equipment is installed. The vendor
repeats the tests performed in staging and conducts additional tests arising from
the equipment’s integration into its physical location and other systems. For
example, radio systems are very much dependent on their antenna subsystems.
Functionality of some aspects of the radios can only be adequately tested once
the equipment is in place, antenna systems installed in their final locations, and
other subsystems integrated.

n Reliability Testing
Reliability testing typically requires some sort of simulation. As discussed in the
Law Enforcement Tech Guide, software can be tested for reliability through use of
special applications designed for this very purpose. With hardware, including radio
equipment, time is the only reliable reliability test.

Systems, as we’ve discussed them here, are a complex of software, hardware, and
human aspects. The inanimate parts form their own subsystems that can be tested
by simulating “faults” between components. For example, a shared mobile data
system with a single mobile server, but multiple agency CAD and RMS connections,
could be tested for reliability as the connections to the agencies’ information
systems are broken. This would show how other parts of the system perform under
less-than-ideal conditions.
1 Part II: How Is Interoperability Achieved?

Similarly, radio components may be tested as they lose backbone connections

between sites, power, or even antenna system connections. Advanced systems use
active networking monitoring techniques and devices for detecting faults. Conduct
functional testing of these subsystems while forcing system faults to conduct
reliability testing elsewhere.

Each testing step toward implementation constitutes further integration testing.

n Performance Testing
The third stage of acceptance testing involves getting right down to measuring how
well the technology meets the operational requirements driving its procurement.
Subsystems, such as backbone networks connecting radio sites and other fixed
facilities, can be incrementally tested for performance. On the other hand, final
performance testing requires that all subsystems be installed, configured, optimized,
and integrated.

Performance testing of potentially wide-ranging, multiagency systems for

communications interoperability can be challenging. Consider using limited
exercises once equipment is installed and training conducted. Appropriately timed,
exercises can serve as near-real performance tests leading to acceptance. Full-scale
exercises can be the next best (worst?) thing to an actual emergency to stress-test
communications systems.

n Coverage Testing
A type of performance testing peculiar to radio systems is coverage testing. Radio
coverage testing involves field measurements of signal strength and a healthy dose
of science mixed with probability statistics. Without getting into the heavy details,36
radio coverage varies greatly based on distance and intervening obstacles between the
transmitter and receiver. Obstacles can be everything from buildings to the human
body. It also varies over time at any given spot. Radio system designers work to
account for these variations in predicting coverage.

36
The accepted standards for coverage testing are defined in the Telecommunications Industry
Association (TIA) Telecommunications Systems Bulletin TSB-88, “Wireless Communications
Systems, Performance in Noise- and Interference-Limited Situations, Recommended Methods for
Technology-Independent Modeling, Simulation, and Verification.” Note that this is not a formal
standard, but an accepted technical methodology. For more information, see
http://www.tiaonline.org/.
 Chapter 10: Implement the System
1
Typically, public safety agencies specify coverage requirement as a percentage of a
geographic area under certain conditions and to a certain level of audio quality, such
as the following:
95 percent coverage of the city is required for a Delivered Audio Quality (DAQ ) of 3.4
with portable radios carried outdoors at the hip, for both transmit and receive.

It’s not a matter Obviously, coverage testing during implementation to verify this is going to take some
of simply driving technology, statistics, and work. It’s not a matter of simply driving around saying,
around saying,
“Can you hear me now?”
“Can you hear me
now?”
If your project requires it, coverage testing is not something to be taken lightly! It’s
one of those areas of implementing technology for which you should hire qualified
assistance if you don’t have the expertise internally.
1 Part II: How Is Interoperability Achieved?

Sample Functional Acceptance Tests

While this incremental process of testing should be understandable, there’s nothing like
examples to make them real. Figure 10-2 shows a few of the functional acceptance test pro­
cedures used by the City of Mesa (Arizona) in implementing its trunked radio system. Many
more in each category were used, as were yet more categories of procedures. Each proce­
dure was accompanied with the required setup process to assure that resources needed for
the test were prepared. This plan was provided in draft by the vendor and worked out in
detail with the agency through implementation planning.

As each test was successfully completed, team representatives from the agency and the
vendor signed off on it with any additional notes memorializing the test.

Site Trunking
Feature Description Test
When a site goes into site trunking, Step 1. Place Site 1 into the site trunking mode.
radios with talkgroup call capability Step 2. Initiate a talkgroup call with RADIO-1 on Test TG 1 at Site 1.
Talkgroup Call
Site Trunking

will be able to communicate with

Step 3. Observe that only RADIO-2 will be able to monitor and respond to
other members of the same talk-
the call.
group at that same site. Members
of the same talkgroup at other sites Step 4. Initiate a talkgroup call with RADIO-3 on Test TG 1 at Site 2.
will not be able to monitor those Step 5. Observe that only RADIO-4 will be able to monitor and respond to
conversations. the call.
Call alert is a tone page that allows Step 1. Place Site 1 into the site trunking mode.
a user to selectively alert another Step 2. Using RADIO-1, press the alert button.
radio unit. When a site is in site
Step 3. Enter the Unit ID of RADIO-2 with the keypad, or scroll to the
trunking, Radios at the site will
Call Alert

location where this ID is stored.

only be able to call alert other ra­
dios at the same site. The initiating Step 4. Press the PTT to initiate the call alert.
radio will receive notification from Step 5. Verify that RADIO-2 received the call alert.
the trunked system as to whether Step 6. Exit the call alert mode and return to normal talkgroup mode.
or not the page was received by the
target radio.

Figure 10-2: Excerpts from City of Mesa (Arizona) Acceptance Test Plan
 Chapter 10: Implement the System
19
Wide Area Trunking
Feature Description Test

Radios with talkgroup call capabil­ Step 1. Initiate a wide area call with RADIO-1 in Test TG 1.
ity will be able to communicate Step 2. Observe that only RADIO-2 will be able to monitor and respond to
with other members of the same the call.
talkgroup. This provides the
Step 3. Initiate a wide area call with RADIO-3 in Test TG 2.
effect of a private channel down
Talkgroup Call

to the talkgroup level. This test Step 4. Observe that only RADIO-4 will be able to monitor and respond to
will demonstrate that a talkgroup the call.
transmission initiated by a radio
user will only be heard by system
users who have the same talkgroup
selected. As with other types of
calls, talkgroup calls can take place
from anywhere in the system.
Digital encryption is used to Step 1. Initiate a secure wide area call with RADIO-1 on Test TG 1. Keep
scramble a transmission so only this call in progress until instructed to end the call.
properly equipped radios can Step 2. Observe that RADIO-2 will be able to monitor and respond to the
Secure Operations

monitor the conversation. A “Key” call.

is used to encrypt the transmit
Step 3. Observe that RADIO-3 does not receive the call.
audio. Only radios with the same
“Key” can decrypt the audio and Step 4. Observe that RADIO-4 will also receive the call even with the
listen to it. secure switch set to the nonsecure mode of operation.
Step 5. End the call from RADIO-1.
Step 6. For radios equipped with dual algorithm encryption modules,
select a talkgroup using the second algorithm and repeat Steps 1-5.
Call alert is a tone page that allows Step 1. Using RADIO-1, press the page button.
a user to selectively alert another Step 2. Enter the unit ID of RADIO-2 with the keypad, or scroll to the
radio unit. The initiating radio location where this ID is stored.
will receive notification from the
Step 3. Press the PTT to initiate the call alert. Verify that the RADIO-1 user
trunked system as to whether or
receives audible indication that the call alert was sent.
not the page was received by the
target radio. Units receiving a call Step 4. Verify that RADIO-2 user receives an audible indication of an
Call Alert

alert will sound an alert tone. As incoming call alert that was sent but RADIO-3 does not.
with other types of calls, call alerts Step 5. Verify that RADIO-1 gets an audible indication that the call alert
can take place from anywhere in was successfully received at the target radio.
the system. Step 6. Turn off RADIO-2. Send a call alert from RADIO-1 to RADIO-2.
Step 7. Verify that the RADIO-1 user receives audible indication that the
call alert was sent.
Step 8. Verify that RADIO-1 receives an indication that the call alert was
not successfully received at the target radio.

Figure 10-2, continued

10 Part II: How Is Interoperability Achieved?

Console
Feature Description Test
Dispatchers with talkgroup call Step 1. Initiate a wide area call from any operator position on Test TG 1.
capability will be able to com­
Talkgroup Selection and Call

Step 2. Observe that RADIO-1 and RADIO-3 will be able to monitor the
municate with other members of call. De-key the console and have either radio respond to the call.
the same talkgroup. This provides
Step 3. Observe that all consoles with Test TG 1 can monitor both sides of
the effect of an assigned channel
the conversation.
down to the talkgroup level. When
a talkgroup call is initiated from a Step 4. Initiate a wide area call from any operator position on Test TG 2.
subscriber unit, the call is indicated Step 5. Observe that RADIO-2 and RADIO-4 will be able to monitor the
on each dispatch operator position call. De-key the console and have either radio respond to the call.
that has a channel control resource Step 6. Observe that all consoles with Test TG 2 can monitor both sides of
associated with the unit’s chan­ the conversation.
nel/talkgroup.
Talkgroup patch allows a dis­ Step 1. Select an operator position for testing which contains Test TG 1
patcher to merge several talkgroups and Test TG 2.
together on one voice channel to Step 2. At the desired operator position, select the patch tab in the patch
participate in a single conversation.window.
This can be used for situations
Step 3. Click the button on the patch that allows an operator to set up and
involving two or more channels or
edit a patch (note patch window turns blue).
talkgroups that need to communi­
cate with each other. Step 4. Add Test TG 1 and Test TG 2 to the patch by selecting each
resource tile.
Talkgroup Patch

Using the patch feature, the Step 5. Once the talkgroups are added, click the patch setup button again
console operator can talk and listen to complete the patch setup.
to all of the selected talkgroups Step 6. Initiate several talkgroup calls between radios.
grouped; in addition, the members
Step 7. Observe that all radios are able to communicate with one another.
of the individual talkgroups can
Also via subsystem viewer screen, observe that only one station is
also talk or listen to members
assigned at each of the two sites.
of other talkgroups. Patched
talkgroups can communicate with Step 8. Initiate a call from the operator position using the patch transmit
the console dispatcher and other button and observe that all radios are able to receive the call and only one
members of different talkgroups station is assigned at each of the two sites.
because of the “supergroup” nature Step 9. Remove Test TG 1 and Test TG 2 from the patch.
of the patch feature.

Figure 10-2, continued

 Chapter 10: Implement the System
11
Report Generation

Feature Description Test

Performance reports can be Step 1. From the application launcher, select a subsystem.
created automatically for dynamic Step 2. From that subsystem’s menu, choose subsystem historical reports.
statistical information about the
Step 3. From the historical reports window that opens, select a report.
air traffic activity on the system.
Historical Reports

These reports provide assistance Step 4. Using the left mouse button, click on the view button.
with system management, resource Step 5. Observe a window opens, allowing a user to enter report
planning, usage allocation, and parameters.
monitoring. All reports are prefor­ Step 6. Enter all desired data for the report and generate report.
matted and summarize air traffic
Step 7. Observe a window appears showing the requested report.
activity for a configured time span.
Step 8. Close the report window.
Step 9. Run the following reports during testing: Talkgroup at Subsystem
Summary; Radio User at Subsystem Summary; Site Summary.
System Reliability
This test verifies the essential Step 1. Power down one of the control channel capable stations at the
site operation within a simulcast non-essential site and note that configuration software shows the channel
system. An essential simulcast is disabled at all the other sites.
remote site is one that must have Step 2. Repeat Step 1 for each of the other control channel capable
at least one control channel and
Simulcast Essential Site Operation

stations or until 50% or more of the stations have been malfunctioned.

one traffic channel for the simulcast
Step 3. Verify that configuration software shows that the disabled channels
subsystem to remain in trunking
have been enabled at all other sites in the simulcast subsystem and that
mode. If all control channels or all
RADIO- 1 can communicate with RADIO-3.
traffic channels have experienced
faults at an essential simulcast Step 4. Repower all of the control channel capable stations at the non­
remote site, then the entire simul­ essential site.
cast subsystem is put into failsoft Step 5. Power down all of the control channel capable stations at the
mode to ensure communication essential site.
can continue in the area covered by Step 6. Verify that the simulcast subsystem is now in the failsoft mode.
the essential simulcast remote site.
Step 7. Re-power all of the control channel capable stations at the
When all of the wide area failsoft
essential site and verify the simulcast subsystem is back in wide-area
channels at an essential simulcast
trunking.
remote site have experienced faults,
the essential simulcast remote site
is malfunctioned.
This test verifies that the repeat­ Step 1. Choose one site to test for base station identification.
Base Station Identification

ers programmed for base sta­ Step 2. Set up the service monitor to receive the frequency of the
tion identification at every site identification channel for the particular site.
broadcasts the FCC identifier every
Step 3. Monitor the service monitor until the system ID is broadcast.
30 minutes. To accomplish this, a
service monitor will be set up to
monitor the identification channel
of a random site and note that the
Morse code is heard.

Figure 10-2, continued

 12 Part II: How Is Interoperability Achieved?

Create Standard Operating Procedures and

Train
More likely than not, your agencies will have a few existing policies and procedures
that shaped earlier functional specifications and now have to be incorporated with
the new system. We earlier recommended forming the policies/procedures team
prior to procurement to start collecting and melding policies and procedures between
agencies. If the team has been productive, you should have a core set of standard
operating procedures (SOP) around which training can be developed.

We recognize that developing operational policies and procedures proceeds more

easily when users have real technology up and running. It’s a living process that one
hopes will have its start in your system design, procurement, and implementation,
then mature as the system moves to full operation. We delve more deeply into SOPs
in Chapter 12, Develop Policies and Procedures, in recognition of that ongoing
process.

Your next step is to develop training programs using your own internal operational
Initial training may expertise as to how the system should be used. In large projects, training development
be contracted out. and execution is contracted out because it can be a huge undertaking. Again, look for
operational expertise, not necessarily technical, in developing training for end users.

Vendor training on the equipment and system basics is valuable, particularly

for your agencies’ trainers who will then go on to incorporate information about
the technology into their own training programs. Don’t rely on the equipment
or system vendors to conduct the bulk of training. They typically have good
technician programs, but limited expertise on how the technology is best put to
work by end users.

Use train-the­ If the system will rely on dispatchers to activate resources or use the technology,
trainer courses include special training for all dispatch agencies involved. Consider building internal
to build self- expertise within dispatch agencies involved in your project through train-the-trainer
sustaining courses contracted with either a commercial training company or through peer
expertise.
agencies elsewhere in the country that have been successful with similar projects.

Traditional classroom training is of limited use when it comes to interagency

communications. Theory and diagrams don’t do enough to instill communications
skills needed by first responders. Tabletop exercises are useful to introduce new
systems, work out procedural bugs, and establish an understanding of the sequence
of tasks in using the new capabilities. In short order, though, you’ll need to move to
the field.
 Chapter 10: Implement the System
13
Train for use of your new system in the context that it will actually be used. Put radios
Train in the in responders’ hands, show them how the capabilities are used, then practice until
context of how the their skills are developed to an acceptable standard. Assuming that capabilities will
technology will be placed in the hands of all responders, training will need to be further incorporated
actually be used. into their basic training programs, on-the-job training, and exercises so the skills are
gained by new recruits and refreshed among old-timers alike.

We’ll have more to say about training methods in the next chapter on maintaining
your system and processes.

With an implementation plan in place, acceptance tests lined out, and training
of end users and support personnel planned, your project is well-positioned for a
successful implementation.

An Example
The process of moving from needs analysis through implementation has been
described in detail. To finish up this chapter, which is intended to guide you to an
operational system, let’s use an example to make the implementation process a bit
more tangible.

The example is a hypothetical case used to capture a composite mix of activities, but
based on very real initiatives going on around the country. It captures the mixture of
responsibilities across the project team and your vendor showing how they need to be
timed and communications shared.

Three small cities and a county have joined in an interoperability initiative to improve
communications interoperability. Alphaville, Bravotown, and Charlieport are
independent municipalities in Delta River County.

Delta River County: As-Is

• ­ Alphaville has a conventional voice radio system using separate repeated
channels37 in the UHF band for police, fire, and EMS dispatch. The Alphaville
Police Department (APD) and the Alphaville Fire Department (AFD) each have
direct portable-to-portable channels for their internal tactical needs. Both have
two state-designated mutual aid channels installed in their portable and mobile
radios for talking directly to other UHF users, but the channels are only useful

37
A repeater is a radio typically permanently fixed with an antenna well situated on a tower or other
high spot in the jurisdiction that receives radio communications on one frequency and retransmits
them on another frequency within the same band. See Chapter 16, Pages 252-253, for more detail
and a diagram.
1 Part II: How Is Interoperability Achieved?

on scene since they aren’t repeated. APD uses mobile data computers in patrol
cars to receive routine dispatches; run wants, warrants, and motor vehicle
checks; and for some car-to-car messaging.
• ­ Bravotown shares a conventional voice radio system on VHF-high band with
Delta River County. Dispatch of the county sheriff, volunteer fire departments,
the Bravotown Police Department (BPD), and the Bravotown Fire Department
(BFD) is all handled by a consolidated dispatch center over the same set of
four repeaters spread around the county, although there are separate law
enforcement and fire channels. The repeaters are linked together so they
simultaneously transmit the best received signal on the channel anywhere in the
county.38 The volunteer fire departments have a shared tactical channel between
them for unit-to-unit communications, as do each of the law enforcement
agencies for their intra-agency use. All of the VHF-high band users have five
state-designated mutual aid channels installed in their mobile and portable
radios that are useful for direct communications. EMS services are provided
by fire department quick response units and a commercial ambulance service,
which are all dispatched on the same fire channel.
• ­ Charlieport has a relatively new 800 MHz trunked radio system39 for
voice communications. All municipal users are on the system. Portable
and mobile radios are also programmed with five state-designated mutual
aid channels, which also happen to be nationally standardized. These are
typically used to communicate unit-to-unit with state police and highway
maintenance responders that use a similar statewide system. The Charlieport
Police Department (CPD) and the Charlieport Fire Department (CFD) use
a common mobile computer system with wireless services provided by a
commercial carrier.

While this is a hypothetical scenario, it is very realistic and exists in similar form all
around the country. In our example, all these agencies have joined in a countywide
initiative to improve interagency communications for first responders. Let’s take a
look at the system of systems they chose and what’s involved in implementing it.

38
This is known as a simulcast system with receiver voting. For practical purposes, the system can
be thought of as a single repeater with the wide, composite coverage provided by all the separate
sites. The effect is a single channel that covers a wide expanse, which can be good at times and bad
at others, depending on whether distant communications are needed or only interfering with more
pressing, shorter-range ones.
39
A trunked radio system uses repeaters, too, but computers in the radios and at the heart
of the system automatically assign their use to individual conversations between groups
of users, or talkgroups. This makes channels defined functionally, rather than defined
electronically or geographically.
 Chapter 10: Implement the System
1
Delta River County: To-Be
Through a needs analysis and conceptual design, the agencies decided to use
a combination of approaches to improve their interoperability. The Steering
Committee concluded early on that both voice and data communications were
important. Jointly, the agencies first issued an invitation for bid (IFB) and hired
a systems integrator, then followed up with an RFP to procure the technology.
Functional specifications were created around their requirements and the conceptual
design. They called for the following:
• ­A cache of 16 VHF-high band portable radios programmed for all the county’s
channels and five state mutual aid channels in the band. These will be used for a
command net during extended interagency incidents.
• ­One new channel added to the county’s conventional system for interagency use
and one new site in Charlieport to improve the system’s coverage in the denser
downtown area.
• ­A fixed gateway device in Charlieport capable of interconnecting an existing
CPD/CFD command talkgroup to the new county interagency repeated channel
and Alphaville direct command channels. The gateway will be controlled by
Charlieport central dispatch.
• ­A mobile gateway device to be housed, maintained, and fielded by AFD. It will
be used to interconnect Charlieport mutual aid responders outside of the range
of their system to other responders using direct 800 MHz, county VHF-high
band, and Alphaville UHF mutual aid channels. Similarly, it will bring AFD
and APD direct channels into interconnected groups outside the range of the
Alphaville primary system. In effect, this device will serve as a mobile crossband
repeater for linking channels around an incident site.
• ­An intersystem message switch for connecting the Alphaville and Charlieport
mobile data systems together to allow car-to-car and dispatch-to-dispatch
messaging. The system’s primary use for interagency communications will be
for messaging between dispatch centers, incident command posts, emergency
operations centers (EOC), and evacuation centers. Fixed terminal access to
the Charlieport system will be established in the Delta River Central Dispatch
and EOC.

This initiative uses a combination of approaches to the technical side of

interoperability described in the SAFECOM Interoperability Continuum. In use, there
will be swapping of radios from the cache to add capabilities, gateways to patch
together existing systems, shared channels designated specifically for interagency
communications, and a shared system by some responders. It doesn’t, however,
replace all existing radio systems with a single, shared one. Doing so may be a
future possibility as Delta River County’s needs expand and agencies become more
accustomed to requesting and providing mutual aid outside the coverage of their
individual systems, but for now this approach serves their interoperability needs.
 1 Part II: How Is Interoperability Achieved?

Delta River County: The Implementation

With the scenario laid out, let’s take a look at what will be required for
implementation.

Through the RFP, the partners made multiple awards. The first went to a nearby radio
communications service shop for the cache radios, programming, and packaging in
a deployable case. The second went to a large radio systems vendor for most of the
other work, except for the mobile data system interconnect, which went to a third
company. Training of users and technicians was included as a task under all three
contracts.
TECH GUIDE
Following the Law Enforcement Tech Guide, The Delta River project manager pulled
ORIGINAL

208
together a draft implementation plan from materials in the original project plan and
s new contracts. He had the systems integrator draft an acceptance plan in cooperation
with the other contractors while the implementation plan was being put together.

Several teams were assembled to work through implementation. Most of the

members of the procurement team that guided the IFB and RFP efforts moved on to
the acceptance team, which was responsible for conducting the actual tests to assure
that the system performed as intended.

Initiate changes A policies/procedures team was brought together from key members of the User
to policies, Committee. It was charged with again reviewing all the agencies’ relevant policies,
procedures, and SOPs, and mutual aid agreements that went into a business process baseline report.
agreements early The team was further charged with drafting needed new policies and procedures for
on.
use of their new capabilities.

The earlier needs analysis process had turned up some procedural holes in the
countywide emergency operations plan, particularly as it defined the command
structure for interagency response. While the Incident Command System (ICS) was
commonly expected to be used, few agencies in the county regularly used it.

With funding being increasingly tied to use of the National Interagency Management
System (NIMS), the policies/procedures team found this was a good time to define
Integrate expected how agencies in the county would use NIMS-based ICS for interagency operations.
changes to incident Working through their agencies and the project User Committee, the team came up
response into the with new draft procedures describing interagency command processes and worked
new system of
them through the Steering Committee for approval. The project’s executive sponsors
systems.
carried the new operating procedures and their communications counterparts
through the Local Emergency Planning Committee (LEPC) required by state and
federal legislation.
 Chapter 10: Implement the System
1
Elsewhere in the project, a construction team was assembled with the Steering
Use outside Committee’s approval to guide the development of the new Charlieport radio site. The
resources for help team consisted of the Charlieport facilities director, a county zoning officer, a CFD
managing project captain who served on the city’s earlier steering committee for its 800 MHz system,
construction. and a CPD technical services manager responsible for daily operations of the system,
who also chaired the initiative’s Technical Committee. The team’s charge was to select
an appropriate site with the guidance and eventual concurrence of the system vendor
that provided adequate coverage, was affordable and acceptable, and ideally was on
city- or county-owned property.

The acceptance team built a series of tests for each of the system’s technology
components that would lead them to acceptance of the pieces and eventually the
system as a whole. A previously planned LEPC tabletop exercise provided a good
venue for testing the radio cache when it was delivered. Tests turned up needed
programming changes and suggestions for additional battery packs, which was
outside the contract, but negotiated through a change order with the vendor after the
Steering Committee approved doing so.

Acceptance testing of the fixed and mobile gateways proceeded through three steps:
Functional, Functional, reliability, and performance testing. Functional testing was performed
reliability, and by the team with additional help from members of the Technical Committee. It
performance tests followed a script calling for separate radios from each of the agencies to be brought to
were conducted.
Charlieport, activation of the gateway, and then testing transmissions sent back and
forth. The mobile gateway was similarly tested in Alphaville.

Reliability testing of the gateways was conducted over the period of a month with
reliability testing daily activations of the devices and weekly testing of actual transmissions between
takes time. agencies. Performance QA tests were conducted during all the functional and
reliability tests. They consisted of minimum setup and breakdown times for the
devices themselves, as well as individual connections between channels. Audio quality
Adapt existing tests and induced delay tests were also performed to see if the gateways materially affected
from other agencies communications. Most important, functional tests allowed the partners to look for
and sources. negative tests the gateways had on their existing systems, such as connecting repeated
systems in a loop.

TECH GUIDE
The intersystem message switch between Alphaville and Charlieport mobile data
systems was similarly tested on all three levels. The acceptance team contacted agency
ORIGINAL

216
references provided by the radio system vendor and adapted their test plans from a
s similar implementation. They also made use of sample language provided in the Law
Enforcement Tech Guide, further customized to include tests across both jurisdictions’
dispatch points, the new EOC installations, and directly between responders.
 1 Part II: How Is Interoperability Achieved?

Delta River County: Acceptance

Implementation proceeded smoothly. Each of the vendors had good experience with
similar projects and worked well with the project manager to build a realistic schedule
before starting work, then made adjustments through the Steering Committee
Adjust the schedule concurrence to both lengthen and shorten phases as it proceeded. Only a couple of
by shuffling contractual milestones were at risk of being missed. The project manager, vendor’s
work internally, if
possible.
managers, and the acceptance team sat down and adjusted work in other parts of the
schedule to rebalance the timeline. One deadline was breached, but all parties agreed
that it was due to delays in frequency licensing, which was Delta River’s responsibility,
and no penalty clause was invoked.

Training was designed by the policies/procedures team from materials provided

by the vendors under contract. The vendors provided early training to key dispatch,
technical, and field supervisors who would be expected to understand parts of the
system more thoroughly to conduct further staff training. This “train-the-trainer”
approach is commonly used to capture as much knowledge and technique as possible
from the vendors in building a cadre of future instructors.

Anticipate that Further training continued as various parts of the system were put into place. It was
training will be a timed so that, if the schedule went as planned, there would be no more than 6 weeks
perpetual process. between hands-on training and final acceptance.

Final acceptance was contingent on a full-scale exercise that was planned and
scheduled by the acceptance team through the LEPC starting early in the project.
The exercise brought out police, fire, EMS, and emergency management personnel
from across the county in a tornado scenario. Since the county had regularly used
such scenarios for emergency planning in the past, it provided a good opportunity to
stress-test the new system of systems—complete through all technology elements,
Use exercises policies and procedures, and training.
for performance
testing. The exercise pointed out needed adjustments in procedures for activation of the fixed
gateway and coordination of its use with technicians deploying the mobile gateway
in order to reduce any future interference between the two. These adjustments
were entirely the responsibility of the project team, so didn’t affect final acceptance
and payment to the vendor. A error in the mobile data interconnect configuration
that prevented direct messaging between the Charlieport and Alphaville EOCs was
Use successful
identified as out of specifications, though, and that vendor was able to quickly fix the
final tests to
congratulate the problem.
team and set the
stage for future A small ceremony and press conference was held the morning following the exercise
interagency by the project’s executive sponsors. They used media attention to the exercise—and
collaboration. successful testing—to announce that the project had been successfully completed.
 Chapter 10: Implement the System
19
The system Separately, they met with the vendors’ representatives and formally accepted all the
of systems is remaining contractual elements, releasing the final 10 percent of payment.
the functional
collection of
The project was completed on time and budget (of course!). Training was a key part
people, technology,
and business of its success, starting with the tabletop exercises for functional testing, to traditional
processes. “train-the-trainer” methods, and on to training in the real context of how the system
will be used. This focus on training means the collection of technologies, policies,
procedures, and people will work as a single system.
 CHAPTEr 11
TrAnSITIOn TO lOnG-TErm
GOvErnAnCE
 Chapter 11:
Transition to Long-Term
Governance

What The ongoing work to keep technology and organizational processes working toward
interoperability goals over the lifecycle of the system.

Why In a word, because of entropy. All systems, natural and manmade, deteriorate over
time if left unattended. Communications interoperability isn’t a one-shot proposition.

Who A revised governance structure, involving many of the project’s participants, is

needed to maintain the system of systems over its lifecycle. The Steering Committee
bears the responsibility of creating the ongoing structure before dissolving the
project team.

When Immediately after implementation, the project has to be closed out and the
maintenance phase begun.

TECH GUIDE
Chapters 18 and 19 of the Law Enforcement Tech Guide cover project
ORIGINAL

closeout, maintenance, and grant management for technology projects

s in general.

If you have followed this Guide in carrying out a communications interoperability

project, congratulations are in order. Following implementation of the technology
and processes to put it to work, there is cause for celebration as your agencies move
into the subsequent and long-term phase of systems maintenance. There are a few
final project details to attend to, but we’re going to suggest you do that very thing
soon: Celebrate!
 1 Part II: How Is Interoperability Achieved?

A System of Systems
We’ve used the term “system of systems” throughout this Guide. Your
communications interoperability system, for better or worse, richer or poorer, is the
collection of policies, procedures, and technologies, as well as training and exercises
that tie it all together. As we’ve said, all systems have geographic, technical, and
functional boundaries. They also have administrative boundaries where jurisdictions
participating in your system of systems have to work with “outsiders.”

safEcOM twenty-year Vision

Established 2003

There is an integrated system-of-systems, in regular use, that allows public safety

personnel to communicate (voice, data, and video) with whom they need on demand, in
real time, as authorized.40

Over time, successful communications interoperability systems have a way of melding

with neighbors at the borders. If public safety agencies are able to create an integrated
All communications
system of systems, nationally, it will be a complex of different technologies and
systems have
boundaries. procedures that meet the needs of agencies rural and urban, large and small, paid and
volunteer. It will support all who have to respond to emergencies that don’t respect
geographic, technical, functional, and administrative boundaries.

Systems—in all their animate and inanimate dimensions—have to be maintained

over time. Communications interoperability systems are no exception and will,
indeed, otherwise deteriorate rapidly because they are dependent on the proper
functioning of so many pieces.

This lifecycle maintenance encompasses not only the technology that you’ve just
implemented, but the governance and management structures that drive the
system, the policies and procedures that define it for all practical purposes,
and the training and exercises that make it real.

40
U.S. Government Accountability Office, Homeland Security: Federal Leadership and
Intergovernmental Cooperation Required to Achieve First Responder Interoperable Communications, GAO-
04-740 (Washington, D.C.: July 2004) p. 54.
 Chapter 11: Transition to Long-Term Governance
1
Project Closeout
Before moving on to the long-term, recurring processes of maintenance, we have a
few loose ends with the project to wrap up. Through the following steps, the project
is completed.

Hold a Transition Meeting

As mentioned in Chapter 10, complex systems are managed by vendors through
Hold a meeting to installation. At some point, often in a series of steps, system management is handed
hand over the keys. over for long-term maintenance. You may have chosen to have one or more of your
vendors stay on to maintain portions of the technology over time, but typically there
are still configuration and monitoring tasks, at least, to transition.

A final transition meeting is useful to get everyone in one room to hand over the
keys to the technological components of your new system. Proceed involving
project management and vendor staff, as well as the technicians and all
stakeholders who will be charged with maintaining the hardware, software, and
other physical components of the system. Follow the transition meeting with a
larger, open meeting for broad attendance.

Conduct an Open Review Meeting

Too often, projects wind down or drag on without a real end point. This has an
unfortunate effect on project participants who, naturally, need to see a positive end
point that signals success.

Recognizing that there are processes that will continue on for weeks and months to
come, find a natural breakpoint to hold an open review meeting. Conduct a review
where executive sponsors, the Steering Committee, and the rest of the project team
can sit down to examine the project from start to finish. Honestly evaluate how
well the project’s objectives were met and how the process to achieve them varied
from original expectations. Ask the simple question of what participants would do
differently if they were to undertake the same project again.

Use the open review meeting to celebrate the successful completion of your project.
Use the opportunity The completion of the meeting is a great time for the executive sponsors to issue press
to publicly declare
releases and otherwise publicly announce the project’s completion and its success.
success.
With large projects, use a public forum afterward to present the project, problems
faced, and hurdles overcome.

Carefully document all discussions, as they will be useful in your last job as project
manager: The final report.
 1 Part II: How Is Interoperability Achieved?

Write a Final Report

For the sake of those who will come afterward, write a final project report. It may be
a requirement if the project was grant-funded, but should be considered necessary in
any regard.

The report documents the final project timeline and costs. It also documents how the
Contribute lessons project’s objectives were met and what performance measures were used to assure
learned in your quality. A final budget and cost accounting is critical for both understanding and
final report for the justifying costs. Your past work to keep the project and implementation plans up-to-
benefit of others. date will simplify this task!

The report will be of most use to future readers from your agencies and perhaps
others if it includes a succinct statement of lessons learned during the project. These
are likely to be organizational, management, and operational lessons as much as they
are to be technical ones.

In our work with jurisdictions across the country that are striving to improve
communications interoperability, we find the most meaningful lessons coming from
other agencies that have been down similar paths. Contribute your lessons learned as
a special section of your final report.

n Get Internal Acceptance

Wrap up the project by delivering the final report to first the Steering Committee and
then the executive sponsors for their review, changes, and eventual approval. Use a
simple signing ceremony to officially close the project.

Govern and Manage

A cardinal principle We should be so fortunate that signatures on the final report signal the achievement
of Total Quality of communications interoperability. The reality is that the project end marks the
escapes too beginning of a process of ongoing governance and management. It’s a process
many managers:
necessary for continued interoperability and continuous improvements that will go
You cannot
continuously on as long as agencies need to communicate with one another.
improve
interdependent The project Steering Committee should create an ongoing governance and
systems and management structure to assume the helm upon its own dissolution.
processes until
you progressively
perfect Build Long-Term Governance Structures
interdependent, Long-Term and project governance structures vary in at least a couple of ways. For
interpersonal obvious starters, long-term structures are intended to remain in effect indefinitely,
relationships. which leads to a different dynamic between participants. The need for executive
—Stephen Covey sponsorship separate from steering has disappeared. While processes always need
 Chapter 11: Transition to Long-Term Governance
1
champions, the most effective champions for ongoing governance are those who can
Ongoing processes
need champions,
participate in its regular, if less frequent, deliberative meetings. Agency executives
but not executive who are able and willing to actively participate will lend strength to ongoing
sponsors. governance and management, however.

In addition, many representatives who would insist on being part of the Steering
Committee will now be comfortable stepping back from regular meetings and
delegating ongoing oversight to joint representatives. This may be a process that takes
a while, but will occur over time.

n Create the Board or Council

The ongoing governance structure doesn’t need to be significantly different from that
used for the project. Some of the titles change and reporting responsibilities vary a
bit, but otherwise there can be a smooth transition from the project to maintenance
phases. See Figure 11-1 for a sample governance structure.

Your structure will vary, as did your project governance, based on the scope of your
Adapt your project initiative. Whether the project is large or small, ongoing oversight can be provided
governance by a similar, but smaller group. Large initiatives for widely shared systems face
structure for difficult choices between models, such as creating independent governmental or
ongoing needs. quasigovernmental organizations or partnering with private companies. Regional
projects, on the other hand, typically act as consortia of independent jurisdictions
operating under mutual agreement.

REGIONAL
INTEROPERABILITY BOARD

ExECUTIVE
COMMITTEE

STATEWIDE
INTEROPERABILITY SYSTEM MANAGER(S)
COMMITTEE

USER COMMITTEE TECHNICAL COMMITTEE

Figure 11-1: Sample Ongoing Governance Structure

1 Part II: How Is Interoperability Achieved?

A typical long-term governance structure for a moderately sized initiative,

costing from a few hundred thousand to several million dollars, needs no more
than a central board, User and Technical Committees, and one or more hired or
designated managers.

Seriously consider limiting the size of the board. Any body that has more than 10
members needs an executive committee of fewer people to get work done between
meetings. All participating jurisdictions can and should be represented, although they
don’t necessarily need a seat on the board.

n Partner with the Statewide Interoperability Committee

Increasingly, statewide interoperability committees or councils are being created to
SIECs are state more broadly guide efforts. Many had their origins as state interoperability executive
or statewide committees (SIEC) or an equivalent required by the Federal Communications
interoperability Commission (FCC) of states that chose to manage 700 MHz radio spectrum dedicated
executive to interagency communications. Following September 11 and the greater focus on
committees. communications interoperability it brought, these committees have grown in many
cases to represent public safety agencies statewide more broadly on the subject.

Establish a liaison with the statewide interoperability committee to keep regional

efforts aligned with what is going on elsewhere. Regional efforts near borders should
participate with adjoining states’ SIECs, as well.

STATEWIDE INTEROPERABILITY
COMMITTEE RESOURCES
Federal Communications Commission (FCC):
http://wireless.fcc.gov/publicsafety/700MHz/interop.html

National Public Safety Telecommunications Council (NPSTC):

http://www.npstc.org/siec/siec.jsp

Association of Public-Safety Communications Officials International, Inc. (APCO):

http://www.apcointl.org/frequency/siec/documents/documents.htm
 Chapter 11: Transition to Long-Term Governance
19
n Formalize Agreements
If your project didn’t lead you to formal agreement between agencies, ongoing
mOUs are suitable operations will surely take you there. Formalized agreements are necessary to
for small initiatives. establish authorities, responsibilities, and mutual expectations. In order of
increasing formality, these are familiar to most public safety officials as memoranda
of understanding (MOU), memoranda of agreement (MOA), inter-local agreements
(ILA), intergovernmental agreements (IGA), or joint powers agreements or
authorities (JPA).
Study your
Each jurisdiction will have a different protocol acceptable for creating and adopting
local and state
regulations these types of agreements. Those involved in your initiative may each have different
covering requirements, though the greater informality of MOUs lend themselves to simple
interagency agreements, particularly for smaller initiatives. Study your local and state regulations
agreements. covering agreements between agencies and divisions of government.

Appendix A includes example agreements for simple and more complex sharing
projects. Any agreement covering all aspects of system sharing, including
governance, basic use procedures, and maintenance responsibilities, will be an
extensive document.

n Make Use of the Project Communications Plan

Your project communications plan is a great resource to be carried to ongoing
governance and management. It addressed sharing information between the various
stakeholders who now have more of a stake than ever. Agencies, governing bodies,
user and support personnel groups, and the public will need information indefinitely
about the system or state of communications interoperability.

Adapt the project communications plan for the new board or council.

gOVErnancE rEsOurcEs
To find more information on governance structures for large, shared systems,
see the supplemental resources that were produced by the National Task Force
on Interoperability (NTFI):
http://www.justnet.org/pdffiles/ntfi_supplemental.pdf (~3.0 MB)
 190 Part II: How Is Interoperability Achieved?

Build a Sustainable Financial Structure

Interoperability projects can be very expensive. Agencies regularly ask, “Where do we
get the money?”

“Where do we get The sources are many and varied, ranging from the public agency equivalent of
the money?” passing the hat (asking participants to provide some share of costs out of their own
budgets), to grants, and perhaps new forms of recurring review, such as taxes and
fees. We’re aware of jurisdictions that have turned to the private sector for grants and
donations, although these typically provide only a small share of what are often costly
projects.
TECH GUIDE
Grant funding is traditionally sought for technology initiatives. The Law Enforcement
ORIGINAL

235
Tech Guide provides a whole chapter on grant management and compliance that you
s will find invaluable if you have received a grant.

Homeland security grants have become a new source of interoperability funding in

recent years, but are highly sought after for other types of projects as well. As homeland
security grant funding has increased, other existing programs have diminished.

Interoperability is a national concern and need. Federal grant programs can only fund
a share of a small number of needed initiatives across the country.

The total cost of n Plan for the Total Cost of Ownership

system ownership The total cost of ownership (TCO) for radio communications systems can be as much
can be double its as twice the original system cost. A system, over its lifecycle, may cost as much to
purchase price. operate and maintain as to purchase.

grant funding rEsOurcEs

The SAFECOM Program maintains a web page listing potential sources
of funding for communications interoperability projects:
http://www.safecomprogram.gov/SAFECOM/grant/default.
htm
 Chapter 11: Transition to Long-Term Governance
191
Total costs of ownership for communications interoperability projects consist of:
— Development, procurement, and contracting costs
— Site development, including real estate and fixed facilities
— Hardware and software purchases, installation, configuration, and testing
— Frequency coordination and licensing
— Extended warranty and upgrade contracts
— Maintenance, support, and training costs
— Personnel costs for support staff and training overtime
— Operations costs, such as electricity and telecommunications circuits.

Modern voice radio systems have an expected lifespan of about 10 years. Though user
Estimate a 10­ and infrastructure radios have traditionally been kept in service two or three times
year lifecycle for that long, today’s sophisticated systems are increasingly computer-controlled and
modern voice radio become obsolete much more rapidly. Manufacturers establish technology lifecycles,
technology. which affect upgrade needs and, eventually, replacement.

Data communications systems are in an even greater state of flux as more and more
agencies move from low-tech systems they owned, operating essentially as did their
voice radios, to higher bandwidth systems, both governmental and commercially
operated. A major manufacturer of equipment recommends using a 3- to 5-year
WlAn lifecycles are
estimated as 3 to 5 period for calculating the TCO of wireless local area networks (WLAN).41 Consumer-
years. grade technology tends toward the lower end of that time range, while that built for
military and public safety purposes can physically be expected to last much longer,
perhaps beyond its useful life. For planning purposes, figure that the technology
lifecycle for data communications radio technology is closer to 5 years.

Also for planning purposes, estimate that ongoing operations, maintenance,

Ongoing costs and other support costs will annually cost roughly 10 percent of the initial cost
are commonly
of the technology. Costs for real estate and physical infrastructure, which can
10 percent of the
original technology safely be estimated to have a life span of 30 years, may be taken from the initial
cost. costs for this estimation. However, there are ongoing costs for inspections and
maintenance of infrastructure.

The good news is that your agencies are probably already paying a portion of that cost
in the form of maintenance and support personnel. You’ll have to determine if there
will be added staff and training costs in the future based on the scope of your project
and the agencies’ willingness to share maintenance responsibilities.

41
“Wireless LANS – Total Cost of Ownership,” Cisco Systems, Inc., 2004. See http://www.cisco.
com/application/pdf/en/us/guest/products/ps4076/c1244/cdccont_0900aecd801bb7d4.
pdf.
 192 Part II: How Is Interoperability Achieved?

n Create a Long-Term Funding Model

Ultimately, Grant funding has provided the impetus for many technology projects, but it isn’t part
taxpayers bear of a long-term funding model. It’s imperative that the ongoing costs of your system
the cost of of systems are addressed early and in depth. Sustainable funding structures require
communications dependable, recurring revenues. Ultimately, taxpayers bear the cost of providing
interoperability. public safety communications interoperability.

A funding model consists of project costs, funding sources, and policies for cost
sharing. Create 5- and 10-year projections of expenses and revenues. A 5-year plan is
sufficient to account for budget cycles and the expiration of initial warranties. A 10-
year plan has to take into account the system lifecycle and the planning costs, at least,
for the system’s replacement.

Use 5- and 10-year Long-Term funding models are as varied as the initial systems and their funding
projections. sources. The simplest are based on a handshake agreement. More complex initiatives,
such as those making use of shared systems for both their intra- and interagency
communications, often make use of monthly service fees to pay at least ongoing costs.
Observed monthly costs range from $20 to $60 per end-user radio.

Innovation is on the upswing in funding communications interoperability projects.

Fees are being assessed on consumer services, such as telephones, and vehicle
registrations. General appropriations and earmarked taxes are often necessary to
balance the budget. Bake sales are out.

sharEd systEM cOsts

Consider the following costs and responsibilities for shared systems.
3 Infrastructure purchase – Apportioned to the jurisdiction where located.
3 Mandatory system upgrades – “Must have” upgrades or system additions are paid
for by the jurisdiction whose subsystem must be upgraded to coexist with the larger
system; systemwide upgrades are apportioned across all jurisdictions.
3 Optional system upgrades – “Nice to have” feature costs are shared between
jurisdictions desiring the upgrade.
3 Infrastructure maintenance costs – Apportioned across all jurisdictions.
3 End-user equipment purchase – Covered individually by jurisdictions.
3 End-user equipment maintenance – Covered individually by jurisdictions.

Adapted from Wake County (North Carolina) Interlocal Agreement for its 800 MHz
trunked radio and CAD systems
 Chapter 11: Transition to Long-Term Governance
193
The pursuit Create a Review Process
of perfection As the final piece of setting up governance and management, create a process for
often impedes
periodic review of all aspects of the initiative—from the governance structure and
improvement.
its membership to the financial structure. Focus particularly on the system policies
—George Will
and procedures that fuel communications interoperability. Reviews bring out
needed updates and validate those parts that don’t need changes. They provide a
means of continuous improvement without participants becoming lost in a pursuit
Periodically review of perfection.
the governance and
financial structures, Annual reviews are usually sufficient. Stagger individual reviews throughout the year
as well as policies to make them less of a chore, sharing ongoing work across participants. For example,
and procedures. January is a good time for strategic reviews to capture the enthusiasm of the new year
during a slower period for most agencies. The financial structure and budgets may be
reviewed shortly before the end of the participants’ fiscal year—presuming they are
similar—to identify needs that might be met through year-end funding and to prepare
a budget, if needed.
Have a wish list for
surprise year-end Policies and procedures should also be reviewed on a rotating schedule throughout
opportunities.
the year to spread the work. The User and Technical Committees appropriately
bear the bulk of the effort, with the Board, in whole or part, annually reviewing
management policies and procedures.
Spread reviews
through the year
and responsibility
across the
participants.
 CHAPTEr 12
DEvElOP POlICIES AnD PrOCEDUrES
 Chapter 12:
Develop Policies and Procedures

What Formalized interagency agreements on how the system will be maintained and used,
integrating the National Incident Management System (NIMS).

Why Interagency communications policies and procedures establish how technology is to

be used to achieve interoperability. Integration of NIMS ensures an operational focus
compatible with incident management systems with other potential cooperators
beyond the initiative.

Who The system governance board approves acceptable policies and procedures developed
by the User and Technical Committees.

When Starting early in the project and carried on through a process of continuous
improvements after implementation.

In Chapter 10, we briefly touched on the creation of policies and standard operating
procedures (SOP). We noted that they evolve from SOPs existing within or,
potentially, already between partnering agencies that influenced your project needs
statements. During implementation, some are ideally further defined and executed
through initial system training. The bulk, however, are likely to grow as the system is
used more and more.

We refer here to policies as proscriptive rules and procedures as practical guidance for
how something is done. Policies may make procedures mandatory, but SOPs aren’t
necessarily so.
 19 Part II: How Is Interoperability Achieved?

Integrate NIMS into SOPs

SAFECOM’s Interoperability Continuum addresses standard operations procedures
(SOPs) as one of its five key dimensions in achieving interoperability. SOPs based on
the Naional Incident Management Systems (NIMS)42 are identified as an indicator of
advanced communications interoperability.

Central to NIMS integration into policies and procedures is the Incident Command
System (ICS). Policies and procedures based on ICS, incorporating its structure,
conventions, and operational principles, bring commonality to the way different
agencies work.

Create policies and procedures for routine and targeted capabilities using a standard
nImS-integrated
SOPs lead to model adopted by the governing body. Address technical and operational aspects
interoperability. of the system, integrating NIMS throughout. This approach assures the greatest
communications interoperability, plus compatibility with neighbors far and wide.

We will cover communications aspects of NIMS ICS in detail shortly.

National Priorities:
Focus on Routine and Targeted Capabilities
–nImS Policies and procedures for communications systems, first and foremost, provide for
–Information agencies’ day-to-day operational needs. Procedures that are used regularly become
sharing part of a responder’s natural reactions. All emergency response disciplines recognize
–Communications that, under the stress, people perform as trained—for better and worse. The classic, if
interoperability tragic, story in law enforcement is of the officer found shot with empty cartridge cases
in his pocket, having spent hours on the shooting range practicing “procedures” that
had nothing to do with—and were counterproductive to—surviving a shootout.
People perform as
During the stress of emergencies, responders will most reliably perform the tactics
trained—for better
and worse.
they have learned, exercised, and used daily. Interagency communications procedures
are only effective if used. They are most likely to be used if they are part of daily or, at
least, very regular practice.
Tactics and tools
used daily will Lay the groundwork for automatic behaviors during emergencies by establishing
be most reliable routine interagency procedures. Make the less common ones memorable by making
during unusual them simple, by creating “cheat sheets” for easy reference, and by practicing them
emergencies. during exercises. Don’t presume that every proscriptive policy and each procedure
established will immediately become part of every responder’s repertoire.

42
See Chapter 3, Operability—Job #1.
 Chapter 12: Develop Policies and Procedures
199
Targeted Capabilities
In late 2003, Homeland Security Presidential Directive 8 (HSPD-8), “National
Preparedness,” was released.43 Its purpose was to strengthen preparedness
capabilities of all levels of government to terrorist attacks, major disasters, and other
emergencies. It required development of a national preparedness goal44 that included
readiness metrics and full implementation of a closely coordinated interagency grant
process for first responder preparedness assistance by the end of federal Fiscal Year
2005 (September 30, 2005). The directive noted that, “[t]o the extent permitted by
law, Federal preparedness assistance will be predicated on adoption of Statewide
comprehensive all-hazards preparedness strategies.”

Three of the seven national priorities articulated in the National Preparedness Goal
(NPG) are particularly relevant here: Implementation of NIMS, strengthening
of information sharing and collaboration capabilities, and strengthening
communications interoperability. The NPG relies on an approach called Capabilities-
based Planning to reach the goal, with 15 standardized National Planning Scenarios,
a Universal Task List to reference tasks performed by all levels of government and
different disciplines during incidents, and a Target Capabilities List identifying
capabilities needed to perform the tasks.

The National Response Plan provides a concept of operations to which state and local
Emergency emergency operations plans are intended to be aligned. Emergency operations plans
operations plans are supported by or built upon SOPs that are intended to be consistent with NIMS
are to be built upon guidelines, standards, and protocols.45 Emergency planners are expected to identify
SOPs consistent tasks from the Universal Task List that their organizations need to perform based on
with nImS. their assigned roles and mission. The Target Capabilities List (TCL) descriptions are
used to determine the capabilities needed to accomplish these tasks, variously by
different response elements.
Interoperable
communications Currently, there are 36 capabilities in the list, of which 32 are grouped into four
is one of four
mission areas: Prevent, protect, respond, and recover. The remaining four are
capabilities
common to all capabilities common to all mission areas. Interoperable communications is second
mission areas. among the four common capabilities.

43
See http://www.whitehouse.gov/news/releases/2003/12/20031217-6.html.
44
See http://www.ojp.usdoj.gov/odp/assessments/hspd8.htm.
45
The National Response Plan and National Incident Management System were established
by Homeland Security Presidential Directive 5: Management of Domestic Incidents (HSPD-5). See
http://www.whitehouse.gov/news/releases/2003/02/20030228-9.html.
 200 Part II: How Is Interoperability Achieved?

Work is under way to define conditions and standards for each task, as well as
performance measures and metrics to assess capabilities. Measuring communications
interoperability is addressed in Chapter 15, Measuring Interoperability.

Throughout this book, we address communications interoperability capabilities

generally. They are not listed here for security purposes. Adoption and incorporation
of NIMS and capabilities listed in the TCL will lead to advanced interagency
communications supporting common response processes.

Specific information on the National Response Plan tasks and capabilities can be
found in the U.S. Department of Homeland Security’s Lessons Learned Information
Sharing web site.46

A standard method Establish and Use a Standard Method

for procedures Policies and procedures governing interagency communications are crucial for
simplifies their interoperability. Agencies that have adopted a standard method for their creation
creation and
have found them easier to develop and maintain. Two examples come from the
maintenance.
northern latitudes: Minneapolis-St. Paul, Minnesota, and the state of Montana.

Shared Systems in the Twin Cities

The Metropolitan Radio Board (MRB) of the Minneapolis-St. Paul, Minnesota, area
oversees a radio system shared between many agencies. It’s the nucleus of what is
becoming an even larger system and is in a period of transition as of this writing. The
MRB has used a standardized template and approach to create an extensive set of
standards, protocols, and procedures.

The comprehensive standards document, which is available online,47 includes a

template showing and describing seven elements:
— A document title, control, and approvals block
— A purpose or objective statement
— A technical background statement describing capabilities and constraints under
which the standard, protocol, or procedure is used

46
The Lessons Learned Information Sharing web site is only available to emergency response
providers and homeland security officials. Registration is required and eligibility is verified. See
https://www.llis.dhs.gov .
47
System governance is being transferred to the Metropolitan Emergency Services Board and
the system is becoming part of the larger, statewide system. The document is currently available
through the Statewide Radio Board at http://www.armer.state.mn.us/.
 Chapter 12: Develop Policies and Procedures
201
— An operational context statement addressing when it is appropriate
— A recommended protocol/standard statement addressing related criteria that
qualify use of the one being established
— The recommended procedure, itself, describing how the task is performed,
including individual steps and locations of reference documents ­
— A management statement describing who is responsible for supervising or
managing this procedure. ­

Appendix B contains an example from the MRB document that addresses patching of
shared channels in the region to the system.

Shared Channels Under the Big Sky

The montana The state of Montana has a comprehensive, shared channels plan widely used by
shared channels local, state, and federal responders in the state.48 It defines 14 channels available for
plan includes use across disciplines, incorporates ICS throughout, and provides practical examples
policies, of use. The bulk of the plan addresses practical applications, with the formal plans,
procedures, and plus policies and procedures, included as appendixes.
practical use
examples.
The formal plans for each channel are simple, one-page documents describing the
purpose of the channel, eligibility for use, and basic usage standards. More detailed
policies and procedures documents are provided for each separately, addressing in
a standardized form oversight, eligibility, licensing and authorization, operations,
requirements, procedures, and channel use discipline.

The Montana shared channels plan demonstrates a standardized method for creating
policies and procedures, coupled with practical demonstrations of use.

Create Technical Policies and Procedures

Following a standardized method, you can create policies and procedures that both
serve your system of systems and are manageable. Both technical and operational
SOPs will be needed. The Technical and User Committees of the governing body are
commonly tasked with responsibility to create the SOPs, carry them through approval
and adoption, and maintain them over time.

48
Montana Mutual Aid and Common Frequencies, State of Montana, 1990-2005. The most current
version is a minor update to the 1994 edition written by this author. See http://itsd.mt.gov/
techmt/publicsafety/mutal_aid_manual/2005_mutual_aid_book_2005_web_final.pdf.
 202 Part II: How Is Interoperability Achieved?

Many technical SOPs can be developed over time, shaped by your system and needs.
Some of the more common ones include:
— Equipment management and deployment
— Standard equipment configurations
— Maintenance of radio caches
— Gateway configuration, maintenance, deployment, and use
— Outage responsibilities and standards for repairs
— Availability of spare equipment
— Preventive maintenance
— Notification of maintenance activities.

Technical maintenance needs are addressed in Chapter 14, Maintain the Technology,
which discusses some specific activities where technical SOPs may be necessary.

Create Operational Policies and Procedures

Operational policies and procedures address how the technology is put to work. Many
will arise from existing SOPs, but you will need to develop others that extend the
interagency communications capabilities through your new system.

The highest levels of interoperability are achieved through integration of the NIMS
into procedures used regionally across participating jurisdictions.

ICS Communications Unit

Under NIMS ICS, the Communications Unit is established as a logistical service
function. It is responsible for establishing the Incident Communications Center
Under ICS, the (ICC), which is typically part of the Incident Command Post, and creating the
Communications
Incident Communications Plan.49 The Communications Unit Leader is responsible for
Unit is under the
logistics Section. participating in incident planning meetings to do the following:
— Determine the feasibility of providing the required communications support
— Provide operational and technical information on communications equipment
available for the incident
— Provide operational and technical information on communications equipment
capabilities and restrictions.50

49
ICS uses standardized forms. The Incident Communications Plan, described further in this
chapter, is based on form ICS 205. See http://www.nimsonline.com/nims_3_04/examples_
of_ics_forms.htm#205.
50
Adapted from current editions of National Wildfire Coordinating Group task books. Available at
http://www.nwcg.gov/pms/taskbook/logistics/logistic.htm.
 Chapter 12: Develop Policies and Procedures
203
The The Communications Unit is composed of four different positions, as needed: The
Communications unit leader, technicians, radio operators, and ICC managers. These positions are only
Unit includes a filled when needed. Appendix C provides tasks lists from NIMS-compliant source
leader, technicians,
material for each of these positions.
radio operators,
and ICC managers.
Integrated communications is an original, fundamental tenet of ICS. Policies and
procedures for use of the ICS Communications Unit during larger emergencies are
important for communications interoperability.

Incident Dispatch Teams

In the public safety field, incident dispatch teams have grown in popularity over
the past few years. In law enforcement, they are more commonly known as tactical
dispatch teams for their role in supporting SWAT team operations.

By either name, incident dispatchers and their supervisors would staff the ICS radio
operator and ICC manager positions, respectively, in a NIMS-based response. During
large emergencies, an on-scene communications center is crucial.

Consider establishing policies and procedures for incident dispatch teams as part of
your Communications Unit.

incidEnt dispatch rEsOurcEs

At least two organizations exist for the benefit of incident dispatch.

The California Tactical Dispatcher Association is focused primarily on police operations:

http://www.tacticaldispatch.com/

Incidentdispatch.net, also based in California, is more broadly focused on all-risk

incident communications:
http://www.incidentdispatch.net/

Almost all aspects

of communications
Emergency Traffic
continue to be From a very practical standpoint, communications procedures continue to be
problematic, from problematic. Improved interagency communications depends on developing some
initial notification to of the most basic emergency procedures. For example, consider how traffic is held or
tactical operations. cleared on a channel for other, higher priority emergency traffic.
—Arlington County,
virginia Most agencies have procedures for declaring “emergency traffic only” on a channel.
9/11 After-Action In routine operations, dispatchers are charged with the responsibility on dispatch
report
 20 Part II: How Is Interoperability Achieved?

Communications channels of declaring it or accepting an announcement from another user. They are in
often becomes charge of controlling the network, in effect, and opening it back up for regular traffic.
the ‘fall guy’ for
organizational Procedures are also needed for emergency traffic on channels that dispatchers
problems. An
don’t manage. Tactical channels used on scene are in equally high need of
excessive number
of responders procedural definition of who declares “emergency traffic,” who controls the
attempting to talk to channel, and how it’s cleared. Typically, the highest-ranking ICS position on the
the IC* (generally channel bears the responsibility.
all at once),
compressed time,
getting behind and
Channel Span of Control
chasing the incident Very similar to the ICS principle of maintaining a manageable span of control in
problem, playing supervision, channel span of control procedures are important. The history of
‘catch up,’ and emergency response is replete with stories of responders in dire circumstances who
general operational couldn’t get access to a channel because of too much traffic. One of the most tragic
confusion can occurred in Hackensack, New Jersey.
quickly beat up and
overwhelm any
incident commo
In its 135-year history, nine Hackensack firefighters made the ultimate sacrifice. Four
[communications] have died in motor vehicle accidents. Five perished during one fire on July 1, 1988.
plan/system. … Two firefighters—who initially survived the collapse of a bowstring truss ceiling
Any part of the that claimed the lives of the others—were trapped inside where they were unable to
system operating communicate their situation due, in part, to the channel being overloaded with other
beyond their tactical, command, and dispatch traffic.
effective span of
control (five to
six) will almost Maintenance of a manageable span of control on a radio channel enforces the more
instantly develop general ICS management principle. Use of tactical channels removes some share of
commo problems. other incident traffic from broader dispatch and response channels. Ideally, only a
The way to fix the single supervisor and subordinates would operate on a single channel. Any more than
commo problem is that and responders have to decipher traffic not intended for them, risk mixed orders,
to fix the span-of­ and compete for the channel when they have emergency traffic. The volume of traffic
control problem,
on overloaded channels has caused more than one responder to turn the volume
and (bingo!) the
commo settles down or radio off in order to have a moment to think or converse with others.
down and becomes
normal. Operations with extremely compressed timeframes, such as SWAT incidents,
—Fire Command advanced life support, and most firefighting require simple, direct, and immediate
Chief Alan communications capabilities. This can only be provided by maintaining a manageable
Brunacini, channel span of control.
Phoenix (Arizona)
Fire Department Create policies and procedures that move incident traffic from cluttered channels
to operational and tactical channels organized in a manner similar to the incident
* Incident
Commander organizational structure.
 Chapter 12: Develop Policies and Procedures
20
Common Standard Language
terminology,
Much of what passes as poor communications is actually miscommunications. NIMS
resources
definitions, and ICS and its predecessors identify as its first management characteristic the use of
plain language common terminology for organizational elements, position titles, resources, and
are crucial for facilities. One of the most important policies that can be established for interagency
communications communications is common terminology to be used by responders, further reinforced
interoperability. through procedures.

In addition, standard resource definitions improve interoperability. From

a communications standpoint, naming conventions for channels and other
communications resources are critical to get standardized across jurisdictions. It’s
unfortunately common for agencies to be working together with a common radio
channel at their disposal that they’re unaware of or that are named so differently
that nobody would associate them. Some regions go so far as to establish not only
standard names for shared channels or talkgroups, but also standard programmed
positions in the radios for interagency resources.

Last, the most important language policy that can be adopted to improve interagency
communications is the use of plain language—eliminating codes and jargon. This is
a simple idea, but every vocation and avocation has its own terminology. When these
diverge across agencies and disciplines, responders don’t communicate.

Communications-Order Model
Another communications best practice that has proven effective is a communications-
order model that provides positive message acknowledgement. This is a basic process
that can work with any medium, voice or data, but is most clearly seen with first
responder push-to-talk radio communications. It’s simple and we do it in our daily
lives when we’re communicating best.

Five steps are involved:

1. Calling unit gives the name of the called unit, followed by its own.
2. The called unit responds with the reverse.
3. ­The calling unit transmits its message.
4. The called unit briefly restates the message to show understanding.
5. ­If the message was received correctly, the calling unit responds with an
affirmative acknowledgment, otherwise responds “Negative” and repeats the
message. ­
 20 Part II: How Is Interoperability Achieved?

Some jurisdictions reverse the order of whose “name” goes first. A standard
convention is most important, though there’s bound to be those border issues where
one convention butts into the other, confusing everyone who doesn’t recognize the
callers’ voices and is trying to figure out what’s going on. While there is no definitive
standard, we suggest the sequence above. It’s used by many public safety agencies, the
U.S. Army, and air traffic controllers, which is good enough for us!

Positive message The keys to the communications-order model are convention and positive message
acknowledgment acknowledgment. The sender knows the message was received as intended. With
is good practice, it can be done efficiently, with a fraction of the airtime necessary for
communications. repeated and missed messages.

Operational Unit Reporting

The final example of a communications SOP for operational purposes is standardized
unit reporting. Beyond the obvious value of clearly communicating who’s talking
and what the message is, status information can be transmitted efficiently that
provides greater context for all parties involved in the conversation, active or not.
Standardized reporting during multiagency response when confusion often reigns can
be established through policies and procedures.

Development of A simple example is the transmission of location and status by reporting units—
unit reporting typically those in the field—once during a sequence of transmissions. While modern
procedures gets
trunked radio and automatic vehicle location (AVL) systems capture some of this
operations folks
talking about information, nothing is so simple and effective for all participants as a simple voice
operational needs transmission. Not every one who “needs to know” will be near a CAD display or
and uses of the using AVL-enabled radios (essentially only mobiles). A simple “Available at staging”
system. statement says a lot.

Operational unit reporting procedures across agencies are powerful tools to flesh out
the system of systems by getting field operations staff talking about what they need to
talk about.

Build Incident Communications Plan Templates

SOPs drive the development of the incident communications plans. Under ICS, the
Incident Communications Plan is documented using the ICS 205 form, which is
itself part of the formal Incident Action Plan (IAP). The IAP is a collection of forms,
starting with the ICS 201 (Incident Briefing), plus supporting material.
 Chapter 12: Develop Policies and Procedures
20
ICS 20
The Incident Communications Plan—sometimes called the Incident Radio
Communications Plan—is specific to an incident due to its unique geographic
location and extent, the type of operations supported, and the scale of response.
Templates are useful tools in preparing for response.51

Templates are Plans do have to be customized by a Communications Unit during larger emergencies,
useful, but however. What constitutes a large emergency is jurisdiction-dependent. Basically,
communications any response requiring more than a couple dozen responders needs an on-scene,
plans have to be
incident communications center of some form—and a communications plan tweaked
customized for
large events.
somewhat to fit the incident.

The ICS 205 identifies communications resources, their functional assignments

(e.g., “Talkgroup X is assigned to Division A command”), and technical parameters
of the resource, such as frequencies and tones for conventional channels. From an
operational standpoint, the ICS 205 says a lot about the participating agencies and
the incident command structure. A well-done Incident Communications Plan both
reflects and reinforces the command structure. Supplemental material may describe
such things as usage priorities, procedures, and protocols.

The diagram in Figure 12-1 depicts a realistic organization chart identifying

responders to a hypothetical event by their function. This is highly preferred to
identification by agency, which tells the user nothing about what they’re doing.

In this example, each line between functional elements represents a communications

path of some sort. During emergencies, these are typically radio channels—whether
discrete frequencies in a conventional system, talkgroups in a trunked system, or
even composite channels as may occur when multiple frequencies and talkgroups are
patched together with a gateway.

Consider an example. The “Law Enforcement Branch” director and each of the team
Branch directors,
group supervisors,
leaders and group supervisors are connected by a common line, or channel, of some
and team leaders form. The communications plan has to identify how that connection is made. Typically,
are standard ICS some radio channel would be assigned for “Law Enforcement Branch Command,” which
position titles. is represented by that line. The ICS 205 for this scenario would, figuratively, describe
how each of those interconnecting lines is supported with communications.

51
The National Wildfire Coordinating Group, a long-organized group of government agencies
with wildland firefighting responsibilities, has standardized the ICS 205 and other ICS forms. See
http://www.nwcg.gov.
20 Part II: How Is Interoperability Achieved?

The experienced responder will notice that the chart in Figure 12-1 stops at a certain
level of detail and doesn’t depict the tactical channels that would be used within
many of the indicated operational elements. The diagram is simplified for the sake
of discussion, whereas an actual incident response with those operational elements
would likely involve more than a hundred responders. The ICS 205 for the scenario—
whether as a template or an actual incident plan—would identify all communications
resources to be used to support the response.

Figure 12-1: Sample Improvised Explosive Device (IED)

Scenario Organizational Chart
 Chapter 12: Develop Policies and Procedures
209
Tactical Interoperable Communications Plans
Under the Federal Fiscal Year 2005 Homeland Security Grant Program,52 all
designated Urban Area Security Initiative (UASI) regions and one metropolitan area
in each state without a UASI region, were required to complete a tactical interoperable
communications plan. This plan was intended to identify how the region would
support operational response within an hour of an incident occurring. The elements
of the required plans may be instructional to all agencies, whether or not they were
required to complete them as a condition of homeland security funding.

Tactical Federal guidance for these plans suggested including the following elements:
interoperable — Background, describing the urban area and how tactical interoperable
communications communications would be governed in the region ­
plans are a
requirement of — An equipment and capabilities inventory, including points of contact for
some homeland activating and supporting resources
security grant — Tactical interoperable communications policies and procedures
funding.
— Incident communications plans matching resource to response structures
— NIMS-compliant training planned for Communications Unit leaders
— Appendixes that further document details.

These topical areas outline well the information needed for incident communications
planning.

52
See http://www.ojp.usdoj.gov/odp/docs/fy05hsgp.pdf.
 CHAPTEr 13
TrAIn AnD ExErCISE
 Chapter 13:
Train and Exercise

What The process of instilling skills and improving performance for achieving
communications interoperability.

Why As part of the system of systems for interoperability, users have to be prepared for
routine and targeted capabilities in the context that skills will actually be used.

Who The User and Technical Committees are responsible for guiding development of
training and exercises for interagency systems.

When Start training and doing realistic exercises during implementation, continuing in a
process of continuous improvement through the system’s lifecycle.

Not every difficult All the policies and procedures created to improve interagency communications are
and dangerous useless unless they are put to work. Training and its practical counterpart, exercises,
thing is suitable are required for any system of systems to work during routine events, special task
for training, but force operations, or large-scale emergencies.
only that which
is conducive
to success in Focus on Both Routine and Targeted
achieving the object
of our effort. Capabilities
—Epictetus As noted previously, the most well-executed tactics are those used and practiced on
a daily basis. Communications interoperability is achieved, foremost, through the
regular use of interagency capabilities on a routine basis.

Instill the best practices for response during emergencies large and small by building
A good plan today them into basic training and in-service programs, as well as into exercises that give
is better than responders even greater ability to use the communications capabilities during realistic
a perfect plan circumstances. Meld the target capabilities of the National Response Plan into
tomorrow. training for both routine and extraordinary events, to assure agencies involved in your
—General George initiative can leverage what they do daily for even larger emergencies. Recognizing
S. Patton that many capabilities will grow over time, use a process of continual improvement to
chart progress.
 21 Part II: How Is Interoperability Achieved?

Train in Context
The most effective method of training adults in practical skills is by doing it within the
context of how the skills will actually be used. For example, the training mentioned
previously that led police officers to pocket empty cartridge cases has given way to
realistic, tactical training in which officers are required to seek cover, distinguish
threatening from nonthreatening targets, and shoot effectively under added
I hear and I distractions. This training in the context of how skills will be used is very effective and
forget. I see and I applicable in communications training.
remember. I do and
I understand.
In effect, end users aren’t trained to use radios—they’re trained to communicate while
—Confucius
doing their jobs. That may seem like a subtle distinction, but in practice it means
that communications training is most effective when it is embedded within other
training—not conducted in isolation.

Building on the above example, realistic police communications training would

require an officer to request assistance by radio while engaging targets on the range.
Or a firefighter reporting completion after ventilating a roof with a power saw.

Use Standardized Exercise and Evaluation

Processes
Exercises offer the opportunity to train skills in context. The use of a standardized
exercise process, coupled with meaningful evaluations, provide the means to train and
progressively develop skills.

Exercises provide From the perspective of communications interoperability, exercises provide an ideal
the means to opportunity to stress test the entire system, including the hardware, the software,
stress-test the and the “liveware.” A standardized exercise program includes a progressive set of
entire system of exercises that are each appropriately evaluated, with results incorporated back into
systems.
the program for further training.

The U.S. Department of Homeland Security’s Homeland Security Exercise and

Evaluation Program53 (HSEEP) provides extensive guidance for designing, conducting,
and evaluating exercises. Discussion- and operations-based exercises are addressed
in detail. The program is currently under revision to further incorporate the National
Planning Scenarios, Universal Task List, and Target Capabilities List of the National
Response Plan. Not only does the program provide useful guidance, its use helps
jurisdictions meet requirements for grant funding.

53
See the HSEEP at http://www.ojp.usdoj.gov/odp/docs/hseep.htm.
 Chapter 13: Train and Exercise
21
Discussion-Based Exercises
HSEEP addresses four types of discussion-based exercises: Seminars, workshops,
tabletop exercises, and games. Seminars and workshops are familiar to most
people, while tabletop exercises and games are less so. According to HSEEP,
operational simulation games are an increasingly sophisticated and useful component
of exercise programs. They seem to currently offer little in the way of communications
training suitable for first responders, however.
Tabletop exercises
provide the means Tabletop exercises are probably more familiar in emergency training to most than
to master script for games or other automated simulations. Tabletops offer an opportunity to first
operations-based introduce new policies and procedures, identify disconnects as they are tested through
exercises. discussion, and then master scripts that might be further tested operationally.

Operations-Based Exercises
As the name and distinction implies, operations-based exercises take participants to
Operations-based the field for actual training and practice. They provide the means to validate policies
exercises provide and procedures, while testing the technology as well. Three types of operations-based
training in context. exercises are identified by HSEEP: Drills, functional exercises, and full-scale
exercises.

Drills are limited in scope, testing one part of the system in isolation, although
as realistically as possible. An example for communications may be a drill of a
technician team responsible for deployment of field gateways. Procedures that could
Drills are limited only have been discussed during a tabletop exercise can be tested in more realistic
exercises. circumstances, although still in isolation from a larger response system. This allows
system managers and planners an opportunity to evaluate the procedures—as well as
the drill design—for subsequent improvements.

A functional exercise along the same lines might bring a special operations team and
the technicians to the field with a mobile command post to test not only deployment
and setup, but also further use. The exercise is still limited in scope and evaluation
is key to the process of continuous improvement. HSEEP notes that functional
exercises are generally designed to exercise the direction and control of resources,
rather than systems. In our example, the gateway would not be thoroughly tested for
functionality, capacity, and coverage, but rather for its appropriate deployment and
operational command.

Full-scale exercises are, by definition, multijurisdictional exercises that bring out a full
Full-scale exercises response system. Communications is tested as a part of a larger effort. This provides
stress-test entire realism that exercises the communications interoperability system of systems, as a
systems.
whole, in the context of how it’s used during near-real operations. Full-scale exercises
are intended to stress-test systems under realistic circumstance and timeframes.
21 Part II: How Is Interoperability Achieved?

Evaluations
As noted, exercise evaluations are crucial. They are appropriately designed, planned,
Exercise and carried out with as much attention to detail as the rest of the exercise. HSEEP
evaluations provides an entire volume addressing the process.54 Key elements include the use of a
are necessary
debriefing for planners, facilitators, controllers, and evaluators and a “hot wash” for
for a process
of continuous all others. The hot wash follows the exercise immediately while multiple debriefings
improvement. may be necessary to capture observations and document details from multiple sites.
Debriefs and hot washes are used in evaluation of both discussion- and operations-
based exercises.

An After-action Analysis and Report (AAR) captures details more broadly for the record
and recommends improvements. Under HSEEP, they are prepared for all exercises
except workshops and seminars, where a summary report suffices.

Communications is not an independent element of emergency response that

can be adequately exercised and evaluated in isolation. It is only through
integrated exercises that it can be trained in context, tested, evaluated, and set
for continuous improvements. Interagency communications can likewise only
be exercised adequately and evaluated critically through multiagency efforts.

54
Homeland Security Exercise and Evaluation Program, Volume II: Exercise Evaluation and Improvement,
U.S. Department of Homeland Security. Available at
http://www.ojp.usdoj.gov/odp/docs/hseep.htm.
 CHAPTEr 14
mAInTAIn THE TECHnOlOGy
 Chapter 1:
Maintain the Technology

What The ongoing work to keep technical components of the system operational over its
lifecycle.

Why Without maintenance, technology deteriorates over time. Optimal performance of

technology is achieved through regular and preventive maintenance, coupled with a
proactive process of managing changes to it.

Who Ultimately, the system’s governing body is responsible for identifying which agency,
agencies, or vendors will maintain different technical components of the system.

When Starting from the day the technology is installed, throughout the system’s lifecycle.

Maintaining your communications interoperability system of systems involves not

only the human components, but also the technology they use. Upon implementation,
your system technicians immediately went into maintenance mode. While new
technology, once up and running smoothly, requires less initial maintenance, there
are aspects that have to be maintained continuously.

Identify Responsibilities
Start the maintenance process by identifying responsibilities for each technological
component of the system and each job that has to be done. Your implementation plan
provides a good starting point for this effort. Address the roles and responsibilities of
each participating agency’s technical staff, equipment installers (if independent), local
radio shops that are to be used, and other network maintainers. This last category
includes maintenance functions of leased telecommunications circuits, if you have
used them.

Use a matrix of responsibilities that is charted by agency or organization. Cooperative

Use a matrix systems being built around the country often have a particularly complex set of roles
to chart
and responsibilities. Make them clear to reduce confusion and potential conflicts,
responsibilities.
while maintaining the highest level of system performance.
220 Part II: How Is Interoperability Achieved?

Create a Technical Continuity of Operations

Plan
Near the top of the list of things to do in maintaining the technology is to create a
continuity of operations plan. Technical staff are in the best position to manage risks
naturally faced with the technology.

A technical continuity of operations plan addresses the following:

• Risks, including their likelihood, severity, areas of impact, and mitigation
• Points of contact for managing outages
• Procedures for notifying user agencies of outages
• Technical adaptations to maintain system performance.

During large-scale emergencies and disasters, information about impacts on

communications systems is vital. Prepare the continuity of operations plan to inform
incident management staff of immediate or imminent effects on this crucial piece of
their response system.

Do Regular and Preventive Maintenance

Equipment built to public safety standards often comes with extended warranties that
help underwrite the cost of repairing problems. Unlike consumer electronics, which
occasionally find their way into emergency communications systems, public safety
equipment is generally built to withstand years of routine use.

The equipment still needs maintenance, however. Both electronics and physical
structures need to be inspected, tested for proper functioning, and adjusted. As much
as modern radios are driven by embedded computers, they still have other internal
components that occasionally need to be tuned. Likewise, physical components, such
as towers, shelter HVAC (heating, ventilation, air conditioning), and power systems,
need to be inspected and maintained. Just one lighting violation notice from the
Federal Aviation Administration (FAA) due to a failed tower strobe can ruin a system
manager’s day!

Testing and maintenance records are important to keep. Prior work on equipment is
always useful for technicians to have at hand and may be necessary for documenting
equipment failure trends.

System infrastructure is tuned for optimal performance. Radio signal and line levels
are adjusted for optimum performance, as are data network components. Records
establishing a baseline for measurements and allowing tracking over time are
invaluable for system maintenance. Some tuning measurements show seasonal shifts,
 Chapter 14: Maintain the Technology
221

!
One large jurisdiction with a P25 trunked radio system had to replace all of
its new portable radios, numbering many thousands, not once, but twice.
Technicians first found the radios unacceptably susceptible to other nearby
portable transmissions, rendering them effectively deaf to the much weaker
system signals from towers.

After the portables had been replaced with great effort, another design problem was
found in the push-to-talk (PTT) switches, which weakened over time, causing multiple
erroneous system requests each time the button was pressed. These problems were
discovered through agency testing and documented to prove the problem.

The los Angeles while others show variance due to system load and component aging. Documentation
Tactical radio of routine maintenance measurements is necessary for identifying and fixing
Communications problems.
System (lArTCS)
is a joint effort of
city, county, and
Test at Least Monthly
state agencies in Regular testing is important for assurance that the system will be available when
los Angeles County. needed. Schedule monthly tests, at least, to verify that system components are
It is tested by user functioning as anticipated. The type and degree of testing should be established as a
agencies twice a week. matter of policy and procedure.
lArTCS connects
together different
End-user testing on a regular basis is a good means to assure that the system is
radio systems through
a gateway. See:
operational. Technical testing needs to also be conducted to detect problems before
http://www.lartcs.org they affect operations.

Maintain System Security

Unfortunately, system security is often overlooked. Both physical and electronic
security of modern communications systems is important. It’s also time-consuming,
so agency and system managers need to provide the resources necessary for it to be
done. Inspections, monitoring, and proactive measures are involved.

Physical security is the first bastion in protecting communications systems. All

access control systems—from fences to lock keys to electronic access cards to active
Security is
detection systems—require their own maintenance procedures.
necessary for
mission-critical
systems. Interagency SOPs should be set up to prevent breaches due to a single weak link.
Nobody wants to be the weakest link! Use inspections and active monitoring to secure
the systems.

Monitoring systems allow system managers to keep track of both physical access
 222 Part II: How Is Interoperability Achieved?

Intrusion detection to communications facilities and logical access by, for example, remote computers
and prevention for system configurations. Some components of voice radio systems, evermore
systems can be computerized, can be reactively monitored by intrusion detection systems (IDS) and
used with central
proactively secured by intrusion prevention systems (IPS). In effect, these systems
parts of digital
radio systems. watch for unusual activity and either provide notification and/or take action to
mitigate impacts.

Other proactive measures, such as encryption key management, are necessary to keep
systems operating at expected levels of security. Key management is a serious and
necessarily rigorous process for agencies using encrypted radio systems. We touch on
it for both voice and data technologies, in the Part III – Exploring the Technologies.

Prepare for System Changes

As another Finally, as much as you don’t want to hear it, it’s never too early to start preparing
companion to
for system changes. System expansions of scope and depth are inevitable, as is the
the original Law
Enforcement Tech unending march of technology into the sea of obsolescence. Even harder to prepare
Guide, SEArCH for are regulatory changes that force changes to systems.
has developed the
Law Enforcement
Tech Guide on
Evaluate Potential System Upgrades
Information You prepared for system upgrades early in your project by documenting needs
Technology uncovered during early analysis and left unaddressed during implementation. Every
Security: How to project will have some share of nice-to-have features that went by the wayside as the
Assess Risk and project’s scope, timeline, and budget were fixed. The oversight board can effectively
Establish Effective keep participants actively engaged with a living, evolving system by recognizing these
Policies funded by needs and working with participants to meet them over time.
the COPS Office.
(Publication
pending, 2006.) Anticipate that unimplemented features of the chosen technology may become
useful over time as well. Vendors will have a natural interest in selling upgrades—
initially minor and eventually major—that may address unmet needs. Use working
committees actively to investigate upgrades, analyze their impacts, and make
recommendations. For example, growing use of commercial wireless data networks
subjects the agencies using them to rapid technology transitions—transitions that
Use working
are uncommon with more slowly evolving public safety technologies. Managers
committees to
actively investigate, of interagency communications systems that use commercial services have to
analyze, and make continuously analyze their vendors’ technology lifecycles.
recommendations
on potential system
upgrades.
Prepare for Regulatory Changes
In closing, regulatory changes face most public safety radio users. Large agencies and
consortia are effective in the Federal Communications Commission (FCC) regulatory
process that governs the radio world, but it takes a significant commitment of time to
stay on top of what, at times, seems to be a torrent of public notices, notices of public
rulemaking, notices of inquiry, final reports, orders, and more.
 Chapter 14: Maintain the Technology
223
rely on Most agencies are more effective by working through their professional organizations,
professional such as the International Association of Chiefs of Police (IACP), International
organizations to Association of Fire Chiefs (IAFC), National Sheriffs’ Association (NSA), National
help manage the EMS Management Association (NEMSMA), and the Association of Public-Safety
effects of regulatory Communications Officials – International (APCO).
change.

The most significant regulatory issues on the horizon are 800 MHz rebanding,
release of 700 MHz spectrum, and narrowbanding of public safety frequencies
below 512 MHz. These changes affect pretty much all public safety radio users.

n Rebanding
Rebanding of 800 MHz is necessary to move public safety users in that band away
from harmful interference they are receiving from commercial radio services.
rebanding of 800
The move offers the opportunity to consolidate public safety spectrum, leading
mHz is expected to
cost $2.5 billion. to improved management of systems and technological opportunities. The cost,
estimated at $2.5 billion, is being borne by Nextel, whose facilities have interfered
most with public safety operations.

Rebanding will take place during a 3-year period and is expected to be complete by
mid-2008. The United States is split geographically into four zones. Four “waves” of
transitions are defined. Licensees in affected portions of the 800 MHz band that have
to be relocated will be contacted by a “transition administrator” to plan and schedule
the transition.

n New 00 MHz Spectrum

A good deal of new spectrum in the 700 MHz band for public safety will be released
in coming years as incumbent television broadcasters are relocated. It is already clear
in some areas of the country without broadcasters on the affected UHF television
channels (63, 64, 68, and 69). New wider channels capable of higher speed data are
being made available in this band. Existing 800 MHz systems in need of additional
channels may look to add incremental 700 MHz channels as rebanding proceeds and
equipment capable of the spread proliferates.

n Narrowbanding
The majority of public safety agencies in the country operate in VHF-high and lower
narrowbanding will UHF bands. This spectrum, between 150 and 512 MHz, has been the subject of
affect the majority intense debate for years between federal regulatory and public safety agencies. In
of public safety an effort to make more efficient use of the bands, allowing more channels, the FCC
agencies in the released an order in late 2004.
country over the
next 5 to 7 years.
The order sets a deadline of January 1, 2011, for the manufacture and importation
of equipment capable of wider band (25 kHz) channels. Applications for wider band
22 Part II: How Is Interoperability Achieved?

channels also will be accepted until that 2011 deadline. All public safety voice
operations between 150 and 512 MHz are to be moved to narrowband (12.5 kHz)
channels by January 1, 2013.

REGULATORY RESOURCES
The 800 MHz rebanding is addressed in detail on the FCC web site: http://wireless.
fcc.gov/publicsafety/800MHz/bandreconfiguration/index2.html.

The FCC has designated a “transition administrator” to manage the tremendous change
and cost associated with relocating 800 MHz users within the band. The transition
administration web site is: http://www.800ta.org/.

The FCC’s web site on 700 MHz spectrum contains the most up-to-date information on
efforts across the country to put this spectrum to use:
http://wireless.fcc.gov/publicsafety/700MHz/.

Efforts to “refarm” spectrum use below 512 MHz have been under way since 1992.
The most recent regulations require reductions in the amount of spectral space used,
referred to as “narrowbanding.” See the FCC web site:
http://wireless.fcc.gov/services/plmrs/refarming/.
 CHAPTEr 15
mEASUrInG InTErOPErABIlITy
 Chapter 1:
Measuring Interoperability

What A process for subjectively assessing communications interoperability across five

accepted dimensions.

Why Plot your current position and heading, with midcourse corrections, to verify that
you are on track to achieving interoperability.

Who The governing body of the interagency initiative or project is in the best position
to complete the assessment itself, or to direct a more thorough assessment across
participating agencies.

When Measure the state of interoperability early and repeat the assessment at least
annually.

Interoperability is a difficult quality to measure. Forgetting the fact that the

term has come to be used in reference to everything from fire hose couplings to
web-based software services, it’s an elusive capacity that only truly shows itself
in practice, not as some sort of static state of being. It is a necessary capacity
allowing public safety agencies to work together to achieve their respective
missions in protecting the public.

Interoperability isn’t a destination; it’s a waypoint. Your own agency’s destination

may be different from the next, but all rely on an ability to communicate with
Interoperability isn’t others. The “ability” isn’t always necessarily used, so the mere capacity to
a destination; it’s a communicate doesn’t tell us whether it’s put to beneficial use. Our measures
waypoint. of current position and course have to take into account not only the technical
capacity, but also its practical application to prevent, deter, respond to, and
recover from the effects of hazards of all types.

The agencies involved in your communications interoperability efforts will have

excellent reasons to frequently measure interoperability over time. This chapter
offers a subjective assessment process to help those involved in your initiative to
show progress on the route that has been charted.

Communications interoperability is a complex, but important, issue to measure.

It will become more complex over time.
 22 Part II: How Is Interoperability Achieved?

Why Measure Interoperability?

Any effort to improve the capabilities or performance of organizations needs to
you get what you establish a baseline to assess progress and regularly reassess it to steer efforts toward
measure. the desired destination. Measures of communications interoperability have to be
carefully chosen and defined to ensure that what is being assessed is what is desired.
You get what you measure.

The process of measuring interoperability offers benefits. It helps to focus effort

on the achievable, rather than simplistic ideals, by establishing understandable,
measures observable objectives. It encourages joint ownership of both the objectives and
communicate.
progress in meeting them. It provides a tool for accountability. Most of all, it
communicates in a language of objectives that, even if imperfect, can be common
among stakeholders.

The measures chosen must accurately and adequately reflect the desired goal, being
both accepted as relevant and measurable. Recognize that measures, objectives,
measures reflect and goals are progressive. Achieving interoperability between public safety
objectives on
communications systems is only a step to achieving the greater goal of interoperations.
course to achieving
goals. Ultimately, the measure of interagency communications is its yeoman service,
unobtrusively and effectively supporting public safety responders working across
disciplines, jurisdictions, and levels of government to serve the public.

Cautious Measures
A strong conviction A point of note before proceeding: Interoperability has become an important rallying
that something cry, but has come to mean widely different things to different people. To some, it is
must be done is the the willingness of agencies to work together. To others, it is merely having compatible
parent of many bad technologies. To most, it is a term that has grown in importance in the past decade
measures. following national tragedies and responder cries for better communications.
—Daniel Webster
The basic measures of communications interoperability addressed in this chapter
have been carefully crafted by the public safety response community. While basic,
they are not simplistic, nor are they particularly simple to achieve. They are,
however, the common elements that are broadly recognized as key to this elusive
quality called interoperability.

The Interoperability Assessment Scorecard

Agencies identify the need for a basic, yet relevant, means of assessing their
communications interoperability. Drawing on SAFECOM’s work in conducting a
national interoperability baseline assessment, a simple process is offered here for
marking the current state of your initiative and assessing its progress over time.
 Chapter 15: Measuring Interoperability
229
SAFECOM Interoperability Baseline Assessment
In 2005, SAFECOM initiated a project to define an interoperability baseline
assessment process. The multiphase process first sought to define how the level of
interoperability in an agency or a region can be assessed. The goal was to provide
the means to understand the current state of interoperability. A practitioner
working group was established to collaborate with staff and contractors preparing
the assessment.55

Previous studies of communications interoperability have been narrowly focused

on the issue. The SAFECOM baseline assessment uses the five dimensions of
interoperability introduced in the Interoperability Continuum to get more deeply at the
root of key interagency communications factors (Figure 15-1). Through development
of a straw man measurement tool and its refinement by four focus groups held across
the United States, 13 measurable subelements of these dimensions were chosen for
assessing interoperability.

Interoperability Continuum Element Baseline Assessment Subelement

leadership
Decision-making Groups
Governance Agreements
Interoperability Funding
Strategic Planning
Policy, Practices, and Procedures
Standard Operating Procedures
Command and Control
Approaches
Technology Implementation
maintenance and Support
Operator Training
Training and Exercises
Exercises
Usage Frequency of Use and Familiarity

Figure 15-1: SAFECOM Baseline Assessment Elements (2005)

55
As this Guide goes to print, the baseline assessment has just been released. The author is a
member of the SAFECOM Advisory and the Baseline Working Groups.
230 Part II: How Is Interoperability Achieved?

Descriptive measures of each subelement were developed for assessing whether

an organization was in an early, moderate, or full stage of development for
communications interoperability. Additional measures were developed to identify
advanced stages of development as well. This measurement tool arising from the
original Interoperability Continuum, consisting of the elements, their subelements, and
the descriptive measures for each stage of development, was the basis for the baseline
assessment matrix.

Conduct a Self-Assessment
Understanding that you may have picked up this Guide for a variety of reasons,
a baseline is always useful. You may be preparing for a multiagency initiative to
improve interoperability, in the midst of a project as we’ve discussed throughout this
Guide, or even proceeding to sustain a long-term effort. A baseline—and the earlier,
the better—establishes a multidimensional picture of where the agency, project,
or initiative is at that point in time. Subsequent self-assessments can be used to
determine if progress is being made across the continuum. Annual assessments as
part of a continuous improvement program can help link progress with programs.

The Interoperability Self-Assessment Scorecard

The Interoperability Self-Assessment Scorecard in Appendix D is a simplified form of
SAFECOM’s baseline assessment tool (an example of which is provided as Figure
15-2). It is useful with small and large groups alike, and can serve as an icebreaker
with new groups or to apply SAFECOM’s assessment process formally to a
particular initiative. It’s also easily replicable, meaning that it can be used over time
to gauge progress.

The SAFECOM baseline assessment presents one or more questions for each of
the 13 subelements and asks respondents to indicate separately across disciplines,
jurisdictions, and levels of government whether one of four statements—
corresponding to early, moderate, full, or advanced stages of development—best
describes their situation.

The Scorecard uses the assessment tool’s questions and measures, but collects a
singular assessment of each subelement across disciplines and jurisdictions in a
matrix for presentation. It presents the four statements and asks for a subjective
assessment of the current stage of development across cooperators or project
participants using further prompts both from the assessment methodology and
baseline measurement tool.
 Chapter 15: Measuring Interoperability
231
ExAMPLE
Consider the question and how
Governance: Strategic Planning this measure varies across
organizations, then choose one of
Strategic Planning these stages of development
How would you best describe the
planning efforts to make decisions, Early Development
take actions, and create processes that
no interoperability
ensure interoperability?
strategic plan or strategy
- no interoperability strategic in place
plan in place; some preliminary
planning may have begun
Moderate Development
- Strategic planning process
in place and plan under Strategic planning process
in place and plan under
development
development
- Strategic plan in place and
accepted by all participating
organizations Full Development

- Strategic plans reviewed annually Formal strategic plan in

and after system upgrades place and accepted by all
participating stakeholders
and events that test your
organization’s capabilities
Advanced Development
Institutionalized processes
to review strategic plans
on an annual basis and
after significant events or
upgrades

Figure 15-2: Interoperability Self-Assessment Scorecard Example

This assessment is necessarily subjective. While you may (and should!) strive to
be objective in assessing your agency, jurisdiction, or region’s communications
interoperability, it’s still based on personal observations and conclusions. Its primary
importance is in establishing a baseline against which subsequent, equivalent
assessments can be compared and in communicating objective elements of success in
achieving communications interoperability.
232 Part II: How Is Interoperability Achieved?

Using the Self-assessment Scorecard

Even a subjective self-assessment can provide a tangible reference of where you
currently are and guidance on where you are headed. Whether conducted as a
structured poll or presented interactively to a group, keep in mind that this is a
subjective survey of a limited audience, not a scientifically applied survey to a
carefully selected sample. The results are useful for putting a stake in the stand and
seeking consensus on needed areas of work.

Step 1
Find a Suitable Venue
Use the Scorecard as either a standalone survey distributed to your project committees,
system oversight board, or any other group with a shared interest in communications
interoperability. Or during a meeting, present the subelements interactively. Ask
the group through a showing of hands or something more imaginative how their
organization rates the current state of affairs.

Step 2
Collect and Compile Responses
Collect and compile the results in some graphic format to depict the distribution
of responses for “analysis.” Another Scorecard, as shown in Figure 15-3,
serves well to collect all the responses. Whether through a distributed survey
or interactive poll, again remember that the results are simply a subjective
assessment of a limited audience.

In this hypothetical example, a 10-person Steering Committee of a communications

interoperability project is asked to evaluate their organizations’ interoperability using
the Scorecard. Responses are simply tabulated using check marks. On the Scorecard,
the stage of development, early through advanced, is described specifically for each
subelement using descriptions taken from the SAFECOM Interoperability Continuum
measurement tool.
 Chapter 15: Measuring Interoperability
233
Stage of Development
Element Subelement Early moderate Full Advanced
leadership 333 33333 33

Decision-making
3 33333 333 3
Groups
Governance Agreements 333333 333 3

Interoperability
333333333 3
Funding
Strategic Planning 333333 33 33

Policy, Practices,
Standard 3333 3333 33
and Procedures
Operating
Procedures Command and
333 333 333 3
Control
Approaches 33333 333 3 3

Implementation 3333 33333 3

Technology
maintenance and
333333 33 33
Support

Training and Operator Training 3333333 33 3

Exercises Exercises 3333 33333 3

Frequency of Use
Usage 3333 3333 33
and Familiarity

Figure 15-3: Interoperability Self-Assessment Scorecard Example

Step 3
Analyze the Results
There’s not much “analysis” to do, but watch out for a couple of potentially odd results.

First, without getting into statistical theory, any survey or poll of more than just a few
people is going to show a distribution of responses. If the audience is at all diverse
(most likely so with interoperability initiatives!), there will be a response or two well
outside the others. While there’s no wrong answer in this survey, it’s unlikely that
a single agency is much more or less interoperable than its neighbors. For example
in the Scorecard above, “Approaches” drew one response far from the median. For
purposes of finding some consensus measure, it can be ignored.

Second, a flat distribution of something as shown under “Command and Control”

above indicates there were either multiple interpretations of the question, differences
between represented disciplines, or other widely varying perceptions. In any case,
it bears further investigation. The discrepancy may indicate a particularly thorny
dimension of interoperability between the participants that needs to be addressed.
 23 Part II: How Is Interoperability Achieved?

Step 
Present the Results
Carefully present the Scorecard results. They can be misinterpreted or misconstrued if
presented outside the context of the questions asked and measures used, so explain
the results in terms of the stages of development. For example, the “Frequency of
Use and Familiarity” results tabulated in Figure 15-3, examined in comparison to
development definitions included with the Scorecard (Figure 15-4), are fairly clear.
They could be reasonably understood to suggest respondents collectively concluded
that the agencies use solutions during planned events and somewhat regularly during
emergencies, but rarely for routine communications. Without the context of these
definitions, the stages of development may be understood too broadly to be useful.

Usage: Frequency of Use and Familiarity

Early Moderate Full Advanced

Development Development Development Development
First responders First responders use First responders use regular use of
seldom use solutions solutions regularly solutions regularly seamless solutions
unless advanced for emergency and easily for all has expanded
planning is possible events, and in a day-to-day, task to include state,
(e.g., special event) limited fashion force, and mutual aid federal, and private
for day-to-day events responders
communications
Performance
measurement, in
simplest terms, is Figure 15-4: Interoperability Self-Assessment Scorecard
the comparison Development Definitions
of actual levels
of performance
to preestablished On the Horizon: Performance Measures
target levels of Increasingly, effective management of public safety agencies requires the use of a
performance. performance measurement program rich in strategy and solid in application. Well
To be effective,
implemented, such a program ensures, among other things, that projects undertaken
performance must
be linked to the
are aligned with organizational goals and objectives, provide tangible improvements,
organizational manage factors associated with success and failure, are replicable, and through all
strategic plan. demonstrate a fair return on investment. Ultimately, performance measures are the
—The only legitimate means of evaluating organizational goals and objectives.56
Performance-
Based
Management
Handbook, 56
As another companion to the original Tech Guide, SEARCH has developed the Law Enforcement
U.S. Department Tech Guide for Creating Performance Measures that Work: A Guide for Executives and Managers funded
of Energy by the COPS Office (publication pending, 2006).
 Chapter 15: Measuring Interoperability
23
While the Scorecard described above can be useful in sketching a baseline for
your interoperability initiative and charting its progress, it is neither a fair nor
adequate measure of performance. Unfortunately, the absence of performance
goals and measures is a national challenge in achieving interoperability. (See “GAO
Congressional Testimony” on page 236.)

Measuring Effects, Not Capabilities

In and of itself, interoperability is unlikely to be a strategic goal of agencies whose
missions revolve around protecting public safety. Interagency communications is
certainly a key resource in many operations, but it is just part of the interagency
processes through which mutual services are delivered. The outcomes and impacts of
those processes—not some technical capacity to communicate—are the appropriate
subjects of performance indicators.

Communications interoperability is more than the mere capability to communicate

across agencies. In the most fundamental sense, it is the absence of communications
impediments in interagency operations. Inasmuch as too much communications can
actually interfere with operations at times, and intra-agency communications needs
typically far outweigh those between agencies, interoperability is a low performance
indicator for some processes. It’s not hard to imagine that high-performance
indicators of some interagency operations may necessarily be very little (or highly
controlled) interagency communications.

Interoperability This is not to say that communications interoperability is unimportant. Hardly!

performance Interoperability performance measures are inseparable from measures of mutual
measures are business process performance between agencies. Communications interoperability
inseparable from is the condition, ipso facto, that needed resources were available. What’s needed can
measures of
only be determined through rigorous definition of business processes (the right
mutual business
processes. things being done) and performance measures for those processes (things being
done right).

n An Example
An example may be useful. Radio gateways play an important role in linking
separate networks. They are notorious, however, for causing problems when
misused—a very real potential with many implementations. By linking two
channels, they potentially double the amount of traffic on each, tripling it with
three channels, and so on. If the mere presence of a gateway is factored as a
measure of interoperability, the measure may neglect the more important factor
of how the gateway is used; that is, whether in fact it actually improves or reduces
communications capabilities and operational performance.

The situation isn’t all dire, however.

23 Part II: How Is Interoperability Achieved?

GAO CONGRESSIONAL TESTIMONY

In 2003 Congressional testimony, the General
Accounting Office (GAO—now Government
Accountability Office) identified performance
goals and technical standards as the second
of three most pressing challenges in achieving
interoperability, following definition of what
interoperability is and preceding definition of
intergovernmental roles.
.
“When the interoperability problem has
been sufficiently defined and bounded, the
next challenge will be to develop national
interoperability performance goals and
technical standards that balance consistency
with the need for flexibility in adapting
them to state and regional needs and
circumstances.”
—U.S. General Accounting Office, Homeland Security: Challenges in Achieving
Interoperable Communications for First Responders, GAO 04-231T (Washington, D.C.:
Nov. 6, 2003). See http://www.gao.gov/new.items/d04231t.pdf.

Performance Measurement Improves

Communications
Given our topic, it’s ironic that a side benefit of a well-implemented performance
measurement program is improved communications within organizations, as well
as with external stakeholders. It improves communications by clearly relating
performance objectives to service goals and explicitly stating indicators of success. A
system of systems that improves interagency communications will actually flourish
through agency performance management programs that include measures of
interagency operations. It will do so because key business processes (and performance
indicators) will have been defined, and thus more easily communicated.

If this all sounds reminiscent of our discussion of needs analysis in Chapter 6, it

should. The first step in analyzing needs for your project was defining interagency
business processes and the final product was a business process baseline report. Not
only does a thorough understanding of business processes provide the framework for
technology projects, it’s also the heart of performance measurement.
 Chapter 15: Measuring Interoperability
23
Conclusion
The bottom line is this: Performance measurement is based on business needs,
not technological capabilities. It is impossible to measure the performance of
technology independent of the performance of the business processes it supports.
The most highly featured system cannot be shown to benefit an agency or multiple
agencies that don’t actively manage their own business process performance.

Communications interoperability projects will be subjected to required proofs of

performance more and more in the coming years. The scope, cost, and intended
impact of these projects is just too large to proceed on broad emotional appeals. The
public, elected officials, and funding agencies all demand accountability.

The choice for agency administrators and project managers will be to show the needed
performance benefit of improved interagency communications and why technology is
needed to accomplish it.
 Part III:
Exploring the
Technologies

Any sufficiently advanced technology is

indistinguishable from magic.
— Arthur C. Clarke
 CHAPTEr 16
vOICE COmmUnICATIOnS
 Chapter 1:
Voice Communications

Guideposts: Exploring the Technologies

The final part of this Guide introduces basic technologies used for public safety
communications, generally, and interagency communications, more specifically.
In this chapter, we start with background on the basic technologies used for
voice communications and then delve more deeply into their application for
interoperability.

We’ll cover the following topic:

• Understanding the Technologies
— ­ Federal Communications Commission (FCC) Classification of Radio
Systems
— ­ Analog and Digital Radio Technologies
— ­ Conventional and Trunked Radio Systems
— ­ Communications in Tunnels and Buildings
— ­ Satellite Communications
— ­ VoIP in Voice Systems.
• Approaches to Interoperability
— ­ Technology Approach: Swap Radios
— ­ Technology Approach: Gateways
— ­ Technology Approach: Shared Channels
— ­ Technology Approach: Shared Systems.
• Security
— ­ Advanced Radio Features for Physical Security
— ­ Encryption and Key Management.

In Chapter 17, we address data communications, as it may be used for everything

from simple text to live video.
 2 Part III: Exploring the Technologies

Have faith. Someone is thinking about the future.

Take a look at the diagram in Figure 16-1, which is intended to show a range of user
devices, all interacting through several applications, across various technologies. If
it looks terribly confusing, take heart. Your responsibilities probably take your time
and available attentions elsewhere on a daily basis. Your responsibility to manage an
agency, a division, or this particular interoperability project probably leaves little time
to delve this deeply into technology.

Figure 16-1: Future Interoperability Needs Between Wireless Devices

Source: Public Safety Wireless Network,
“Embedded Communications Broker (ECB) Technology,” October 2001
Any radio or mobile
data system will
only perform as Have faith that there are technologists who understand where we are today and
well as it is funded what technologies are likely to enable your operations tomorrow. Your own job
and engineered. more likely entails understanding the public safety business, getting and using
—Steve Proctor, funding effectively to improve operations, and figuring out how you’re going to
Executive Director, work with partners in response.
Utah
Communications
Agency network
 Chapter 16: Voice Communications
2
Understanding the Technologies
Public safety communications technology parallels consumer and other
commercial technologies. As more digital communications are used, voice
becomes more indistinguishable as the “payload” over much of the networks
connecting senders and receivers of information. It has unique features that shape
how it’s moved from the analog world of sound, handled over digital transmission
SAFECOM Library systems, and then converted back to sound. However, in most ways it can be
The SAFECOm transported and stored in digital form just like more traditional data.
online library is
a prime source
While voice and data communications for public safety services have long been
for technical
information conducted over both wired and wireless links, we focus here mostly on the latter.
about voice It’s there that the greatest communications interoperability challenges have
communications occurred for first responders. Recognize that advanced radio systems increasingly
systems. It includes include many wired components at their cores, just as voice and data are
documents from increasingly intertwined in emergency response communications.
multiple sources,
including the past
Public Safety FCC Classification of Radio Systems
Wireless network Before we look at the primary voice radio technologies, let’s pause to clarify some
(PSWn) Program. terminology and look at FCC classifications of radio systems.
See http://www.
safecomprogram.
The FCC uses specific terms to distinguish radio technologies and their uses. The
gov/SAFECOM/
library/technology/. term type is used to distinguish different fundamental technologies, while services
distinguish between different applications of the technology.

The term type acceptance is commonly used in the radio world. It refers to the FCC’s
formal process of evaluating and approving technologies. Individual manufacturer
The FCC radio models must receive FCC-type acceptance before they can be made
distinguishes radio commercially available. It’s not uncommon to hear manufacturer representatives
types and services. speak of new models and note they are awaiting type acceptance before they will
be mass-manufactured and sold.

Several radio services are used by public safety agencies, including:

• Broadcast • Commercial • Specialized mobile
• Aeronautic • Maritime • Amateur.
• Unlicensed • Land mobile

Traditional dispatch, car-to-car, and field communications used by public safety

is land mobile radio (LMR). This term is commonly used by industry and in
regulations in reference to terrestrial radio services to support mobile users.
Portable and car radios are both classified as “mobile” at this level of discussion.
 2 Part III: Exploring the Technologies

While several of the radio services listed above are probably recognizable to readers,
The FCC classifies others may be confusing. Most public safety radio networks are regulated by the FCC
most public safety as private radio systems. Where common carrier systems are made commercially
radio systems as available for general public use, those built and operated for private use are
private radio. considered private systems. In this case, “private” refers to how they’re used, rather
than owned.

Many commercial industries have their own private radio systems. A few are actually
more than 300 shared with public safety agencies, but the vast majority of police, fire, and EMS
agencies in South voice radio communications takes place over systems owned and operated by the
Carolina use the agencies themselves. Most of these systems require FCC licensing. Unlicensed radio
Palmetto 800 technologies, such as those that might be used for wireless local area networks
System, an 800
(WLAN), are regulated separately.
mHz system shared
with power utility
companies. Whether licensed or unlicensed, private or common carrier, radio technologies are
For further broadly subject to FCC regulations. Rely on your radio technicians, vendor
information, see: representatives, frequency coordinators, and professional associations to help you
http://www.cio. sort out details if you intend to be heavily involved in radio technology.
sc.gov/cioContent.
asp?pageID=756&
menuID=411. Analog and Digital Radio Technologies
For the first century of radio, analog radio technologies predominated. Those
technologies include amplitude modulated (AM) and frequency modulated (FM) radios
that we’re all familiar with from broadcast radio services. Others exist, but all analog
technologies are based on use of audio tones (frequencies) being superimposed on
radio frequencies (RF) in a standardized manner.

Audio frequencies, such as those delivered electronically by radio microphones,

are mixed with RF within analog radio circuitry, further amplified, and then
transmitted. At distant receivers, the audio is extracted electronically in more
or less the reverse manner. Data can be transmitted much like voice over analog
systems by encoding bits using different audio tones and other techniques of
shaping the transmitted RF signal.

n Channel Bandwidth
FM is by far the most common analog radio mode today. It is also the compatibility or
legacy mode for digital radios. However, transmitters and receivers not only have to
use common means of putting information on the RF signal (i.e., modulating it), they
also have to use compatible channel widths and operate in the same frequency band,
such as VHF, UHF, or 800 MHz.
 Chapter 16: Voice Communications
2
Frequency bands for common public safety voice purposes are typically described in
Public safety
millions of radio wave cycles per second, or megahertz (MHz) (Figure 16-2). They are
frequency
bands for voice occupied by channels of a certain bandwidth. That is, they take up a specific amount
communications of the frequency band.
are typically
described in Channel bandwidths are described in thousands of cycles per second (kilohertz
megahertz, while is abbreviated as kHz). A channel is a slice of some part of the radio frequency
channel bandwidths spectrum. That is, we talk about a traditional 25 kHz voice channel in the 450 MHz
are described in
public safety frequency band. A traditional voice channel in that band has been
kilohertz.
allotted 25 kHz of RF spectrum.

Figure 16-2: Public Safety UHF Frequency Band, 450-470 MHz

n Narrowband Channels
Narrowbanding, as discussed in Chapter 14 (Page 223), is an FCC regulatory effort
that will affect all analog radio users. Its goal is to reduce the amount of RF spectrum
occupied by a single channel to increase the number of channels that can fit in a given
band. This is not the first time the FCC has split channels for this purpose and we can
expect it to happen again.

The FM radio channel has existed for decades as nominally 25 kHz in width. We say
“nominally” because channel width is more an absolute under regulations than under
the laws of physics. It actually varies in width according to transmitter adjustments
The FCC requires and characteristics of the audio being carried. In addition, the transmitted power isn’t
that public safety all contained within the defined channel; a progressively smaller fraction exists farther
operations move to and farther away from the channel center.
12.5 kHz channels
or the equivalent by
January 1, 2013. FCC rules will have all public safety voice operations between 150 and 512 MHz
moved to narrowband (12.5 kHz) channels by January 1, 2013. Technically, the
requirement is that a channel can occupy no more than 12.5 kHz or the effective
 2 Part III: Exploring the Technologies

equivalent. This last clause can be a bit confusing. There are proprietary techniques to
interweave two separate conversations, both using the whole 25 kHz, but splitting use
of the channel second by second. Most commonly, the narrowband channel will be
used wholly for a single communications path.

One net effect of this transition is that narrowband analog transmitters will have
less spectral space to put RF energy, thus reducing the power and range of an analog
channel relative to the wider band channel. Just how much is the subject of debate,
but recognize that the range of a narrowband transmitter will be less than that of its
wider band cousin.

While digital uses of these radio bands are similarly affected, existing digital
technologies already use 12.5 kHz channels or allow multiple voice conversations to
occur within a traditional 25 kHz channel. Narrowbanding is thus leading to wider
adoption of digital techniques.

n Digital Radio
Digital radios use many of the same components as their analog relatives. For voice
radio purposes, microphone audio frequencies are first converted into bits by the voice
A vocoder converts encoder or vocoder. This is a particularly important part of the digital radio system; not
analog sound to all vocoders are created equally. For public safety purposes, great work has gone into
digital bits.
testing and choosing vocoders that efficiently produce a digital stream to make most
use of the radio channel, while still faithfully representing it.

The process of creating digitized audio, transmitting it over the largely inhospitable
The P25 vocoder airwaves, and decoding it on receivers is fraught with danger for the lowly voice bit.
standard carefully Project 25,57 which produced the national standard for public safety digital voice radio
balances efficiency, systems, took on the challenge. It undertook a significant effort to find a vocoder
robustness, and sufficiently efficient, yet producing resiliently encoded audio for the most critical
fidelity. missions, in some of the most difficult radio environments. The Project 25 vocoder
standard was selected as a careful balance of efficiency, robustness, and fidelity.

Digital radio standards for public safety don’t stop at speech encoding, however. As a
matter of fact, the vocoder is just a small part of the technology that takes audio,

57
Initiated by the Association of Public-Safety Communications Officials – International (APCO),
in cooperation with the National Association of State Telecommunications Directors (NASTD)
and with support of other public safety organizations like the International Association of Chiefs
of Police (IACP). Project 25 received its name following APCO’s tradition of numbering its
broad initiatives to affect the public safety communications world. P25, as it is also commonly
known, is the association’s best-known project. The specifications have been codified by standards
development organizations. For further information, see http://www.project25.org.
 Chapter 16: Voice Communications
29
radio encodes it, packages it up, inserts it aboard the radio channel train, and assures it can
transmissions are be unpackaged successfully on the other end.
weakened over
distance and by the Another key piece of the Project 25 standard is its Common Air Interface (CAI).
environment. Without going into depth, the CAI provides the standardized means for receiving
radios to recognize what is coming over the airwaves and extract an intelligible signal.
Any digital receiver has to know how to decode the audio bit stream once received and
passed to internal microprocessors, and then convert it back to audio frequencies that
The P25 Common can be heard through speakers. That’s not all, though. Receiving radios also have to
Air Interface is know when and where a package of bits begins and ends, how to deal with inevitably
the public safety missing or erroneous bits, how to recognize other embedded codes, and more. Project
standard for digital,
25’s CAI is the standard for how that’s done with public safety digital voice radios.
rF transmissions.

Standards are absolutely essential for interoperability of radio systems.

n The Radio Environment – Analog

Once transmitted, radio waves are subjected to the same environmental effects
regardless of their payload. The laws of physics aren’t particularly concerned with
whether they’re bearing analog or digitally encoded information.

It’s a hostile environment. Received radio signals may be millions and millions
of times weaker than they were at their source. Not only do signals diminish
geometrically as a function of distance, they also are weakened or attenuated by the
environment over and through which they pass. Manmade and natural obstructions
both tend to absorb radio waves. Similarly, each time a radio wave is reflected or
diffracted (which is often!), it scatters and loses a bit more energy. Add to this the
additional challenges imposed by relatively rapidly moving transmitters and receivers
and it’s nothing short of fundamental magic that any intelligence can be extracted
from distant transmissions!

Anyone who has listened to an FM broadcast recognizes the sound of a station fading
in and out. If you’ve listened carefully in areas where FM broadcast stations overlap
on the same frequency, you’ve also heard the effects of two roughly equal signals
competing in your receiver. “Roughly” in the radio world is measured in factors of
tens and hundreds. A signal that is 100 times or stronger than competing signals will
generally be the only one heard on a channel. In the radio environment, signals can
vary by a factor of a hundred within the distance of a few feet.
Overlapping radio
signals cause FM has something called the capture effect whereby once a receiver is locked on to
interference in a given signal, it rejects a competing one up to a point. As the new signal becomes
receivers. increasingly stronger, the receiver finally gives up on the first and locks onto the
20 Part III: Exploring the Technologies

second. In between, distorted and mixed audio is heard. Portable and mobile radio
users of two-way FM channels quickly learn to recognize the signs of one user
“walking on” another through overlapping transmissions.

n The Radio Environment – Digital

Digital radio technologies designed for public safety use error correction
techniques to recover intelligible audio from signals that are battered about by the
environment and other radio users. Forward error correction (FEC) techniques are
used to allow a receiver to recreate a damaged signal from, in effect, redundant
parts of the digital stream. Additional signal information takes up part of the
digital channel for FEC purposes.

The term bit error rate (BER) is used to describe the percentage of received bits in a
digital stream that are “broken.”
While public safety radio
technologies can recover nearly
original audio with bit error rates in
the vicinity of 2 percent, recovered
Digital
audio starts to degrade as error rates Signal
Audio quality

increase.58 See Figure 16-3, Anyone

who has used a cellular telephone in
recent years has noticed the effect of Analog
weak digital signals on caller voice Signal

intelligibility. At some point the BER

becomes too high for digital signal
Signal Strength
processors to recover accurate audio
from the digital stream, leading the Figure 16-3: Recovered Audio quality by
receiver to shut off digital-to-audio Signal Type
conversion rather than pushing
noise to its speaker.

While the human ear and brain has a remarkable ability to recover intelligent audio
in the presence of relatively high noise levels, digital radio receivers are more limited.
At some point they have to stop trying lest they start making up sounds that weren’t
originally there. By comparison, intelligible audio can be discerned by the human ear

58
Vanderau, John M., Delivered Audio Quality Measurements on Project 25 Land Mobile
Radios, NTIA Report 99-358 (Washington, D.C.: U.S. Department of Commerce, Institute for
Telecommunications Science, 1998). A BER of 2 percent corresponds to a Delivered Audio Quality
(DAQ ) measure of 3.4. See http://www.its.bldrdoc.gov/pub/ntia-rpt/99-358/.
 Chapter 16: Voice Communications
21
through an FM or other analog receiver at a lower signal level than a digital receiver
can use. On the other hand, a digital receiver can recreate the identical audio signal
that was sent, while the received analog signal gains increasing background noise as it
gets weaker.

Let’s move on to the different types of systems that put analog and digital radio
technologies to work.

Conventional and Trunked Radio Systems

There are two broad categories of radio systems used for voice communications
today: Conventional and trunked. In order to understand the difference, it’s useful to
first understand a few basic system principles and common building blocks.

n Building Blocks – Simplex Communications

Land mobile radio systems are commonly designed to allow one party in a
conversation to talk while others listen. By contrast, telephone systems throughout
the years have been designed so both parties may speak simultaneously. Voice radio
protocols in public safety have evolved around the fact that only one speaker has
access to a channel at a time.

The common term for this form of communications is simplex. In radio usage, the
term carries further meaning. Simplex radio channels carry conversations conducted
on a single frequency where participant radios transmit (Tx) and receive (Rx) on the
same frequency. In Figure 16-4, “Frequency 1” (F1) is used for all transmissions.

The radio depicted at the tower is referred to as a fixed-base station, whether it is

closely or remotely attached to agency facilities. The base station could be placed on a
mountaintop far from dispatch facilities, for example, and controlled remotely.

Figure 16-4: Simplex Radio Example

 22 Part III: Exploring the Technologies

This approach to radio communications works well and is the simplest, most resilient
form of coverage when all radio users are within range of one another. It becomes
problematic, though, when radio end users move out of range of each other.

In all two-way voice systems, from the simplest to most complex, radio coverage is,
well, a two-way street. It’s relatively easy to increase the transmission range of a base
station by increasing its power, but that doesn’t help users of mobile and portable
radios, which are comparatively weaker, talk back to the base. Radio engineers work
to balance the “talk-in” and “talk-out” of systems.

n Building Blocks – Duplex and Half-duplex Communications

When transmissions need to be relayed to include all users on a channel, a different
class of radio station is used that can simultaneously receive a transmission from
one user and retransmit it to all others. This capability is referred to as duplex
communications. User radios typically can transmit or receive, but not do both
simultaneously. As a whole, such systems of users and fixed stations are considered to
be half-duplex because end users are transmitting or receiving, while stations relaying
communications in the middle are doing both, simultaneously.

True duplex communications, as commonly experienced with telephones, allow the

Telephones
provide duplex
most natural forms of conversation. Since land mobile radio has evolved for one-to-
communications. many conversations in which at any moment there is one speaker and many more
Few radio systems listeners, full duplex systems are unusual. As anyone who has ever been part of a
are designed to telephone conference call can attest, having simultaneous “transmission” capabilities
do so. across all participants can actually impede communications at times.

n Building Blocks – Repeaters

Half-duplex relays are fundamental building blocks of public safety radio systems.
“Mobile relay” is the official term for this class of station, but they’re widely known
as “repeaters.” Repeaters as described have been used by public safety agencies for
decades to automatically relay transmissions for system users who would otherwise be
restricted in range by direct, simplex systems.

Repeaters are typically placed permanently with a well-situated antenna high up on a

A repeater
retransmits on one tower, building, or hilltop. From this vantage point, a repeater receives transmissions
frequency what it on one frequency and retransmits them on another. This serves to extend the effective
receives on another, range of a lesser powered radio, such as a portable, allowing other users of the
well separated from channel to hear and talk with others at greater distances. Other fixed radio stations—
one another to at dispatch, for example—can also transmit through the repeater. These are known as
reduce interference. control stations.
 Chapter 16: Voice Communications
23
The repeater’s frequencies have to be separated sufficiently from a spectrum point
of view to keep the transmitter from overpowering the receiver. If not, the repeater’s
transmitter effectively prevents its receiver from “hearing” the relatively much weaker,
distant signals. Some of the magic of radio engineering is dedicated to avoidance of
these and more complex interference effects. Sophisticated antenna systems are used
to isolate a repeater’s transmissions from its receiver so it doesn’t become the radio
equivalent of an alligator: All mouth and no ears.

Figure 16-5 shows how frequencies are split between the repeater and its users. Note
that the repeater’s frequency pairing is the reverse of the other radios. Field users,
including those at the station, transmit on Frequency 1 (F1) but receive on Frequency 2
(F2)—the repeater’s transmission frequency. The repeater does the reverse.

Figure 16-5: Half-duplex (Repeater) Radio Example

n Building Blocks – Mobile and Portable Radios

Public safety agencies use mobile and portable radios to connect field operations
with dispatch and other fixed stations, as well as among field users. Though lumped
together by the FCC as “mobile” devices, vehicular and portable radios are considered
by industry and the public safety community, itself, somewhat differently.

As might be imagined, portable radios are relatively handicapped compared to

vehicular radios on two-way LMR networks due to limited transmission power and
compromised antennas. They operate with much less transmit power than vehicular
radios—about 5 to 10 percent of the latter’s output power. Their antennas provide
needed portability, often in exchange for efficiency, and are typically situated at
 2 Part III: Exploring the Technologies

something of an electromagnetic disadvantage compared to those on vehicle roofs.

The human body, itself, tends to block radio waves that would otherwise be received
or transmitted by the portable. To this, add the fact that portables can be and are
often carried into locations far less friendly to radio emissions than the streets where
vehicular radios operate.

Radio system design is hugely affected by whether primary coverage is sought for
portable or mobile radio use. Two-way radio networks, voice and data alike, are built
to take into account differences between fixed and mobile devices on the network.

n System Building Blocks – Simulcast and Receiver Voting

Systems
The technologies discussed so far have been in use for decades. In these conventional
Coverage needs
lead to use of
radio systems, there is a one-to-one correspondence between each frequency (or pair
simulcast systems of frequencies in duplex or half-duplex operations) and a channel. In effect, channels
where multiple are simply defined by who has and uses the designated frequencies within a given area
sites transmit of operation.
the same signal
simultaneously to Large-scale, wide area systems have been built for years with conventional
cover an area.
technologies. Public safety agencies have put up multiple repeaters to provide needed
channel capacity for simultaneous operations and to cover wider areas. Capacity
and coverage demands call for multiple repeaters at a single site in some cases and
multiple sites in others. It’s not uncommon to use multiple sites to provide coverage
that can’t be had from a single site. With such systems, users are relied upon to use the
appropriate channel (i.e., frequency) depending on their job and location.

It’s possible with conventional systems to simultaneously transmit the same signal
from multiple locations. This is referred to as simulcasting. It requires careful
synchronization of the individual transmitters and a healthy backbone of microwave
or some other form of dedicated telecommunications circuit to deliver the outbound
signal to all sites simultaneously.

In the example shown in Figure 16-6, audio to be transmitted from all sites
simultaneously originates from the central facility—a dispatch center, for example.

While simulcasting reduces the need for users to manually “steer” their radios by
the channel selector knob as they move around a geographic area, it adds system
complexity and a reliance on the circuits connecting to remotely operated base
stations. It also brings a need for the system to deal with the common situation of two
or more sites receiving a transmission from a field user. Just as a field user’s radio will
likely receive a transmission simultaneously from multiple sites, it will also likely be
heard by multiple ones when it’s transmitting.
 Chapter 16: Voice Communications
2

Figure 16-6: Simulcast Simplex Radio Example

Additional electronics are added to the heart of the system to select the best signal
received by the sites. In the example shown in Figure 16-6, two sites might receive
decent signals from a user, while the third site receives a weak signal. Central
electronics pick out the best signal and pass it to users at the fixed facility.

This is known as a simulcast system with receiver voting. For practical purposes, the
system can be thought of as a single base station with the wide, composite coverage
provided by all the separate sites. The effect is a single channel that covers a wide
expanse. While useful in low-traffic, routine operations, such wide-area, blanket
coverage can be a problem during periods of high demand when the load across all
sites can overwhelm a single channel.

The final conventional radio example to be presented here combines multiple

technologies and adds a new one: Remote receivers. Actually, remote receivers
have been depicted in the previous examples, too, but have been paired with their
associated transmitters.

Figure 16-7 depicts a repeater system with additional remote receivers. Sites labeled
“Rx Only” are simply receivers that send back received signals to the central site
where a voter can pick out the best received signal. Remote receivers are often used to
 2 Part III: Exploring the Technologies

accommodate portable radios that can “hear” the more powerful and well-situated
fixed transmitter sites, but are unable to “talk” back to them due to the distance or
terrain.

remote receivers
allow weaker
signals to get into
the system.

Figure 16-7: Simulcast Repeaters with Remote Receivers

In this example, some possible receive and transmit paths have been omitted for the
sake of clarity. It depicts a circumstance where Repeater A can be heard by User 1, but
that user can only be heard by Repeater B. Repeater B can be heard by both users, but
User 2 can only be heard by Repeater C and one of the remote receivers.

The combinations and permutations of which transmitter can be heard by which

receiver—both fixed and mobile—are nearly endless in a large system. Imagine how
complex this can become with dozens of fixed sites with multiple channels. It should
be no wonder that radio engineers are needed to design and carefully tune all the
components that make such an electromagnetic marvel operate!

n System Building Blocks – Trunking

The next major technology used for public safety operations is trunking. Simply put,
trunking is the means to share a limited number of frequencies between users, with
each set of users having its own virtually private channels.
 Chapter 16: Voice Communications
2
Trunking is widely used in telecommunications systems. Users of the public switched
telephone network serving businesses, residences, and emergency response agencies
worldwide are well experienced at using a trunked system—even if they are unaware
of it. Complex technology assigns circuits (channels) dynamically upon requests for
access, such as occurs when a telephone number is dialed. The newly assigned circuit
may have just been used for an entirely different telephone call between different
locations, but now is being reassigned.

Radio systems can be constructed to operate the same way. The primary value of
The primary value trunking is channel efficiency. That is, rather than having sets of users occupy a
of trunking is channel fixed by frequency, leaving the channel empty at times and overloaded
channel efficiency. at others, the trunked system takes multiple channels and assigns them to sets of
users as needed. This also enables groups of users that could never have a separate
conventional channel to have a trunked one for private use.

With a conventional system, three repeaters at a single site might have served police,
Trunking
fire, and EMS, individually, with all users from one of the disciplines operating on
provides multiple
virtual channels a single channel. With these three repeaters trunked, a nearly limitless number
for separate of virtual channels can be assigned and used without interference between users.
conversations. However, the number of simultaneous conversations is still limited to the total number
of talk repeaters at the site.

This brings up an important point: Most public safety trunking systems reserve
one repeater at each site for the system or control channel. This is the channel of
communications over which the radios talk among themselves behind the scenes
to coordinate who goes to which frequency, at which site and what time, to become
part of a conversation. This system traffic goes on nearly continuously as portable
and mobile users move around between sites and change their channel selectors to
become part of a different conversation.

While there is a direct correlation in conventional radio systems between channels

A trunked channel and frequencies, trunked systems abstract the notion of a channel. Rather than being
is called a a fixed pair of frequencies, a trunked channel is a temporarily assigned repeater for
talkgroup. use among a predefined group of users. In trunking parlance, the channel and its
defined users are both known as a talkgroup.

Any individual user radio can be part of many talkgroups. The user may, depending
on agency policy and radio programming, choose to scan multiple talkgroups during
normal operations, just as they may have scanned multiple conventional channels
with an earlier system. In a trunked system, the user radio literally notifies the system
that it wants to be part of any conversations occurring among the selected talkgroups.
Still limited by the fact that the radio can only receive one transmission at a time,
 2 Part III: Exploring the Technologies

the user also has to select a single talkgroup on which to transmit using the radio’s
channel selector knob.

Because trunked talk channels are set up and torn down as needed, end-user radios
rely on the system to tell them when a talkgroup is coming active and to get directions
on where to tune. This takes place over the control channel, normally in a fraction
of a second. As soon as an open repeater is available, which may actually be multiple
repeaters if the network spans more than one site, the transmitting radio is allowed
to talk and all other radios in the talkgroup automatically tune to the transmission
frequency(s).

All talkgroup conversations go through the system. A central controller connected

to all sites and each repeater steers system resources to maximize capacity
according to preset parameters. The system can be programmed, for example,
to give certain user groups preference over others as they queue up waiting for
assignment of a channel. It can automatically spread conversations over multiple
overlapping sites to reduce bottlenecks.

Trunked systems can also be managed on the fly by dispatchers and system
Trunked channels administrators to collapse multiple talkgroups into a single one. This has a strong
(talkgroups) can be implication for interoperability. Where several talkgroups may be operating
collapsed into one independently from one another during an incident, and thus unable to communicate
to bring otherwise between their various users, a dispatcher appropriately authorized can combine the
separate users talkgroups into one. All users of the affected talkgroups can effectively be moved to a
together.
common one. While increasing interoperability, this also has the effect of increasing
traffic on the newly combined channel.

n Trunked System Pros

Trunked systems are commonly built with all the simulcast and remote receiver
capabilities described for conventional systems. In addition, the systemwide ability to
create virtual channels and assign radio resources as needed brings great flexibility to
user agencies. The system, itself, can contribute by balancing demand across physical
radio resources. Again, the greater channel efficiency of trunked systems may mean
they are the only choice in jurisdictions where spectrum resources have otherwise
been exhausted.

n Trunked System Cons

With all of this power, there are downsides to trunked radio systems. First, they
are costly. Agencies can expect to pay upwards of 50 percent more for the cost of a
trunked system over a conventional one with the same number of sites and radios.
 Chapter 16: Voice Communications
29
Second, all this power comes at the cost of greater complexity and potential for
failure. While modern system design calls for “fail-soft” systems that still operate
in a degraded mode as components fail or become unavailable, trunking still
ultimately depends on fixed infrastructure to work. The final fail-soft mode for
trunked radio systems is to operate conventionally—that is, with radios talking
Trunked System directly on predesignated frequencies chosen for specific purposes.
Policies
The complexity and
configurability of Communications in Buildings and Tunnels
trunked systems Emergency responders face great coverage challenges in both urban and rural
require great care areas. Where the challenge in mountainous terrain is overcoming natural
in implementation
obstacles, radio systems in more populous areas are equally challenged to
and ongoing
management.
overcome manmade mountains, canyons, and caves. Since the earliest days of
Design such radio, engineers have looked for ways to provide communications in buildings
complex systems and tunnels.
through careful
needs analysis Fixed, point-to-point communications in such environments are relatively
(Chapter 6), straightforward. On the other hand, communications with field units—whether
implement them
vehicular-mounted mobile radios or personally-carried portables—is the biggest
using functional
acceptance tests challenge. Portable radio communications are most difficult to accommodate,
mapped to user of course, because of their relatively low output power and limited antennas.
requirements Portable communications are further handicapped by how they are generally
(Chapter 10), used, being worn in close proximity to the body, which serves a lot better as
and manage their a signal absorber than reflector. Recognize that portable and mobile uses are
flexibility through similarly affected by coverage challenges, only to different degrees.
strict adherence to
both technical and
operational policies
and procedures SAFECOM LIBRARY:
(Chapter 12). TRUNKED SYSTEM RESOURCES
Several useful reports on trunked radio can be found on the SAFECOM web site,
including these:
Comparisons of Conventional and Trunked Systems (1999):
radio system http://www.safecomprogram.gov/SAFECOM/library/technology/1179_
coverage in conventionaland.htm
buildings and Operational Best Practices for Managing Trunked Land Mobile Radio Systems
tunnels requires
(2003):
additional
infrastructure. http://www.safecomprogram.gov/SAFECOM/library/systems/1049_
OperationalBest.htm
How 2 Guide for Establishing and Managing Talkgroups:
http://www.safecomprogram.gov/SAFECOM/library/systems/1047_
HowTo.htm
20 Part III: Exploring the Technologies

n Area Solutions
The most basic technique used to improve communications in buildings and tunnels
is to put additional system sites in denser urban areas. This increases the fixed station
(base or repeater) signal into nearby buildings and provides it a somewhat stronger
signal from the field unit. Because the greatest weakness is usually the fixed station’s
ability to “hear” the portable transmission, a more advanced technique is not to add
entire fixed stations (transmitters and receivers), but more receivers strategically
placed. This allows the relatively weak portable signal to “get into the system” from
more places.

While basic, this approach can be satisfactory in some locales and reduce
requirements for specialized technology and the additional expense of in-building
systems. System managers face an ongoing challenge in assuring that new
construction in and around the areas of interest doesn’t reduce coverage or otherwise
interfere with the balance achieved.

n Point Solutions
More and more often, peripheral technology is being used. This requires placement
of special repeating equipment within buildings, tunnels, and other signal-
challenged areas.

Bi-directional Amplifiers (BDA) are placed within the building to, as the name implies,
improve signals both inbound and outbound. Internal and external antennas are
linked by the BDA to capture weaker signals from within and retransmit them
beyond, and vice versa. Large structures may require a more elaborate, distributed
system of internal coverage antennas connected together, then linked to the outside
world through a single “donor” antenna.

Some areas, such as tunnels, are well suited to use of a special type of distributed
antenna system built from radiating coaxial cable. Traditionally, coaxial cable (coax)
of various forms is used to connect radios to their antennas. Properly speaking, the
cable is part of the antenna system, but is intended to quietly move signals from each
end to the other.

Radiating cable, on the other hand, is constructed to “leak” signals in and out along
its length. This can be a very effective sort of distributed antenna, although, as might
be expected, some careful engineering is needed for systems of this sort. Figure 16-8
shows an example of a BDA.
 Chapter 16: Voice Communications
21
Donor Coverage
Antenna Antenna

Bi-Directional Subscriber
Amplifier (BDA) Unit

Figure 16-8: Bi-Directional Amplifier Example

Source: PSWN, November 2002

n Governmental Regulation of In-building Coverage

There has been increasing interest post-9/11 in local ordinances requiring building
and structure owners to assure public safety radio coverage inside. While the need
for coverage improvements is indisputable, systems are sufficiently specialized that
they don’t promise to improve communications interoperability outside of the
improved coverage of a single, targeted system. In other words, they don’t broadly
improve interoperability.

A 2002 report by PSWN on the topic concluded that such ordinances “have no
noticeable impact on interoperability between public safety organizations.”59

Satellite Communications
Recent natural disasters have brought increased interest in satellite
communications to overcome the damaged and destroyed land-based radio
systems. Hurricane Katrina, which ravaged the United States Gulf Coast late in
August 2005, widely disrupted radio systems. Not only was cellular telephone
infrastructure damaged and nonexistent in many places, but public safety radio
systems were disabled in many locations (Figure 16-9). Whenever basic agency
radio systems are damaged, interagency communications suffer.

59
Public Safety In-Building/In-Tunnel Ordinances and Their Benefits to Interoperability
Report, Public Safety Wireless Network Program, November 2002, p. 14. See http://www.
safecomprogram.gov/SAFECOM/library/technology/1032_PublicSafety.htm.
22 Part III: Exploring the Technologies

Figure 16-9: Plaquemines Parish (Louisiana) Radio Tower – August 29, 2005
Source: Plaquemines Parish web site, http://www.plaqueminesparish.com

Satellites provide a backup means of communicating, particularly when terrestrial

infrastructure is nonexistent. They are regularly used in wildland fire and other
disasters, both to provide telephone services and data communications. In a
traditional or newly created wilderness, satellite communications may be the only way
to talk out from an incident scene.

Satellite services are available from a variety of vendors. Some are provided by way of
geosynchronous satellites that appear to the user to be fixed at a spot in the sky. At an
altitude of 22,241 miles, such satellites orbit at the same rate the earth rotates. Similar
to direct broadcast satellite (DBS) television, these services require a fixed antenna
that is pointed at the satellite or one that is electronically steered to keep itself so.

Other services are provided through low earth orbit (LEO) or medium earth orbit
(MEO) satellites that are relatively much closer, though still far distant compared to
cellular and terrestrial public safety radio infrastructure. LEO satellites orbit in a band
from a few to several hundred miles above the earth. This distance still challenges the
portable communications needs of first responders.
 Chapter 16: Voice Communications
23
Despite their value for disaster telephone and data services, satellites are not a
complete replacement for terrestrial voice radio systems used by public safety for
several reasons:
• One-to-many communications are inadequate. Voice communications
as most commonly used via space is limited to telephone-like services where
a user can dial up another telephone user—whether on the public switched
telephone network or elsewhere on a satellite system. Satellites do not offer
the immediate, one-to-many sort of radio conversations needed by public
safety responders.
• Coverage is inadequate. First responders moving about with portable radios
need coverage in all areas. Less penetrating than even cellular telephone signals,
satellite signals don’t reach far inside buildings or into dense vegetation.
Public safety radio systems are engineered to provide coverage far beyond what
satellite systems provide.
• Portable capabilities are inadequate. Even LEO satellites are many times
farther away in distance than traditional land mobile radio infrastructure. Since
both use radio frequencies to communicate, satellite signals are reduced in
strength even more across the distance, requiring bulkier antennas and higher
power. Even with adaptive power modes that reduce battery demand, satellite
handsets require more battery power than a responder’s standard portable
radio transmitting a much shorter distance. The demanding emergency
response environment leads to greater power consumption as users move in
and out of clear view of the sky.
• Capacity is inadequate. Communications between emergency responders
on scene during events is frequent. Many channels are needed for larger
events, such as those that would take out terrestrial infrastructure, and near-
instantaneous communications is needed in most cases. A single responder
often needs to communicate instantly with dozens of others. Satellites don’t
provide this ad hoc broadcast capability.

Satellite communications are vital in response to disaster. Their primary value is as a

replacement for cellular and other terrestrial telephone systems. In times of disaster,
there may be no alternative. Running a close second in value, data communications
via satellite are indispensable from any location out of range of terrestrial wireless
systems due to distance or events.

VoIP in Voice Systems

A bright star on the communications horizon is Voice over Internet Protocol or VoIP.
Most simply, it is the semistandardized means of taking voice or other audio that
has been digitized, then pushing it over networks similar to any other form of data.
Internet Protocol (IP) is part of the suite of standards that powers—imagine this—
the Internet and most other data networks today.
2 Part III: Exploring the Technologies

We refer to VoIP as “semistandardized” because there are limitless ways to move

digitized voice over IP-based data networks. It’s not as simple as just throwing voice
data packets on the wire and reassembling them at the end. The process is much
more complex and requires more communications between sending and receiving
systems than just the voice data. Different means are used by different vendors
and for different purposes to control the “envelope” of what we would consider a
conversation that is stuffed with voice bits and bytes.

n Basics of Digital Audio

Digitized audio has been passed over backbone telecommunications circuits for
years. VoIP differs in that the audio (voice or otherwise) is passed over modern
data networks that can route and reroute packets across a variety of intermediate
networks. They can, and do, pass over networks used for other data purposes. There
are tradeoffs, though.

Voice communications is much more time-sensitive than data communications.

Network delays that would be unnoticed by the typical data user become noticeable
and even intolerable when the user is trying to carry on a two-way conversation. Most
cellular and many other telephone systems today exhibit such delays and we all are
becoming increasingly familiar with how it affects normal conversation.

This isn’t an effect of VoIP, per se, but rather of digital networks being slowed due to
demand or disruptions. IP-based networks traditionally used for data will dynamically
adapt to such factors and are designed to trade speed for certainty of delivery. That is,
the network will try and try again to get a packet that has been lost or damaged so it
can package them reliably and deliver the complete lot at once.

Voice communications, on the other hand, can survive an occasional dropped

packet better than it can handle delays. Each packet contains a small piece of audio
information. The human brain is remarkably able to extract an intelligible message
from disrupted audio.

n VoIP in Public Safety Communications

Public use of VoIP telephone systems has brought all sorts of challenges to the public
safety world, particularly in delivery of 9-1-1 services. However, it has proven to be a
boon in other ways.

Transmission of voice and other audio over IP-based data networks has rapidly
become a critical, underlying means of connecting agencies for interoperability. VoIP
is used to interconnect private telephone systems, dispatcher consoles, and parts of
the radio infrastructure. For practical purposes, it is an underlying protocol rather
than an end-user application, though.
 Chapter 16: Voice Communications
2
For example, dispatch consoles have been connected for decades to remote base
stations through dedicated telephone circuits—typically analog ones much like plain
old telephone service (POTS—seriously). As telecommunications infrastructure has
moved to digital from analog, lines that tie one fixed point with another have also
migrated. VoIP is increasingly used in this case to move the dispatcher’s voice to the
radio transmitter and the user’s voice back from the receiver.

n A Fundamental Tool
VoIP is growing as a fundamental tool connecting pieces of public safety
voIP is a communications systems. Unfortunately, it has been subject to a lot of
fundamental tool, interoperability hype. While it may today and in the future be an underlying protocol
but not a silver for connecting systems at an audio level, it doesn’t solve the problems posed by any
bullet. gateway between disparate radio systems, as described further in the next section,
Approaches to Interoperability.

VoIP is the current, logical choice for connecting pieces of a system where
dedicated telephone circuits may have been used in the past. As any higher level
communications protocol, it relies on underlying network infrastructure to carry
data. VoIP offers the possibility of passing voice over networks used for other data
communications, but in the process naturally puts those packets in contention with
other traffic on the network.

Critical systems The state of the art in VoIP telephone systems is to use dedicated data networks—
need dedicated physical or virtual—to reduce that contention and assure acceptable service. Critical
network services. public safety systems need high-quality service, as well.60

n “Radio over IP”

The term “radio over IP” has been used to describe VoIP used in radio applications.
It’s a confusing term and one we advise against using. It’s the logical equivalent of “Air
over Esperanto.”

Without getting deep into theory,61 data being transmitted using Internet Protocol
can pass over many different physical mediums, both wired and wireless. Voice, as

60
Several years ago, the Public Safety Wireless Network Program released an assessment of VoIP for
public safety radio systems. See Software-Enabled Wireless Interoperability Assessment Report – Voice-
Over-Internet Protocol Technology, December 2001, http://www.safecomprogram.gov/SAFECOM/
library/technology/1171_softwareenabledwireless.htm.
61
The Open Systems Interconnection (OSI) model is fundamental in telecommunications
theory, having originated in 1977. It describes systems in terms of a layered stack and defines
interoperability between layers. Radio is a low, physical layer, while Internet Protocol is in
the middle. Voice as an application of a system would be at the top of the model. For further
information, see http://en.wikipedia.org/wiki/Open_Systems_Interconnect. htm.
2 Part III: Exploring the Technologies

an application, runs over IP and other protocols, then over one or more mediums en
route to one or more final destinations. “Radio over IP” is backwards.

In addition, modern radio systems use VoIP to move voice and other audio, such
as signaling tones, across their infrastructure. They don’t, however, use it over the
airwaves. Land mobile radio systems reassemble the voice packets and transmit them
over the air using the system’s fundamental operating mode—whether analog or
digital, as in P25. This is analogous to what a receiver does with digital music before it
sends it to its speakers in a classic stereo system.

VoIP is a fundamental tool in today’s telecommunications systems, but it’s not

a silver bullet.

Let’s move on to how these technologies are used in pursuit of interoperability.

Approaches to Interoperability
Communications interoperability has been hindered in the past due to the simple
lack of a common vocabulary for discussing the topic. SAFECOM’s Interoperability
Continuum has improved the situation greatly through practitioners’ definition of five
critical dimensions of interoperability. It also provides simple measures for assessing
relative stages of development. Of the five dimensions, technology in particular is
the subject of only one. Proportionally, this continuum effectively represents the fact
that the great majority of work in achieving interoperability is in the human aspects of
governance, procedures, training, and familiarity through frequent use.62

The Interoperability Continuum provides a simple, effective description of the

technology choices available to provide interagency voice communications. These
means of communications provide a convenient way of examining the range of
choices, sophistication, and completeness of voice radio technology. As in the
Interoperability Continuum, technology choices are listed below in order of increasing
capabilities.

Let’s take a look at these approaches individually.

62
SAFECOM’s Interoperability Continuum is included in this Guide as Appendix G.
 Chapter 16: Voice Communications
2
Technology Approach: Swap Radios
As noted in the SAFECOM description, agencies have swapped radios to enable
communications among themselves since the earliest days of public safety radio
usage. To this day, agencies exchange spare radios with key cooperators on incident
Swapping radios or scenes for the sake of interoperability. In some cases, they do so even though their
maintaining a cache respective systems are otherwise technologically compatible. For example, this may
of standby radios is occur because the users either don’t have common channels programmed into their
an age-old solution radios or they use different channel naming and naming conventions. Whether due to
that provides technological incompatibilities or a lack of prior planning, the end result is the same:
results but is often
A conclusion that this, the most basic means of interoperability, is necessary.
time-consuming,
management-
intensive, During incidents when agencies respond with incompatible equipment—using
expensive, and may different frequency bands, for example—swapping radios provides responders with
only provide limited the ability to talk to the other agency via that other agency’s system. Obviously, while
results due to this can and does work for very simple operations, it becomes unworkable as more
channel availability. and more agencies arrive.
—SAFECOm
Interoperability
A common use of this technique is in deployment of radio caches. A radio cache
Continuum
is simply a supply of radios, typically portables, held aside for larger incidents.
The cache may include spare batteries, antennas, and carrying cases to simplify
deployment. Typically, the cache is left stored away until a request is made for
its deployment.

The use of radio caches is, unfortunately, fraught with pitfalls. Common troubles
include the following:
• Unknown or nonexistent procedures for request and deployment
• Inadequate maintenance of the equipment, particularly batteries that can be
damaged from both too little and too much charging
• Poorly documented channel programming, leading to inadequate usage
• Lack of training on the equipment, its available channels, and their
appropriate use. ­

By far the majority of multiagency emergencies handled day-to-day in this country

arise and are handled much too rapidly for caches of radios to be deployed. On the
other hand, large-scale emergencies often call for the use of cached radios to allow
multiple responding agencies use of a single system.

Two examples of cached radio equipment are notable in this approach to

communications interoperability.
 2 Part III: Exploring the Technologies

n National Interagency Incident Communications Division

During the seemingly annual natural disasters that plague the American West, the
National Interagency Fire Center (NIFC) in Boise, Idaho provides logistical support
to federal, state, and local agencies. A prime resource is radio equipment from its
communications cache.

The nIICD radio

NIFC’s National Interagency Incident Communications Division (NIICD),63 operated
cache is jointly jointly by agencies of the U.S. Departments of Agriculture and the Interior, provides
maintained by the equipment in response to natural and manmade disasters of all sorts. Its cache was
U.S. Departments heavily tapped for equipment and trained ICS Communications Unit personnel in
of Agriculture and response to the Gulf Coast following Hurricanes Katrina and Rita.
the Interior.
NIICD cache equipment is used for standalone communications networks where
needed to support large-scale emergency response, typically involving many agencies.

n Beltway Sniper Incidents

During a 3-week period in October 2002 two men terrorized the Washington, D.C.,
montgomery area through seemingly random sniping incidents that left 10 people dead. Each of
County (mD) had the incidents brought local first responder agencies together, but more broadly, law
a supply of new, enforcement agencies from across the region and all levels of government convened in
unused radios that
pursuit of the attackers.
was pressed into
interagency service.
Montgomery County, Maryland was the location of the earliest and majority of the
attacks. By coincidence, the county happened to be in the middle of deploying a new
radio system for its public safety agencies. System infrastructure was largely in place
and end-user equipment was warehoused for pending installation.

When joint task force operations involving many law enforcement agencies ensued,
the new radio system was activated and the new radios distributed to provide
interagency communications. In effect, cached equipment was used to provide a
common communications environment, much as is done in the West during remote
wildfires. Outside agencies used their own communications capabilities as well as they
could considering varying coverage limitations, but the distribution of Montgomery
County radios to cooperating responders and investigators provided simple, but
much needed communications interoperability.

63
For more information on the NIICD, see http://www.fs.fed.us/fire/niicd/.
 Chapter 16: Voice Communications
29
Technology Approach: Gateways
Response to the Beltway sniper incidents involved another approach to
interoperability: Connecting different systems or channels through a gateway. In order
to provide communications between users of its old and new systems during the
Gateways (or unanticipated activation, Montgomery County linked channels together across the
audio bridges) two. The effect was to provide a common channel shared across each.
retransmit across
multiple frequency The term “gateway” is used for any of a number of means of patching transmitted
bands, providing and received audio from one source to another. Technically, it is a bit more complex,
an interim
requiring controlling circuitry to initiate transmission on one side of the equation
interoperability
solution as
when something is received on the other. Whether involving radio channels,
agencies move telephone calls, or another source of audio, channel patching is another age-old
toward shared approach to connecting users from one system to those on another.
systems. However,
gateways are In its earliest form and still practiced today, a dispatcher at a communications console
inefficient in that can literally patch the audio from one channel to another despite the fact that there
they require twice
might be huge technological differences between the individual systems. This is the
as much spectrum
because each same approach, technically speaking, that a dispatcher would use to patch a telephone
participating agency call to a radio channel and vice versa. The effect is that the two communications
must use at least channels are collapsed into one using bridges or gateways between different
one channel in each telecommunications systems.
band per common
talk path and they Modern technology has made it possible to do this not only in increasingly complex
are tailored for
ways from the dispatch console, but also via remotely operated gateways. The simplest
communications
within the gateway devices are no larger than a pack of cigarettes, limited in size physically more
geographic by the space needed for connecting cables than by the complexity of their internal
coverage area electronics. This sort of portability allows for devices that can be fielded to patch
common to all together first responder channels. Though most commonly used to bridge radio
participating channels in different frequency bands, many of the devices can also be used to link
systems. “push-to-talk” radios64 to other two-way audio sources, such as landline, cellular, and
—SAFECOm satellite telephones.
Interoperability
Continuum
Increasingly sophisticated networking technology allows gateways to be connected
between dispatch consoles and other audio sources across data networks. Audio is
digitized, addressed, and routed across networks just like any other form of data.

Gateways patch
transmitted and
received audio
64
“Push-to-talk” radios are the standard type of radios used by public safety agencies. Whether
from one source to portable, mobile, or installed at a fixed location, they’re distinguished from other forms of radios
another. by the fact that some sort of switch is manually or electronically actuated to initiate transmissions
from the radio. The term “push-to-talk” has been used to distinguish the familiar two-way radio from
other types of portable communications devices, such as cellular telephones.
 20 Part III: Exploring the Technologies

voIP is being used As mentioned previously, Voice over Internet Protocol (VoIP) can be used for
to connect systems moving audio across data networks between radio systems. Those networks can
across data
even connect a gateway on one radio system to another that is geographically
networks using
gateways.
distant, providing radio end-users at either location with a means to talk to each
other. This isn’t 21st century James Bond wizardry, though. Amateur radio operators
have been using the technology since the late 1990s and now have a worldwide
network of more than a thousand Internet-connected radio nodes serving every
continent, including Antarctica.

Whether as simple as a dispatcher’s console patch or as complex as a worldwide

VoIP network, gateways are widely used to connect distant and disparate channels of
communications. While commonly used, this approach to interoperability has serious
limitations and brings challenges of its own.

n Gateway Issue: Capacity

By design, gateway devices linking together multiple channels of communications—
radio or otherwise—end up repeating traffic from one channel to others. This reduces
the original load-bearing capacity of each.

When two actively used channels are linked, the amount of traffic on each will
increase significantly. Popular gateway devices allow many more than two channels
to be linked, potentially multiplying the amount of traffic on each by the number of
connected channels.

Obviously, any moderately used channel can be heavily taxed by patching together
other, similarly used channels. This can result in serious contention for access to the
channels, not to mention an increased level of traffic that may not be relevant to the
original channel users.

Separate channels of communications are necessary during emergency response

in order to segment responsibilities and account for the limited capacity of
any individual channel. Indiscriminately used, gateway devices can disable the
channels they interconnect by overwhelming them, literally or practically, with
too much traffic.

n Gateway Issue: Coverage

It might not be intuitively obvious, but gateways can only link first responders at an
incident scene in areas of overlapping coverage between the linked systems. In other
words, once outside the range of one’s home system, the system user doesn’t benefit
by the gateway. The gateway doesn’t extend the geographic range of the individual
systems that are interconnected.
 Chapter 16: Voice Communications
21

TMI: HOW MUCH DO YOU WANT TO

COMMUNICATE?
In the wide world of communications, the term “signal-to-noise ratio” is used in talking
about the eventual intelligibility of exchanges. The principle is that a signal has to
be significantly stronger than any background noise for effective communications to
occur. Anyone who has ever observed the volume level of conversation rise at a party
as attendees increasingly struggle to be heard over one another has witnessed how the
signal (conversation) can be lost amid background noise.

Back in the field, first responders often struggle to catch transmissions relevant to their
jobs during incidents as radio transmissions multiply many times over. The challenge of
too much information, of the signal being lost among “noise,” is equally as disabling as
not getting enough information.

Conversely, and somewhat perversely, linked systems can lead to too much, yet
inadequate, coverage. For example, linking together Systems A, B, and C depicted
in Figure 16-10 means that users of System C will be heard across the range of all
systems, but still can’t talk to any other system user when traveling outside of the
range of their own. This can and does lead to systems interfering with others beyond
their normal coverage areas. More critically, it also leads to communications failures
in areas where responders were previously heard, but can’t talk from once they get
there.

Radio coverage is a complex issue under the best of

Gateways can circumstances. It becomes even more so when multiple System System
easily lead to systems are linked together. Coverage becomes A B
asymmetrical radio asymmetrical. That is, radio users can be heard in
coverage. places where they can’t talk from. Again referring System
to Figure 16-10, System A users can talk to users of C
both Systems B and C—as long as they are within the
coverage footprint of System A. Once outside of it,
they can’t speak to anyone through the gateway even
Area of Overlapping
though they are in the range of the other, linked systems. Coverage

Figure 16-10: Overlapping

Coverage of Systems
 22 Part III: Exploring the Technologies

n Gateway Issue: Transmitter Licensing

If the above technical complexities of gateways aren’t daunting enough, their legal
operation poses additional challenges. Unfortunately, a proliferation of gateway
devices in recent years has led to some being used in operations outside the authority
granted by the FCC for the respective interconnected systems. This is a rather obtuse
and occasionally confusing subject, but we’ll try our best to explain it here and
provide reference to other sources.

Basically, FCC licenses are required for practically all radio transmitters used in
public safety communications systems. Each portable, mobile, and fixed station
most transmitters radio is covered under a license that specifies, among other things, an area of
are licensed for
operation—the area in which the radio can transmit. Most classes of fixed stations,
a limited area of
operations. such as base stations and repeaters, are licensed for a particular physical location,
height above ground, and maximum power. Typically, end-user radios are licensed
for operations only across the agency’s jurisdiction or within a given distance from a
fixed point.

Mutual aid and other types of interagency operations are often conducted outside
of one or another agency’s jurisdiction—by definition. While the visiting agency’s
radio system may provide incidental coverage outside its jurisdiction, it is illegal for
end users to use any system outside of its licensed area of operation. This is done to
protect other legitimate use of the licensed radio frequencies and to allow reuse of
spectrum elsewhere.
rely on FCC- When gateways are used to interconnect systems, the potential arises for radios to be
certified frequency
coordinators
operated outside their licensed area of operation. In addition, a portable or mobile
for guidance on radio connected to a gateway becomes a different class of radio station. In essence,
gateway licensing. it’s no longer legally an end-user radio, but rather a type of fixed station. While the
FCC can grant “Special Temporary Authority”65 under emergency circumstances to
operate an unlicensed transmitter, nothing beats preplanning and licensing.

The FCC-certified public safety frequency coordinators66 are the best source
of guidance in navigating the complexities of licensing transmitters used to
interconnect radio systems through gateways.

65
The FCC maintains a web page describing the procedure for obtaining Special Temporary
Authority for a station. See http://wireless.fcc.gov/publicsafety/sta.html.
66
For more information on FCC-certified frequency coordinators, see
http://wireless.fcc.gov/publicsafety/coord.html.
 Chapter 16: Voice Communications
23

FCC rules and regulations governing public safety radio systems (Part 90 – Private
Land Mobile Radio Services) provide latitude for alternate use of licensed radio stations
during emergencies that have disrupted communications facilities.

fcc rules and regulations

47 c.f.r. §90.407 Emergency communications
The licensee of any station authorized under this part may, during a period of
emergency in which the normal communication facilities are disrupted as a
result of hurricane, flood, earthquake or similar disaster, utilize such station
for emergency communications in a manner other than that specified in the
station authorization or in the rules and regulations governing the operation
of such stations. The Commission may at any time order the discontinuance
of such special use of the authorized facilities.

n Gateway Issue: The “Ping Pong” Effect and Other

Complexities
Despite the relative simplicity with which gateways can be deployed to connect
responders, they can have a negative impact on systems they interconnect. The
National Institute of Justice (NIJ) CommTech Program67 has worked for several years
testing gateway devices and sharing lessons they have learned. Much of what we know
about their use in the public safety environment comes from NIJ testing.

One technical complexity that has been described is referred to as the “ping pong”
effect. It occurs when a gateway is used to connect users through two or more
repeaters—fixed radio stations that receive transmissions from portable, mobile, or
other fixed stations and repeat them for other radio users to hear more widely and
clearly. Without careful tuning, gateways connecting repeaters can endlessly cause the
other to transmit.

Similarly, multiple gateways on the scene of an incident or inappropriately configured

ones can actually dis-able, rather than enable interagency communications. This can
happen when uncoordinated use of multiple gateways leads to systems talking in an
endless loop.

67
CommTech was previously the Advanced Generation of Interoperability for Law Enforcement
(AGILE) Program. Further information about the program can be found on its web site. See
http://www.ojp.usdoj.gov/nij/topics/commtech/.
 2 Part III: Exploring the Technologies

DUELING RADIOS
“By far the most challenging technical aspect of the deployment of the
[gateway] was in interfacing with the repeater systems of the participating
agencies. In systems in which a radio interfaced to the [gateway] is
transmitting to a receiver site through a repeater, due to the length of
the squelch tail, a repeater could stay up long enough to bring the radio
connected to the [gateway] back up before the repeater goes down. Then
because the radio is back up, the repeater could come back up, bringing the
radio back up; and so on. This effect is referred to as the ‘ping pong’ effect.”

Advanced Generation of Interoperability for Law Enforcement (AGILE)

Report No. TE-00-04, 23 July 2001
http://www.ojp.usdoj.gov/nij/topics/commtech/Gateway_Subsystem_Op_Test.pdf

Despite the issues described here, gateways play an important part in many
interagency communications systems today. They offer the portability and flexibility
necessary to link various radio systems, frequency bands, and protocols existing
across public safety agencies. Well used, they provide an important technological
approach to interoperability.
Interoperability is
promoted when
agencies share a Technology Approach: Shared Channels
common frequency Historically, the most common means of interagency communications by radio has
band and are
been through the use of shared or common channels. As noted in the Interoperability
able to agree on
common channels.
Continuum excerpt, users of the same frequency band have the added option to
However, the share channels for interoperability. These channels may be for direct or unit-to-unit
general frequency conversations within a limited range on scene or through repeaters programmed into
congestion that their respective radios for greater range.
exists across the
United States Although fragmented radio spectrum use reduces the potential, shared channels
typically places
provide a low-cost and effective means of interagency communications in locales
severe restrictions
on the number
where users have the benefit of a common frequency band between their agencies.
of independent Commonly shared or formally designated interoperability channels now exist
interoperability across all major public safety bands. In some jurisdictions, gateways are used to link
talk paths that are designated shared channels between different bands, combining the use of multiple
possible. approaches to interoperability at the cost of duplicating transmissions across
—SAFECOm multiple channels.
Interoperability
Continuum
 Chapter 16: Voice Communications
2

PALMETTO 800 SYSTEM GATEWAY

GUIDELINES
The state of South Carolina maintains guidelines for using gateways to interconnect
other systems and users to the Palmetto 800 System. The purpose, objectives, and
benefits of the guidelines are clearly stated:

Purpose: To maintain the availability and functionally of the Palmetto

800 System for the primary system users.

Objectives:
a) Ensure the integrity of the Palmetto 800 System
b) Provide interoperability options
c) Manage system loading
d) Establish a guideline for the use of interconnects.

Benefits:
a) Improve safety
b) Reduce interference and interconnect technical problems
c) Provide alternate 800 MHz service for special events and
emergencies.

For more information, see: http://www.cio.sc.gov/cioContent.asp?pageID=772

Putting Shared
Channels to Work
Use your radio FCC Designation of Shared Channels
technical resources In addition to any specific frequency (or pair of frequencies for a repeater) adopted
and frequency by convention by agencies for shared use, FCC rules and regulations designate specific
coordinators to frequencies for interagency communications. The number and availability of these
learn if there are frequencies vary considerably by band, as well as location.
FCC-designated
shared channels
available for use.
Five VHF-high band (150 to 174 MHz) frequencies, ten UHF (450 to 470 MHz)
There may be frequency pairs, and five 800 MHz frequency pairs have been designated for more
existing shared than a decade for interagency use. However, the VHF and UHF frequencies have been
channel plans incorporated into interagency communications plans differently across the country,
that you can and often not at all. In many cases, the frequencies have been assigned for specific
take advantage agency use. The 800 MHz pairs were designated solely for interagency use and provide
of, but know
key shared channels capability where this band68 is well used.
the limitations
and licensing
requirements 68
The FCC created the National Public Safety Planning Advisory Committee (NPSPAC) in the
before putting them 1980s to guide rules for a segment of the 800 MHz band dedicated to public safety use. This
to use. spectrum is commonly referred to as the “NPSPAC band” or “800 MHz NPSPAC.”
 2 Part III: Exploring the Technologies

FCC narrowbanding rules and regulations split out additional channels from the
traditional, 25 kHz ones, though they won’t be wholly available until operations on
adjacent channels migrate to narrowband. In 2000, the FCC designated five additional
VHF frequencies and four UHF frequency pairs for interoperability use. These are
Regional shared
narrowband (12.5 kHz) channels. Since January 1, 2005 their use under FCC rules for
systems are the interagency communications has taken precedence over other licensed uses.
optimal solution
to interoperability. Many more channels specifically designated for interagency use are available in the
While proprietary 700 MHz band for regions of the country where this spectrum is clear of television
systems limit broadcasters. As public safety systems are built in this frequency band, agencies will
the user’s choice
have access to more than 100 shared channels whose use is governed by state-level
of product and
manufacturer,
decision making bodies.69
standards-
based shared Technology Approach: Shared Systems
systems promote The growing complexity and cost of radio systems have combined with serious
competitive
needs for improved interoperability to push public safety agencies toward sharing of
procurement and
a wide selection systems. Whether built of proprietary technology or based on accepted standards,
of products to shared radio systems offer economies of scale, less redundancy, and inherent
meet specific user interoperability of the chosen technologies. While sharing a radio system doesn’t
needs. With proper alone provide agencies with communications interoperability, it does provide core
planning of the talk parts of the technical foundation.
group architecture,
interoperability
is provided as
Radio systems have been shared as long as public safety has been using the
a byproduct of technology. In relatively recent history, however, technical innovation has followed
system design, their need to manage rising costs, crowded radio spectrum, and difficulties
creating an communicating with other agencies migrating to other frequency bands and
optimal technology technology. System sharing has come as a natural solution to each of these needs.
solution.
—SAFECOm n Proprietary Shared Systems
Interoperability
Trunking, as previously discussed, has been adopted as the primary means of
Continuum
sharing limited radio channels while still providing individual users with privacy and
autonomy. The earliest trunked radio systems were built of proprietary technology,
limiting the choice of system components and generally increasing costs through
reduced competition and vendor lock-in. Many such systems are still in use today,
both in single agency and shared use.

69
The FCC maintains a web page explaining use of 700 MHz interoperability spectrum in greater
detail. See http://wireless.fcc.gov/publicsafety/700MHz/interop.html.
 Chapter 16: Voice Communications
2
Proprietary or not, shared systems provide the technological compatibility necessary
Shared systems
offer economies
for interoperability between their users.
of scale, less
redundancy, n Standards-Based Shared Systems
and inherent The simplest shared system is where one or more channels is used conventionally
technological (i.e., not trunked), either analog or P25 digital, between agencies. There is no
compatibility.
proprietary aspect of such an approach and radios from various manufacturers
can be mixed and matched to create the system. While channel efficiency of
conventional systems can’t approach that of trunked ones, they are a cost-effective
option and provide opportunities for sharing of system infrastructure and
backbone networks. Individual channels can be dedicated by agency with others
shared for interagency communications.
P25 is the public
safety standard for
digital radio. Because channel demand has overwhelmed available public safety spectrum, trunked
systems provide the only alternative for shared systems in many areas of the country.
As mentioned, trunking provides the means for many virtual channels, used privately
between defined users, from a relatively few radio frequencies. This allows multiple
agencies to come together on a shared system, use common channels (talkgroups),
and still have private channels.

As public safety radio use migrated toward digital and trunked radio systems, the
community saw a need—and an opportunity—to escape proprietary systems by
setting future standards. Project 25 began in 1989 as a joint effort of the Association
of Public-Safety Communications Officials – International (APCO) and the National
Association of State Telecommunications Directors (NASTD) to ensure that public
safety agencies would have an open, standards-based alternative for digital radio
systems. Today, P25 provides that standard and is being extended to eliminate the
lock-in that proprietary trunked systems face.

DEPARTMENT OF HOMELAND SECURITY

TECHNICAL ASSISTANCE
The U.S. Department of Homeland Security offers help to recipients of its grants
to improve interagency communications. As part of the Preparedness Directorate’s
Office of Grants and Training, the Interoperable Communications Technical Assistance
Program (ICTAP) provides policy, operational, and technical help to projects funded
under DHS programs.
See http://www.ojp.usdoj.gov/odp/ta_ictap.htm
 2 Part III: Exploring the Technologies

Security
The security of public infrastructure, including information and communications
systems, is of critical importance today. Security covers a much broader expanse than
can be covered here, but we want to note issues that an interagency communications
project manager may face. Particularly, there is a delicate balance between security
and availability, which affects interoperability.

Traditional information technology (IT) systems have long been guided by formal,
All radio system well-defined security practices. Radio system managers increasingly face the same
managers should
threats as their traditional IT counterparts. For example, denial of service attacks can
follow established
IT security affect and spread to all IP-based systems. The very flexibility that drives greater use of
practices. VoIP also increases vulnerabilities. All radio system managers seeking to secure their
systems should follow established IT security practices.

The National Institute of Standards and Technology (NIST) within the U.S.
Department of Commerce has published a series of documents on generally accepted
security principles and practices,70 recommended controls for securing federal IT
systems,71 and further principles addressing the subject from a systems perspective.72
These documents describe the means of building a suitable foundation for secure
voice radio systems.
SEArCH received
funding from
the COPS Office
NIST addresses security throughout phases of the system lifecycle:
to produce a 1. Project initiation.
companion
2. Development and acquisition.
Tech Guide, Law
Enforcement 3. Implementation.
Tech Guide on 4. Operations and maintenance.
Information
Technology 5. Disposition of systems.
Security: How to
Assess Risk and
Establish Effective
Policies. This 70
Swanson, Marianne, and Barbara Guttman, Generally Accepted Principles and Practices for Security
guide provides
Information Technology Systems (Washington, D.C.: U.S. Department of Commerce, National
more information
Institute of Standards and Technology, September 1996). See
on nIST security
http://csrc.nist.gov/publications/nistpubs/800-14/800-14.pdf.
processes.
71
Ross, Ron, et al., Recommended Security Controls for Federal Information Systems, NIST SP
800-53 (Washington, D.C.: U.S. Department of Commerce, National Institute of Standards and
Technology, February 2005, including updates to June 17, 2005). See
http://csrc.nist.gov/publications/nistpubs/800-53/SP800-53.pdf.
72
Stoneburner, Gary, Clark Hayden, and Alexis Feringa, Engineering Principles for Information
Technology Security (A Baseline for Achieving Security), NIST SP 800-27 (Washington, D.C.: U.S.
Department of Commerce, National Institute of Standards and Technology, June 2001). See
http://csrc.nist.gov/publications/nistpubs/800-27/sp800-27.pdf.
 Chapter 16: Voice Communications
29
nIST points out The first four of these five phases of a system lifecycle should be familiar to the reader
that security is built from Part II of this book. NIST principles point out that technology security isn’t
into systems from added onto systems, but rather built into them from the foundation up.
the ground up.

Advanced Radio Features for Physical Security

When most people think of radio systems security, they think of physically securing
the infrastructure and logically securing the information that passes over the network.
Conventional radio systems over the years have been plagued by the ease with which
someone with malicious intent can disrupt communications by transmitting on the
system. Lost and stolen radios are the biggest risk, but more than one system has been
disrupted when a responder’s young child wanted “to be like mommy or daddy” and
spirited off a radio to the closet to talk.

Trunked radio systems control access to channels centrally, so offer an inherent ability
to reject rogue radios with just a little effort on the system administrator’s part. Better
yet, modern radio systems, both conventional and trunked, offer the ability to disable
modern radio the lost, stolen, or otherwise misappropriated radio remotely. That prevents the radio
systems allow from requesting system access—or even transmitting at all!
radios to be
disabled remotely.
While physical security is understandable as a fundamental to securing all systems,
securing the information the system is built to transport is another matter.

Encryption and Key Management

It’s nearly impossible with current public safety technologies to prevent radio signals
Confidentiality,
from being captured over the air. Military spread-spectrum techniques, where a signal
integrity, and
availability are the is distributed across a wide swath of frequencies and thus made largely undetectable,
three objectives haven’t found their way to public safety voice systems. It’s worthy to note that this
of information technique is used with some cellular and wireless data systems, though.
security.
Encryption is the traditional means of securing voice radio communications since they
are so easily intercepted. The three objectives of information security—confidentiality,
integrity, and availability—are served to different degrees by encryption.
• Confidentiality of the information is expected as long as the encryption system
is uncompromised and the keys for unlocking its secrets are secured. ­
• Integrity of the information is the assurance that what was received is what was
sent by the original sender. Encryption provides this, to a degree, simply by
locking up the data, but other parts of the system contribute to its integrity by
limiting access to the system to authorized users. ­
• Availability is a particularly difficult feature to secure in the radio environment
because channel access can be denied simply by the presence of a rogue
transmitter spewing RF noise across the frequencies in use (denial of service). ­
20 Part III: Exploring the Technologies

The great majority of public safety voice communications don’t require great
confidentiality. From an interoperability perspective, encryption brings additional
challenges. Not only do all users that are expected to talk together on secure channels
have to use the same encryption means and methods, but they must have current
keys to lock and unlock transmissions. In effect, encryption adds technological
junction points where interagency communications can be fractured. For example,
most gateway approaches, such as console patches and other common audio bridges,
require special care when moving traffic from one secure channel to another. There
is the risk of originally encrypted traffic on one channel being decrypted at a gateway
and broadcast unexpectedly on another channel unencrypted. Alternately, the
encrypted traffic may be moved through a gateway to users of other channels who are
unable to decrypt and use it, resulting in added noise and confusion for those users.
Encrypted
interagency Despite these difficulties, the confidentiality and integrity of certain voice
communications communications is of high value—high enough that availability risks are
require greater acceptable. Where needed, encrypted communications between multiple agencies
efforts to ensure require additional attention to technical compatibilities and their maintenance, to
interoperability. ensure interoperability.

n The Digital Future of Encryption

Encryption of analog radio communications has a checkered past. Users have long
been dissatisfied with the reduced range of encrypted communications and the lack
of techniques to deal with a harsh RF environment that confuses the encryption
systems. Analog encryption has been a necessary evil in most cases.
Digital
communications
naturally support Digital radios bring a new day, though. The digital radio signal is, by nature,
encryption. encoded, which reduces casual reception by common FM scanning receivers. As
digital scanners become more prevalent, there’s another arrow in the public safety
radio quiver: The digital signal can be encrypted without effect on the system’s basic
functionality. That is, the transmitters, receivers, and radio environment keep on
moving digital bits, not knowing whether they’re scrambled one way or another.

n Key Management
The big trick in dealing with encryption is managing the keys. Since encryption
creates virtual private networks within the radio system, access to the keys allows
users to be part of the network. There may be multiple sets of keys for different sets
of users to limit access to only those with a predefined need for the “private” channel.

Like any other encryption system, those for radio are only as strong as their weakest
link. That’s usually the keys. Many an encryption system has been compromised
because the secret decoder ring was stolen. Thankfully, this isn’t a frequent occurrence
with public safety radio systems, but all it takes is one radio to be lost or stolen for all
others sharing the same keys to need re-keying.
 Chapter 16: Voice Communications
21
First responder mobility challenges key management. If all users of an
encrypted channel were in the same room, it would be easy to keep the keys up-
OTAR is over-the­
to-date, switching them out as necessary to maintain security. Unfortunately
air re-keying, or
updating encryption
for the radio system manager, users are rarely so easily contained. The need
keys wirelessly. for “over-the-air re-keying” (OTAR) becomes apparent if you consider just the
logistical challenge of maintaining encryption keys for potentially thousands
of users on a large, modern radio system. OTAR is simply the process of
encryption keys being passed from the system control point to affected radios,
and then activated simultaneously.

OTAR makes it possible to load keys on the fly wherever the radios are, and then
switch to the new set when they are all prepared.

Technology provides the means of key management in a shared radio system.

Encryption is The more difficult part is managing the people environment to gain concurrence
managed as a about what will be encrypted, how the process and keys will be managed, and
piece of the larger procedures for use of encrypted channels so users don’t become stranded on
interoperability yet another desert island lacking interagency communications. This aspect
project.
of the technology is managed as a piece of the larger puzzle that is addressed
throughout this book.

n Reports Available from SAFECOM

The Public Safety Wireless Network (PSWN) Program produced two reports on
encryption key management. These reports are available from the SAFECOM
library. The first is an introductory text explaining basic encryption concepts.73
The second provides a key management plan template.74

73
Introduction to Encryption Key Management for Public Safety Radio Systems, Public Safety Wireless
Network Program, October 2001. See http://www.safecomprogram.gov/SAFECOM/library/
security/1113_securityissues.htm.
74
Key Management Plan Template for Public Safety Land Mobile Radio Systems, Public Safety Wireless
Network Program, February 2002. See http://www.safecomprogram.gov/SAFECOM/library/
security/1114_keymanagement.htm.
22 Part III: Exploring the Technologies

ON THE HORIzON – VOICE

COMMUNICATIONS TECHNOLOGY
The most promising technology on the horizon for improving interoperability is
software defined radios (SDR). Much like other electronics throughout the
technology universe, radios are increasingly designed with internal functionality
provided through software.

Thirty years ago, public safety radios were limited to just a few frequencies spread over
a narrow slice of RF spectrum. Twenty years ago, early “programmable” radios were in
use that allowed frequencies available in the radio to be changed electronically, rather
than by substituting internal hardware. These radios also allowed use of a greater range
of frequencies.

During the past 20 years, more and more radio functionality has been moved from
hardware to software. Software defined radios are the next evolution that will allow even
greater agility not only across bands, but also with varying channel bandwidths and
across different modes of transmission. For example, the U.S. Department of Defense
is developing the Joint Tactical Radio System that will operate across multiple bands,
use various analog and digital transmission modes, and provide a combined platform to
eliminate a plethora of different systems.

For public safety interoperability, the technology promises greater ability to span the
chasm between different frequency bands in use. Today, radios using VHF aren’t able
to communicate with those using 800 MHz. In the future, this fundamental technical
challenge to interoperability will be overcome.

Similarly, different means of getting information through radio channels will become
more flexible. Narrow and wider bandwidths will be accommodated through software, as
will analog and a variety of digital transmission modes.

Today, Project 25 radios provide analog and digital, narrow and wider band capabilities
largely through software. SDR technologies will gradually be integrated into mainstream
public safety radios, eliminating some of the technological barriers preventing direct
interagency communications.

Much like artificial intelligence in computer systems, SDR techniques will be embedded
in technology and largely unobserved by the end user. The effects will be significant,
however.

Technology marches on, bringing new capabilities and overcoming the old.
 CHAPTEr 17
DATA COmmUnICATIOnS
 Chapter 1:
Data Communications
Voice communications over radio is accepted as the central interoperability
challenge, but it’s increasingly difficult to separate voice from data and
wired from wireless networks. Data networks tie together public safety
communications systems from beginning to end. From the automatic number
identification/automatic location identification (ANI/ALI) data arriving
SAFECOM
with an initial 9-1-1 call for services through the responder’s final status code
Technology Library
The SAFECOm transmission from a mobile data computer, data systems connect responders
technology library to the public they serve and beyond. Even at the core of modern radio systems,
is a prime source wired and wireless data networks connect dispatch consoles to central
for information electronics banks, link complex subsystems in the radio room, and carry audio
about data widely between distant transmitters.
communications
systems. It includes
Since the World Wide Web surfaced from the primordial Internet barely more
documents from
multiple sources, than a decade ago, data networks have come to pervade our homes, our offices,
including the past and even our automobiles. In this chapter, we look first at the protocols and
Public Safety standards that fueled this explosive growth and then into the technologies
Wireless network of both wired and wireless data networks. We’ll wrap up the chapter with an
(PSWn) Program. examination of how data networks are secured and close with a look at data
See http://www. communications developments on the horizon.
safecomprogram.
gov/SAFECOM/
library/technology/. Common Protocols and Standards
Common protocols and standards are the building blocks for interoperability,
technologically or otherwise. At technical and social levels, alike, the Internet has
influenced the world of information sharing greatly, from civic and commercial
realms, to government. Just as the World Wide Web evolved as the model of
information sharing globally, the common protocols on which it was built have
Common protocols become the foundation for nearly all data communications.
and standards are
the building blocks
of interoperability. The Internetworking Effect
What suite of protocols powers the Internet and every private network that has
arisen from it?

If the following section title didn’t give it away, you might be surprised to know it’s
the Transmission Control Protocol/Internet Protocol best known as TCP/IP. Lest the
term “suite” strike you as pretty fancy for just two protocols, understand that TCP/
IP is commonly used to refer to dozens of protocols that lace the Internet together.
2 Part III: Exploring the Technologies

The Internet has become so ubiquitous and part of our daily lives that we may forget
at times that it’s a minor miracle that we can transfer a wide assortment of data
around the world with little worry about how it happens. Electronic mail, files, video,
music, and now voice telephony speed from point to point across increasingly faster
and faster networks upon an amazingly standardized set of protocols.

Internationally, a body known as the Internet Engineering Task Force (IETF)75 is

central to the definition and formalization of these protocols. It’s beyond the scope
of this Guide to get very deep into the protocols, but we do want to note that they are
many, varied, and built upon one another. The most basic, hidden services of wired
and wireless networks connect physical components together in standardized ways,
while increasingly complex protocols are built upon them to deliver information in a
humanly digestible form.

n At the Heart: TCP/IP and Friends

TCP/IP, its companions, and associated other protocols occupy the middle ground
of a stack of open, standardized means of interconnecting information sources.
The very term “Internet Protocol” describes the original purpose for the protocol:
Connecting different networks.

Other key Internet protocols that have found their way into the heart of public safety
communications include the following:
• File Transfer Protocol (FTP) – A venerable graybeard of the earliest days of
internetworking and today underlying data transfer between many criminal
records and other information sharing systems.
• Simple Mail Transfer Protocol (SMTP) and Post Office Protocol Version
3 (POP3) – Key pieces of today’s e-mail, as well as automated fingerprint
identification systems.
• User Datagram Protocol (UDP) – TCP’s alter ego and the foundation for
Voice over IP (VoIP) networking, including systems for interconnecting radios
over data networks.
• Session Initiation Protocol (SIP) and Real-time Transport Protocol
(RTP) – Doing yeoman’s work for networking services as varied as peer-to-peer
music sharing systems and VoIP telephony, beyond to the instant messaging
capabilities of the Capital Wireless Integrated Network (CapWIN) around
Washington, D.C.

75
The IETF is an international community of industry, academia, and government. See
http://www.ietf.org/.
 Chapter 17: Data Communications
2
• Lightweight Directory Access Protocol (LDAP) – Serving at the core of
NASA’s Integrated Services Environment just as it serves user authentication
information to encryption engines securing Kansas’ innovative Criminal Justice
Information System.
• Simple Network Management Protocol (SNMP) – Giving technical staff a
view into the core of the Internet, as well as the supervisory control and data
acquisition systems of modern trunked radio systems.

These and many more standardized protocols have brought about a Golden Age for
data sharing at a technical level, whether those data packets are carrying criminal
history records, voice dispatch communications, or fingerprint images. As much as
they contribute, these networking protocols alone don’t make the data intelligible,
though. It takes higher level application protocols and standards to transform data
into information.

XML—Universal Language of the Internet

Broad adoption of Internet protocols has supported growth of a key tool for
interoperable data communications: the Extensible Markup Language (XML). A
project manager dealing with interagency data communications today will have a
hard time avoiding XML. It is the universal language of data communications today,
particularly for data that cross system and jurisdictional boundaries.

XML actually had its origin before widespread use of the Internet in something called
Standardized General Markup Language (SGML). A markup language is basically
simple, textual conventions for describing associated data and providing further
details on how the data are used. SGML is actually an international standard; XML is
a simplified subset of it.

XML’s magic is in its extensibility—its innate capacity to describe and extend itself
for wrapping data into ever more useful packages. It is structured text, making it both
human and computer readable, but XML can wrap up and describe data of all types.
Software capable of processing XML documents—packages of XML text and data
payloads—are able to “learn” of the structure of the document, including associated
nontextual data.

Applications that consume XML-based data can be structured to be very rigid

or flexible in understanding the data. That is, the software can restrict itself to
consuming only highly structured information or maintaining flexibility to learn
how to deal with data in different forms. Not all systems can or should be so willing
 2 Part III: Exploring the Technologies

to adapt to changing data forms, particularly in high-security and mission-critical

environments, but XML provides the means for software to extend its understanding
of the data it processes as designers see fit.

n XML in the Justice System

As with consumer, business, and government systems worldwide in recent years,
public safety information systems in the United States have become more open
through the application of XML. Work by individuals and organizations involved
with the justice system nationwide contributed a key, anchor tenant to the
information sharing bazaar—the Global Justice XML Data Model, or GJXDM. (Don’t
even try to pronounce it; you’ll be in lip splints for weeks.)

There’s no shortage The U.S. Department of Justice (DOJ) Office of Justice Programs (OJP) released the
of acronyms in the GJXDM in early 2004 as the first comprehensive product to wrap together a data
world of Internet dictionary, a data model, and an XML schema.
protocols—even
ones with others A data dictionary is a set of standardized descriptions of data to provide a common
embedded!
definition and means of describing, for example, a person’s name. A data model
expands on a data dictionary by establishing how different data elements relate to
each other. For example, a person has a birth date, height, and weight, while a vehicle
has a make, model, and style. An XML schema defines how data elements make up
documents and how documents are related to each other. Remember that in the
worldwide web of information protocols and standards, XML documents can range
from very simple to very complex sets of information.

GJXDM provides its own rich set of definitions that can be used outside the justice
world. It and the use of XML, more broadly, are becoming requirements for
public safety information systems funded with federal dollars in order to ensure
interoperability between systems. In fact, the COPS Office now encourages police
agencies engaged in technology projects to use XML whenever possible. For example,
the Baltimore City Police Department was encouraged to use the GJXDM while
working on a regional crime analysis project funded by a COPS Office grant. The
department committed to incorporating GJXDM-compatible functionality into the
regional database used in its Regional Crime Analysis Program and Regional Crime
Analysis Geographic Information System. In doing so, the department has greatly
enhanced the ability of police agencies participating in the Regional Crime Analysis
System organization to share information about crimes and offenders.76

76
Source: Baltimore City Police Department Progress Report, December 2005, submitted to the
COPS Office.
 Chapter 17: Data Communications
29

The Global JXDM is an XML standard designed specifically for criminal

justice information exchanges, providing law enforcement, public safety
agencies, prosecutors, public defenders, and the judicial branch with a tool
to effectively share data and information in a timely manner. The Global
Implementing JXDM removes the burden from agencies to independently create exchange
Interoperable standards, and because of its extensibility, there is more flexibility to deal
Systems using
with unique agency requirements and changes. Through the use of a
GjxDM
common vocabulary that is understood system to system, Global JXDM
The standard
reference for enables access from multiple sources and reuse in multiple applications.
implementing —U.S. DOJ OJP web site, http://www.it.ojp.gov/gjxdm.
GJxDm was
produced by
SEArCH for the
Office of Justice The COPS Office also funded SEARCH to convene a series of workshops and
Programs, develop GJXDM Information Exchange Packages (IEP) for Law Enforcement.77 The
Bureau of Justice
publication of law enforcement IEPs provided, for the first time, tangible models and
Assistance.
Building Exchange
GJXDM content that could be used by law enforcement agencies, whether large or
Content Using small, urban or rural, federal, tribal, state, county or local, to begin on the path of
the Global Justice data interoperability to support information sharing about crimes and offenders.78
XML Data Model:
A User Guide for GJXDM—and all the information-sharing capabilities it has spawned—contribute
Practitioners and greatly to interoperability for data communications. It can be a complicated subject,
Developers was
so for our purposes we’ll leave the topic here and move on to how it and other uses of
published in June
2005. XML are advancing emergency response.
See http://it.ojp.
gov/documents/
GjxDMUserGuide.
pdf.

77
The workshop report is available online at http://www.search.org/files/pdf/gjxdm-iep.pdf.
Documentation reports, such as Field Interview Report, Charging Document, Sentence Order, and
Incident Report, are freely available from SEARCH at http://www.search.org/programs/info/
xml-iep.asp.
78
Elsewhere in federal grant programs, recipients of grants from the U.S. DOJ’s Office of Justice
Programs that are implementing XML are required to use GJXDM. See http://it.ojp.gov/topic.
jsp?topic_id=138. Also, Fiscal Year 2005 grant guidelines from the Department of Homeland
Security (DHS) required use of GJXDM specifications and guidelines regarding use of XML
to support intersystem exchanges of information. “Fiscal Year 2005 Homeland Security Grant
Program – Program Guidelines and Application Kit.” See http://www.ojp.usdoj.gov/odp/docs/
fy05hsgp.pdf.
 290 Part III: Exploring the Technologies

n XML in Emergency Response

The lEITSC The beauty of XML standardization efforts is that, with proper coordination, different
web site offers areas of interest or domains can leverage each other’s efforts. For example, the Law
emerging CAD/
Enforcement Information Technology Standards Council (LEITSC) has established
rmS standards
information: http://
priority objectives for development of functional standards for records management
www.leitsc.org/. (RMS) and computer-aided dispatch (CAD) systems. XML and related standards are
the primary focus of its technical committee.

The emergency management world is also seeing rapid growth of information sharing
standards built around XML. For example, the Emergency Data Exchange Language
(EDXL) is an effort to advance interoperability between data systems. EDXL is
being developed through a practitioner-driven, public/private partnership between
industry and the DHS’s Disaster Management (DM) E-Gov (electronic government)
initiative to advance U.S. disaster management response capabilities. One standard
established before DM involvement was the Common Alerting Protocol (CAP). EDXL
is a broad suite of draft standards to provide tools for information sharing, while CAP
is a specific, standardized protocol for alerting and event notification.79
The Disaster
management CAP has seen use in both government-funded and commercial applications. Disaster
Interoperability Management Interoperability Services (DMIS),80 an interoperability software toolset
Services (DmIS) providing real-time, secure sharing of incident information for public safety agencies,
are part of a is an example of the former. DHS funded development of it as part of the Disaster
Presidential
Management initiative. DMIS uses the CAP standard, as well as other XML-based
e-government
initiative to advance exchanges, to move information between users of either a no-cost DMIS client
U.S. disaster application or with other applications capable of using the protocol. The DMIS client
management application provides basic functionality using standard, web-based services to create,
response view, and exchange incident information.
capabilities.
Commercially, crisis information management systems (CIMS) are a rapidly
developing breed of application built for information sharing. They commonly
use XML to push data to and pull it from other information systems. Distinct
from traditional RMS and CAD systems used by responder agencies, CIMS
implementations are designed specifically to collect, distribute, and display

79
For further information, see the web site of the Organization for the Advancement of Structured
Information Standards (OASIS) at http://www.oasis-open.org. OASIS is a not-for-profit
consortium of vendors and users developing guidelines for interoperable systems. For information
on EDXL, see http://xml.coverpages.org/edxl.html.
80
See the Disaster Management Interoperability Services web site at
http://www.cmi-services.org/.
 Chapter 17: Data Communications
291
information from various sources—both from humans and machines. For example,
popular commercial products allow integration of information from CAD and
geographic information systems (GIS), while providing document sharing, video
conferencing, and other collaboration tools.

Commercial CIMS products with XML capabilities are finding popular adoption
among emergency management officials for noncrisis events, too. For example:
• Football Championship Game – Jacksonville, Florida
In February 2005, the Jacksonville Sheriff ’s Office used a commercial, web-
based collaboration product to help it and dozens of other agencies manage
information flowing in all directions. It was found to be particularly useful in
maintaining situational awareness, executing Incident Command System (ICS)
incident action plans, and producing situation reports.
• Presidential Inauguration – Washington, D.C.
A month earlier, the Metropolitan Police Department in Washington, D.C.,
made use of a different CIMS to push information to other homeland security
and law enforcement information systems. It also helped the department
document activities for subsequent federal reimbursement of expenses.
• National Political Convention – Boston, Massachusetts
Boston was the site for a national political convention late in the summer
of 2004. The Boston Emergency Management Agency implemented yet a
different commercial CIMS for hundreds of users across dozens of agencies and
organizations. It was used for incident information sharing between the agency
and the U.S. Environmental Protection Agency during the convention.

There is great room for XML and similar technologies to advance interoperability
of data communications. An October 2004 report on CIMS interoperability by
Dartmouth College81 noted the need to create a common vocabulary of technical
terms, define data elements, promote public/private partnerships to advance
standards, and overcome “cultural issues” affecting information sharing. Similarly,
standards for open messaging between RMS and CAD systems are in their infancy.

81
Institute for Security Technology Studies, Crisis Information Management Software (CIMS)
Interoperability: A Status Report, (Hanover, New Hampshire: Dartmouth College, October 2004). See
http://www.ists.dartmouth.edu/TAG/cims1004.pdf.
 292 Part III: Exploring the Technologies

Building Blocks for Interoperability

The very process of standardizing, accepting, and implementing common protocols
is endlessly challenging due to the rate of change in the world of information
technology. Government, in general, and public safety, more specifically, faces
these challenges in spades. It’s impossible to adopt the power of standards without
becoming part of the dynamic evolution of information sharing.

Challenges notwithstanding, the future looks bright for greater and greater technical
capabilities to share data, make it intelligible, and, ultimately, make it into actionable
information. Information sharing is the true measure of interoperability.

***
It’s becoming
increasingly difficult Common protocols and standards arising in conjunction with the Internet depend on
to separate wired
physical networks to move data about. Increasingly, interagency communications
and wireless modes
of communications. capabilities are evolving simultaneously on both wired and wireless networks. In
truth, it’s becoming increasingly difficult to separate the two modes of
communications. For the sake of discussing data communications technologies that
use the protocols and standards mentioned, we’ll take a look at wired and wireless
networks separately.

Wired Data Networks

The term “network” is a very flexible one, something like “system.” On the one hand,
it’s used formally to refer to technical assemblages of telecommunications hardware
and software. On the other, it’s used more broadly in reference to groups of people or
functions linked by technology. Our use in this chapter is toward the technical side of
that spread.

A Whole Lotta *AN Going On!

Most anyone who has been around an office computer environment more than about
an hour has heard the term “local area network” (LAN). But have you heard about
campus, metropolitan, and wide area networks (CAN, MAN, WAN)? Despite the
obvious fun that can be had by use of the acronyms (in some quarters, at least), do
these have anything to do with communications interoperability?

Well, yes they do. Thanks for asking! Just as common terminology is a key factor for
interoperability, the design and operation of interagency communications systems is
furthered by common use and understanding of terms. Data networking is easier to
understand with a common, consistent vocabulary for network types.
 Chapter 17: Data Communications
293
n Standard Network Types
Local area networks are typically constrained to an office or building environment.
There are physical wiring limitations that have given rise to the term, but generally a
LAN is considered a geographically and functionally constrained network connecting
personal computers, and perhaps, servers and printers.

Multiple LANs may coexist in a single location to segregate use for functional or
security purposes. For example, it’s not uncommon in dispatch centers for separate
connections to the state data network and to the city or county LAN to exist side-by-
side—often connecting separate computers. The state connection provides access to
the FBI’s National Crime Information Center (NCIC), the National Law Enforcement
Telecommunications System (NLETS), and state systems, while the other provides
access to local applications and data.
Statewide networks
connect local,
From an end user’s point of view, CANs, MANs, and WANs may appear to be
campus, and
metropolitan area largely arbitrary distinctions in the geographic extent of data communications
networks to create systems. To a large extent, that’s true. Data networks are categorized in these
the technical basis geographic terms more for the sake of convenience in discussion rather than
for law enforcement inherent technical limitations.
information
sharing. Groupings of networks to create the successively larger ones are defined at a technical
level, of course, but widespread adoption of TCP/IP for data communications often
makes them seem all as part of a larger whole. With the right agreements, technicians,
and overarching applications—such as the Internet—they can easily serve as the
technical means of data communications interoperability.

For example, the FBI’s Criminal Justice Information Systems (CJIS) WAN connects to
each state and some larger cities, providing the backbone for a wide array of NCIC,
The FBI’s CJIS criminal history, and automated fingerprint identification services to agencies
WAn connects nationwide. Specialized networking equipment and circuits connect each of these
law enforcement
agencies
pieces. And a whole lot of tuning and configuration makes it possible to pass data
nationwide. from one end to the other, but at the network level, there is interoperability.

n Public Safety Network Types

Project MESA, an international effort to standardize broadband wireless access for
emergency response, introduced several important networking concepts to public
safety. We’ll discuss Project MESA further in the final section of this chapter, but want
to introduce the networking concepts here.
 29 Part III: Exploring the Technologies

In the process of examining intra- and interagency needs, different type of networks
were defined to address differing needs for high-speed data exchange. These aren’t
necessarily independent networks and may, indeed, be built of similar technology.
Each amounts to a separate functional type of network.

The first is a personal area network (PAN). In public safety response, this is the
networking environment that surrounds the individual responder. It may be
short-range wireless means for microphones, location monitoring devices, and
How many environmental sensors to be connected to a personal hub. From that hub, information
acronyms can fit on may be made available to the individual responder, as it may be shared with team
the head of a PAn? members, incident commanders, and beyond. The PAN will carry both data and voice
communications within close proximity to the first responder.

At a higher level, an incident area network (IAN) links multiple response

elements responding to a particular incident. This is most easily seen as a network
geographically limited to the scene of the incident, but the concept recognizes
that outgoing and incoming communications from afar—such as from a central
Emergency Operations Center (EOC)—may touch the incident area network as well.

Beyond individual incidents, the jurisdiction area network (JAN) describes functional
and even technical networking requirements that span the general operational
environment of one or more agencies. In essence, it serves to connect both widely
dispersed resources and concentrated “hotspots.”

The final networking type described by Project MESA is the extended area network
(EAN). Multiple sub-networks linked across broad geographic expanses are most
commonly known as WANs or extranets. The idea is that through use of common
technical protocols, application-level interoperability, and shared security measures,
data communications can span individual agency and jurisdictional networks.

Data Networking Evolution

For law enforcement, all this network connectivity isn’t that unusual. NCIC, NLETS,
and other collaborative data systems have allowed agencies to share wanted persons,
stolen vehicle, and other information nationwide for almost 40 years. What has
changed is that the networks have gotten smarter, faster, and more flexible. Dedicated
circuits between systems that were more than adequate for decades have largely
been relegated to the dust bin of history, as more and more data needs to be moved
between agencies.
 Chapter 17: Data Communications
29
n Speed Matters
Wired networks speeds have increased dramatically as the world has come to revolve
more and more around access to information. Thirty years ago when ARPANET, the
Internet’s precursor, was the private domain of military facilities, defense contractors,
Today, nCIC
and nlETS rely
and a few universities, LAN speeds were measured at just a few million binary digits
primarily on packet- (bits) per second—megabits per second or Mbps. WAN circuits speeds were orders of
switched circuits. magnitude slower, running at what we would today consider good dial-up modem
rates, measured in thousands of bits per second (kilobits/sec or Kbps).

Today, LANs are commonly built to transfer billions of bits per second (gigabits/sec
or Gbps). Long-haul fiber optic circuits forming the backbones of modern WANs are
measured in hundreds of Mbps, while even home access to the Internet is more often
than not measured in broadband terms of megabits per second. In 2005, 60 percent
of home Internet access in the U.S. was via broadband connections. 82

n Intelligent Networks
“The days of the fat, dumb pipe, are over.”

According to industry sources,83 increasing demand for TCP/IP networks to carry

great volumes of data of various types brings a need for more smarts than raw
bandwidth. Traditionally, demand for smarter networks arises as coworkers or
collaborators get spread further apart geographically, depend more and more on
web- and other server-based applications, and increasingly depend on IP networks for
carrying voice and other multimedia traffic. Internetworking of government functions
is at an all-time high and destined to be more critical as information sharing becomes
not only expected by the public, but demanded.

Network intelligence has gradually come to the public safety world. Ten years ago
essentially all access to NLETS and NCIC occurred over circuit-switched connections
using specialized network protocols. Today, the majority occurs over packet-switched
circuits, most typically using TCP/IP at the core. While private virtual circuits are
used to protect traffic from prying, the circuits are still “virtual”; that is, they’re
passing through a larger cloud of intermingled bits and bytes.

n Improving Quality of Service

voIP applications The greatest driving factor for increased network intelligence today for public safety
need “fast” purposes is to provide an improved quality of service (QoS) at a low networking level
networks. to applications, such as VoIP telephony, which suffer terribly from network delays.

82
Source: http://www.websiteoptimization.com/bw/0509/.
83
Erlanger, Leon, “Building the intelligent network,” InfoWorld, July 18, 2005. See
http://www.infoworld.com/reports/29SRintelnet.html.
 29 Part III: Exploring the Technologies

Digitized and packetized audio from telephones or radios that is being sent and
received in real time demands fast networks. Delays measured in fractions of a second
can disable simultaneous two-way (duplex) voice communications, as we’re used to
with telephones.

And fast isn’t the same as big, though the two have been intertwined since the
earliest days of networking. That big, fat networking pipe connecting two points
might, like a railroad, be capable of carrying huge amounts of data, but it can be
slow to get up to speed and equally slow to decelerate, like a train. In the networking
world—wired or wireless—delays between transmission and receipt of bits and
bytes is referred to as latency.

Have you ever noticed how hard it can be to carry on a cellular telephone
network latency conversation when there are network delays between you and the other party?
affects duplex
(simultaneous
Estimates are that delays of more than a quarter of a second (250 milliseconds)
two-way) disrupt the normal flow of human conversations. Even that tiny amount of time
communications. serves as a cue for the wetware between our ears to switch from “receiving” to
“transmitting” in a two-way conversation.

Wired data networks are more easily managed to maintain a set QoS level than are
wireless networks.

Wired Networks Keep On Keeping On

Thankfully, the interoperability of data communications over wired connections isn’t
much of a technical challenge today. From the physical level of wiring through widely
accepted and reliable networking protocols, there’s little to prevent network architects
from lacing together interagency communications systems.

The greater challenges probably come from too much connectivity, which brings security
concerns, fosters the spread of viruses and other network pestilence, and generally
threatens the manageability of segmented networks. We will address security issues and
technologies associated with data communications later in this chapter.

Wireless Data Networks

Many protocols originally developed for wired data networks have migrated to
wireless networks. While most originally arose for connecting independent data
networks that were built at the time from coax cable and twisted pairs of copper
wire, the rapidly evolving wireless world is pouring its own share of protocols into a
spreading pool.
 Chapter 17: Data Communications
29
Higher level standards and protocols, such as IP, are equally as important in wireless
networks as they are elsewhere. However, unlike in the wired world, there is great
variance in low-level wireless standards. For example, Ethernet84 in its various speeds
is widely accepted and used for wiring together LANs using standard types of cabling.
The wireless data world is much more in a state of transition, by comparison.

In this section, we’ll look at wireless data communications technologies available to

public safety agencies for their own networks and those used for commercial services.
We’ll tour the field in this order:
• Common principles
• Private radio technologies
• Commercial radio technologies
• Wireless local area networking
• Wireless metropolitan area networking.

We’ll conclude this section with a look at how to evaluate options for building your
own wireless data networks versus buying services from commercial providers.

Common Principles
In your own considerations of wireless data communications
technology, work to avoid “Silver Bulletitis”—an affliction
leading to the belief that there’s a single, ideal technology
awaiting discovery or deployment that will provide
interoperability. Keep in mind a few common principles
demonstrating the practical realities and tradeoffs facing
network architects.

n Speed, Capacity, and Throughput are Interrelated

Speed, capacity, and throughput (the effective amount of data passed) are all
interrelated. All other factors being equal, more users on a network reduces total,
practical capacity. This occurs because each user brings a certain amount of
networking overhead. Theoretically, with enough users a network would reach
capacity with overhead communications, alone and provide no useful capacity for
practical applications. More users reduce the amount of network bandwidth available
to all, reducing throughput and effective speed.

84
Ethernet is the popular name given to wired networking technology that has grown dominant
during the past 30 years. Technically, it is standardized by the Institute of Electrical and Electronic
Engineers (IEEE) as IEEE 802.3. It has evolved in speed over the years, with good backwards
compatibility.
 29 Part III: Exploring the Technologies

n Faster and Deeper Requires Smaller “Cells”

Recognize that basic networking theory maintains that more, smaller zones of
coverage (e.g., cells, hotspots, etc.) provide greater speed and capacity. The tradeoff
is complexity and cost. A side benefit is that smaller cells of coverage result in greater
overlap, on a proportional basis, and thus redundancy.

Wireless WANs that depend on few fixed access points for bringing mobile users back
home are relatively limited in capacity and speed. This applies to satellite networks,
as well. Satellite data networking also demonstrates that the mere distance between
users and central network components limits speed and capacity. That is, nature
decrees that electromagnetic radiation is going to take a fixed amount of time to travel
a given distance. Wireless networks of a few hundred feet in radius are faster and offer
the potential for greater capacity than those connecting hundreds or thousands of
miles into space.

n Advanced Capabilities Cost Money

Speed, coverage, reliability, and security cost money. Compromises are made
continuously in public and private sector data networking, as well as by commercial
carriers, to provide the most for the best price. What constitutes an acceptable
compromise and a good price varies widely, of course.

There’s no free lunch, only relative compromises.

Private Radio Technologies

Early generation technologies available for wireless data systems were slow, providing
speed only adequate for low-volume textual information. Very much like other data
systems that relied on wide-area coverage by a relatively few transmitters, early mobile
data systems ran at 4.8, 9.6, and 19.2 Kbps—rates considered painfully slow even
by dial-up networking standards today. And recognize that those systems weren’t
dedicated to a single, point-to-point connection as a dial-up modem is, but shared
each frequency among multiple users, just as voice radio channels were used.

Wideband As a matter of fact, the technologies for these systems operated in standard voice
standards for public channels, encoding data as sounds just like a telephone modem does. Technological
safety use are advancements allowed data speeds to double and then double again, but the result
rapidly developing.
We’ll take a look
was still a network that ran a poor second compared to dial-up. Did we mention the
at the prognosis data channel was shared by multiple users?
for them in the
final section of this Slow technologies are still in wide use. The most common mobile data technologies in
chapter, “On the public safety use today still only run at 19.2 Kbps. And digital voice radios don’t offer
Horizon.” any immediate improvement. Project 25 (P25) radios, capable of passing voice and
data digitally, have a maximum rate of 9.6 Kbps and effective throughput of half that.
 Chapter 17: Data Communications
299

MICROWAVE SUBSYSTEMS
Many public safety voice and data systems have private microwave backbones
linking together facilities and radio sites. While unlicensed microwave technology is
widely available, most agencies prefer to build backbone networks using microwave
channels assigned by certified frequency coordinators and licensed through the Federal
Communications Commission (FCC). As with voice frequencies, coordination and FCC
licensing offers much better assurances that agencies won’t suddenly find other users
interfering with their operations.

Microwave backbone networks are popular because they offer high-speed, high-
bandwidth connections without requirements for intervening infrastructure or recurring
payments to network carriers for leased lines. Properly engineered, they are also
considered more resilient to accidental and intentional disruptions.

(More than one public safety network has been subject to “backhoe fade,” the tongue­
in-cheek term for accidental breaks of buried wire and fiber circuits. Anyone involved
in telecommunications for long has a horror story to tell of losing network access,
receiving a call from a network carrier, and eventually gasping in awe at the sight of
thousands of wires ripped apart by an errant backhoe operator.)

Shared microwave backbones are increasingly popular among public safety agencies
looking to leverage funds and take advantage of the tremendous capacity of today’s
microwave systems. They are a natural adjunct to other shared systems, offering
great potential to interconnect parts of participating agencies’ data, voice radio, and
telephone systems.

Mobile data systems built to operate across voice channels are inevitably constrained
by the channel width of those frequencies. Greater bandwidth yields greater speed.
Data systems built upon the narrow bandwidth of existing voice channels are limited
to low speeds.

Commercial Radio Technologies

Industry sources estimate that 80 percent of the U.S. population is covered by carriers
providing wireless data services at dial-up speeds or better. Nearly 50 percent of the
population is covered by systems offering high-speed data transfer ranging from 10 to
30 times dial-up rates. The lure of such speed and implied capacity is understandable.
Across the country, more and more agencies have turned to commercial services.

Commercial wireless services long ago outran technologies commonly available

to public safety agencies for their own systems—at least in terms of raw speed
and capacity. Recognizing that agency choices may value availability over raw
performance, the attraction of commercial data rates is often a deciding factor.
300 Part III: Exploring the Technologies

n Background: Generations of Commercial Wireless Services

Wireless data services provided by commercial carriers are commonly discussed
in terms of which “generation” they’re part of. There’s some debate about what
exactly splits the generations (sound familiar?), but we know that for wireless data
communications, it tends to be based on transfer rates—or the amount of data
measured in thousands or millions of bits per second (Kbps or Mbps).

At the time of this writing, second and third generation services—2G and 3G,
respectively, in short—are being offered.

A brief taxonomy and short chronology of commercial wireless services may be useful.85
• 1G – Defined only in retrospect, first generation wireless services included early
analog cellular telephones and overlay data services, such as Cellular Digital
Packet Data (CDPD). CDPD was popular among police and fire agencies as a
commercial networking alternative. It ran at 19.2 kilobits/second (Kbps).
• 2G – Digital cellular telephone systems are considered the second generation.
Second generation systems include GSM, iDEN, and cdmaOne. Data rates for
these technologies are around 20 Kbps.
• 2.5G – Services running in the range of a few dozen to few hundred Kbps are
considered to be in this transitional ground from dial-up speeds to wideband,
3G services. Examples include GPRS, 1xRTT, and EDGE technologies.
• 3G – High-speed technologies that can compete with wired services, ranging in
speed from a few hundred Kbps to more than 1 Mbps. Examples include EvDO
and UMTS.

n Growing Private and Public Sector Use

Use of commercial wireless services is growing. A 2004 report by the Yankee Group,
a high technology market research firm, indicated that more than half of large U.S.
businesses would be using wireless wide area networks by mid-2006, citing the growth
of 3G networks and their capacity to bring enterprise-class application services to the
mobile user. 86

Figure 17-1 depicts real-world data throughput of different wireless technologies and
likely dates for broad availability.

85
The world of wireless data networking is full of acronyms. See Appendix F for a glossary of
terms.
86
Signorini, Eugene, 3G Represents an Inflection Point for Enterprise Mobility (Boston, Massachusetts:
Yankee Group Research, Inc., 2004).
 Chapter 17: Data Communications
301
1440
1320
1200
real-world throughput range in Kbps

1080
960
840
720 Mobile
Fixed WiMax
600 WiMax (802.16c)
480 Wi-Fi (802.16d)/
(802.11) OFDM
360 EVDO HSDPA
240
120 EDGE
0 GPRS 1xRTT

2000 2005 2010 2015

likely date for broad availability

Figure 17-1: Wireless Data Rates and Availability

Source: InfoWorld, September 26, 2005

Satellite Services Technologically, public safety tends to trail, but track, private data networking trends.
Commercial We can look at those broader trends to project where public safety wireless is headed.
satellite services
are the only means
A late 2005 reader survey by MissionCritical Communications87 showed that slightly
for U.S. public
safety agencies to more than half of respondents said that traditional, private radio networks were the
gain the advantages primary means of wireless data access for their agencies’ responders, while more than
of space-based a third relied on commercial networks. Significantly, about half as many respondent
communications. agencies relied on high-speed wireless LAN (WLAN) technologies as relied on
As addressed in commercial services—16 percent versus 34 percent.
Chapter 16, Voice
Communications,
The use of popular WLAN technologies is an interesting parallel of public safety and
satellites have
a definite niche private sector uses. The cited survey also indicated that 75 percent of respondent
for emergency agencies planned to deploy WLANs at their facilities before the end of 2007. Of
response. They also course, there’s a difference between using the technology at facilities, such as offices
have technical and and parking garages, and covering the wide, deep emergency response environ. Due
cost drawbacks that to limited range of WLANs, most agencies using them rely on traditional private or
keep terrestrial data commercial networks for more general coverage.
networks as the
first choice, where
available.

87
“Public Safety Report: Snapshot Survey – Wireless Networking,” MissionCritical Communications,
September 2005, p. 64.
 302 Part III: Exploring the Technologies

Wireless Local Area Networks

The growth and popularity of WLANs is indisputable. Various industry sources
cite double-digit annual increase rates for the equipment market and triple-digit
growth rates in the number of users worldwide. The value of mobile computing
long recognized by public safety agencies has now been recognized in the consumer,
industry, and general business sectors. Popularity has driven down the technology’s
price and spurred innovation in its use.

n WLAN Technologies
As a matter of background, wireless LAN technologies are most often described
in terms of the standards they use. The most common is the IEEE 802.11 family of
standards,88 which define wireless networks very similar to Ethernet (IEEE 802.3) in
the wired world.

Standardization has been key to WLAN growth. However, it wasn’t until the thorny
The Wi-Fi Alliance issue of interoperability was taken up that manufacturers adopted a common
brought a standard
implementation of the standards, fueling an explosion in growth. The Wi-Fi Alliance,
implementation to
802.11 wireless a nonprofit trade association established late in the 1990s, brought that common
networks. implementation well known today as Wireless Fidelity or Wi-Fi.89 The term Wi-Fi has
become such a standard part of the international wireless lexicon that it’s well to
remember it has a formal meaning.

High-speed wireless data networks are an increasingly important part of the

interoperability equation. As agencies seek greater mobile access to information and
weigh their options to rent or own networks providing it, the value of wireless data
networking technologies is being factored in. We will address those technologies and
evaluate privately owned versus commercially available options shortly.

n Wi-Fi and Other 02.11 Networks

The IEEE 802.11 series of standards covers two incompatible types of technology:
802.11a and 802.11b. Though very similar technologically and both serving well in
accurately described Wi-Fi networks, a key difference is in the frequency bands they
use. Just like voice technology, WLANs using different frequency bands lack technical
interoperability at a very low level. It’s possible to include both 802.11a and b
technologies in the same box, but they’re still operating independently even if linked
at a higher networking level.

88
For further technical information on the IEEE 802.11 series of standards, see
http://www.ieee802.org/11/.
89
Wi-Fi® is a registered trademark of the Wi-Fi Alliance. Wi-Fi CERTIFIED™ equipment is the
implementation standard for the vast majority of WLANs. See http://www.wi-fi.org.
 Chapter 17: Data Communications
303
Both 802.11a and b technologies operate in the FCC’s unlicensed frequency bands at
802.11a networks 5.8 and 2.4 GHz, respectively. While use of these bands is unlicensed, it is regulated
use 5.8 GHz
and every WLAN device has to comply. Antenna and power emission regulations
frequencies, while
802.11b networks
limit what can be done with the devices.
use 2.4 GHz.
Largely due to the more limited range of the frequencies used, 802.11a has not been as
widely adopted as 802.11b, despite its higher data rates. As a matter of fact, common
reference to Wi-Fi hotspots—local access points or base stations with broader
network connections—in public transit areas and cyber cafés is usually referring to
the slower, lower frequency equipment. Less range means that more access points
are needed to cover the same area, leading to higher costs and greater complexity in
linking all the devices to a common backbone.

Offering the lower frequency (2.4 GHz) and high data rates (up to 54 Mbps), 802.11g
is a later standard now growing in popularity. It is also backwardly compatible to
802.11b. Real throughput is still less than half of the raw data rate and just like
802.11a and b, this latest Wi-Fi technology throttles itself back when faced with
interference or weak signals in order to maintain connections.

Outside these factors, 802.11a, b, g networks are very similar in operation. Each uses a
very few wideband channels in their respective bands. They move bits of data around
the wide channel in a predetermined sequence to improve throughput and resistance
to certain types of interference. This process of direct-sequence spread spectrum (DSSS)
is common to Wi-Fi technologies.

By contrast, the basic 802.11 standard also provides for frequency hopping spread
spectrum (FHSS) techniques that operate at lower data rates (1 or 2 Mbps), but
which in application offer greater resistance to signal jamming and interference,
unintentional or otherwise. Wireless network technologies using 802.11 FHSS are
available for public safety use, though are eclipsed by the Wi-Fi juggernaut.

FREqUENCY HOPPING SPREAD SPECTRUM

In the midst of World War II, communications security was paramount. A little-known
patent was filed in 1941 by “H. K. Markey et al”—Hedy K. Markey, better known to
the world as the actress Hedy Lamarr—for a system using frequency hopping spread
spectrum techniques to code transmissions for radio-guided torpedoes.

Now known to be a particularly robust transmission mode and effective encoding

Hedy Lamarr method, spread spectrum techniques never found popularity until long after Patent
No. 2,292,387, “Secret Communications System,” expired. Lamarr lived to see their
popularization in military and commercial technologies.
30 Part III: Exploring the Technologies

WIRELESS DATA NETWORKING

STANDARDS
The world of wireless standards is wide. Primary data networking standards are
established by the IEEE in its 802 series, including:

802.11 – The ubiquitous wireless LAN standards. Wi-Fi equipment and networks
are a particular, popular implementation of the IEEE 802.11 standards. Actual TCP/IP
throughput is about half of the raw channel rate, which itself is stepped down to
maintain connections in weaker coverage areas.
• 802.11a – Operating at 5.8 GHz, offering up to 54 Mbps raw data rates
• 802.11b – Operating at 2.4 GHz, offering up to 11 Mbps raw data rates
• 802.11g – Operating at 2.4 GHz, offering up to 54 Mbps raw data rates and
backwardly compatible with 802.11b.

Other 802.11 standards define further implementation details, such as:

• 802.11i – A 2004 amendment correcting early security vulnerabilities in the
Wired Equivalent Privacy (WEP) specification. A subset of this standard was
adopted by industry and entitled Wi-Fi Protected Access™ (WPA™).

And next generation technologies are on the horizon here, as well.

• 802.11n – A developing IEEE standard, occasionally referred to as Next-Gen
Wi-Fi, promising higher data rates and greater range with 802.11 backwards
compatibility.

802.15 – Standards under development for personal area networks (PANs).

802.16d and e – Developing wireless metropolitan area network (WMAN) standards

for faster wireless networks promising greater range and security. Where 802.11
equipment is technically related to its Ethernet forebears, 802.16 is different at a low
level, so fundamentally incompatible with WLAN technologies. 802.16e is intended to
bring enhancements for mobile access to the networks. The interoperable standard for
802.16 implementations is referred to as WiMAX.

802.20 – Another WMAN standards effort intended to provide broadband wireless

access for true vehicular speeds. Formally known as the Mobile Broadband Wireless
Access, this standards process is in its early stages and it’s expected to be years before
compliant equipment is commercially available.
 Chapter 17: Data Communications
30
n WLAN Interoperability
There’s a remarkable degree of interoperability with Wi-Fi, making it such a popular
technology. A combination of de jure (IEEE) and de facto (Wi-Fi Alliance) standards,
openly accessible radio spectrum, and a receptive market caused it to boom.
Manufacturers rushed to meet market demand, which in turn brought competitive
prices for buyers. It’s easy today to pick up a Wi-Fi network access card for less than
the monthly cost of a cell phone and use it to connect to the Internet from public
access points, often at no cost.

Some public safety WLAN needs can and have been met by no more sophisticated
equipment than used by the average cyber café surfer. For example, “parking lot
LANs” have been created and police vehicles suitably equipped so that reports,
virus software updates, and other sizeable packages of data can be transferred in a
reasonable amount of time when the officer gets within range of the station hotspot.

n WLAN Weaknesses
The beauty of 802.11 wireless LANs is that the technology is readily available and
highly developed due to its popularity. However, the technology does have a number
of weaknesses.
• Popularity. Yep, the strength is also a weakness. Wi-Fi (IEEE 802.11b) hotspots
today all compete for the same few slices of 2.4 GHz radio spectrum. Separate
networks can operate in the same slice and over the same territory, but physics
dictates that they will interfere with one another.
• Use of unlicensed spectrum. Popularity is one thing, but unlicensed
use of the spectrum makes the WLAN ecosystem a bit of a jungle. Other
widespread public, commercial, and industrial use of both 2.4 and 5.8 GHz
unlicensed spectrum reduces its suitability for public safety purposes. For
example, Wi-Fi networks share the band with cordless phones, microwave
ovens, and nanny cams. ­
• Security. Wi-Fi networks have gotten a bit of a black eye for their hack-ability.
While this has led public safety agencies toward proprietary adaptations of ­
802.11 standards, it seemingly hasn’t dampened general enthusiasm elsewhere.
Network security experts point out that all shared-medium networks, such as
basic Ethernet and Wi-Fi, are inherently more vulnerable. Encryption and other
security measures have been used for years with wired and wireless networks,
alike, to at least protect the privacy of their communications.
• Mobility. The 802.11 standard suite wasn’t designed for mobile devices that
may be moving rapidly in and out of optimal coverage or in and out of range
of different network access points. In essence, each Wi-Fi cell is a separate LAN
unto itself, using separate network addresses. Even if the WLAN could manage
 30 Part III: Exploring the Technologies

breaking and making connections each time a user moved from one cell to
another, IP-based networks and applications don’t deal well with addresses
being switched on the fly, potentially several times a minute or more when
users operate at cell boundaries. Proprietary extensions to 802.11 standards
reduce this to a degree by making the access points “dumb” and moving most
intelligence for managing mobility back to the network core. This comes at the
cost of less standardization and, somewhat as a result, less interoperability.

n WLAN Technology in Action

802.11b (Wi-Fi) Across the United States, municipalities are building wireless LANs to serve their
technologies residents, businesses, visitors, and agencies. Large and small cities, alike, see wireless
are preferred for as a means to bridge the “digital divide,” keeping less advantaged citizens from the
citywide broadband
wealth of information and services available in our Connected Age, as well as the
wireless access
projects.
means to serve the community broadly. Almost exclusively, Wi-Fi technology is being
used to deliver wireless access to users.

Examples are numerous. “Wireless Philadelphia” and San Francisco’s “TechConnect”

are two of the most expansive initiatives. The City of Philadelphia requested
proposals in early 2005 looking for a network to cover its 135 square miles.90 Later
the same year, the City and County of San Francisco followed suit in efforts to cover
its 49 square miles. Each specified Wi-Fi, specifically 802.11b or g, recognizing as put
by San Francisco, “its ubiquity in user devices, standardization, low cost and ease of
provisioning.”91

Spokane, newark, Large cities are not the only ones building wireless LAN systems. Police and other
and many other emergency agencies across the country are already making use of the technology, if
jurisdictions at smaller scales, to connect field staff to information. Examples include Spokane,
across the country
Washington, which has built a dual-use network with separate segments for public
are using WlAn
technologies to
access and emergency agency use. The system covers a 100-block section of the
provide broadband downtown area, providing access for police and fire uses. Across the country, the
data to emergency Newark (New Jersey) Police Department is using a COPS Office Interoperable
responders. Communications Technology Program grant to install a broadband wireless network
linking multiple policing partners and hospitals around the area.

90
The Wireless Philadelphia web site has further information. See
http://www.phila.gov/wireless.
91
The San Francisco TechConnect web site has further information. See
http://www.sfgov.org/site/tech_connect_page.asp?id=33899.
 Chapter 17: Data Communications
30
multiagency Wi-Fi In essence and practice, these are standards-based, shared systems. Widely
networks provide available and compatible technology provides agencies using Wi-Fi networks with
standards-based, a competitive market to keep prices down and service quality up. Broad use outside
shared data the public safety market brings innovation and further economies of scale through
communications sharing of infrastructure. Police, fire, and EMS agencies are leveraging the commercial
systems.
popularity of Wi-Fi technology.

n Mesh Networking Technologies

Many of the networks mentioned above will be built in the form of mesh networks,
a form of networking that links together individual nodes to blanket part or all of
a jurisdiction with broadband wireless access while providing high reliability and
system throughput. According to ABI Research, implementation of citywide wireless
networks are expected to be the largest factor in the growth of mesh networks
between 2005 and 2010.92

A mesh network The term “mesh network” has come to be used rather loosely in recent years, but
is made up of properly refers to a network of many nodes, each of which communicates with two
many nodes, each
or more of its neighboring nodes. End-user network devices, such as a mobile data
communicating
with two or more
computer, can access a mesh network and thereby become part of it, but rarely are
others. designed to be part of the mesh fabric itself.

Figure 17-2 depicts a simple mesh network of four access points (AP) that
communicate with each other and mobile computers. Each AP maintains a line of
communications with all other APs. Traffic received at one AP is passed to the station
and, potentially, on to a WAN either directly or through another access point.

Figure 17-2: Mesh Networking of WLAN Access Points

92
“Mesh Network Market May See Tenfold Growth in Five Years,” ABI Research press release,
November 16, 2005. See also http://www.abiresearch.com/abiprdisplay.jsp?pressid=556.
 30 Part III: Exploring the Technologies

Wired or wireless links separate from the WLAN channels provide alternative paths
for the traffic to follow. This helps in balancing traffic on the mesh links and provides
resiliency in case one of the intermediate APs is lost. Circuits or links that carry
masses of traffic from one point to another are referred to as backbone links.

Consider an example. The laptop in Figure 17-2 is depicted as being able to

communicate with either AP Alpha or Charlie. This assumes the APs have some share
of overlapping coverage, which is common in real-world networks. Under normal
conditions, Alpha would serve as the AP of choice since it’s closer to the station,
network-wise. If it went down for some reason, communications from the laptop
could continue through Charlie to Bravo and onto the backbone.

This is a classic, full mesh network. If the individual APs weren’t connected to
all others, it would be considered a partial mesh. If each was linked directly back
to the station, it wouldn’t properly be called a mesh, but rather would be said to
have a star network topology.

Tempe is building Mesh networking is becoming the rule rather than the exception when multitudes of
an expansive mesh WLAN access points are used in concert across a jurisdiction. For example, the City
network to cover of Tempe (Arizona) is building tandem Wi-Fi mesh networks over a 40-square-mile
more than 40 area to serve the public and municipal agencies, independently. Approximately 400
square miles using access points will be used to communicate with mobile wireless devices, as well as to
approximately 400 route network traffic to backbone networks. Emergency responder vehicles capable of
access points.
operating on either the mesh network or the city’s pre-existing mobile data network
will use in-vehicle routers to dynamically choose the optimal network path back to
agency servers.

WLANs linked together to MANs today require proprietary technologies to make

them appear to users on both the wireless and wired sides as part of a single network.
Not to draw too fine a point, but wireless mesh networking is a bit of a frontier
itself. As of late 2005, there were no fewer than six companies offering different
technologies to bridge WLANs into a common mesh.
mesh networks
commonly use
proprietary
While a lack of standards in this realm may cause interoperability concerns, it should
technologies to link be pointed out that the mesh technology is linking together parts in the background,
Wi-Fi access points not at the network level the user sees. In the networks discussed here, any common
into a common Wi-Fi-enabled laptop computer could, with appropriate authorization, roam onto
network. the mesh network, find the appropriate channel, and operate regardless of who
manufactured the computer or its wireless card.

Wireless local area networks are an increasingly important means of interagency

communications. The standardization, popularization, and widespread availability of
 Chapter 17: Data Communications
309
Wi-Fi technology, in particular, has opened many broadband wireless opportunities
for public safety agencies.

Rent or Own?
WLAN technology is one of several choices available for interagency data
communications. Where public safety agencies had only one practical means
of connecting mobile users to data sources—building their own networks—an
explosion in commercial services has provided viable alternatives for many. With the
popularization of consumer wireless data technologies, agencies now have a third,
hybrid alternative to build their own networks from technology broadly available
outside of the public safety environment.

We’ve heard heated debates about why one approach to wireless data for public safety
agencies is preferable. There are many strong points to be made on either side, but
ultimately, the best decision is made by agencies that put technological debates to
simmer on the back burner while letting their own business needs drive the decision.
Those needs and all compromises made will only then properly include consideration
of system lifecycle costs, security needs, and operational priorities.

There’s no single right choice of wireless technologies. The techniques recommended

in this Guide for managing interagency communications projects will lead to the best
choice between wireless data technologies for your agencies’ particular needs.

The following chart (Figure 17-3) will be useful in balancing needs. Three alternatives
are examined:
1. Build Using Specialized Public Safety Technologies – Traditionally, wireless
data networks used by public safety agencies have been built by the agencies
themselves, using niche technologies. Broad consumer and business use of the
technologies never existed. Traditional, low-speed mobile data networks are
included in this category.
2. Lease Commercial Services – Data network services are leased through a
wireless carrier.
3. ­Build Using Broadly Available Technologies – Use of widespread wireless
data technologies brings a hybrid option to build agency-owned networks
from commonly available parts. Wireless LAN technologies are included in
this category.

Pros and cons for decision factors and alternatives are provided. The “ratings”
indicators include a minus sign (-) for detracting factors, a plus sign (+) for attractive
factors, and a check mark (3) for acceptable compromises.
310 Part III: Exploring the Technologies

Wireless Data Communications

Rent or Own Decision Factors
SPEED AVAILABILITY RELIABILITY
rating Pro Con rating Pro Con rating Pro Con
no nosebleeds Data speeds Coverage Design, Stable, Capacity is very
at 1% to 5% designed construction, dependable low relative to
Build Using of alternatives; for agency and technologies alternatives
improved requirements implementation built for the and difficult
Specialized
Public Safety – coding + of networks + rigors of public to increase
techniques and takes time safety use significantly
Technologies software yield
little relative
improvement
The fastest Technology Existing Coverage is Highest Capacity is
wide-area turnover brings networks designed for capacity, designed for
alternatives new user means systems broader market typically, due broader market
are available equipment and can be brought needs; reduced to sharing with needs; reduced
soonest installation up more coverage other users capacity in
Lease costs quickly in rural and rural and
Commercial + – isolated urban – isolated
Services areas urban areas;
ruggedized
user equipment
may be
required at
higher cost
much faster Turnover of Coverage Design, Capacity High capacity
than traditional, consumer designed construction, designed to meet surge
specialized and industry for agency and for agency needs requires
public safety technologies requirements implementation requirements overbuilding;
Build Using technologies is faster than of networks that can be ruggedized
specialized takes time; increased user equipment
Broadly
Available
3 technologies 3 coverage is 3 relatively easily may be
traditionally typically spotty required at
Technologies used by public compared higher cost
safety to traditional
networks; wide
area coverage
is expensive

Figure 17-3: Rent or Own Alternatives and Factors

 Chapter 17: Data Communications
311

– = Detracting + = Attractive 3 = Acceptable

Factors Factors Compromises

SECURITY SUPPORT COSTS

rating Pro Con rating Pro Con rating Pro Con
relatively Staples of relative Heavy reliance Easily limited
obscure modern reliability of on vendors for predictable market for the
technologies network equipment information, initial costs; technology
lead to a bit security, leads to even with long product increases initial
more security such as reduced internal lifecycles costs; ongoing
virtual Private support needs support maintenance
networks costs can be
3 (vPns) and – high, mainly
advanced for vendor
authentication, maintenance
are difficult contracts,
or impossible licenses,
to use internal labor,
and contracted
services
Broadband Common use least amount lack of internal Predictable recurring
provides IP and widely of internal expertise and costs that may costs, typically
and other available support support leads be negotiated monthly;
standards information on required; to vendor and contracted; shortest
supporting technologies broad usage dependence lowest internal lifecycles
3 modern used increases + means there is labor costs; for user
network vulnerabilities widely available other markets equipment;
security community find wide-area most rapid
measures support commercial migration of
services cost- technologies,
effective adding to costs
Broadband Widely Wide range Internal Wide Ongoing
provides IP available of community expertise availability of maintenance
and other information on support requires technology costs can be
standards technologies continuous reduces high, mainly
3 supporting used increases 3 study; purchase, for labor or
modern vulnerabilities commercial operations, and services;
network user maintenance relatively rapid
security technologies costs equipment
measures are less rugged lifecycles

Figure 17-3, continued

$
Cost factors vary by
implementation. Initial and
ongoing costs should be
evaluated over comparable system
lifecycles and assessed based
on requirements met. Absolute
dependence on any one or
more requirements may lead to
acceptance of higher costs.
 312 Part III: Exploring the Technologies

You’ll note that the third alternative, building agency-owned networks from widely
used technologies, is considered here a good compromise across the board. It is
an increasingly attractive alternative buoyed by a boom in wireless data usage by
consumers, business, and industry. Public safety usage was once a large share of
the wireless data market, but today is miniscule by comparison. The advantages of
long product lifecycles and security through obscurity of traditional mobile data
technologies are fading.

n Leveraging Advantages: Layered Networks

Modern networking technology makes it possible, at a price, to combine the
advantages of each of these approaches. The Tempe, Arizona system mentioned
earlier is such an example. The ideal is the coverage availability and reliability of
traditional public safety wireless data networks combined with the speed, capacity,
and suitability for advanced security measures that are supported by commercial
services—and, of course, ideally available at the lowest cost over all systems’ lifecycles.

It is possible to build user devices making use of high-speed WLANs or hotspots,

Ubiquitous, when available, switching to broader coverage, slower MANs between hotspots,
broadband and eventually resorting to low-speed WANs as the lowest common denominator.
wireless coverage Practically speaking, this requires different radio technology at the lowest levels for
is economically each type of network, plus mobile equipment that dynamically chooses the ideal route
unfeasible in many for each packet of data. That route not only varies by location, but by the speed of the
jurisdictions.
mobile device and other service demands on the broader networks.
narrowband, slow-
speed data is often
the only means The technology to do this is available today. Its use in supporting interagency
to fill in gaps left communications needs is evolving. Networks upon networks are built to serve
in higher speed, different needs and practical realities. Since the data networking is almost always
higher bandwidth, provided through core infrastructure—as opposed to directly between units—the
shorter range wider network, itself, serves as an ever-present gateway to other networks. With
WlAns.
adoption of standard wireless and higher-level protocols, such as IP, security and our
ability to manage it to serve interagency communications needs becomes a key factor.

Security
Security for data communications networks, wired and wireless alike, necessarily
evolves at least as rapidly as the connecting technologies themselves. Threats have
grown in direct proportion to the capacity and extent of networks stretching across
the globe and deep into societies worldwide. Not only has access to networks by
those with malicious and criminal intent grown tremendously, but every insecure
networked computer can serve as a naïve accomplice in attacks. Growth in high-
speed, always-on connections to homes and small businesses has magnified the risk.
 Chapter 17: Data Communications
313
It’s easy to maintain secure data communications. Just lock up all computers
networked together into a single room, building, or compound, secured
electromagnetically to TEMPEST standards,93 and then control physical access by
their users. It’s done all the time. It just isn’t very practical for the public safety
environment, particularly where interagency collaboration is the rule rather than
the exception.

Police, fire, and EMS agencies maintaining their own physical or logical networks
within or connected to others necessarily have security interests that must be
Interoperability maintained. Some, such as the FBI’s Criminal Justice Information Systems (CJIS)
requires the Security Policy, are conditions of connecting to other networks. The boundaries
technical between networks, physical and logical, are secured to control access, determine
capability to share
authorities, and provide means of auditing use. Interoperability requires the technical
information within
the legitimate
capability to share information within the legitimate constraints of each partner’s
constraints of each security needs.
partner’s security
needs. Whether to guard against criminal, terrorist, or nuisance attacks, network security
tools continue to grow in sophistication and availability. We will examine some of
those tools and their relations to interoperability in a moment. First, let’s take a look
at a key federal policy shaping law enforcement information systems.

FBI Criminal Justice Information Systems

Security Policy
The FBI’s National Crime Information Center (NCIC), the original information
sharing system for law enforcement agencies, has brought changing needs for
The CJIS Security data communications security during the past 40 years. As central information
Policy covers a
repositories, NCIC and its younger siblings such as the Integrated Automated
number of security
areas. Those related
Fingerprint Identification System (IAFIS) originally operated over dedicated, point-
to interagency data to-point communications networks. These systems still connect state and local law
communications enforcement agencies over commercial circuits segregated electronically and logically
are addressed here. from other users, but today connect to other networks that are, themselves, widely
connected elsewhere. Growing internetworking of all forms has shaped the FBI’s CJIS
Security Policy.

93
TEMPEST is a national standard defining limits of unintentional electromagnetic emissions from
electronics for security purposes. Endorsed TEMPEST products are required for the most secure
telecommunications networks, but are rarely specified for public safety purposes. See also
http://www.nsa.gov/ia/government/index.cfm.
 31 Part III: Exploring the Technologies

n Scope
Established in 1999, the CJIS Security Policy affects all agencies using FBI systems
The CJIS Security managed by its Criminal Justice Information Services (CJIS) Division. Because the
Policy affects all policy is considered Sensitive But Unclassified, we’ll only cite a couple of elements
agencies using FBI
in passing. State and local agency systems connected to CJIS Division systems are
systems managed
by its CJIS Division. required to adhere to the policy, so affected agencies should have ready access to it
through official channels.

Most law enforcement agencies access NCIC and other similar systems through
state-level proxies. CJIS System Agencies are those agencies with direct connections
to CJIS Division systems. Most operate both as primary users of the systems and
intermediaries. For example, a state police computer center may be the termination
point for a CJIS Division network circuit and, from a relative perspective, the start of a
statewide data network for access by its own users and those of other agencies.

For both network and information security purposes, the CJIS Security Policy applies
to all users of CJIS Division systems and information from them. Systems and
networks not connected to the FBI aren’t subject to the policy, but combined networks
carrying CJIS, CAD, internal records, and radio system control traffic are increasingly
common in law enforcement agencies.

n Technical Security Requirements

The CJIS Security Policy establishes standard requirements for technical security of
connected systems. They include the following:
• Documentation of network configurations
• Use and maintenance of physically secure facilities
• Use of advanced authentication means
• Unique identifiers for all authenticated users
• Standards for network security, including ­
— Encryption and its management ­
— Internet, wireless, and dial-up access ­
— Firewalls ­
— Audit trails ­
— Virus protection ­
— Penetration testing

A full treatment of these subjects is beyond the scope of this Guide; CJIS Security
Policy, itself, is the definitive statement. The FBI CJIS Division and each CJIS System
Agency has a designated Information Security Officer (ISO). Check with the ISO
 Chapter 17: Data Communications
31
responsible for your agency with questions about requirements for data networks
carrying CJIS Division information.

Since interagency communications can be affected by these requirements, we want to

address a few from the standpoint of interoperability. A couple of basic principles of
the CJIS Security Policy should be kept in mind for that discussion.
1. Different technical security requirements exist for public or shared networks
than for those entirely under the control of a criminal justice agency. Networks
with components in nonsecure locations or which pass through public network
segments require special authentication and encryption measures.
2. The 5 years from September 30, 2005 to September 30, 2010 is a transitional
period for CJIS security requirements. Systems purchased or upgraded after
the earlier date are subject to higher user authentication and encryption
requirements. After the later date, all systems accessed from nonsecure
locations or across public network segments must meet the higher
requirements.

In essence, the distinction between secure and nonsecure locations and networks
revolves around management control. Systems and networks entirely under the
control of a criminal justice agency are considered secure. General governmental
networks, the Internet, and telephone dial-up access are all examples of nonsecure
networks presumed more susceptible to compromise by unauthorized individuals.

n Interoperability
New connections between, for example, two local agency systems already subject
to the policy don’t necessarily bring added security requirements. However,
interconnections made across networks managed by others likely do need additional
security measures.

For example, consider a county sheriff ’s office and a municipal police department that
are independent users of a state criminal justice network that provides their NCIC
access. Each is subject to relevant parts of the CJIS Security Policy. If the two agencies
chose to connect their internal, secure networks to share CJIS information over a
general-use municipal or county government network, that connection would be
subject to the same CJIS security requirements. This might occur if the two agencies
wanted to exchange calls for service between their respective CAD systems that
contain NCIC records information. The solution would be to secure the connection
across the noncriminal justice network according to CJIS Security Policy, for example,
by using a virtual private network (VPN) “tunnel” between the agencies.
 31 Part III: Exploring the Technologies

Wireless data networks are given special treatment by the policy due to the ease by
which RF signals can be intercepted. While encryption and security requirements
Wireless data are significant and must be observed on wireless networks of affected agencies,
networks are given the practical effect of the policy on interagency data communications is the same,
special treatment whether wired or wireless. This is because the interconnection of two wireless
by the CJIS
networks operated under the policy is handled just like the example above. Similarly,
Security Policy.
a single wireless network shared by multiple agencies, some CJIS users and some not
(e.g., by police, fire, and EMS), must have its CJIS traffic encrypted and authenticated
just as it would have to be over the Internet or other common-use network—say
through the use of a VPN.

Securing The process of operating interagency data networks brings challenges due, in large
interagency data part, to the added coordination needed between agencies for common management
networks is more of encryption and advanced authentication. It’s simply harder for multiple agencies to
of a management coordinate management of the complex technologies, sharing control and authority.
than a technical This is true in any multiagency security process; it’s not a unique effect of the CJIS
challenge.
Security Policy.

***
If information sharing is the product of interoperability, then FBI CJIS Division
systems are a cornerstone of the process. From a data communications standpoint,
the common need of criminal justice agencies nationwide to uphold the CJIS
Security Policy means its provisions are a de facto standard. The FBI’s longstanding
Advisory Policy Board (APB) guides policy, assuring it meets federal, state, and local
security requirements.

Common conventions, standards, and means of interfacing systems provide for

interoperability of data communications. However, greater security requires more
coordination and planning to assure interoperability, otherwise mechanisms to
prevent unauthorized access can be barriers between those who would otherwise
cooperate. For example, encryption will deny information access to anyone without
the keys, seeking to use it illegitimately or just without adequate prior coordination.

Fortunately, the CJIS Security Policy is maintained and managed in part to provide
this very coordination.

Securing Data Networks

Standard technologies for securing data networks are equally applicable to public
safety. The primary tools of the trade are virtual private networks and firewalls. Both
bring interoperability implications since their whole purpose is to restrict access.
 Chapter 17: Data Communications
31
n Virtual Private Networks
Virtual private networks (VPNs) are a workhorse of modern data
communications security because they provide the means to secure a substream
vPns can be of data across a more broadly used network. The name alone pretty well
implemented describes their purpose.
in hardware, in
software, or most VPNs can be implemented in software, hardware, or most commonly
commonly through
a combination of
through a combination of both. They are used over many different types of
both. data networks, too. Physically, all types of wired and wireless networks are
supported, most typically using Internet Protocol (IP) standards that are
largely oblivious by design at this level to the type of physical connection or
media over which they’re running.

The important issue from an interagency data communications standpoint (the

topic of this chapter!) is mainly the “V” part of VPN—their virtual nature. Much
as with trunked radio systems and their talkgroups, a VPN is a virtual channel
within a larger network. Granted, the “P” part (private) may be important or
even critical to the virtual channel (network) users, but if so, that’s probably true
whether or not interagency communications are being carried.

In attempting to understand VPNs, it’s useful to picture a tunnel between two

networks through a third. For our simple purposes, picture two relatively secure,
agency-operated networks using the Internet or common-use municipal network
to hook up. Properly implemented, the secured border crossing points between
each agency and the common network can be connected by a tunnel that looks
open from either end, but inaccessible from the middle. See Figure 17-4.

Figure 17-4: VPN Tunnel Between Agency LANs.

 31 Part III: Exploring the Technologies

Advanced authentication techniques are generally used with VPNs. The techniques
assure that the VPN only gets connected for authenticated users. Typically, a
combination of a password and encryption certificate stored on the computer or
in a device that can be connected to the computer serve to prove that a legitimate
access attempt is being made. As with the VPN software, hardware configurations,
and system permissions, user authentication has to be managed to provide
interoperability across jointly connected data networks. The alternatives are
undesirable: Either no access or networks with big security holes in them.

n Firewalls
The device at each network border depicted in Figure 17-4 is a firewall. A firewall
is simply a device that sits at the junction point between two or more networks.
This diagram is a bit of a simplification because there is typically more networking
equipment, but recognize that the firewalls are the means to control traffic crossing
network borders.
Firewalls can
vary greatly in
complexity and The simplest firewall is a small computer with two network interfaces and software
cost. They also controlling what passes in which direction. Firewalls grow in complexity, up to
can provide an enterprise-grade devices that may have dozens of physical networks attached and
end point for vPn allow tens of thousands of individually encrypted VPN sessions.
connections.
And this brings us back to the point of interoperability. For purposes of interagency
communications, firewalls can be an impediment. Most assuredly, they are a basic
building block for secure data networks, but they can and do impede interagency
communications if not managed to provide the capability.

An example of how firewalls are used may be helpful in understanding the

interoperability impact. Consider the two agency LANs in Figure 17-4, each with its
own firewalls. The firewalls are configured to block LAN file server and printer traffic
from passing, while allowing Simple Mail Transfer Protocol (SMTP) connections to
pass packaged fingerprint images.

Before being activated, firewalls are loaded with rules defining what data may pass
Firewalls are in which direction. For security purposes, they are typically configured to deny
typically configured everything by default from the “untrusted” outside network to the “trusted” network
to deny all traffic inside. Akin to Mikey in a classic breakfast cereal commercial, they don’t like anything
passing from the
and refuse to pass it. One-by-one, specific rules are added to customize the firewall.
“untrusted” outside
network to the As may be imagined, the firewall has to be configured accordingly to provide the
“trusted” inside. needed interagency communications, in our case, without opening up the connected
networks to all forms of virulence and pestilence.
 Chapter 17: Data Communications
319
Obviously, this takes coordination between network uses on either side, and a degree
of trust. It’s not uncommon for two secure networks to be connected with firewalls
back-to-back—one being managed by each of the agencies and likely sharing similar
security profiles and traffic rules (in reverse). While this may seem like a waste of a
good firewall, the fact of the matter is that it allows each party in the arrangement to
control its own border, just like nations do with their own physical borders.

n Other Network Security Devices

Network security is an important, dynamic field. A multitude of techniques and tools
are used to protect individual and multiagency networks. Other tools include active
intrusion prevention systems and more passive intrusion detection systems.

Any network subsystem that has the potential to shut down communications has an
Security has to be interoperability dimension. Whether through the security of VPNs, firewalls, or other
carefully managed
subsystems, the intended communications can only proceed reliably if agency needs
to avoid it acting
as a barrier to
are clearly identified, articulated, and documented to assure the technology serves
interoperability. its purposes. Security doesn’t need to be compromised to allow agencies to share
information, but it has to be carefully managed to avoid it acting as a barrier.

On The Horizon
Rapidly developing technologies and standards mean that public safety agencies have
greater and greater data networking capabilities to look forward to. The most exciting
developments (and interest) has been in wireless networking.

Wireless Metropolitan Area Networks

Standards development organizations in the United States and worldwide are
working to tame the latest wireless frontier: High-speed data networks spanning
greater distance, supporting truly mobile users who may move through and across
cells of coverage at vehicular speeds consuming bandwidth at rates unseen today.
Wireless Metropolitan Area Networks (WMANs) are the current frontlines in
WimAx is the standards development.
popular name for
802.16 wireless
metropolitan The term “WMAN” implies more expansive networks and this is, indeed, the intent
area network of standards developed for them. In 1999, the IEEE formed its 802.16 Working Group
implementations on Broadband Wireless Access Standards. The evolving series of standards, known
standards. as WiMax, are expected to define faster, more robust broadband wireless access
techniques that will extend current wireless LAN technologies. 94

94
For further information, see http://www.ieee802.org/16/.
 320 Part III: Exploring the Technologies

The first WimAx The first WMAN standards released defined how fixed points are linked together
standard is for with compliant technology. Others in the series that are under development provide
fixed point-to-point definition for mobile uses, particularly intending to overcome Wi-Fi limitations.
wireless networks.
In 2001, the WiMAX Forum was created by interested industry parties to bring
common implementations of the diverse set of options within 802.16 standards,
commonly known today as WiMAX.95

Broadband Wireless Access for Public Safety

Public safety agencies have had to adapt to commercial and popular use technologies
to get broadband (multimegabit per second) wireless networking in the past.
Increasing availability of spectrum in the vicinity of that used for 802.11a Wi-Fi
promises to bring the power of mass markets and broad standards to bear on police,
fire, and EMS needs for broadband wireless access.
The 4.9 GHz
frequency band was
In 2002, the FCC allocated 50 MHz of spectrum in the 4.9 GHz band for public safety
allocated by the
FCC for exclusive
use.96 The amount and location of the spectrum were important because they allow
public safety use. for the development of broadband wireless equipment to meet public safety needs
for ruggedness and reliability, but which could be largely based on more popular
commercial technologies, bringing economies of scale to keep costs low. For example,
802.11a Wi-Fi operates in the nearby 5.8 GHz band. With minor changes, popular
consumer and industrial technology can be adapted to operate in the exclusive public
safety band, offering greater security and reducing competition for the airwaves.

WlAns in the In practice, 802.11a-based WLANs require much more infrastructure, such as wireless
4.9 GHz band access points, than do 802.11b/g ones. This is due to the transmission characteristics
will require more of the different frequency bands used—5.8 versus 2.4 GHz.
access points for
the same coverage
How much of a difference in coverage is there? Studies show that the lower frequency
as 802.11b Wi-Fi
networks.
signals are 100 to 1,000 times stronger in foliage, 10 to 100 times stronger through
common building materials, and 5 to 10 times stronger filling in gaps in the open

95
The WiMAX Forum is a nonprofit association formed by manufacturers to ensure
interoperability of IEEE 802.16-compliant equipment and networks. See ­
http://www.wimaxforum.org. ­
96
For further information on the FCC’s actions, see “Public Safety’s New Allocation – Answering
Users’ Questions on the 4.9 Gigahertz Band,” available from SAFECOM at http://www. ­
safecomprogram.gov/SAFECOM/library/spectrum/1088_publicsafetys.htm. ­
 Chapter 17: Data Communications
321
beyond the line-of-site of transmitters.97 Optimistic estimates are that twice as
many access points are needed at the higher frequencies to provide the same level of
coverage, while less optimistic ones suggest 5 to 10 times as many are needed

Public safety agencies will build jurisdiction area networks (JANs) in the 4.9 GHz
band using mesh and other networking topologies, but it’s likely the technology will
be used mostly for campus and incident area networks in the near term.

Wideband Wireless Standards for Public Safety

Outside the traditional VHF, UHF, and 800 MHz bands with their narrow voice
channels, the 700 MHz band offers some hope for high-speed data. The band is to be
transitioned to public safety use as incumbent broadcasters move to digital television
The public safety (DTV) technologies. FCC regulations98 provide 120 paired channels (base and
700 mHz band will mobile), each 50 kHz wide, that can be combined for greater bandwidth.
have 120 paired
wideband channels
An additional 18 paired channels in the 700 MHz band are designated specifically
and another
18 designated as wideband interoperability channels that can be combined in groups of three for
exclusively for up to 150 kHz of bandwidth—the equivalent of a dozen Project 25 channels. Thus
interoperability. combined, six wideband interoperability channels will be available as the spectrum is
cleared and 700 MHz Regional Planning Committees99 complete their work.

Tests have shown the potential of high-speed technologies built specifically for public
The TIA-902
standard has been
safety use. Technologies used in a 2001 experimental pilot conducted by Pinellas
recommended for County, Florida yielded raw data rates pushing 460 Kbps in 150 kHz channels.100
adoption by the Following these tests, the Telecommunications Industry Association (TIA) published
FCC for use on the TIA-902, a standard since recommended to the FCC by its Public Safety National
700 mHz wideband Coordination Committee (NCC) and the National Public Safety Telecommunications
interoperability Council (NPSTC).
channels.
At the time of this writing (late 2005), FCC action on recommended standards
for wideband use of 700 MHz channels was pending and considered imminent.
A decision was anxiously awaited because FCC rules prevent licensing and use of
wideband interoperability channels until it has adopted a standard for their use.

97
Dobkin, Daniel M., RF Engineering for Wireless Networks: Hardware, Antennas, and Propagation
(Burlington, MA: Newnes, 2004).
98
47 CFR Chapter I, § 90.533(c).
99
The FCC maintains a web page addressing public safety 700 MHz public safety spectrum and the
regional planning process. See http://wireless.fcc.gov/publicsafety/700MHz/.
100
See the Public Safety Wireless Network report available from SAFECOM, http://www.
safecomprogram.gov/SAFECOM/library/technology/1033_GreenhouseProject.htm.
 322 Part III: Exploring the Technologies

NATIONAL PUBLIC SAFETY

TELECOMMUNICATIONS COUNCIL
(NPSTC)
The NPSTC is a federation of public safety organizations. It is very active in
wireless regulatory matters, standards development, and support for statewide
interoperability committees.

Project MESA
Project MESA, also known as the Public Safety Partnership, began as another in the
Association of Public-Safety Communications Officials – International, Inc.’s (APCO)
respected series of projects shaping the world of public safety communications.
As Project 25 proceeded to define the standard for public safety digital voice
Project mESA
communications, an ambitious project to do the same for data began life as APCO
seeks to address Project 34 in 1995. Interest in the effort grew, eventually becoming international in
both operability scope. During a series of meetings in Mesa, Arizona it was adopted as a joint project
and interoperability of the North American-based TIA and the European Telecommunications Standards
aspects of Institute (ETSI). It has been known as Project MESA since.101
broadband wireless
data for public
Project MESA seeks to address both operability and interoperability aspects of
safety.
broadband wireless data for public safety. That is, much like Project 25, resultant
standards will affect communications within and between agencies. It will most likely
not result in the production of new types of electronics and low-level engineering
protocols as did P25.

Where public safety makes up a sizeable share of the two-way wireless voice world, its
use of wireless data is increasingly insubstantial as a share of the total. Public safety
agencies will increasingly use more generalized commercial technologies for wireless
data networking due to relatively gigantic leaps in capabilities being made available
and dramatically dropping costs of equipment sold in great volumes. Broadband
public safety networks will be built of generally commercialized electronics,
customized at high network protocol layers for its unique needs.

Project MESA will most likely provide standard implementation profiles for public
safety use of commercially available broadband wireless technology, much as the Wi-
Fi Alliance and WiMAX Forum serve, rather than technology standards.

101
See http://www.projectmesa.org.
 Chapter 17: Data Communications
323
Standards: A Necessary, But Insufficient Condition
Late into this Guide, it probably comes as no surprise that we’re advocates
of standards for everything from training to technology. The wireless
communications world has demonstrated particularly well how standards— ­
particularly complex technological standards—are the first step toward
rich technical interoperability. However, we’ve learned with Project 25, as well as the broader
standards provide world has learned through WLAN implementations, that the plethora of options
enough options available under reasonable standards leads to divergent implementations of the
that divergent technologies—and a lack of interoperability. ­
implementations
can preclude
The Wi-Fi Alliance and WiMAX Forum previously mentioned were formed expressly
interoperability.
to bring interoperability for implementations of IEEE 802.11 and 802.16 standard
technologies, respectively. Early WLAN products operating well within IEEE 802.11
standards were not interoperable between manufacturers.

The WLAN market didn’t take off until the Wi-Fi Alliance created a “meta-standard”
Wireless lAns
narrowing the range of implementation options for 802.11 technologies and a process
didn’t take off until
a subset of 802.11 to certify Wi-Fi compatible products. As expected, this process brought critical mass
standards was to the market. Today, Wi-Fi, with all its compromises that reduce options across a
settled on. well-considered standard, is being used around the world from coffee shop hotspots
to public safety mesh networks. ­

The WiMAX Forum was created with forethought to assure interoperability.

The success of those efforts in bringing broad standardization to WMAN
implementations is yet to be seen, but the market is bound to be further advanced
through them than it would have been otherwise. ­

In the public safety arena, debate continues in the digital voice realm about which
P25 (TIA/EIA-102) elements of the broad set of standards known as P25 (TIA/EIA-102) must be
is a rich set of implemented for interoperability. And because P25 is frequency-band agnostic, even
standards that can use of its fundamental standard—the Common Air Interface—doesn’t guarantee that
be interpreted and
implemented in
radios can talk to each other if they’re operating in different bands. We expect similar
different ways. interoperability questions to be raised in implementation of TIA-902 wideband
standards for public safety data communications. Development of conformance tests
is key to the practical use of both voice and data standards. ­

This important debate can’t be done adequate justice here, but suffice it to say that
broad standards alone are not sufficient to guarantee interoperability in the technical
realm. Further implementation standards are inevitable. ­
32
Epilogue
Through wired and wireless networks, carrying voice and data, communications
interoperability is built as a complex system of systems. While technology is an
inescapable piece of the interoperability puzzle, it alone cannot solve the problem, for
it will be forever impossible to build a complete system without human management,
operations, and procedural subsystems being integrated far in advance.

SEARCH has been privileged to work with agencies large and small across the
country under U.S. Departments of Justice and Homeland Security programs that
provide assistance to improve interagency communications among first responders.
We’ve seen great need for resources—human, financial, and technological—to solve
this puzzle, but we’ve also seen growing cooperation among responders from all
disciplines and levels of government.

Our intention in creating this Communications Interoperability Tech Guide was to share
best practices in project planning, procurement, and implementation, as we’ve come
to understand them through agencies making a difference in their own jurisdictions.
We’re confident that the best practices in this Guide will improve the odds of your
project’s success.

And, if you need help along the way, we’ll be there to support you with technical
assistance resources.
Appendix A:
Sample
Agreements
These sample agreements are provided here courtesy of
n The north Central Texas Council of Governments
n The los Angeles (California) regional Tactical
Communications System
n The new Orleans (louisiana) maritime
Intercommunications Committee
 Appendix A:
Sample Agreements

North Central Texas

Council of Governments
Example Memorandum of Understanding
MEMORANDUM OF UNDERSTANDING
INTER-JURISDICTIONAL RADIO MUTUAL AID COMMUNICATIONS
IN THE NCTCOG AREA
(DATE)
We, the undersigned, representing the County of __________, City of _______(the
“Agencies”) do hereby agree to the following:

Whereas, the Agencies all utilize, and/or plan to utilize, trunked radio systems using
technology from a common equipment manufacturer, and/or plan to implement specialized
3rd party equipment designed to provide interoperability between systems from different
manufacturers,

Whereas, each of the Agencies desires to improve the quality and timeliness of inter-
agency communications during mutual aid operations,

Whereas, each of the Agencies desires to provide other Agencies with direct access to
their individual trunked public safety radio system, for the express purpose of cooperation
and coordination with neighboring law enforcement agencies,

NOW THEREFORE, The parties hereto jointly agree:

1. ­ Each Agency shall allow the other Agencies to either directly access their respective
public safety trunked radio systems, or provide access through 3rd party interoperability
equipment.
2. ­ Each Agency shall share with the other agencies all information necessary to configure
and program user radios for operation on their respective public safety trunked radio
systems.
3. ­ ALL programming information and parameters shall be considered CONFIDENTIAL
and shall not be disseminated to any party not included in this Memorandum without
the express written permission of the respective Agencies.
32 Appendix A

4. ­ Direct access is reserved for emergency, priority or other incidents where its use creates a
significant advantage to public safety, including felony pursuits, officer needs emergency
assistance, lookouts for incidents near political boundaries, perimeter search operations,
task force operations, and mutual aid fire scenes. Direct access may also be used to provide
communications for pre-arranged activities, such as funeral escorts or parades through two or
more jurisdictions.
5. ­ Direct access during “priority” or “emergency” incidents is encouraged. The Agencies are
encouraged to develop guidelines that permit field users to directly access neighboring
trunked systems in a timely manner by notifying their dispatcher prior to switching.
Telephone coordination between dispatch centers is not necessary.
6. ­ In cases where two Agencies share a common border, it is recommended that the Agencies
share the appropriate “dispatch” and “primary tactical” talkgroup used in the adjacent
jurisdictions and/or “districts”, “patrol areas” or “beats”.
7. ­ Plain English shall be used for all mutual aid communications. “10codes”, “signals”, jargon,
and slang phrases shall not be used.
8. ­ Field units shall identify themselves by stating their agency name and unit designator.
Examples: ­
“DFW Airport unit 131”
“Arlington Unit Three Forty Four”
“Fort Worth Three Adam Eighty One”
“Grand Prairie Unit 367”
“Collin County unit Three Ten Baker”
“Grapevine Baker 211”
“Carrollton Unit One Twenty Four” ­
9. ­ When communicating with field units from neighboring jurisdictions, dispatch center
personnel shall identify themselves by stating their agency name.
10. ­In the case of “short term”, “priority”, “emergency”, and “notification” communications, once
the need to communicate directly with a neighboring jurisdiction has been established, the
field user shall inform their home dispatcher of their intention to switch, and only make the
switch after dispatcher acknowledgement and clearance. If possible, the field user shall leave
a radio on their home channel, in case their dispatcher or other units need to establish contact
with them.
11. ­When calling a neighboring jurisdiction, the field user shall state their unit identification as
described above, the word “to”, and the name of the agency that they are calling. The field
user shall then wait for the dispatcher to respond before giving any additional information.
Example:
“Arlington Three Adam Eighty One to City of Ft. Worth.”
 Sample Agreements
329
12. ­Provided that the channel is not currently in use, the neighboring jurisdiction’s dispatcher
should respond immediately. If the channel is in use, the dispatcher will ask that the calling
user stand by. Example:
“City of Ft. Worth to Arlington Three Adam Eighty One, go ahead.”
13. ­After their call is acknowledged, the calling user shall state the reason that they are calling and
what, if any action the neighboring agency needs to take. Example:
“We have a bank robbery that just occurred in Arlington on I-20 just east of the city line.
The direction of travel was westbound on I-20 into Ft. Worth. I have lookout information
when you are ready to copy.”
“I am on the scene of an accident with injury that just occurred on I-30, just west of
border between Arlington and Ft. Worth. I need one of your units to respond to this
location, and start rescue for one patient with minor injuries.”
14. ­Once initial contact has been established and the reason given for the call, the communication
shall proceed in a normal fashion until complete. Before returning to their home radio
system and channel, the calling user shall state their unit designator and inform the neighbor
dispatcher that they are switching back to their normal channel. Example:
“Arlington Three Adam Eighty One, I have no further traffic. I am switching back to
Arlington PD Channel 1.”
15. ­In the case of “long term” and “static” events where mutual aid assistance is requested by
an Agency of another Agency, a supervisor shall contact the neighboring Agency or cause
the neighboring Agency to be contacted, and a formal request shall be made for mutual aid
assistance in accordance with existing mutual aid agreements. If approved, the assisting
Agency shall be provided with the specific type of assistance required (K-9, helicopter,
ambulance, etc.) by the requesting Agency. The assisting Agency shall be provided with
the talkgroup or channel where communications for the mutual aid operation are being
conducted by the requesting Agency. The assisting agency shall determine appropriate unit(s)
to respond to the mutual aid event, and provide the above information to the responding
unit(s) at time of dispatch. Once all information is received, the responding unit(s) shall
switch to the designated talkgroup on the requesting Agency’s trunked radio system and
initiate contact as outlined in Paragraphs 10-13 above.
16. ­Complaints of abuse or unauthorized operation by users from neighboring jurisdictions are
encouraged to be resolved at the field supervisor level as soon as possible after an alleged
problem occurs. If the complaint cannot be resolved at this level or if the severity warrants,
a complaint in writing can be made to the jurisdiction involved. Written complaints shall
include the date and time of the offense, the nature of the complaint, the six-digit radio
identification number, the name of the person who witnessed the offense, and, if available,
any audio recording of the offense. Complaints of abuse or unauthorized operation shall
be resolved using established internal procedures, and a written response detailing the
action taken shall be sent to the complaining Agency within 30 working days of the initial
complaint.
330 Appendix A

17. ­New law enforcement or Fire/EMS agencies may be added by amendment to this
Memorandum from time to time, subject to the approval of the Agencies.
18. ­Nothing in this Memorandum shall be construed as to prohibit any individual Agency from
entering into mutual aid communications agreements with separate law enforcement or fire/
EMS entities not included in this Memorandum. Under no circumstances shall any Agency
disseminate another Agency’s programming parameters to any third party without express
written approval from the other Agency.
19. ­Each Agency shall assume full responsibility for all costs associated with programming their
radios for direct access.
20. ­During times of law enforcement or fire mutual aid operation, each Agency shall make
every reasonable effort to provide the same level of communications support to units from
neighboring Agencies as they would to their own units.
21. ­Each Agency shall designate a representative to serve on a NCTCOG Mutual Aid
Communications Committee. On an annual basis, the chair of this committee will be rotated
through all member agencies, by alphabetical order. These representatives shall meet on a
quarterly basis, or more frequently as required, to identify and resolve any issues that arise
during mutual aid or direct access. In the event that an Agency’s representative is no longer
available due to reassignment, the Agency shall appoint a new representative and inform the
committee Chairperson in writing.
 Sample Agreements
331
Los Angeles Regional
Tactical Communications System
Memorandum of Understanding

LOS ANGELES REGIONAL

TACTICAL COMMUNICATION SYSTEM
MEMORANDUM OF UNDERSTANDING BETWEEN ­
PARTICIPATING LOCAL, STATE, FEDERAL, AND MILITARY ­
AGENCIES, FOR RADIO COMMUNICATIONS ­

This Memorandum of Understanding (MOU) between participating Local, State, Federal, and
Military agencies, and the Los Angeles Regional Tactical Communications System Executive
Committee, establishes policy and procedures for the activation, use, and deactivation of an
interoperability communication system. This system will be known as the Regional Tactical
Communications System (LARTCS).

PURPOSE
The purpose of the LARTCS is to allow direct voice communication between participating
agencies in dealing with both short term (felony pursuits, fires, hazmat, etc.) and long term
incidents (major disaster, large scale fires and floods, civil disturbances, terrorist incidents,
etc.). The LARTCS cross-connects different radio channels over various radio frequency
bands, throughout the Los Angeles region. This will enhance the safety of participating
agencies through real time, field unit-to-unit, direct voice communication interoperability.

SCOPE
A “participating agency” shall be defined as any local, state, federal, or military agency that
has read, agreed, signed, and will abide by this MOU.

POLICY
A. ­ Any supervisor of a participating agency may request the activation of the LARTCS.
These personnel shall be held accountable for radio discipline by their respective
agencies.
B. ­ Each communications center will assign the appropriate access channel for their agency
that will be linked to the LARTCS. For agencies participating in specific incidents, each
affected communications center shall monitor the LARTCS to ensure requested resources
are provided, as well as compliance with this agreement and other policies.

Los Angeles Regional Tactical Communications System Memorandum of Understanding

10/28/2004
332 Appendix A

C. ­ During an incident, any agency communication center, incident commander, or supervisor

may deactivate use of the LARTCS, based on operational needs. Notice to other agencies on
the LARTCS will be given when use is deactivated.
D. ­ Deactivation of the LARTCS shall be a joint decision by the involved agencies.
E. ­ All personnel broadcasting on the LARTCS will use plain spoken English. The use of radio
codes, acronyms, and abbreviations, are to be avoided as they have different meanings for
different agencies. Due to agency terminology differences in use of plain text of words such as
“Help”, “Assistance”, “Repeat”, and “Back-up”, the use of these words shall be followed with
a brief description of why the above is needed. (i.e., officer requesting assistance with traffic
control, etc.). The use of the word “Help” should be avoided unless it is being used in the
universal context in a life-threatening incident.
F. ­ Due to the fact the various radio frequencies used in the systemmay be monitored by the
general public, only non-classified information may be passed over the LARTCS. Any
confidential or classified communications shall be made through other secure means.
G. The LARTCS may be activated or used for emergency joint agency incidents. However, it may
also be used for planned joint agency tactical operations, large public events, joint training
exercises, and planned system testing. The type and priority of incidents are as follows:
Priority 1: Disaster and extreme emergency operations.
Priority 2: ­ Emergency or urgent operations involving imminent danger to the safety
or life and property.
Priority 3: ­ Special event control activities, generally of a pre-planned nature, and
generally involving joint participation of two or more agencies.
Priority 3a: ­ Drills, tests, and exercises.

These priorities conform to the State Office of Emergency Services (OES) CLEMARS mutual
aid plan. Priority 4 level communications (single agency secondary communications) are not
covered by this MOU, and are not to be used on the LARTCS.
H. ­ A request to participate in the LARTCS is not a request to transfer responsibility of an
incident.
I. ­ The LARTCS could be used for Homeland Security or other related incidents. It shall be the
policy of the LARTCS for the participants not to release the radio frequencies, CTCSS/CDCSS
codes, channel plan, and other information related to the system. No system information
shall be released to the media or other entities, public or private. Exception: anyone involved
with the direct maintenance or repair of the participating agency’s radio equipment. This
information shall be provided to service technicians on a “need to know” basis only. Failure to
safeguard the LARTCS information may be cause for suspension or cancellation of this MOU
with the offending agency.
Los Angeles Regional Tactical Communications System Memorandum of Understanding
10/28/2004
 Sample Agreements
333
PROCEDURES
As previously stated in this document, the LARTCS is intended for use when immediate
information will enhance the safety or effectiveness of personnel dealing with an incident. It is not
to be used to deliver mundane information. The LARTCS may be requested, if needed, to allow
voice communications between each agency’s command personnel dealing with the incident.
Specific procedures will be defined in the LARTCS Operations Manual.

MAINTENANCE
Each participating agency is responsible for the maintenance of the involved hardware and
software for their agency. All participating agencies shall be responsible for their own connection
maintenance costs, if any. The Los Angeles County Sheriff ’s Communications Bureau shall
maintain the infrastructure of the LARTCS.
It is understood that radio reprogramming and maintenance will be required on an ongoing basis,
and system configuration changes will occur as the system grows. Participating agencies agree to
promptly reprogram their radio equipment as necessary, in order to maintain continuity of the
system.

For uniformity of identification in radio displays, radio frequencies in each band will be labeled as
specified in the LARTCS Operations Manual.

CONTROL
A. ­ There is an Executive Committee representing all participating agencies.
B. ­ The Commander of the Los Angeles County Sheriff ’s Department, Communications and
Fleet Management Bureau, will assume the duties of System Coordinator for the LARTCS.
The System Coordinator will coordinate and maintain copies of original Memorandums
of Understanding for this system and the associated communications agreements for the
LARTCS. The System Coordinator can be reached at Communications and Fleet Management
Bureau, 1277 North Eastern Avenue, Los Angeles 90063. (323) 267-2501.
C. ­ The System Coordinator will forward any complaints, concerns, or proposed changes to the
Executive Committee, for review and appropriate action.

AGREEMENT OF PUBLIC SAFETY AGENCY

Any Local, State, Federal, or Military agency may participate in the LARTCS by signature of
agreement by the department head or their designee, on this MOU. The System Coordinator will
notify all other participating agencies of any new member agencies.

Los Angeles Regional Tactical Communications System Memorandum of Understanding

10/28/2004
33 Appendix A

REVISIONS
This MOU may be revised or amended at any time by mutual agreement of participating agencies.
Any participating agency may terminate their participation by giving written notice to the
System Coordinator. The System Coordinator will notify all other participating agencies of the
withdrawal. ­

The agrees to this Memorandum

AGENCY

Of Understanding, and will conform to its policies and procedures.

DEPARTMENT HEAD SIGNATURE TITLE DATE

PRINT DEPARTMENT HEAD NAME

DESIGNEE SIGNATURE

PRINT DESIGNEE NAME

AGENCY ADDRESS TELEPHONE

AGENCY 24 hour contact (duty agent/response/dispatch) TELEPHONE E-MAIL ADDRESS

AGENCY 24 hour technical contact TELEPHONE E-MAIL ADDRESS

Los Angeles Regional Tactical Communications System Memorandum of Understanding

10/28/2004
 Sample Agreements
33
New Orleans
Maritime Intercommunications Committee
Operational Guidelines
Operational Guidelines

Rev. 8/24/03

NEW ORLEANS MARITIME

INTERCOMMUNICATIONS COMMITTEE (NOMIC)

Definition The New Orleans Maritime Intercommunications Committee (NOMIC) is a

collaboration of local, state and federal agencies working in concert to build a
seamless interoperability communications network linking port control and first
response agencies.

Purpose The purpose of this committee is to:

♦Provide rapid and reliable means by which to exercise command, control
and coordination of mobile assets between participating agencies.
♦Identify roles and responsibilities of those participating agencies to
guarantee continued success of the program within the region.
♦Insure participating agencies are aware of the capabilities, limitations and
equipment maintenance responsibility of the network.

Controlling a) NOMIC shall act as the sole controlling authority for the program and provide
authority
updated information to all agency participants as changes dictate. Furthermore
the committee shall coordinate necessary upgrades or repairs with each
participating agency.
b) The New Orleans Fire Department communications facility shall house the
ACU-1000 audio matrix switch and act as the primary Network Control Station
(NECOS) executing requested patches as necessary.
c) Where situations preclude the primary NECOS from performing requested
functions, U.S. Coast Guard Group New Orleans shall act as secondary
NECOS.

Policy Interoperability telecommunications patches shall be conducted in accordance

with;
♦This Operational Guideline
♦International Telecommunication Union (ITU) regulations
♦Federal Communications Commission (FCC) regulations
♦Other instructions and directives issued by proper authority and so
distributed by NOMIC.
33 Appendix A

Operational Guidelines

Inter­ This list illustrates the connectivity of the original Interoperability

operability
Communications System.
COMM-SYS
New Orleans Fire Dept. New Orleans Police Dept. U. S. Coast Guard
New Orleans EMS Jefferson Parish Sheriff Causeway Police
Crescent City Conn. LA. State Police Harbor Police Dept. Fed.
Bureau of Invst. U. S. Customs U. S. Border Patrl.
Drug Enforcement Adm.

OTHER SYSTEM PORTS BEING USED

VHS Progr., UHF Progr., 2 Teleco. Circuits, ITAC, ICALL, Remote

Agency a) Each participating agency shall be responsible for maintaining equipment

responsibility
provided and attached to the JPS Communications ACU-1000 audio switch.
b) Each participating agency shall provide continual administrative and
operational contact information to the NOMIC.
c) Continual operational oversight shall be provided to the NOMIC in an effort
to better refine these Operating Guidelines.

Operational Operational notification to the NOMIC is required for the following situations
Notification
involving communications equipment.

♦Modifications
♦Removal
♦Installations
♦Changes in capabilities
•Changing frequencies
•Other modifications which would alter the mode or method on which
the equipment was designed to operate.
Communications Equipment Includes (And Not limited To)
♦ACU-1000 Switch or equipment
♦Transmitters
♦Receivers
♦Transceivers
♦Telephones (both land line and cellular)
♦Other telecommunications equipment
♦Antennas and Cables
♦Accessories
 Sample Agreements
33
Operational Guidelines

Equipment
Failure Any agency detecting equipment failures, whether their own or another agency,
must notify the primary and secondary NECOS points of contacts via voice and
e-mail at the addresses provided in the POC enclosure to this document.

Step Action
1 Identify the failure
2 Notify NECOS units
3 Your Agency: Notify your appropriate maintenance entity
Other Agency: Notify point of contact per POC enclosure
4 Notify NECOS units of repair personnel & arrival time for access
and possible estimate time of repair (ETR).

Comms This interoperability solution is unclassified. Wherever possible, do not divulge

Security information sensitive to any mission.
(COMSEC)
These circuits offer no communications security. The general public and
possible hostile sources will be able to obtain information about multi-agency
operations easily by monitor these working frequencies. If joining a patch, any
agency may be recorded by another participating agency.

Testing &
Training The NOMIC shall coordinate all testing and training. Individual agency training
is encouraged but the NOMIC members should be notified in advance of non-
scheduled training between agencies.
Testing and training should be coordinated and scheduled by the NOMIC for all
participating agencies.
Testing and training will be scheduled during the last week of each month.

OPERATIONAL COMMUNICATIONS

Guidelines
a) NECOS shall never be requested to coordinate between the requesting and
receiving agencies.
b) A single agency’s participation on multiple patched circuits can only be
accomplished by having more than one radio attached to the ACU-1000 audio
matrix switch. Since all participating agencies only have one radio attached,
any agency can only participate in one interoperability patch at a time.

3 DRAFT
33 Appendix A

Operational Guidelines

Voice Call Agencies will always identify themselves by agency name and number.
Signs
Communications personnel shall provide mobile units with appropriate call
signs of other government agency units as obtained from other communications
watch personnel.

In example: NOPD vehicle 728 has requested communications with FBI 455.
NOPD will coordinate through FBI Comm. Center and request NOPD 728 to
call “FBI 455” on the designated working frequency.

Example: “ NOPD 728 to FBI 455 ”

Acronyms &
brevity codes To reduce confusion or misinterpretations between agencies, the use of
agency specific acronyms and brevity codes should not be used. Common
acronyms are acceptable if it is reasonably sure definitions are universal from
agency to agency (i.e. roger for yes or affirmative). Use clear text when
possible.

System
Purpose “Official Use Only” Special incidents. Not to be used as a “talk channel”.

ACU-1000 The audio switch used to allow interoperability between agencies with
disparate radio systems.
Incident
Commander (I/C) The individual directly responsible for command and control of any given
incident.

NOMIC Patch: The joining of one agency’s radio system to another agency’s radio system,
using the ACU-1000.
Requesting
Agent The individual(s) or agency requesting to have their communications channel
added to an in-progress incidents communications path.
Request for
NOMIC Patch: This is made by individual or agency wishing to be added into the
communications. The request is made to the incident commander.
Authority to
Patch: Authority to add any agency to an existing incident communications is granted
to the Incident Commander.
 Sample Agreements
339
Standard Operating Procedure

Request for Once an agent or agency has been relieved and no longer wishes to be part of
Release the Incident Communications Path, the agent or agency will notify NECOS to
remove his/her agency from the patch.

Contact
Person to The I/C shall contact the NECOS to authorize NOMIC patches. The I/C has the
Initiate a authority to request that any agency be removed from a particular Incident
Patch: Communications Path.

Authority of an The I/C is the individual directly responsible for command and control of any
Incident given incident. The I/C will authorize any interoperability patches as needed to
effectively command and control a given incident.

Authority to The authority to add any agency to an existing incident communications is

add Agency granted to the I/C or his designee.
to Patch

Request for The agency requesting to be patched into an ongoing incident should contact
Inclusion into the I/C for authorization. The I/C should be contacted by contacting the I/C’s
a Patch communications center. The I/C should send his request through his
communications center. The requesting agency shall notify their dispatch of the
intended patch and obtain clearance from their agency for the patch.

Contact Point
for NECOS The contact point to establish patches within the New Orleans area is NECOS.
**REFER TO POC DOCUMENT FOR NAMES AND NUMBERS** A log will be
kept, with the following: Date, Time, and Agencies on a given patch, and I/C’s
name and agency.

Release from
a NOMIC The agency requiring release from the NOMIC patch should contact the
Patch NECOS upon conclusion of that agency’s participation in the incident. The I/C
may elect to disengage any agency he deems appropriate during the incident.
NECOS will log who requested the release and the date and time of the
release. Any agency participating in a patch may choose at any time to stop
participating in a patch without any additional authority. If a participating
agency wants to be released from a patch, the agency should notify the I/C.
Pre-planning
of likely Any agency participating in the MOU can request a pre-plan of a likely incident.
Incidents This agency should identify who the agency would like to be able to
communicate with during a given incident and those patches can be preset.
The preplanned patches would then be authorized by the I/C of an incident.
Each agency in the preplan would authorize his agency’s participation.
 Appendix B:
SOP Example
 Appendix B:
SOP Example
Courtesy of the Metropolitan Emergency Services Board, St. Paul, Minnesota.
http://www.metro9-1-1board-mn.org

INTERIM INTERIM

800 MHz Trunked Regional Public Safety Radio System

Standards, Protocols, Procedures

Document Section: 3 - Interoperability Guidelines TOC Recommended

Sub-Section: 3.1f
Procedure Title: Use of Regional 800 MHz to Metro Date: 5/24/01
Emergency Interoperability
Date Established: 2/12/01
Replaces Document Dated: 5/14/01 MESB Approval
Date Revised: 5/30/03 Date: 06/06/03

1. Purpose or Objective:
Establish procedures for use of patched regional 800 MHz to Metro Emergency UHF (MET-
EMRG-UHF) channel interoperability radio facilities for interagency communications when
coordination is required between law enforcement users of UHF radio systems and law
enforcement users of the regional 800 MHz trunked radio system.

2. Technical Background:
ƒ Capabilities
A UHF radio system covering the City of St. Paul, the University of Minnesota and Minneapolis-St.
Paul International Airport is available for use by personnel of government entities using UHF radio
systems that need interagency communications to coordinate activity with personnel of entities that
use the new regional 800 MHz trunked radio system. This UHF interoperability radio system
includes an UHF infrastructure on the State of Minnesota Metro Emergency UHF radio channel that
can be hard patched to a regional 800 MHz trunked radio system talk group.

ƒ Constraints
One regional 800 MHz talk group can only be in one patch.

3. Operational Context:
The patch between the Metro Emergency UHF channel and the corresponding regional
800 MHz radio system talk group should only be used when there is a significant need for
communications to support coordinated activities between personnel of entities that are on UHF
radio systems and personnel of entities that are users of the regional 800 MHz radio system.

The Metro Emergency channel and the associated patched regional 800 MHz talk group may be
used for short-term high intensity events, and for long-term extraordinary events.

3.1f Metro Emergency 1 Section 3.1f

3 Appendix B

INTERIM INTERIM

The Metro Emergency UHF channel patched to a regional 800 MHz talk group should be used
only if other suitable means for interagency communicating are unavailable or if the other
available means for coordination communications are insufficient for the needs. Other means
may include use of radio to radio cross band repeaters (See Interoperability Guidelines
Subsection 3.3c) between tactical channels at the scene, and radio console soft patching of a
preauthorized agency UHF tactical channel to a RF control station on a talk group on the
regional 800 MHz radio system (See Interoperability Guidelines Subsection 3.3b).

4. Recommended Protocol/ Standard:

It is recommended that there be a regional 800 MHz pool talk group, METEMERG, hard
patched to the Metro Emergency UHF channel.

The regional 800 MHz METEMERG talk group shall not be part of any multi-group.

No personnel in any dispatch center shall soft patch the UHF metro emergency channel to a RF
control station on a regional 800 MHz trunked talk group (See Section 3.3b RF Control Stations
and Portables).

It is recommended that the regional 800 MHz METEMERG talk group be included in scan lists
of all law enforcement radios on the regional 800 MHz radio system.

The METEMERG talk group on the regional 800 MHz radio system shall be recorded (See
Section 3.1h).

TG Requirements For Whom?

Highly Recommended None
Recommended Metro Law Enforcement
Optional None
Not Allowed None

Cross Patch Standard YES/NO To Talk Group(s)

Soft Patch No NA
Hard Patch Yes MET-EMRG-UHF

5. Recommended Procedure:
Most of the time, an event that requires interagency coordination will begin on a main dispatch radio
channel of one of the public safety dispatch centers. When it becomes apparent that interagency
coordination of law enforcement agencies will be needed (and possibly fire and EMS), and
coordinating participants are on UHF and on the regional 800 MHz systems, a dispatch center
operator should advise the UHF radio users to switch to the Metro Emergency UHF channel.

3.1f Metro Emergency 2 Section 3.1f

 SOP Example
3
INTERIM INTERIM

Dispatch center operator support, and the decision to use the Metro Emergency UHF channel patch
to the METEMERG talk group, shall be performed by a dispatch center operator in the center
responsible for the agency that started the event.

6. Management:
The dispatch center managers for agencies on the regional 800 MHz radio system shall insure
that there is a procedure for use of the Metro Emergency UHF channel to METEMERG talk
group patch in the dispatch center for which they are responsible.

Dispatch center operators shall receive initial and continuing training on the use of this
procedure.

Responsibility for monitoring performance and for modifying this procedure shall be a function
of the Technical Operations Committee of the Metropolitan Emergency Services Board.

The development of and the management of statewide rules for use of the Metro Emergency
UHF radio channel shall continue to be the responsibility of the Metro Emergency Channel
Users Committee. All users of the Metro Emergency Channel and the regional 800 MHz radio
system METEMERG talk group shall comply with the Metro Emergency Channel operation
rules; and with the MINSEF rules when the Metro Emergency channel is patched to the
MINSEF VHF frequency.

3.1f Metro Emergency 3 Section 3.1f

 Appendix C:
ICS
Communications
Position Duties
 Appendix C:
ICS Communications
Position Duties

The National Wildfire Coordinating Group (NWCG) has created task books formalizing
responsibilities of Incident Command System (ICS) positions. Though NWCG task books
serve to prepare individuals for roles during wildfire response, they also define responsibilities
applicable to ICS-oriented response more generally. They provide the most comprehensive
list of duties available at this time for describing communications responsibilities during
weapons of mass destruction incidents. Included below are those specific to these
communications functions.1

1
The following has been adapted from current editions of National Wildfire Coordinating Group task books.
Available at http://www.nwcg.gov/pms/taskbook/logistics/logistic.htm.
30 Appendix C

Communications Unit Leader (COML)

1. ­ Receive Incident Action Plan (IAP). Determine support needs to meet IAP.
2. ­ Determine requirements for communications to be established and place the initial order.
Using information obtained from IAP, section briefings, and agency briefings, immediately
order, using proper procedures, the supplies, materials, and equipment necessary to support
projected incident size.
3. ­ Participate in incident planning meetings as the technical expert for communications needs.
– ­ Determine the feasibility of providing the required communications support.
– ­ Provide operational and technical information on communications equipment
available for the incident.
– ­ Provide operational and technical information on communications equipment
capabilities and restrictions.
4. ­ Design communications systems to meet incident operational needs.
– ­ Determine additional resource needs and order necessary equipment and personnel.
– ­ Prepare Incident Communications Plan, ICS Form 205.
– ­ Request any additional communications vendor services; e.g., telephone, satellite
communications, microwave, and identify costs associated with equipment.
– ­ Coordinate, through the chain of command, the locations for equipment to be
installed; e.g., repeaters, telephone lines.
– ­ Provide communications support for internal and external data operations.
– ­ Coordinate frequencies in use following established procedures.
5. ­ Install communications equipment.
– ­ Obtain equipment from supply unit.
– ­ Install and test all components of the communications equipment to ensure the
incident’s systems are operational.
– ­ Develop installation priorities, while adhering to safety standards regarding
communications needs of tactical personnel; i.e., operations before logistics.
6. ­ Assign communications equipment.
– ­ Identify kinds and numbers of communications equipment to be distributed to
specific units according to the communications plan.
– ­ Provide resources and unit leaders with appropriate equipment based on the
communications plan.
– ­ Maintain equipment inventory to provide accountability.
7. ­ Establish Incident Communications Center (ICC).
– ­ Coordinate location of ICC with Facilities Unit Leader.
– ­ Locate ICC close to the incident command post and away from high traffic areas and
noise.
 ICS Communications Position Duties
31
– ­ Locate ICC away from radio frequency and electronic noise.
– ­ Verify ETA of communications personnel and establish assignments based on
incident requirements. Set schedules around operations requirements.
– ­ Obtain necessary supplies for ICC to function properly.
8. ­ Manage operations of the ICC.
– ­ Document radio/telephone activities on appropriate forms.
– ­ Set up filing system for ICC documentation.
– ­ Direct radio/telephone traffic to proper destinations.
– ­ Establish notification procedures for emergency messages.
– ­ Identify system problems, both technical and operational, and determine
appropriate solutions.
– ­ Follow established routing procedures for messages.
9. ­ Coordinate frequencies, activities, and resources with the communications coordinator for
other incidents in the region, if any.
– ­ Identify communications equipment and personnel that are excess to incident needs
and demobilize if appropriate.
– ­ Identify resources as to type/qualifications, quantity, and location.
10. ­Notify agencies; e.g., state, county, or local on adjacent incident(s) of system design and
frequency allocations.
11. ­Initiate and maintain accurate records of all communications equipment.
– ­ Initiate and maintain accountability system for issuing radio resources.
– ­ Document geographic locations of equipment and transfer this information to local
maps (latitude/longitude, legal).
– ­ Keep records for local and national resources to ensure return to proper locations.
12. ­Perform operational tests of communications systems throughout the duration of the
incident.
– ­ Identify and take necessary action to accomplish minor field repair or place orders
for replacement of equipment.
– ­ Plan for battery replacement.
– ­ Act decisively to minimize interruptions in system operation.
13. ­Interact and coordinate with appropriate unit leaders and operations personnel.
– ­ Coordinate with medical unit for medical evacuation plan.
– ­ Coordinate with air operations for frequency needs.
– ­ Participate in planning meetings and briefings.
– ­ Coordinate with operations regarding system coverage and needs.
32 Appendix C

Incident Communications Technician (COMT)

1. ­ Obtain incident information needed to accomplish tasks from the Communications Unit
Leader (COML), including the Incident Action Plan and maps.
2. ­ Assist the COML in designing communications system to meet incident operational needs.
– ­ Determine resource needs.
– ­ Prepare and/or order necessary equipment and personnel through supply unit.
– ­ Assist the COML with requesting any additional communications vendor services;
e.g., telephone, satellite communications, microwave, and identify cost associated
with this type of equipment.
– ­ Identify locations for equipment to be installed; e.g., repeaters, telephone lines.
– ­ Provide communications support for data operations and imagery.
3. ­ Install communications equipment.
– ­ Obtain equipment from supply unit.
– ­ Install and test all components of the communications equipment to ensure the
incident’s systems are operational.
– ­ Clone or program radios.
– ­ In the absence of or in conjunction with the COML, establish installation priorities,
while adhering to safety standards regarding communications needs of tactical
personnel; i.e., operations before logistics.
4. ­ Assign communications equipment.
– ­ Identify kinds and numbers of communications equipment to be distributed to
specific units according to the Incident Communications Plan (ICS Form 205).
– ­ Provide resources and unit leaders with appropriate equipment based on the Incident
Communications Plan.
5. ­ Identify any operational restrictions to the Incident Communications Center Manager.
6. ­ Initiate and maintain accurate records of all communications equipment.
– ­ Initiate and maintain an accountability system for issuing radio resources.
– ­ Document geographic locations of equipment and transfer this information to local
maps (latitude/longitude, legal).
– ­ Keep records for local and national resources to ensure return to proper locations.
7. ­ Perform operational test of communications systems throughout the duration of the
incident.
– ­ Accomplish minor field repair and place orders for replacement of equipment.
– ­ Plan for battery replacement.
– ­ Act decisively to minimize interruptions in system operation.
 ICS Communications Position Duties
33
Incident Communications Center Manager (INCM)
1. ­ Obtain briefing from the Communications Unit Leader (COML).
– ­ Determine numbers of communications personnel ordered and on site.
– ­ Discuss “check out” procedures for communications equipment; e.g., radios.
– ­ Discuss the specifics of the Communications Plan, ICS Form 205.
– ­ Discuss the current organization of the incident; e.g., section chiefs, unit leaders,
operations staff, etc.
– ­ Discuss how messages from the incident area are handled; e.g., orders from the line,
emergency, etc.
– ­ Discuss the Medical Plan, ICS Form 206, and procedures.
– ­ Obtain a copy of the Incident Action Plan and other informational documents from
COML; e.g., maps.
– ­ Discuss unit planning meetings and operational period briefings.
– ­ Follow parameters outlined by COML for physical establishment of the Incident
Communications Center (ICC).
2. ­ Establish the ICC.
– ­ Coordinate, with the Facilities Unit Leader, the location of the ICC.
– ­ Ensure the orderly arrangement of supplies and equipment.
– ­ Request sufficient staff to meet the needs of the communications center.
– ­ Order supplies, through the supply unit, to set up and operate the ICC.
– ­ Acquire forms; e.g., ICS Form 210 (Status Change Card), ICS Form 213 (General
Message), ICS Form 214 (Unit Log), Telephone Logs, Radio Logs.
3. ­ Assist the COML with the following duties:
– ­ Maintain equipment accountability and inventories.
– ­ Maintain or, if directed, establish issue accountability system and issue radio
resources.
– ­ Maintain or, if directed, establish an inventory accountability system.
– ­ Ensure that issued equipment is operational (includes battery replacement).
– ­ Tag nonfunctioning equipment upon return.
– ­ Order needed equipment (e.g., batteries), if directed.
– ­ Clone radios.
– ­ Assist user in interpreting the Communications Plan.
– ­ Recognize basic communications network malfunctions (low battery on repeater,
intermittent repeater transmissions, dead spots) and alert COML.
– ­ Fill out lost radio reports.
– ­ Implement a document filing system.
3 Appendix C

– ­ Ensure information regarding communications restrictions or coverage limitations is

disseminated to operations and ICC personnel.
4. ­ Supervise and manage the ICC.
– ­ Carry out established policies, priorities, and operational procedures.
– ­ Provide for safety and general welfare of ICC personnel.
– ­ Directly supervise each Radio Operator (RADO) position; e.g., the use of radio/
telephone logs, proper radio procedures, and protocols.
– ­ Brief subordinate(s) and relief personnel. Direct communication is critical.
Information is to be given periodically and with every change from planned work.
– ­ Maintain an incident message board.
– ­ Develop and maintain an incident telephone directory.
– ­ Plan and implement an operational period staffing schedule.
– ­ Ensure that proper radio and documentation procedures are followed in the event of
an emergency situation.

Radio Operator (RADO)

1. ­ Obtain briefing from the Incident Communications Center Manager (INCM).
– ­ Learn location of units at the incident base camp and Incident Command Post (ICP).
– ­ Understand time of first work period and discuss work schedule.
– ­ Discuss specifics of the Incident Action Plan (IAP) for the current operational period,
particularly ICS 204(s), Assignment List.
– ­ Discuss specifics of the ICS 203, Organization Assignment List.
– ­ Discuss specifics of the ICS 205, Incident Radio Communication Plan.
– ­ Discuss specifics of the ICS 206, Medical Plan and medical evacuation process.
– ­ Discuss allocation of phones to the units and existence of a phone directory.
– ­ Discuss procedure for processing supply orders from the operations area.
– ­ Discuss presence/need for message board.
2. ­ Perform duties in accordance with incident communications unit structure.
– ­ Understand communications unit jobs/positions.
– ­ Understand Incident Command System organizational structure/jobs/positions.
3. ­ Perform duties with constructive attitude and skill.
– ­ Maintain professional demeanor.
– ­ Remain flexible in the face of changing priorities.
– ­ Cooperate with other RADOs.
– ­ Process information as directed.
 ICS Communications Position Duties
3
– ­ Use standard terminology, symbols, designators, and acronyms.
– ­ Continue involvement in decisions.
4. ­ Effectively transfer information verbally or in writing.
– ­ Use correct radio/telephone protocols.
– ­ Communicate with other RADOs and incident personnel.
– ­ Write legibly.
5. ­ Participate in communications unit/incident communications center manager meetings.
– ­ Provide information on radio equipment performance.
– ­ Discuss any information flow problems.
6. ­ Demonstrate familiarity with communications equipment, procedures, and basic functions/
capabilities.
– ­ Hand-held, portable, multi-channel radios.
– ­ Radio check-out and check-in procedures.
– ­ Respond with proper frequency when requested.
– ­ Use accountability forms for radio check-out and check-in.
– ­ Procedure for battery check and issuing new batteries.
– ­ Check-out and check-in of appropriate radio accessories.
– ­ Remote phone system (base to line, base to camp, base to helibase).
– ­ Cellular phone (cell coverage, battery recharging).
– ­ Facsimile machine.
– ­ Public address system (paging).
7. ­ ICS 213 - General Message.
– ­ Use the ICS 213 in appropriate situations.
– ­ Correctly demonstrate how to fill out the form.
– ­ Correctly demonstrate how to route the form.
– ­ Complete the follow-up process to close the loop on requests.
8. ­ Correctly demonstrate how to fill out and process selected ICS and NFES forms.
– ­ ICS 210 - Status Change.
– ­ Radio Station Log, NFES 0370.
– ­ Telephone Call Register, NFES 0816.
9. ­ Correctly process and file communications paperwork for documentation purposes.
– ­ Radio logs.
– ­ Telephone logs.
– ­ Incident Action Plans.
3 Appendix C

– ­ ICS 210 - Status Change.

– ­ ICS 213 - General Message.
– ­ ICS 214 - Unit Log.
– ­ Radio check-out information.
– ­ Other communications-related paperwork.
10. ­Respond with appropriate communications to emergency situations.
– ­ Medical transport request.
– ­ Medical evacuation request.
– ­ Aircraft emergency.
– ­ Evacuation.
– ­ Search and Rescue.
– ­ Fatality.
11. ­Respond with appropriate communications to routine requests/information.
– ­ Supply orders from the operations area, camps, helibase, etc.
– ­ Locating personnel at the incident base or in the field.
– ­ Routing “camp net” and “operations net” traffic.
– ­ Incoming phone calls to base/camp(s).
12. ­Transition with replacement personnel.
– ­ Brief replacement on major events of the concluding operational period, unusual
situations or conditions, and information required by the communications unit
leader (COML).
– ­ Provide written notes about items that need follow-up during the upcoming
operational period.
 Appendix D:
Interoperability
Self-Assessment
Scorecard
 Appendix D:
Interoperability
Self-Assessment Scorecard

In 2005, the Department of Homeland Security’s Project SAFECOM, an

electronic government initiative of the President, created a process to assess
communications interoperability across agencies and jurisdictions. The
following five elements of interoperability and 13 related subelements are used.

Interoperability Continuum Element Baseline Assessment Subelement

leadership
Decision-making Groups
Governance Agreements
Interoperability Funding
Strategic Planning
Policy, Practices, and Procedures
Standard Operating Procedures
Command and Control
Approaches
Technology Implementation
maintenance and Support
Operator Training
Training and Exercises
Exercises
Usage Frequency of Use and Familiarity

The process presents one or more questions about the element with sample
response statements corresponding to early, moderate, full, and advanced stages
of development. It further asks respondents to indicate the stage of development
across disciplines, political entities, and levels of government, as appropriate.
30 Appendix D

In the following pages, a reduced version of the SAFECOM assessment is presented as

a self-assessment tool. Its appropriate use is to create a snapshot of capabilities along
the 13 subelements. This snapshot is useful for depicting and communicating the
level of interoperability across the agency, group, or initiative. Interoperability across
disciplines, jurisdictions, and levels of government by each of the subelements is left
as a single measure to simplify use of the results.

In completing the assessment, consider all three aspects and answer each question for
the predominating influence. For example, if regular, National Incident Management
System NIMS-based exercises are planned and conducted with full participation
across disciplines, but not between jurisdictions, choose a stage of development best
reflecting the impact of that aspect. Use the scorecard below while stepping through
each of the subelement descriptions to record choices in one spot.

Chapter 15, Measuring Interoperability, provides further suggestions for using the
Self-Assessment Scorecard.

Stage of Development
Element Subelement Early moderate Full Advanced
leadership
Decision-making
Groups
Governance Agreements
Interoperability
Funding
Strategic Planning
Policy, Practices,
Standard and Procedures
Operating
Procedures Command and
Control
Approaches
Implementation
Technology
maintenance and
Support

Training and Operator Training

Exercises Exercises
Frequency of Use
Usage
and Familiarity

Self-Assessment Scorecard
 Interoperability Self-Assessment Scorecard
31
Governance: Leadership
Consider the questions to the left
Public Safety Leadership and how this measure varies across
How would you best describe the fiscal and organizations, then choose one of
political support that public safety leaders provide these stages of development
to improve your organization’s interoperability?
- The leadership within your public safety Early Development
organization may understand the importance Government leaders are
of interoperability and its role, but has not yet aware of interoperability
taken any political or fiscal action needs to support
- The leadership within your public safety protection of citizens and
safety of first responders
organization has begun to seek political or
fiscal support for interoperability
- The leadership within your public safety Moderate Development
organization pursues multiple avenues of
political and fiscal support for interoperability Government leaders
and makes it an organization priority understand the importance
of interoperability and
- The leadership within your public safety provide some political and
organization has successfully ingrained fiscal support
interoperability as an organizational value
such that future leaders are expected to be
champions for interoperability support Full Development
Government leaders
demonstrate that
Political Leadership interoperability is a
How would you best describe the fiscal and political and fiscal priority
political influence that political leaders have and begin to coordinate
across jurisdictions
on the progress of public safety organizations’
interoperability?
- Political leader(s) have not yet provided Advanced Development
political or fiscal support for interoperability
Government leaders
- Political leader(s) have begun to provide serve as interoperability
political support (e.g., attending discussions advocates and act to
and/or summits on interoperability, including ensure long-term political
it on the platform) or fiscal support and fiscal support
- Political leader(s) have demonstrated that
interoperability is a political and fiscal priority
by taking concrete actions (e.g., establishing
funding mechanisms, regional or statewide
planning efforts) to improve interoperability
- Political leader(s) act to ensure that
interoperability remains a priority across
future administrations (e.g., legislation,
dedicated appropriations)
32 Appendix D

Governance: Decision-Making Groups

Consider the questions to the left
Decision-Making Groups and how this measure varies across
How would you best describe your organization’s organizations, then choose one of
involvement in groups of public safety these stages of development
practitioners and leaders that apply operational,
technical, and management expertise to remove Early Development
barriers to interoperability?
no interagency
- your organization may or may not participate partnerships or forums
in informal interorganization partnership(s) in place
or forum(s)
- your organization participates in a mix
of informal and formal partnership(s) or
forum(s). A formal partnership has a
Moderate Development
published agreement that designates the
group’s authority Informal partnerships
- your organization participates exclusively or forums to address
common interests,
in formal interoperability planning and
operations, and technology
governing bodies (e.g., bodies with defined
missions, responsibilities, and authorities)
- your organization’s formal groups proactively
recruit new participants, including Full Development
responders beyond first responders Formal interoperability
planning and governing
bodies with defined
Does your key interoperability decision-making missions, responsibilities,
group: and authorities in place
- meet regularly?
- Have consistent membership?
- Have governance rules? Advanced Development
- Disseminate information to all members? Proactive recruiting of new
- Disseminate information to public safety participants to include
leaders (as appropriate)? cross-governmental
membership and type of
- Disseminate information to political leaders responder
(as appropriate)?
- Have the capacity to make recommendations
concerning interoperability?
- Have the capacity to implement its own
decisions?
 Interoperability Self-Assessment Scorecard
33
Governance: Agreements
Consider the questions to the left
Agreements and how this measure varies across
How would you best describe the informal organizations, then choose one of
practices and formal documentation that establish these stages of development
agreed-upon means to ensure interoperability?
- There may be informal, undocumented Early Development
agreements that enable interoperability in Unofficial, informal
practice agreements in practice
- Published agreements (e.g., mOU/mOA/
mAA, Ordinance, Executive Order, IGA) are
enforced with some of the organizations with
whom you provide incident response
- Published agreements are enforced with all Moderate Development
of the organizations with whom you provide
incident response Some of the necessary
agreements (e.g., mOU/
- There are institutionalized processes to mOA/ mAA, Ordinance,
develop and review agreements at least every Executive Order, IGA, and
3 to 5 years, and after system upgrades legislation) in place to
and events that test your organization’s address multi-organization
capabilities communications

Full Development
All necessary agreements
(e.g., mOU/mOA/mAA,
Ordinance, Executive
Order, IGA, and
legislation) in place to
address multi-organization
communications

Advanced Development
Institutionalized processes
to develop and review
agreements at least
every 3-5 years and after
significant events and
upgrades
3 Appendix D

Governance: Interoperability Funding

Consider the questions to the left
Funding for Capital Investments and how this measure varies across
How would you best describe how well your organizations, then choose one of
funding meets needs for capital investments in these stages of development
interoperability?
- your organization either does not have Early Development
funding dedicated to interoperability capital limited and fragmented
investments (e.g., equipment and other one­ funding dedicated to
time costs), or some funds may be cobbled multi-organization
together communications
- your funding does not meet all requirements
for interoperability capital investments;
difficult allocation decisions may be required
Moderate Development
- your organization has funding for capital
investments such that interoperability long-Term planning
requirements can be met begins for partially
funded multi-organization
- your organization is working to ensure communications
funding of future interoperability capital
investments

Full Development
Funding for Operating Costs Acquisition of long­
How would you best describe how well your term funding for
funding meets needs for operating costs that multi-organization
support interoperability? communications

- your organization either has no funding

dedicated to operating costs (O&m, leases, Advanced Development
staffing), or some funds may be cobbled
together multiple organizations
and standing committees
- your organization has dedicated funding working to strategically
for operating costs in the current budget acquire and manage
cycle; source of funding beyond that may be sustained interoperability
undetermined and maintenance funding
- your organization has dedicated funding
beyond the current budget cycle for operating
costs
- your organization is working to ensure
funding for interoperability operating costs
beyond the time that current sources expire

Does your organization have joint interoperability

funding with other public safety disciplines,
political entities, and levels of government?
 Interoperability Self-Assessment Scorecard
3
Governance: Strategic Planning
Consider the questions to the left
Strategic Planning and how this measure varies across
How would you best describe the planning efforts organizations, then choose one of
to make decisions, take actions, and create these stages of development
processes that ensure interoperability?
- no interoperability strategic plan in place; Early Development
some preliminary planning may have begun no interoperability
- Strategic planning process in place and plan strategic plan or strategy
under development in place

- Strategic plan in place and accepted by all

participating organizations
- Strategic plans reviewed annually and after
system upgrades and events that test your Moderate Development
organization’s capabilities
Strategic planning process
in place and plan under
development

Full Development
Formal strategic plan in
place and accepted by all
participating stakeholders

Advanced Development
Institutionalized processes
to review strategic plans
on an annual basis and
after significant events or
upgrades
3 Appendix D

Standard Operating Procedures: Policies,

Practices, and Procedures Consider the questions to the left
and how this measure varies across
Policies, Practices, and Procedures organizations, then choose one of
How would you best describe the direction these stages of development
provided to first responders to implement
interoperable communications? Early Development
- Informal policies, practices, and procedures Informal policies,
may be in place to address interoperable practices, or procedures
communications with designated types of
responders; none are formal. “Formal” means
published and enforced
- Formal polices, practices, and procedures
are in place to ensure interoperable
Moderate Development
communications during planned and day­
to-day events (e.g., vehicle pursuit, multiple Some formal policies,
station response) with designated types of practices, or procedures
responders
- Formal policies, practices, and procedures
are in place to ensure interoperable
communications during emergency or out­
of-the-ordinary events (e.g., mass casualties, Full Development
flipped tanker that closed a major highway)
All necessary formal
with designated types of responders
policies, practices, and
- Processes exist to develop and annually procedures
review policies, practices, and procedures
for consistency across designated types of
responders
Advanced Development
Processes to develop and
regularly review policies,
practices, and procedures
for consistency across
participants
 Interoperability Self-Assessment Scorecard
3
Standard Operating Procedures: Command and
Control Consider the questions to the left
and how this measure varies across
Command and Control organizations, then choose one of
How would you best describe the direction these stages of development
provided to first responders to implement
interoperable communications? Early Development
- Informal command and control SOPs Some elements of formal
concerning interoperability may be in command and control
place; no formal policies. “Formal” means policies in practice
command and control policies are published
and enforced
- Formal command and control SOPs address
interoperability in planned and day-to-day
Moderate Development
events (e.g., vehicle pursuit, multiple station
response) for agencies with which you Formal command and
provide joint incident response control policies in practice,
but not consistent with
- Formal command and control SOPs
command and control
address interoperability during day-to-day, policies of all other
emergency, and out-of-the-ordinary events necessary organizations
(e.g., mass casualties, flipped tanker that
closes major highway) for agencies with
which you provide joint incident response
Full Development
- There is a review of interoperability command
and control policies annually and after events nImS-compliant
that test organization capabilities command and control
policies in practice
consistent with all
Are your agency’s interoperability command and necessary organizations
control policies NIMS-compliant?

Advanced Development
Annual review of
command and control
policies to assure
continued compliance with
nImS and evaluation of
command and control after
significant events
3 Appendix D

Technology: Approaches
Consider the questions to the left
Approaches and how this measure varies across
How would you best describe the solutions first organizations, then choose one of
responders employ for interoperability? these stages of development
- Portable, mobile, or temporary solutions
developed in the field by first responders Early Development
using resources/equipment on hand (e.g., Implementation of
radio swaps) portable, mobile, or
- Planned solution(s) are readily deployable, temporary solutions (ad
but do not employ mutually accepted hoc or COTS)
equipment standards (e.g., communications
vehicle)
- Permanent infrastructure-based solution(s) Moderate Development
using mutually accepted equipment
standards (e.g., shared system) Communications
requirements exceed ad
- Continuous technical improvements are hoc capabilities, steps
planned that will develop networks that are being taken toward
completely transparent to responders permanent solutions

Full Development
Permanent infrastructure-
based solutions using
mutually accepted
standards

Advanced Development
Strategic, coordinated
communications plans in
place to guide technical
improvements that lead to
seamless networks
 Interoperability Self-Assessment Scorecard
39
Technology: Implementation
Consider the questions to the left
Implementation and how this measure varies across
How would you best describe the methods used by organizations, then choose one of
first responders to achieve interoperability? these stages of development
- no consistent approach to solutions; first
responders must improvise a solution Early Development
- Planned solution(s) require human Ad hoc solutions
intervention by someone other than first
responders (e.g., must get patch through
dispatcher)
- Solution(s) available to all first responders as
authorized, without any intervention
- Piloting of advanced solution(s), Moderate Development
technologies, and processes
Planned solutions that
require human intervention

Full Development
Solutions available 24x7
without any intervention

Advanced Development
research and testing
of advanced solutions,
technologies, and
processes
30 Appendix D

Technology: Maintenance and Support

Consider the questions to the left
Maintenance and Support and how this measure varies across
How would you best describe the frequency and organizations, then choose one of
approach taken in communications equipment these stages of development
care, maintenance, repair, and systems lifecycle
planning? Early Development
- There is either no maintenance or no Ad hoc maintenance and
consistent approach for preventive equipment support
maintenance and interoperability equipment
repair, replacement
- Plans guarantee minimum level of reliability
and availability
- Plans guarantee capability to interoperate Moderate Development
24x7
Plans developed plus staff
- near-term and long-term lifecycle planning and funding available to
(e.g., planning, acquisition, implementation, address maintenance
maintenance) of next solution and equipment support
requirements

Full Development
multiple organizations’
staff share maintenance
and equipment support
roles for jointly funded
infrastructure through
formal agreements

Advanced Development
near-term and long-term
system lifecycle planning
(e.g., planning, acquisition,
implementation) and
staffing
 Interoperability Self-Assessment Scorecard
31
Training and Exercises: Operator Training
Consider the questions to the left
Training for Support Personnel and how this measure varies across
How would you best describe the nature of the organizations, then choose one of
education given to support personnel regarding these stages of development
interoperability?
- Support personnel (e.g., administrators, Early Development
dispatchers, maintenance personnel) may no formal training in
have some awareness of interoperability, and achieving interoperability
some may have received informal education
or training. Informal training has no lesson
plans, may be on-the-job, and provides no
assessment of student performance/change
of behavior
Moderate Development
- Some support personnel have received
formal interoperability training (uses a Some organizations
lesson plan in a classroom or OJT setting, train regularly in using
and includes an assessment of student equipment and applying
performance/change of behavior either at the policies, practices, and
procedures
time of training or shortly thereafter)
- Substantially all support personnel have
received formal interoperability training (as
defined above)
Full Development
- Organizations evaluate after-action reports,
along with the changing operational All necessary organizations
environment, to adapt future training to participate in planned,
address gaps and needs regular training using
equipment, policies,
practices, and procedures,
Training for Field Personnel command and control, and
nImS
How would you best describe the nature of the
education given to field personnel regarding
interoperability? Advanced Development
- Field personnel (e.g., law enforcement Organizations evaluate
officers, firefighters, EmTs) may have some training after-action
awareness of interoperability, and some may reports and the changing
have received informal education or training. operational environment
Informal training has no lesson plans, may be to adapt future training to
on-the-job, and provides no assessment of address gaps and needs
student performance/change of behavior
- Some field personnel have received formal
interoperability training (uses a lesson plan in a classroom or OJT setting, and includes an
assessment of student performance/change of behavior either at the time of training or shortly
thereafter)
- Substantially all field personnel have received formal interoperability training (as defined
above)
- Organizations evaluate after-action reports, along with the changing operational environment,
to adapt future training to address gaps and needs
32 Appendix D

Training and Exercises: Exercises

Consider the questions to the left
Exercises and how this measure varies across
How would you best describe the simulated or organizations, then choose one of
in-field activities conducted to prepare responders these stages of development
for situations that would require interoperable
communications? Early Development
- your organization may have participated Some command and
in planning workshops oriented toward staff across organizations
interoperability participate in workshops
- your organization participates in tabletop oriented to interoperability
exercises, which incorporate interoperable
communications, on a regular cycle
- your organization participates in fully Moderate Development
functional operational exercises, including
interoperable communications, on a regular All necessary organizations
cycle participate in tabletop
exercises; including nImS;
- Organizations evaluate after-action reports planned and on a regular
from fully functional exercises and in the cycle
changing operational environment to adapt
exercises to address gaps and operational
needs Full Development
All necessary organizations
Are your agency’s interoperability exercises participate in fully-
functional operational
National Incident Management System (NIMS)­
exercises, including nImS,
compliant? on a planned and regular
cycle

Advanced Development
Organizations evaluate
after-action reports from
the exercises and the
changing operational
environment to adapt
exercises to address gaps
and operational needs
 Interoperability Self-Assessment Scorecard
33
Usage: Frequency of Use and Familiarity
Consider the questions to the left
Frequency of Use and Familiarity and how this measure varies across
How would you best describe how frequently and organizations, then choose one of
easily your first responders use interoperability? these stages of development
- First responders seldom use interoperability
solutions, except for events that can be Early Development
planned ahead of time First responders seldom
- First responders use solutions regularly for use solutions unless
emergency events and to a limited extent for advanced planning is
day-to-day communications possible (e.g., special
event)
- First responders use solutions regularly
and easily for all day-to-day, task force, and
mutual aid events Moderate Development
- regular use of completely transparent
First responders use
solutions has expanded to all potentially solutions regularly for
involved responders emergency events, and in a
limited fashion for day-to­
day communications

Full Development
First responders use
solutions regularly and
easily for all day-to-day,
task force, and mutual aid
events

Advanced Development
regular use of seamless
solutions has expanded to
include state, federal, and
private responders
Appendix E:
Bibliography
and
Resources
 Appendix E:
Bibliography and Resources

ABI Research press release, “Mesh Network Market May See Tenfold Growth in Five Years,”
November 16, 2005. See http://www.abiresearch.com/abiprdisplay.jsp?pressid=556.

Advanced Generation of Interoperability for Law Enforcement, Operational Test Bed—

Alexandria (OTB-A) Communications Interoperability Gateway Subsystem Operational Test
Document, Report No. TE-00-04, 23 (Rome, New York: National Law Enforcement and
Corrections Technology Center-Northeast, July 23, 2001). See http://www.ojp.usdoj.gov/
nij/topics/commtech/Gateway_Subsystem_Op_Test.pdf.

Arlington County, Virginia, After-Action Report on the Response to the September 11 Terrorist
Attack on the Pentagon, prepared by Titan Systems Corp. (Arlington, Virginia: no publication
date). See http://www.arlingtonva.us/departments/Fire/edu/about/docs/after_
report.pdf.

Cisco Systems, Inc., white paper, “Wireless LANS – Total Cost of Ownership,” 2004. See
http://www.cisco.com/application/pdf/en/us/guest/products/ps4076/c1244/
cdccont_0900aecd801bb7d4.pdf.

Disaster Management Interoperability Services web site. See http://www.cmi-services.

org/.

Dobkin, Daniel M., RF Engineering for Wireless Networks: Hardware, Antennas, and Propagation
(Burlington, Massachusetts: Newnes, 2004).

Erlanger, Leon, “Building the intelligent network,” InfoWorld, July 18, 2005. See
http://www.infoworld.com/reports/29SRintelnet.html.

Federal Communications Commission, 700 MHz Interoperability Spectrum web site. See
http://wireless.fcc.gov/publicsafety/700MHz/interop.html.

Federal Communications Commission, A Glossary of Telecommunications Terms (Washington,

D.C.: 1998). See http://web.archive.org/web/19980524230851/http://www.fcc.gov/
Consumers/glossary.html.

Global Infrastructure/Standards Working Group, A Framework for Justice Information Sharing:

Service-Oriented Architecture (SOA), December 9, 2004. See
http://it.ojp.gov/documents/20041209_SOA_Report.pdf.
3 Appendix E

Global Justice Information Sharing Initiative Advisory Committee, “Charter,” October 15, 2002.
See http://it.ojp.gov/documents/GAC_Charter_2002.pdf.

Harris, Kelly J., and William H. Romesburg, Law Enforcement Tech Guide: How to plan, purchase and
manage technology (successfully!), A Guide for Executives, Managers and Technologists (Washington,
D.C.: U.S. Department of Justice Office of Community Oriented Policing Services, 2002). See
http://www.cops.usdoj.gov/default.asp?Item=512.

Homeland Security Presidential Directive/HSPD-5, “Management of Domestic Incidents,”

February 28, 2003. See http://www.whitehouse.gov/news/releases/2003/02/20030228-
9.html.

Homeland Security Presidential Directive/HSPD-8, “National Preparedness,” December 17, 2003.

See http://www.whitehouse.gov/news/releases/2003/12/20031217-6.html.

Institute for Policy Research, Northwestern University, Policing Smarter Through IT: Lessons in
Enterprise Implementation (Washington, D.C.: U.S. Department of Justice Office of Community
Oriented Policing Services, September 2004). See http://www.cops.usdoj.gov/default.
asp?Item=1331.

Institute for Security Technology Studies, Crisis Information Management Software (CIMS)
Interoperability: A Status Report (Hanover, New Hampshire: Dartmouth College, October 2004). See
http://www.ists.dartmouth.edu/TAG/cims1004.pdf.

McKinsey & Company, Improving NYPD Emergency Preparedness and Response, August 19, 2002. See
http://www.nyc.gov/html/nypd/pdf/nypdemergency.pdf.

McKinsey & Company, Increasing FDNY’s Preparedness, Executive Summary, August 19, 2002. See
http://www.nyc.gov/html/fdny/html/mck_report/toc.shtml.

Metropolitan Emergency Services Board, St. Paul, Minnesota, “800 MHz Trunked Regional Public
Safety Radio System Standards, Protocols, Procedures” (interim).

MissionCritical Communications, “Public Safety Report: Snapshot Survey – Wireless Networking,”

September 2005,

Montana Department of Administration, Public Safety Radio Communications Program, Mutual

Aid and Common Frequencies, 2005 (Helena, Montana: June 2005). See http://itsd.mt.gov/
techmt/publicsafety/docs/2005_mutual_aid_book_2005_web_final.pdf.

National Commission on Terrorist Attacks Upon the United States, The 9/11 Commission Report:
Final Report of the National Commission on Terrorist Attacks Upon the United States (Washington,
D.C.: U.S. Government Printing Office, July 2004). See http://www.9-11commission.gov.
 Bibliography and Resources
39
National Emergency Number Association, NENA Master Glossary of 9-1-1 Terminology, NENA-01-
002 (Arlington, Virginia: November 29, 2005). See http://www.nena.org/9-1-1TechStandards/
Standards_PDF/Master%20Glossary11_29_05.pdf.

National Institute for Occupational Safety and Health (NIOSH), U.S. Department of Health and
Human Services, NIOSH Alert: Preventing Injuries and Death from Falls during Construction and
Maintenance of Telecommunication Towers, NIOSH Publication No. 2001-156 (Cincinnati, Ohio: July
2001). See http://www.cdc.gov/niosh/2001156.html.

National Task Force on Interoperability, Why Can’t We Talk? Working Together to Bridge the
Communications Gap to Save Lives, A Guide for Public Officials, February 2003. See
http://www.ojp.usdoj.gov/nij/topics/commtech/ntfi_guide.pdf.

National Wildfire Coordinating Group Taskbooks. See http://www.nwcg.gov/pms/taskbook/

logistics/logistic.htm.

Project Management Institute, A Guide to the Project Management Book of Knowledge, Third Edition
(Newtown Square, Pennsylvania: 2000).

Project MESA web site. See http://www.projectmesa.org.

Public Safety Wireless Advisory Committee, Final Report, presented to the Federal
Communications Commission and the National Telecommunications and Information
Administration, September 11, 1996. See http://pswac.ntia.doc.gov/pubsafe/publications/
PSWAC_AL.PDF.

Public Safety Wireless Network, LMR Replacement Cost Study Report, prepared by Booz, Allen &
Hamilton Inc., June 1998. See http://www.safecomprogram.gov/NR/rdonlyres/B69361FA-
9AC6-4126-B971-83DF30FED932/0/lmr_coststudy.pdf.

Public Safety Wireless Network, Public Safety Radio Spectrum: A Vital Resource for Saving Lives and
Protecting Property (no date). See http://www.safecomprogram.gov/SAFECOM/library/
spectrum/1102_publicsafety.htm.

Public Safety Wireless Network Program, Embedded Communications Broker (ECB) Technology, white
paper, October 2001. See http://permanent.access.gpo.gov/websites/safecomprogramgov/
www.safecomprogram.gov/admin/librarydocs9/jill_ecb.pdf.

Public Safety Wireless Network Program, Greenhouse Project Wideband Data Technology, white
paper, September 2001. See http://www.safecomprogram.gov/SAFECOM/library/
technology/1033_GreenhouseProject.htm.
30 Appendix E

Public Safety Wireless Network Program, Public Safety In-Building/In-Tunnel Ordinances and Their
Benefits to Interoperability Report, November 2002. See http://www.safecomprogram.gov/
SAFECOM/library/technology/1032_PublicSafety.htm.

Public Safety Wireless Network Program Management Office, PSWN Program Analysis of Fire and
EMS Communications Interoperability, prepared by Booz, Allen & Hamilton Inc., April 1999. See
http://permanent.access.gpo.gov/websites/safecomprogramgov/www.safecomprogram.
gov/admin/librarydocs9/fireems_interop_study.pdf.

Roberts, David J., Integration in the Context of Justice Information Systems: A Common Understanding
(Sacramento, California: SEARCH Group, Incorporated, updated 2004). See
http://www.search.org/files/pdf/Integration.pdf.

Roberts, David J., Law Enforcement Tech Guide for Creating Performance Measures that Work: A
Guide for Executives and Managers (publication pending by U.S. Department of Justice Office of
Community Oriented Policing Services, 2006).

Romesburg, William H., Law Enforcement Tech Guide for Small and Rural Police Agencies: A Guide
for Executives, Managers, and Technologists (Washington, D.C.: U.S. Department of Justice Office
of Community Oriented Policing Services, 2005). See http://www.search.org/files/pdf/
SmallRuralTechGuide.pdf.

Ross, Ron, et al., Recommended Security Controls for Federal Information Systems, NIST SP 800-
53 (Washington, D.C.: U.S. Department of Commerce, National Institute of Standards and
Technology, February 2005, including updates to June 17, 2005). See http://csrc.nist.gov/
publications/nistpubs/800-53/SP800-53.pdf.

San Francisco TechConnect web site. See http://www.sfgov.org/site/tech_connect_page.

asp?id=33899.

Signorini, Eugene, 3G Represents an Inflection Point for Enterprise Mobility (Boston, Massachusetts:
Yankee Group Research, Inc., 2004).

South Carolina Budget and Control Board, Division of the State Chief Information Officer,
“Trunked 800 MHz System Interconnect Guidelines.” See http://www.cio.sc.gov/cioContent.
asp?pageID=772.

Stoneburner, Gary, Clark Hayden, and Alexis Feringa, Engineering Principles for Information
Technology Security (A Baseline for Achieving Security), NIST SP 800-27 (Washington, D.C.: U.S.
Department of Commerce, National Institute of Standards and Technology, June 2001). See
http://csrc.nist.gov/publications/nistpubs/800-27/sp800-27.pdf.
 Bibliography and Resources
31
Swanson, Marianne, and Barbara Guttman, Generally Accepted Principles and Practices for Security
Information Technology Systems (Washington, D.C.: U.S. Department of Commerce, National
Institute of Standards and Technology, September 1996). See
http://csrc.nist.gov/publications/nistpubs/800-14/800-14.pdf.

Taylor, Mary J., et al., State and Local Law Enforcement Wireless Communications and Interoperability:
A Quantitative Analysis, NCJ 168961 (Washington, D.C.: U.S. Department of Justice, Office of
Justice Programs, National Institute of Justice, January 1998). See
http://www.ncjrs.org/pdffiles1/168961.pdf.

U.S. Department of Homeland Security, National Incident Management System, March 1, 2004. See
http://www.fema.gov/pdf/nims/nims_doc_full.pdf. ­

U.S. Department of Homeland Security, Office of Grants and Training, “HSPD-8 Overview.” See
http://www.ojp.usdoj.gov/odp/assessments/hspd8.htm. ­

U.S. Department of Homeland Security, Office of State and Local Government Coordination
and Preparedness, Office for Domestic Preparedness, Fiscal Year 2005 Homeland Security Grant
Program: Program Guidelines and Application Kit, version 2 (Washington, D.C.: December 22,
2004). See http://www.ojp.usdoj.gov/odp/docs/fy05hsgp.pdf. ­

U.S. Department of Homeland Security, SAFECOM Program, Statement of Requirements for Public
Safety Wireless Communications and Interoperability (Washington, DC: Version 1.1, January 26,
2006). See http://www.safecomprogram.gov/SAFECOM/library/technology/1258_ ­
statementof.htm. ­

U.S. Department of Justice, National Institute of Justice, “What’s New from CommTech.” See
http://www.ojp.usdoj.gov/nij/topics/commtech/. ­

U.S. Department of Justice, Office of Justice Programs, Information Technology Initiatives,

“Global Justice XML Data Model.” See http://www.it.ojp.gov/gjxdm. ­

U.S. Department of Justice, Office of Justice Programs, Information Technology Initiatives,

“Global JXDM Implementation Guidelines.” See http://it.ojp.gov/topic.jsp?topic_id=138. ­

U.S. General Accounting Office, Homeland Security: Challenges in Achieving ­

Interoperable Communications for First Responders, testimony before the subcommittees of the
Government Reform Committee, House of Representatives, GAO 04-231T (Washington, D.C.:
Nov. 6, 2003). See http://www.gao.gov/new.items/d04231t.pdf. ­

U.S. Government Accountability Office, Homeland Security: Federal Leadership and

Intergovernmental Cooperation Required to Achieve First Responder Interoperable Communications,
GAO-04-740 (Washington, D.C.: July 2004).
32 Appendix E

Vandereau, John M., Delivered Audio Quality Measurements on Project 25 Land Mobile Radios,
NTIA Report 99-358 (Washington, D.C.: U.S. Department of Commerce, Institute for
Telecommunications Science, 1998). See http://www.its.bldrdoc.gov/pub/ntia-rpt/99-358/.

WebSite Optimization.com, “US Broadband Breaks 60% among Active Internet Users, but growth
slows,” September 2005. See http://www.websiteoptimization.com/bw/0509.

WiMAX Forum, “About the WiMAX Forum.” See http://www.wimaxforum.org/about.

Wireless Philadelphia Executive Committee web site: http://www.phila.gov/wireless.

Wisconsin Department of Justice, Division of Law Enforcement Services, Crime Information

Bureau, “eTIME Project.” See http://www.doj.state.wi.us/les/TIME/eTIME.htm.

Additional Resources
800 MHz Transition Administrator. See http://www.800ta.org/. ­

Association of Public-Safety Communications Officials – International, Inc. (APCO)

Interoperability Resources. See http://www.apcointl.org/frequency/siec/documents/ ­
documents.htm. ­

Automated Frequency Coordination, Inc., a subsidiary of APCO. See ­

http://www.apcointl.org/frequency/WhatisFC1.html. ­

Basecamp™ Project Collaboration Tool. See http://www.basecamphq.com/. ­

California Tactical Dispatcher Association. See http://www.tacticaldispatch.com/. ­

Cover Pages (hosted by OASIS), Emergency Data Exchange Language (EDXL). See ­
http://xml.coverpages.org/edxl.html. ­

Federal Communications Commission (FCC), 700 MHz Public Safety Spectrum page. See ­
http://wireless.fcc.gov/publicsafety/700MHz/.

FCC, 800 MHz Band Reconfiguration page. See http://wireless.fcc.gov/publicsafety/

800MHz/bandreconfiguration/index2.html.

FCC, Public Safety Frequency Coordinators page. See

http://wireless.fcc.gov/publicsafety/coord.html.
 Bibliography and Resources
33
FCC, Interoperability Spectrum page. See ­
http://wireless.fcc.gov/publicsafety/700MHz/interop.html. ­

FCC, Refarming page. See http://wireless.fcc.gov/services/plmrs/refarming/. ­

FCC, Special Temporary Authority page. See http://wireless.fcc.gov/publicsafety/sta.html. ­

Global Justice XML Data Model (GJXDM) Introduction page. See http://it.ojp.gov/jxdm/.

Hawaii State Government Internet portal demonstration video. See

http://www2.hawaii.gov/dags/icsd/content/video/higovdemo_250k.asf.

Incidentdispatch.net. See http://www.incidentdispatch.net/.

Institute of Electrical and Electronics Engineers (IEEE) 802.11 series of standards. See
http://www.ieee802.org/11/.

IEEE 802.16 Working Group on Broadband Wireless Access Standards. See

http://www.ieee802.org/16/. ­

Internet Engineering Task Force (IETF). See http://www.ietf.org/. ­

Law Enforcement Information Technology Standards Council (LEITSC). See ­

http://www.leitsc.org/.

Los Angeles Regional Tactical Radio Communications System (LARTCS). See

http://www.lartcs.org.

Louisville (Kentucky) Metro’s MetroSafe (emergency communications network). See

http://www.louisvilleky.gov/MetroSafe/.

Metropolitan Emergency Services Board, St. Paul, Minnesota. See ­

http://www.metro9-1-1board-mn.org. ­

Minnesota Department of Public Safety, Allied Radio Matrix for Emergency Response (ARMER).
See http://www.armer.state.mn.us/. ­

National Association of Tower Erectors (NATE). See http://www.natehome.com. ­

National Interagency Incident Communications Division (NIICD). See ­

http://www.fs.fed.us/fire/niicd/.
3 Appendix E

National Public Safety Telecommunications Council (NPSTC). See ­

http://www.npstc.org/siec/siec.jsp. ­

National Security Agency, Central Security Service, Information Assurance Directorate page on
TEMPEST. See http://www.nsa.gov/ia/government/index.cfm.

National Task Force on Interoperability, Supplemental Resources to “Why Can’t We Talk? Working
Together to Bridge the Communications Gap To Save Lives,” February 2003. See
http://www.justnet.org/pdffiles/ntfi_supplemental.pdf (~3.0 MB).

National Wildfire Coordinating Group (NWCG). See http://www.nwcg.gov.

NIMSonline.com, serving the National Incident Management System community, examples of

ICS forms page. See http://www.nimsonline.com/nims_3_04/examples_of_ics_forms.
htm.

North Central Texas Council of Governments. See http://www.nctcog.org/.

Open Systems Interconnection model. See ­

http://en.wikipedia.org/wiki/Open_Systems_Interconnect. ­

Organization for the Advancement of Structured Information Standards (OASIS). See

http://www.oasis-open.org.

Project 25 Technology Interest Group. See http://www.project25.org.

SAFECOM Program of the Department of Homeland Security, Science and Technology

Directorate, Office for Interoperability and Compatibility. See
http://www.safecomprogram.gov.

SAFECOM Program, grant guidance page for interoperability projects. See ­

http://www.safecomprogram.gov/SAFECOM/grant/default.htm. ­

SEARCH Group, Incorporated and U.S. Department of Justice, Bureau of Justice Assistance,
Building Exchange Content Using the Global Justice XML Data Model: A User Guide for Practitioners
and Developers, June 2005. See http://it.ojp.gov/documents/GJXDMUserGuide.pdf.

SEARCH, Information Exchange Package Documentation project. See ­

http://www.search.org/programs/info/xml-iep.asp. ­

SEARCH, Workshop Report: Law Enforcement Information Exchange Package Documentation,

Constructed from GJXDM 3.0.2, March 15, 2005. See
http://www.search.org/files/pdf/gjxdm-iep.pdf.
 Bibliography and Resources
3
South Carolina Budget and Control Board, Division of the State Chief Information Officer,
Palmetto 800 Radio System page. See http://www.cio.sc.gov/cioContent.asp?pageID=756&
menuID=411.

Telecommunications Industry Association (TIA). See http://www.tiaonline.org/.

U.S. Department of Homeland Security, Lessons Learned Information Sharing site (requires
registration). See https://www.llis.dhs.gov.

U.S. Department of Homeland Security, Office for Domestic Preparedness, Homeland Security
Exercise and Evaluation Program (HSEEP). See
http://www.ojp.usdoj.gov/odp/docs/hseep.htm.

U.S. Department of Homeland Security, Office for Domestic Preparedness, Homeland Security
Exercise and Evaluation Program, Volume II: Exercise Evaluation and Improvement, NCJ 202198
(Washington, D.C.: October 2003). See http://www.ojp.usdoj.gov/odp/docs/HSEEPv2.pdf.

U.S. Department of Homeland Security, Office of Grants and Training, Interoperable

Communications Technical Assistance Program (ICTAP) page. See
http://www.ojp.usdoj.gov/odp/ta_ictap.htm.

U.S. Department of Homeland Security, SAFECOM Program, Interoperability Continuum. See

http://www.safecomprogram.gov/SAFECOM/tools/continuum/.

U.S. Department of Homeland Security, SAFECOM Program, Library. See

http://www.safecomprogram.gov/SAFECOM/library/technology/.

U.S. Department of Homeland Security, SAFECOM Program, Public Safety Wireless Network,
Comparisons of Conventional and Trunked Systems, May 1999. See http://www.safecomprogram.
gov/SAFECOM/library/technology/1179_conventionaland.htm.

U.S. Department of Homeland Security, SAFECOM Program, Public Safety Wireless Network
Program, How 2 Guide for Establishing and Managing Talkgroups, no publication date. See
http://www.safecomprogram.gov/SAFECOM/library/systems/1047_HowTo.htm.

U.S. Department of Homeland Security, SAFECOM Program, Public Safety Wireless Network
Program, Introduction to Encryption Key Management for Public Safety Radio Systems, October 2001.
See http://www.safecomprogram.gov/SAFECOM/library/security/1113_securityissues.
htm.

U.S. Department of Homeland Security, SAFECOM Program, Public Safety Wireless Network
Program, Key Management Plan Template for Public Safety Land Mobile Radio Systems, February
2002. See http://www.safecomprogram.gov/SAFECOM/library/security/1114_
keymanagement.htm.
3 Appendix E

U.S. Department of Homeland Security, SAFECOM Program, Public Safety Wireless Network
Program, Operational Best Practices for Managing Trunked Land Mobile Radio Systems, May
2003. See http://www.safecomprogram.gov/SAFECOM/library/systems/1049_
OperationalBest.htm.

U.S. Department of Homeland Security, SAFECOM Program, Public Safety Wireless Network
Program, “Public Safety’s New Allocation—Answering Users’ Questions on the 4.9 Gigahertz
Band,” no date of publication. See http://www.safecomprogram.gov/SAFECOM/library/
spectrum/1088_publicsafetys.htm.

U.S. Department of Homeland Security, SAFECOM Program, Public Safety Wireless Network
Program, Software-Enabled Wireless Interoperability Assessment Report – Voice-Over-Internet Protocol
Technology, December 2001. See http://www.safecomprogram.gov/SAFECOM/library/
technology/1171_softwareenabledwireless.htm.

U.S. Department of Justice Office of Community Oriented Policing Services, Summit on

Implementing Wireless Communications: Perspectives on Interoperability from the Law Enforcement
Community. See http://www.cops.usdoj.gov/Default.asp?Item=1495.

Virginia Interoperability site. See http://www.interoperability.publicsafety.virginia.gov/.

Washington State’s Statewide Interoperability Executive Committee. See

http://isb.wa.gov/committees/siec/.

Wi-Fi Alliance. See http://www.wi-fi.org.

Appendix F:
Glossary
 Appendix F:
Glossary

Sources:
Many of the terms in this glossary have been taken from one of the followoing sources. As
applicable, the source is indicated in parenthesis following the term.
n COPS Office, Law Enforcement Tech Guide: How to plan, purchase and manage
technology (successfully!), 2002 ­
(http://www.cops.usdoj.gov/default.asp?Item=512) ­
n National Task Force on Interoperability (NTFI), Why Can’t We Talk? Working Together
to Bridge the Communications Gap to Save Lives, A Guide for Public Officials, February
2003 (http://www.ojp.usdoj.gov/nij/topics/commtech/ntfi_guide.pdf).
n Federal Communications Commission (FCC), A Glossary of Telecommunications
Terms, 1998 http://web.archive.org/web/19980524230851/http://www.fcc.
gov/Consumers/glossary.html.
n FCC Public Safety Wireless Advisory Committee (PSWAC), Final Report of the Public
Safety Wireless Advisory Committee, September 11, 1996
(http://pswac.ntia.doc.gov/pubsafe/publications/PSWAC_AL.PDF).
n National Emergency Number Association (NENA), NENA Master Glossary of 9-1-1
Terminology, November 29, 2005 (http://www.nena.org/9-1-1TechStandards/
Standards_PDF/Master%20Glossary11_29_05.pdf)

1xEv-DO
Formally, CDMA2000 1xEv-DO (Evolution – Data Optimized), a CDMA2000
technology. The “1x” refers to use of a single pair of 1.25 MHz radio channels. Carrier
reported data rates are in the 300 Kbps to 1.2 Mbps range. Considered to be a 3G
wireless service. Also known as “EvDO.”

1xRTT
Formally, CDMA2000 1xRTT (Radio Transmission Technology), a CDMA2000
technology. The “1x” refers to use of a single pair of 1.25 MHz radio channels. Carrier
reported data rates are in the 50 to 200 Kbps range. Considered to be a 2.5G wireless
service.
390 Appendix F

1G, 2G, 3G, etc.

Successive generations of wireless telephone technologies. The first generation is commonly
considered to be analog cellular telephony.

3GSM
See Universal Mobile Telecommunications System (UMTS).

ALI
See Automatic Location Identification.

ANI
See Automatic Number Identification.

Acceptance testing (COPS Law Enforcement Tech Guide)

The process that an agency uses to verify that the delivered and installed product meets
requirements specified in the procurement documents and contract, particularly regarding
functionality, reliability, and performance.

Ad hoc working groups (COPS Law Enforcement Tech Guide)

Groups that are formed as a subset to the project’s formal decision-making structure to look
at specific tasks and business processes that require more in-depth research or analysis, or
to carry out research on and development of a variety of project-specific plans, models,
policies, and directions. Assembled on a temporary basis to address a specific issue or task.

Advanced Generation of Interoperability for Law Enforcement (AGILE)

(NTFI Guide – Glossary of Terms)
The AGILE Program was created in 1998 to group together all of the interoperability
projects [then] underway at the National Institute of Justice.

Analog radio system (NTFI Guide – Glossary of Terms)

A radio system in which voice signals are sent over-the-air in an unaltered form and are
heard in the same time frame over which they were communicated. (The human voice is an
analog signal.) Cellular phones and other wireless devices still use analog in geographic areas
where there is little or no coverage by digital networks.

Antenna (NTFI Guide – Glossary of Terms) ­

Any structure or device used to collect or radiate electromagnetic waves. ­

Association of Public-Safety Communications Officials – International, Inc. (APCO)

(NTFI Guide – Glossary of Terms)
APCO International is the world’s oldest and largest not-for-profit professional organization
dedicated to the enhancement of public safety communications.
 Glossary
391
Assumptions and constraints (COPS Law Enforcement Tech Guide)
Circumstances and events that can affect the success of the project and are generally out
of the control of the project team. Include in the project charter to provide assistance in
making/justifying decisions. Consult also when developing the project timeline and risk
management plan.

Automatic Location Identification (ALI) (NENA Master Glossary)

The automatic display at the public safety answering point (PSAP) of the caller’s telephone
number, the address/location of the telephone, and supplementary emergency services
information.

Automatic Number Identification (ANI) (NENA Master Glossary)

Telephone number associated with the access line from which a call originates.

Automatic Vehicle Location (AVL) software (COPS Law Enforcement Tech Guide)
Used by law enforcement agencies to remotely track the location of agency units via
satellite global positioning systems (GPS). AVL combines GPS technology, wireless
communications, street-level mapping, and a user interface.

Band (NTFI Guide – Glossary of Terms)

In communications, the spectrum between two defined limited frequencies. For example,
the Ultra High Frequency (UHF) is located from 300 MHz to 3,000 MHz in the radio
frequency spectrum.

Bandwidth (NTFI Guide – Glossary of Terms)

The size of a network “pipe” or channel for communications in wired networks. In wireless
communications, it refers to the range of available frequencies that can carry a signal. In
analog communications, bandwidth is typically measured in Hertz (cycles per second). In
digital communications, bandwidth is typically measured in bits per second (bps).

Best practices (COPS Law Enforcement Tech Guide)

Industry-proven processes or methods that, when executed effectively, lead to enhanced or
superior project performance and ensure the success of an undertaking (such as planning,
procurement, implementation, and management).

Bluetooth
An open standard for short range, low-speed wireless networking intended to be used in
computing and telecommunications equipment to replace cabling. It has an application in
personal area networks (PAN) and is used popularly with wireless telephone headsets.

Bonding (COPS Law Enforcement Tech Guide)

Bonds required may include those dealing with performance, maintenance, and payment.
392 Appendix F

Broadband (FCC Glossary of Telecommunications Terms)

Broadband is a descriptive term for evolving digital technologies that provide consumers
with a signal switched facility offering integrated access to voice, high-speed data service,
video-demand services, and interactive delivery services.

Business case (COPS Law Enforcement Tech Guide)

The project’s marketing plan that articulates why the project is important in terms of
operational benefits to the agency, the justice system in general, and the public. Used to
educate and inform all project stakeholders.

Business process (COPS Law Enforcement Tech Guide)

A written description of the things that employees do every day in their job functions
assessed on a what, why, when, how, and where basis. Business processes are what
technology seeks to enhance or improve.

CDMA
Code Division Multiple Access. A method of multiple access to a digital communications
channel. In the wireless telephony environment, data bits from multiple voice channels are
spread across a wide radio channel simultaneously.

cdmaOne
The first CDMA technology for mobile digital telephony based on the TIA/EIA-95 standard,
previously known as Interim Standard 95 (IS-95). cdmaOne™ is a trademark of the CDMA
Development Group, Inc. Considered to be a 2G wireless service.

CDMA2000
A CDMA technology for mobile digital telephony and data based on the TIA Interim
Standard 2000 (IS-2000). The term encompasses multiple CDMA data technologies,
including 1xRTT and EVDO (See 1xEv-DO entry). CDMA2000® is a registered trademark of
the Telecommunications Industry Association (TIA).

Cellular Digital Packet Data (CDPD)

A wireless, packet data service operated on analog or 1G cellular systems. Provided data
rates of approximately 19.2 Kbps. Originally available in the mid-1990s and widely available
by 2000. Major carriers transitioned out of CDPD in 2004 to 2005.

Channel (NTFI Guide – Glossary of Terms)

A single unidirectional or bidirectional path for transmitting or receiving, or both, of
electrical or electromagnetic signals.

Client/server (COPS Law Enforcement Tech Guide)

An application that runs on a personal computer or workstation and relies on a server to
perform some operations. A thin client is a client designed to be especially small so the bulk
of data processing occurs on the server.
 Glossary
393
Commercial services (NTFI Guide – Glossary of Terms)
Communications services (e.g., cellular telephone and paging communications companies)
run by private companies. Many public safety agencies use commercial services in their day-
to-day operations.

Common carrier (FCC Glossary of Telecommunications Terms)

In the telecommunications arena, the term describes a telephone company.

Communications plan (COPS Law Enforcement Tech Guide)

Formal and agreed-upon strategies for communicating project status and activities to key
stakeholders, and methods for developing historical project records and archives.

Communications system (NTFI Guide – Glossary of Terms)

A collection of individual communications networks, transmission systems, relay stations,
tributary stations, and data terminal equipment usually capable of interconnection and
interoperation to form an integrated whole. Note: The components of a communications
system serve a common purpose, are technically compatible, use common procedures,
respond to controls, and operate in unison.

Computer-aided Dispatch (CAD) System (COPS Law Enforcement Tech Guide)

Fully automates the call-taking and dispatching functions of a law enforcement agency and
initiates and manages dispatch and incidents.

Contingency costs (COPS Law Enforcement Tech Guide)

Funding that is set aside for unexpected and, therefore, often unbudgeted activities. On
average, contingencies range from 10 to 15 percent of the hardware and software costs.

Conventional radio system (NTFI Guide – Glossary of Terms)

A land mobile radio (LMR) system architecture similar to a telephone party line in that the
user determines availability by listening for an open channel before transmitting.

Coverage (NTFI Guide – Glossary of Terms)

The geographic area included within the range of a wireless radio system.

Data (NTFI Guide – Glossary of Terms)

Representation of facts, concepts, or instructions in a formalized manner suitable
for communication, interpretation, or processing by humans or by automatic means.
Any representations such as characters or analog quantities to which meaning is or
might be assigned.
39 Appendix F

Day-to-day interoperability (FCC PSWAC Final Report)

This most frequent type of interoperability is commonly used in areas of concurrent
jurisdiction where agencies need to monitor each other’s routine communications. This
minimizes the need for dispatcher-to-dispatcher interaction in exchanging information
among field units. Interoperability is difficult to implement unless all equipment operates in
the same frequency band and within the same type of infrastructure.

Dead spots (or zones) (NTFI Guide – Glossary of Terms)

The area, zone, or volume of space that is within the expected range of a radio signal, but in
which the signal is not detectable and therefore cannot be received. Common causes of dead
spots include depressions in the terrain and physical structures.

Decision-making structure (COPS Law Enforcement Tech Guide)

A group of agency staff that provides leadership and accountability; defines the business
of the agency; analyzes technical environments, policies, and solutions; and effectively
manages projects. Requires participation from three key representative groups within an
agency: executive, business or operational, and technical.

Deliverable (COPS Law Enforcement Tech Guide)

A measurable, tangible, verifiable outcome that must be produced to complete a project or
part of a project.

Digital (signal) (NTFI Guide – Glossary of Terms) ­

A signal in which discrete steps are used to represent information. ­

Digital radio system (NTFI Guide – Glossary of Terms)

A radio system where voice is converted to a digital format before being sent over the air.
When the digital signal reaches the receiving radio, it is converted back to analog so that it
is intelligible to the human ear. The benefit of digital radio systems is that the signal can be
reproduced precisely.

EDGE
Enhanced Data Rates for GSM Evolution. A digital wireless technology providing high-speed
data on GSM and other Time Division Multiple Access (TDMA) networks. EDGE services
are designed to complement general packet radio systems (see GPRS). Carrier reported data
rates are in the 50 to 200 Kbps range. Currently considered to be a 2.5G wireless service, but
capable of being extended to higher speeds.

Electronic Industry Alliance (EIA)

EIA is a national (U.S.) trade organization of electronic and other high-technology
organizations and companies that develops standards.
 Glossary
39
Environmental scan (ES) (COPS Law Enforcement Tech Guide)
An initial step in the planning process that helps the project team gain perspective on the
initiative by allowing the team to systematically assess factors that present opportunities
or threats to the success of the project. Sometimes referred to as a situation or “SWOT”
assessment, an ES contains an internal scan that identifies strengths (S) and weaknesses (W)
of the agency and an external scan that identifies external opportunities (O) and threats (T)
to the agency.

EvDO
See 1xEv-DO.

Executive sponsor (COPS Law Enforcement Tech Guide)

The individual who has the ultimate accountability for the project, having authority
to sanction the project and make it a priority. Serves as the project’s ultimate decision
making authority.

Extended Area Network (EAN)

A basic communications networking type used to describe voice and/or data networks
used by public safety agencies for both routine operations and emergencies. An EAN is the
single or set of networks providing communications between agencies over an extended
geographic expanse. Such a network used for data communications is also known as a wide
area network (WAN) or extranet.

Extensible Markup Language

See XML.

Federal Communications Commission (FCC) (NTFI Guide – Glossary of Terms)

An independent federal agency that regulates U.S. broadcast media and communications
markets, as well as local and state radio spectrum needs.

Federal Law Enforcement Wireless Users Group (FLEWUG)

(NTFI Guide – Glossary of Terms)
FLEWUG began as an ad hoc group of federal radio spectrum users that met to address
the National Telecommunications and Information Administration’s (NTIA) mandate
for digital narrow-banding by 2005. The FLEWUG was formalized as a mechanism to
address interoperability and other challenges related to public safety communications. The
FLEWUG issued the Public Safety Wireless Network (PSWN) Program Management and
Organization document in 1996, which led to the creation of the PSWN Program.

Fee-for-service (NTFI Guide – Glossary of Terms)

An arrangement in which a vendor has expended its own capital to build, install, administer,
and maintain its own system for lease to public safety organizations.
39 Appendix F

Focus groups (COPS Law Enforcement Tech Guide)

A somewhat informal technique that can help to assess user needs while designing the
system. Usually six to nine users gather to discuss issues and concerns about the features of
the new system.

Frequency (NTFI Guide – Glossary of Terms) ­

For a periodic function, the number of cycles or events per unit time. ­

Frequency bands (NTFI Guide – Glossary of Terms)

Frequency bands where land mobile radio systems operate in the United States, including
the following: High HF (25-29.99 MHz), Low VHF (30-50 MHz), High VHF (150-174 MHz),
Low UHF (450-470 MHz), UHF TV Sharing (470-512 MHz), 700 MHz (764-776/794-806
MHz), and 800 MHz (806-869 MHz).

Frequency Modulation (FM) (FCC Glossary of Telecommunications Terms)

A signaling method that varies the carrier frequency in proportion to the amplitude of the
modulating signal.

Functional specifications (COPS Law Enforcement Tech Guide)

Precise descriptions of how a product should operate. These statements should be succinct.
A project plan and procurement document often contains numerous such functional
requirements. During procurement, vendors should be required to divulge how closely their
product matches an agency’s functional specifications.

Functionality testing (COPS Law Enforcement Tech Guide)

A type of acceptance testing designed to ensure that the vendor’s software is functioning as
described in product literature and, possibly, in response to the agency’s RFP.

GPRS
General Packet Radio System. A digital wireless technology providing high-speed data on
GSM and other TDMA networks. Carrier reported data rates are in the 30 to 80 Kbps range.
Considered to be a 2.5G wireless service.

GSM
Global System for Mobile Communications. A worldwide standard for mobile digital
telephony using TDMA channel access means for eight voice channels across wide (200
kHz) radio channels. Considered to be a 2G wireless service.

Gateway
In general telecommunications, a gateway is a device that connects two or more different
networks. The term has come to mean more in land mobile radio communications where
it is used in reference to several means of achieving technical interoperability in which
independent systems are connected together so traffic on one channel, typically, of an
 Glossary
39
agency’s system is duplicated on another agency’s channel. This is commonly done by
electronic patching of transmit and receive audio of one channel to another, either at a
dispatch console, separate radio sites, or in a mobile communications vehicle.

Gigabits/second (Gbps)
A measure of data transfer rates equal to one thousand megabits or one billion bits
per second.

GJXDM
Global Justice XML Data Model. A data reference model for use with XML-based
information exchange in justice and public safety applications.

Global Positioning System (GPS) (FCC Glossary of Telecommunications Terms)

A U.S. satellite system that lets those on the ground, on the water, or in the air determine
their position with extreme accuracy using GPS receivers.

Hertz (Hz) (NTFI Guide – Glossary of Terms)

A unit of frequency in cycles per second. A hertz is one cycle per second.

Holdbacks (COPS Law Enforcement Tech Guide)

A contract provision that allows an agency to keep a percentage of a vendor’s payment until
after the vendor successfully completes certain milestones. Useful for keeping the vendor
interested in completing all of the tasks associated with a project, even those that are less
profitable than others.

Hotspot
In data networking usage, a wireless local area network (WLAN) access point offering
network connections beyond.

ICS
See Incident Command System.

iDEN
Integrated Digital Enhanced Network. A mobile digital telephony system first introduced
in 1994, which uses TDMA channel access means to provide up to six voice channels across
25 kHz radio channels. Considered to be a 2G wireless service. iDEN™ is a trademark of
Motorola, Inc.

Implementation plan (COPS Law Enforcement Tech Guide)

The blueprint that enables project management to define the rules that govern how
technology will be installed, tested, and managed.
39 Appendix F

Incident Area Network (IAN)

A basic communications networking type used to describe voice and/or data networks
used by public safety agencies for emergency incidents or events. An IAN is the single or
set of networks providing communications for responders across the entire organization
and geographic scope of an incident or event. Most commonly, an IAN is considered the
collection of subnetworks used for a particular incident.

Incident Command System (ICS)

An organizational management system adapted from military techniques for public safety
emergency response. It provides common terminology, modular organizational structures,
and objectives-based management principles among its basic principles.

Infrastructure (NTFI Guide – Glossary of Terms)

When relating to radio communications systems, the hardware and software needed to
complete and maintain the system.

Initial costs (COPS Law Enforcement Tech Guide)

One-time expenses to purchase technology and services for a project. Must be considered in
conjunction with recurring costs (see Recurring Costs).

Integration
The ability to access and exchange critical information at key decision points throughout
the enterprise.

Interference (NTFI Guide – Glossary of Terms)

In general, extraneous energy, from natural or manmade sources, that impedes the reception
of desired signals.

Internal costs (COPS Law Enforcement Tech Guide)

Those costs over which your agency has direct financial responsibility and control, including
personnel costs, infrastructure costs, cost recovery fees, etc.

Internet Protocol (IP)

One of a suite of protocols used to control exchange of data across systems and networks.
IP and associated protocols are the common protocols that allowed standardization
of computer networks, resulting in the Internet. Today, IP is the most common data
networking protocol. The term is also used to refer to the entire suite of protocols
commonly used across the Internet and private data networks.

Interconnects
See Gateway.
 Glossary
399
Intergovernmental Agreement (IGA)
A written agreement entered into between two or more public agencies that may be more
or less formal depending on legal requirements on the agencies. Also known as an interlocal
agreement (ILA) and used in some regions synonymously with the terms memorandum of
agreement (MOA) or understanding (MOU).

Interoperability
The ability of public safety responders to share information via voice and data
communications systems on demand, in real time, when needed, and as authorized.

Interstate Compact Agreement (NTFI Guide – Glossary of Terms)

A written contract between states to cooperate on a policy issue or program that extends
across and through state boundaries.

Joint Powers Act ( JPA) (NTFI Guide – Glossary of Terms)

A written contractual agreement entered into between two or more public agencies subject
to any constitutional or legislative restriction imposed upon any of the contracting public
agencies.

Jurisdiction Area Network ( JAN)

A basic communications networking type used to describe voice and/or data networks used
by public safety agencies for both routine operations and emergencies. A JAN is the single
or set of networks providing communications for an agency across the organizational and
geographic scope of its jurisdiction. It may be a shared network between agencies with
overlapping geographic scopes of responsibility.

Kilobits/second (Kbps or kbps)

A measure of data transfer rates equal to one thousand bits per second.

Kilohertz (kHz) (NTFI Guide – Glossary of Terms)

A unit of frequency denoting one thousand Hz.

Land Mobile Radio (LMR) (NTFI Guide – Glossary of Terms)

A radio system that allows for wireless communications between base stations and land
mobile stations (mobile or portable radios) or between land mobile stations.

Landline (FCC Glossary of Telecommunications Terms)

Traditional wired telephone service.

Lifecycle costing methods (COPS Law Enforcement Tech Guide)

Methods to determine the total cost of owning the technology, from procurement through
upgrade and/or replacement.
00 Appendix F

Local Area Network (LAN)

A geographically and functionally constrained network connecting personal computers,
servers, and printers.

Master Street Address Guide (MSAG) (NENA Master Glossary)

A database of street names and house number ranges within their associated communities
defining Emergency Service Zones (ESZs) and their associated Emergency Service Numbers
(ESNs) to enable proper routing of 9-1-1 calls.

Megabits/second (Mbps)
A measure of data transfer rates equal to one thousand kilobits or one million bits per
second.

Megahertz (MHz) (NTFI Guide – Glossary of Terms) ­

A unit of frequency denoting one million Hz. ­

Memorandum of Understanding (MOU) (NTFI Guide – Glossary of Terms)

An agreement of cooperation between organizations defining the roles and responsibilities
of each organization in relation to the other or others with respect to an issue over which the
organizations have concurrent jurisdiction.

Mesh network
A communications network in which nodes connect to two or more other nodes. A node
may be an end-user device, such as a computer, or a junction point between other pieces of
the network. Mesh networks are used for redundancy, resiliency, and traffic balancing. They
can be wired or wireless.

Metropolitan Area Network (MAN)

An organized collection of local area networks (LAN) across several locations in a municipal
or metropolitan area connected by high-speed links to form a larger logical network.

Milestone (COPS Law Enforcement Tech Guide) ­

A significant event in the project, usually completion of a major deliverable. ­

Mobile data computer (MDC)

A computer installed in a vehicle to provide users with data communications over a wireless
network. The computer is part of a system in the vehicle, which typically also includes one
or more software applications running on the computer and a radio to send and receive
data. Analog radio systems also require a modem to convert data to and from audio
transferred over the radio channel, while digital systems, commercial or agency-owned, pass
data without conversion.
 Glossary
01
Mobile data terminal (MDT)
An early type of mobile computing device dedicated to displaying data received across
a radio network and unable to run software applications. The term “MDT” is often used
synonymously today as computers have replaced dumb terminals.

Mutual aid interoperability (FCC PSWAC Final Report)

This involves multiple agencies using radios in “on-the-scene” incidents that are often
outside the range of fixed infrastructure. There is often little opportunity for prior planning
of different agencies to coordinate the necessary talkgroups and frequency assignments.

National Coordination Committee (NCC) (NTFI Guide – Glossary of Terms)

The NCC was established by the FCC to solicit input from the public safety community
in the further development of rules governing the new 700 MHz public safety band,
particularly in regard to interoperability.

National Institute of Justice (NTFI Guide – Glossary of Terms)

NIJ is the research and development agency of the U.S. Department of Justice.

National Task Force on Interoperability

The National Task Force on Interoperability (NTFI) was created by NIJ in 2002. It consisted
of 18 national associations representing state and local elected and appointed officials and
public safety officials. Through NIJ, the Task Force produced Why Can’t We Talk? Working
Together to Bridge the Communications Gap to Save Lives, A Guide for Public Officials.

NEPA
The National Environmental Policy Act. This federal law enacted in 1969 applies to
programs and projects licensed/permitted or funded, including grants in aid, by the
federal government that might have a significant impact on the quality of the human
environment. Major federal actions affecting the human environment require completion
of an environmental impact statement (EIS) or possibly an environmental assessment (EA).
Radio communications projects financed in whole or part by federal funds are often subject
to NEPA, particularly if any building or tower construction is involved.

Network (FCC Glossary of Telecommunications Terms)

Any connection of two or more computers that enables them to communicate. Networks
may include transmission devices, servers, cables, routers, and satellites. The phone network
is the total infrastructure for transmitting phone messages.

Pager (NTFI Guide – Glossary of Terms)

A communications device in which the intended receiver is alerted to receive a message or
return a call.
02 Appendix F

Paging system (FCC Glossary of Telecommunications Terms)

A one-way mobile radio service where a user carries a small, lightweight miniature radio
receiver capable of responding to coded signals. These devices, called “pagers,” emit an
audible signal, vibrate, or do both when activated by an incoming message.

Patch (NTFI Guide – Glossary of Terms)

A control center subsystem that permits a mobile or portable radio on one channel
to communicate with one or more radios on a different channel through the control
center console.

Performance reports (COPS Law Enforcement Tech Guide)

Provides details about project status, including which deadlines have been met and which
have not. Whether prepared by the vendor or internal staff, performance reports should be
provided weekly or biweekly.

Performance testing (COPS Law Enforcement Tech Guide)

A type of acceptance testing that is designed to determine the speed of the combined
hardware and software package during various transactions.

Personal Area Network (PAN)

A basic communications networking type used to describe voice and/or data networks used
by public safety agencies for both routine operations and emergencies. A PAN is a short-
range network for communications among computer and telecommunications devices in
the immediate vicinity of one person.

Personal Communications Services (PCS) (FCC Glossary of Telecommunications Terms)

Any of several types of wireless, voice, and/or data communications systems, typically
incorporating digital technology. PCS licenses are most often used to provide services
similar to advanced cellular mobile or paging services. However, PCS can also be used to
provide other wireless communications services, including services that allow people to
place and receive communications while away from their home or office, as well as wireless
communications to homes, office buildings, and other fixed locations.

Project 25 (P25) Standards (NTFI Guide – Glossary of Terms)

A joint government/industry standards-setting effort to develop technical standards for the
next generation of public safety radios, both voice and data.

Project charter (COPS Law Enforcement Tech Guide)

A document developed early in the process (prior to the full project plan) that contains an IT
project description, complete with scope, objectives, organization, and staffing, a decision-
making structure, the project management approach, and initial resource documents.
Provides guidance to project staff in planning and designing a system.
 Glossary
03
Project management (COPS Law Enforcement Tech Guide)
The application of knowledge, skills, tools, and techniques to project activities in order
to move the project forward to completion and to meet or exceed stakeholder needs and
expectations from a project.

Project manager (COPS Law Enforcement Tech Guide)

An individual dedicated to and accountable for all project-related activities and solely
responsible for the project’s scope, quality, and budget. Responsible for virtually all aspects
of the initiative and is formally accountable to the steering committee and the executive
sponsor.

Project objectives (COPS Law Enforcement Tech Guide)

Quantifiable criteria that must be met for the project to be considered successful. A critical
part of scope, objectives must include measures of quality, time, cost, performance,
reliability, and functionality.

Project planning (COPS Law Enforcement Tech Guide)

A dynamic process that results in a document that guides the entire IT project design,
procurement, implementation, and future enhancements. The plan is the repository for all
project-related research, decisions, deliverables, and documents.

Project scope (COPS Law Enforcement Tech Guide)

Clearly defines the boundaries for the project. Scope addresses what users want (functions);
how well the user requirements are met (quality of ); when and how it must be developed
(constraints); and why (the value in the project).

Project timeline (COPS Law Enforcement Tech Guide)

A mechanism to ensure that the project is accurately and realistically scheduled so that it can
be completed on time within the resources available. The timeline is critical to help prevent
delays and associated cost overruns. Includes activities, deliverables, and milestones.

Proprietary software (NTFI Guide – Glossary of Terms)

Signaling protocol or software that is unique to a manufacturer and incompatible with other
manufactured systems.

Proprietary systems roaming

A means of interagency communications in which cooperating agencies using similar,
but proprietary, systems are able to communicate with each other and use the extended
geographic coverage afforded by neighboring systems.

Protocol (NTFI Guide – Glossary of Terms)

A set of unique rules specifying a sequence of actions necessary to perform a
communications function.
0 Appendix F

Public safety service providers (NTFI Guide – Glossary of Terms)

Persons who perform emergency first response missions to protect and preserve life,
property, and natural resources and to serve the public welfare through federal, state,
or local governments as prescribed by law. Public safety service providers also include
nongovernment organizations that perform public safety functions on behalf of the
government. For example, a number of local governments contract with private groups for
emergency medical services.

Public safety support providers (NTFI Guide – Glossary of Terms)

Includes those whose primary mission might not fall within the classic public safety
definition, but whose mission may provide vital support to the general public and/or the
public safety official. Law enforcement, fire, and EMS would fit the first category, while
transportation or public utility workers would fit the second.

Public Safety Wireless Advisory Committee (PSWAC) (NTFI Guide – Glossary of Terms)
A joint advisory committee of the FCC and NTIA that provided recommendations on the
specific wireless communications requirements of public safety agencies through 2010.

Public-private partnership (NTFI Guide – Glossary of Terms)

A partnering between public and private entities in developing and constructing a
system or a building project. In the case of a statewide communications infrastructure,
a state may enter into an agreement with a third party that will assume responsibility
for communications coverage, capacity, growth, and interoperability. The state will pay
an access fee for use and services and share in revenues from additional users. The state
will also be freed from the need for further appropriations, as well as cost savings on
maintenance, upgrades, and training.

Quality assurances (QA) (COPS Law Enforcement Tech Guide)

Tests to ensure that the vendor’s hardware and software perform according to specification.

Radio cache (NTFI Guide – Glossary of Terms) ­

A portable or permanent storage facility for radios. ­

Radio channel (NTFI Guide – Glossary of Terms)

An assigned band of frequencies sufficient for radio communication. Note 1: The
bandwidth of a radio channel depends upon the type of transmission and the frequency
tolerance. Note 2: A channel is usually assigned for a specified radio service to be provided
by a specified transmitter.

Radio communications (NTFI Guide – Glossary of Terms) ­

Telecommunication by means of radio waves. ­
 Glossary
0
Radio equipment (NTFI Guide – Glossary of Terms)
As defined in Federal Information Management Regulations, any equipment or
interconnected system or subsystem of equipment (both transmission and reception) that is
used to communicate over a distance by modulating and radiating electromagnetic waves in
space without an artificial guide. This does not include such items as microwave, satellite, or
cellular telephone equipment.

Radio Frequency (RF) (NTFI Guide – Glossary of Terms)

Any frequency within the electromagnetic spectrum normally associated with radio
wave propagation.

Recurring costs (COPS Law Enforcement Tech Guide)

Continuing costs that must be considered to support, maintain, and enhance hardware and
software and user skills. Determine in concert with initial costs (defined above).

Risk management (COPS Law Enforcement Tech Guide)

A planning process that prepares the agency for dealing with potentially harmful events
that could happen in a technology initiative. The risk management plan is prepared by the
project manager and steering, user, and technical committees.

Satellite (FCC Glossary of Telecommunications Terms)

A radio relay station that orbits the earth. A complete satellite communications system
also includes earth stations that communicate with each other via the satellite. The satellite
receives a signal transmitted by an originating earth station and retransmits that signal to
the destination earth station(s).

Scanner (FCC Glossary of Telecommunications Terms)

A radio receiver that moves across a wide range of radio frequencies and allows audiences to
listen to any of the frequencies.

Schedule management plan (COPS Law Enforcement Tech Guide)

Provides a structured process for documenting, analyzing, and approving changes in
the project schedule. The schedule management plan should be a formal process that is
documented in the project plan.

Scope management plan (COPS Law Enforcement Tech Guide)

Provides a structured process for documenting, analyzing, and approving changes in project
scope. The scope management plan should be a formal process that is documented in the
project plan.
0 Appendix F

Scope planning (COPS Law Enforcement Tech Guide)

A process to precisely define and document specific activities and deliverables for a
particular project. Clarifies and defines the project focus and keeps activities in control and
within agreed-upon boundaries. Establishes a formal process for proactively managing
changes in project scope.

Scope statement (COPS Law Enforcement Tech Guide)

Defines what is to be included in the project, as well as what is to be excluded. Developed by
the project manager and user committee.

Scope-time-cost relationship (COPS Law Enforcement Tech Guide)

The project elements of scope, time, and cost are inextricably linked and have a
proportional relationship. Should any one of these elements grow or reduce, the other two
elements grow or reduce proportionally.

Service provider (FCC Glossary of Telecommunications Terms) ­

A telecommunications provider that owns circuit-switching equipment. ­

Shared channels
One of several means of achieving technical interoperability in which cooperating agencies
designate specific, often dedicated, radio channels for interagency use. Most public safety
radio bands have designated shared frequencies that are often used, though the term applies
generally to any channels adopted for interagency communications.

Shared system (NTFI Guide – Glossary of Terms)

A communications system developed by two or more different entities (e.g., local and state
law enforcement agencies) to share the effort of system development, maintenance, and
operations. Benefits of shared systems include lower costs, widespread interoperability,
community interaction, and shared management and control.

Signal (NTFI Guide – Glossary of Terms)

The detectable transmitted energy that carries information from a transmitter to a receiver.

Sole-source (COPS Law Enforcement Tech Guide)

A procurement tool used when an agency can show that the chosen vendor is the only
vendor capable of supplying the required hardware, software, and services in the best
interest of the agency.

Spectrum (NTFI Guide – Glossary of Terms)

The usable radio frequencies in the electromagnetic distribution. Specific frequencies have
been allocated to the public safety community.
 Glossary
0
Stakeholders (COPS Law Enforcement Tech Guide)
Individuals and organizations who are actively involved in the project, or whose interests
may be positively or negatively affected as a result of project execution or successful
project completion.

Standards-based shared system

One of several means of achieving technical interoperability in which a radio system based
on open standards serves multiple agencies.

Statement of Work (SOW) (COPS Law Enforcement Tech Guide)

Included as an exhibit in a contract, the SOW defines each task involved in the entire
project. It is the blueprint for implementation.

Steering committee (COPS Law Enforcement Tech Guide)

Members are generally high-level managers and/or supervisors within the agency. This
group will ensure that a structured project management process is adopted and followed.
Provides constant guidance and oversight to the project, its progress and deliverables, and
will make most decisions related to the project.

SWOT (COPS Law Enforcement Tech Guide)

An acronym sometimes used in referring to a situation assessment, SWOT stands for
Strengths, Weaknesses, Opportunities, Threats (see Environmental Scan).

System (NTFI Guide – Glossary of Terms)

Any organized assembly of resources and procedures united and regulated by interaction of
interdependence to accomplish a set of specific functions.

Systems development lifecycle (SDLC) (COPS Law Enforcement Tech Guide)

A cyclical process regarding IT, with several stages, including planning, procurement,
implementation, and management.

TCP/IP
See Transmission Control Protocol and Internet Protocol.

Task force interoperability (FCC PSWAC Final Report)

This involves federal, state, and/or local agencies using portable and/or covert radios,
requiring extensive close-range communications, and roaming in and out of infrastructure
coverage. Normally, prior planning opportunity exists.

Technical committee (COPS Law Enforcement Tech Guide)

Includes technical staff from the agency, as well as others from the agency’s parent
organization (e.g., city, county, or state), if such support is provided. This committee’s
role is to analyze the agency’s existing technical environment and to research and propose
solutions to the agency’s business needs and problems.
0 Appendix F

Technology baseline report (COPS Law Enforcement Tech Guide)

A report that documents an organization’s current technology environment. Created by
the project manager with assistance from the technical committee, it is used to show how
the current technology is used, as well as to determine how new technology could improve
efficiency. The technology baseline report is also used in the procurement process.

Telecommunications Industry Association (TIA)

TIA is a nonprofit trade association that has produced a number of networking standards.

Telephony (FCC Glossary of Telecommunications Terms)

The word used to describe the science of transmitting voice over a telecommunications
network.

Total Cost of Ownership (TCO) (COPS Law Enforcement Tech Guide)

Used in budget planning, TCO refers to the total costs associated with ownership, usage, and
maintenance of the system over time.

Transmission Control Protocol (TCP)

Part of the Internet Protocol suite responsible for ensuring that data packets are sent,
received, and reassembled in the correct order for the appropriate application using the
data. See also Internet Protocol.

Trunked radio system (NTFI Guide – Glossary of Terms)

A system that integrates multiple channel pairs into a single system. When a user wants to
transmit a message, the trunked system automatically selects a currently unused channel
pair and assigns it to the user, decreasing the probability of having to wait for a free channel
for a given channel loading.

UMTS
Universal Mobile Telecommunications System. A wideband CDMA technology for mobile
digital telephony and data intended as the successor for GSM networks. It promises data
rates approaching 2 Mbps. Also known as 3GSM.

User committee (COPS Law Enforcement Tech Guide)

Includes subject matter and business process experts for the functions to be addressed. This
committee’s role is to assist and support in creating a project charter and ultimately the
project plan. This committee will analyze existing work flows, define business processes,
look for efficiencies, and establish the requirements of any new system.

Very High Frequency (VHF) (FCC Glossary of Telecommunications Terms)

The part of the radio spectrum from 30 to 300 megahertz, which includes TV Channels 2-
13, the FM broadcast band and some marine, aviation, and land mobile services.
 Glossary
09
Vision statement (COPS Law Enforcement Tech Guide)
Written by the steering committee, the vision brings a tangible reality to what the agency
will address with the new system.

VoIP
Voice over Internet Protocol. A protocol for voice telephony over common data networks.

WiDEN
Wide Integrated Digital Enhanced Network. An enhanced version of iDEN combining
four standard channels to create 100 kHz radio channels for moderate speed data
communications. Considered to be a 2.5G wireless service. iDEN™ is a trademark of
Motorola, Inc.

Wide Area Network (WAN)

A telecommunications network connecting separate local area networks and individual
users. The Internet is considered a wide area network.

Wi-Fi
The interoperable standard for IEEE 802.11 wireless local area network implementations.
Conformance testing is carried out by the Wi-Fi Alliance, an industry group. Wi-Fi® is a
registered trademark of the Wi-Fi Alliance.

WiMAX
The interoperable standard for IEEE 802.16 wireless metropolitan area network (MAN)
implementations. Conformance testing is carried out by the WiMAX Forum, an industry
group.

Wireless LAN (WLAN) (NTFI Guide – Glossary of Terms)

A local area network that uses radio frequency technology to transmit network messages
through the air for relatively short distances, such as across an office building or college
campus. A wireless LAN can serve as a replacement for or extension to a wired LAN.

Work breakdown structure (WBS) (COPS Law Enforcement Tech Guide)

A component of the scope statement. Dissecting scope by breaking it down into smaller
elements or projects produces specific deliverables and indicates who is responsible for
enacting them. This ultimately defines activities and milestones of the full project scope.

XML (World Wide Web Consortium – W3C)

Extensible Markup Language. A simple, very flexible text format derived from SGML (ISO
8879). Originally designed to meet the challenges of large-scale electronic publishing, XML
is also playing an increasingly important role in the exchange of a wide variety of data on
the web and elsewhere.
 Appendix G:
SAFECOM
Interoperability
Continuum
 Appendix G:
SAFECOM Interoperability
Continuum
The following is provided by the U.S. Department of Homeland Security (DHS), Science and
Technology Directorate’s Office for Interoperability and Compatibility’s SAFECOM Program.

Interoperability Continuum: A tool for improving public safety communications and

interoperability.

Overview
The Interoperability Continuum is designed to help the public safety community and local,
tribal, state, and federal policy makers address critical elements for success as they plan and
implement interoperability solutions. The five elements of the continuum are the following:
1. Governance.
2. Standard operating procedures (SOPs).
3. Technology.
4. Training and exercises.
5. Frequency of use of interoperable communications.

The Interoperability Continuum was developed in accordance with the SAFECOM

Program’s locally driven philosophy and its practical experience in working with local
governments across the nation. This tool was established to depict the core facets
of interoperability according to the stated needs and challenges of the public safety
community and will aid public safety practitioners and policy makers in their short- and
long-term interoperability efforts.

Communications interoperability refers to the ability of public safety agencies to talk across
disciplines and jurisdictions via radio communications systems, exchanging voice and/or data
with one another on demand, in real time, when needed, and as authorized.

Making progress in all aspects of interoperability is essential, since the elements are
interdependent. Therefore, to gain a true picture of a region’s interoperability, progress along
all five elements of the continuum must be considered together. For example, when a region
procures new equipment, that region should plan training and conduct exercises to make the
best use of that equipment.
1 Appendix G

To drive progress along the five elements of the continuum and improve interoperability,
public safety practitioners should observe the following principles:
• Gain leadership commitment from all disciplines (Emergency Medical Services (EMS),
Fire, Law Enforcement)
• Foster collaboration across disciplines through leadership support
• Interface with policy makers to gain leadership commitment and resource support
• Use interoperability solutions on a regular basis
• Plan and budget for ongoing updates to systems, procedures, and documentation
• Ensure collaboration and coordination across all elements (Governance, SOPs,
Technology, Training/Exercises, Usage).

Leadership, Planning, and Collaboration

In addition to progression along the five elements of the continuum, regions should focus
on planning, education, and outreach, and maintain an awareness of the specific issues
and barriers that affect a particular area’s movement toward increased interoperability. For
example, many regions face difficulties related to political issues and the relationships within
and across jurisdictions and disciplines (e.g., EMS, Fire, Law Enforcement). Leadership can
help to work through these challenging internal and jurisdictional conflicts as well as set the
stage for a region’s commitment to the interoperability effort. Additionally, leaders must be
willing to commit the time and resources necessary to ensure the success of any interoperability
effort. For example, ongoing maintenance and support of the system must be planned for and
incorporated into the budget.

Sustainability
Communications interoperability is an ongoing process, not a one-time investment. Once a
governing body is set up, it must be prepared to meet on a regular basis, drawing on operational
and technical expertise to plan and budget for continual updates to systems, procedures, and
training and exercise programs. If regions expect first responders to use interoperable equipment
on a daily basis, supporting documentation and the installed technology must be well-maintained
with a long-term commitment to upgrades and eventual replacement of equipment.

Lastly, an interoperability program should include both short- and long-term solutions. Early
successes can help motivate regions to tackle more time-consuming and difficult challenges. It is
critical, however, that short-term solutions not inappropriately drive the planning process, but
function in support of longer-term improvements.
 Interoperability Continuum
1
Interoperability Continuum Elements
Governance
A common governing structure for solving interoperability issues will improve the policies,
processes, and procedures of any major project by enhancing communication, coordination,
and cooperation, establishing guidelines and principles, and reducing any internal jurisdictional
conflicts. This group should consist of local, tribal, state, and federal entities, as well as
representatives from all pertinent public safety disciplines within the identified region. A formal
governance structure is critical to the success of interoperability planning.
Individual Agencies Working Independently – A lack of coordination among
responding organizations. ­
Informal Coordination Between Agencies – Loose line-level or agency agreements that
provide minimal incident interoperability.
Key Multidiscipline Staff Collaboration on a Regular Basis – A number of agencies and
disciplines working together in a local area to promote interoperability.
Regional Committee Working with a Statewide Interoperability Committee
– Multidisciplinary agencies working together across a region pursuant to formal written
agreements as defined within the larger scope of a state plan. Such an arrangement promotes
optimal interoperability.

Standard Operating Procedures

Standard operating procedures are formal written guidelines or instructions for incident response.
SOPs typically have both operational and technical components.
Individual Agency SOPs – Uncoordinated procedures across agencies that can hinder
effective multidiscipline/multiagency response. ­
Joint SOPs for Planned Events – The development of SOPs for planned events. This typically
represents the first phase as agencies begin to work together to develop interoperability.
Joint SOPs for Emergencies – SOPs for emergency-level response that are developed as
agencies continue to promote interoperability. ­
Regional Set of Communications SOPs – Regionwide communications SOPs
for multiagency/multidiscipline/multihazard responses; an integral step toward
optimal interoperability.
National Incident Management System-Integrated SOPs – Regional SOPs molded to
conform to the elements of the National Incident Management System.
1 Appendix G

Technology
Although technology is a critical tool for improving interoperability, it is not the sole driver
of an optimal solution. Success in each of the other elements is essential to its proper use and
implementation, and should drive technology procurement.

Technology is highly dependent upon existing infrastructure within a region. Multiple technology
solutions may be required to support large events.
Swap Radios – Swapping radios, or maintaining a cache of standby radios, is an age-old
solution that is time-consuming, management-intensive, and may only provide limited results
due to channel availability.
Gateway – Gateways retransmit across multiple frequency bands, providing an interim
interoperability solution as agencies move toward shared systems. However, gateways are
inefficient in that they require twice as much spectrum because each participating agency must
use at least one channel in each band per common talk path, and because they are tailored for
communications within the geographic coverage area common to all participating systems.
Shared Channels – Interoperability is promoted when agencies share a common frequency
band, air interface (analog or digital), and are able to agree on common channels. However, the
general frequency congestion that exists across the United States can place severe restrictions
on the number of independent interoperability talk paths available in some bands.
Proprietary Shared Systems and Standards-based Shared Systems – Regional shared
systems are the optimal solution to interoperability. While proprietary systems limit the user’s
choice of product with regard to manufacturer and competitive procurement, standards-based
shared systems promote competitive procurement and a wide selection of products to meet
specific user needs. With proper planning of the talk group architecture, interoperability is
provided as a byproduct of system design, creating an optimal technology solution.

Training and Exercises

Proper training and regular exercises are critical to the implementation and maintenance of a
successful interoperability solution.
General Orientation on Equipment – Agencies provide initial orientation to their users with
regard to their particular equipment. Multijurisdiction/multiagency operations are often an
afterthought to this training, if provided at all.
Single Agency Tabletop for Key Field and Support Staff – Structured tabletop exercises
promote planning and identify response gaps. However, single agency activities do not
promote interoperability across disciplines and jurisdictions. Additionally, management and
supervisory training is critical to promoting routine use of interoperability mechanisms.
Multiagency Tabletop for Key Field and Support Staff – As agencies and disciplines begin
working together to develop exercises and provide field training, workable interoperability
solutions emerge.
 Interoperability Continuum
1
Multiagency Full Functional Exercises Involving All Staff – Once multiagency/
multidiscipline plans are developed and practiced at the management and supervisory level, it
is then critical that all staff who would eventually be involved in actual implementation receive
training and participate in exercises.
Regular Comprehensive Regional Training and Exercises – Optimal interoperability
involves equipment familiarization and an introduction to regional/state interoperability at
time of hire (or in an academy setting). Success will be assured by regular, comprehensive, and
realistic exercises that address potential problems in the region and involve the participation of
all personnel.
Despite the best planning and technology preparations, there is always the risk of the
unexpected—those critical and unprecedented incidents that require an expert at the helm
who can immediately adapt to the situation. Within the Incident Command System (ICS),
these specialists are called Communications Unit Leaders. The role of the Communications
Unit Leader is a critical function that requires adequate training and cannot be delegated to
an individual simply because that person “knows about radios.” Rather, the proper training
of these individuals is of significant importance to a region’s ability to respond to unexpected
events, and it should prepare them to manage the communications component of larger
interoperability incidents, applying the available technical solutions to the specific operational
environment of the event.

Usage
Usage refers to how often interoperable communications technologies are used. Success in
this element is contingent upon progress and interplay among the other four elements on the
Interoperability Continuum.
Planned Events – Events for which the date and time are known. Examples include athletic
events and large conferences/conventions that involve multiple responding agencies.
Localized Emergency Incidents – Emergency events that involve multiple
intrajurisdictional responding agencies. A vehicle collision on an interstate highway is an
example of this type of incident.
Regional Incident Management – Routine coordination of responses across a region that
include automatic aid fire response, as well as response to natural and manmade disasters.
Daily Use Throughout Region – Interoperability systems that are used every day for
managing routine and emergency incidents. In this optimal solution, users are familiar with the
operation of the system and routinely work in concert with one another.
1 Appendix G
Interoperability Continuum
19
 For More InForMatIon:

U.S. Department of Justice

Office of Community Oriented Policing Services
1100 Vermont Avenue, N.W.
Washington, DC 20530

To obtain details on COPS programs, call the

COPS Office Response Center at 800.421.6770

Visit COPS Online at www.cops.usdoj.gov