Cybersecurity experts often refer to the dangers to an enterprise in terms of their threat surface—all the ways in which a hacker could break into systems to access data or otherwise do harm. In some ways, municipalities do the same when they structure their public safety resources and infrastructure as they seek to protect their residents and property. They assess all the ways in which criminals, accidents and mother nature can do harm. They invest in emergency communications and first responders, and they engage with their neighboring cities and towns to exchange a helping hand when needed.
But as with cyber, the scale of threat surfaces for any particular municipality seems to be expanding rapidly and beyond the original scope of an emergency communications center (ECC) plan or reach. In addition to a flood, cable cut, power outage, or ransomware attack that might shut down an ECC and route emergency calls to an adjacent town or county, the news is now unfortunately filled with threats of regional or multi-state outages to larger portions of the national power or information communications grid at the hands of bad actors.
This is just our geopolitical reality today, and it forces us to rethink how we draw boundaries around the threat surfaces to the public that we serve. As we migrate our emergency communications from the legacy TDM (time-division multiplexing) networks to next-generation IP-based (Internet Protocol) networks, continued attempts to build proverbial moats around jurisdictions might become harder to accomplish and harder to manage going forward. The internet world knows no such boundaries. And as the public safety market builds ESInets (Emergency Services IP Networks) on the march toward NG911 (Next Generation 911), we may need to take a hard look at how we draw those boundaries, particularly when it comes to the redundancy and interoperability we need and expect.
NG911 provides for a future of faster and more resilient emergency communications. The use of internet protocols will allow for more effective transmission of valuable media, including incident IDs, caller verification, video, and other incident-related imagery, with ESInets providing the foundation for network resiliency and interoperability between PSAPs sharing data and resources. The i3 standards from NENA define that vision with an end-state architecture (we’ll come back to that) for the industry to follow:
According to the NENA Knowledge Base, “i3 refers to the NG9-1-1 system architecture defined by NENA, which standardizes the structure and design of Functional Elements making up the set of software services, databases, network elements and interfaces needed to process multi-media emergency calls and data for NG9-1-1."
Fully implemented, i3 will allow public safety vendors and providers to future-proof 911 systems and workloads that might be needed down the road, as well as take full advantage of information technologies such as cloud and edge computing. ESInet providers, such as Intrado, are fully on board with i3 and the capabilities it provides to dynamically engage and interact more with the public and the Internet of Things during emergency incidents and crises.
On the macro level, in the aggregate, that vision holds. But, in the world of information and communication technology, there always seems to be an underlying risk in such transformation: suboptimization.
What do I mean by that? Well, whenever an industry takes on such a monumental change, it’s natural to want to break up that effort into manageable programs and tasks. You already see some of that in the apprehension around video and alarm or sensor-based RFAs (Requests for Assistance). There is a resistance, rightfully so, to overwhelming a PSAP or telecommunicators. The response tends to be to take on such change one step at a time while trying to keep workloads and workflows as stable as possible.
In the case of ESInets, perhaps that might result in adopting a solution with as small a footprint as possible—within a multi-county region or state—maintaining what seems like as much control as possible. The assumption in that approach appears to be that as long as the solution is in compliance with i3, then there will naturally be guaranteed interoperability with any other PSAP that is also in compliance. Aka, suboptimization.
That interoperability guarantee might hold true, yes, with the type of standards setting in, say telecommunications, where a 3GPP [3rd Generation Partnership Project within the European Telecommunications Standards Institute] protocol release defines not just the vision for a new service like 5G, but the technical specification for the entire ecosystem, including the core network, radio access network, and user devices. Your 5G phone must work with any network operator, anytime, anywhere, and the standardization and testing rigors ensure that interoperability.
But with an end-state architecture like i3, the roadmaps to get from here to there aren’t as clearly specified. It’s just telling us how things should look—the functional elements, as they describe—when we get there. Such a reference architecture lets you know when you’re in compliance but doesn’t necessarily dictate the development and implementation of products and solutions within the NG911 ecosystem.
In the end, a pragmatic, practical guarantee of ESInet interoperability will likely come from either extensive (and perhaps expensive) interoperability testing across solutions and geographies—continuous testing programs as standards and solution features evolve—or the adoption of a scalable, nationwide ESInet where the scale is built into the solution.
Why might scale be important to an ECC or a state office of emergency services? The term scale usually connotes massive and heavy-weight applications that may not be as customizable to local needs. But what if the benefits of scale can address the scale of uncertainty that seems to be growing in a more interconnected and unpredictable society? A nationwide ESInet is built with the “carrier-grade” investment and performance of a scalable telecommunications network. Carrier-grade architectures include:
-
5-9s (99.999%) Availability
-
Multicore capacity (the ability to handle multiples of peak call loads)
-
The ability to upgrade components or features seamlessly and with minimal disturbance
-
Not directly peered with (or exposed to) the Internet
-
Distributed, i.e., simply, the network won’t fail
-
Encrypted, with a zero trust edge (a topic that I will address in a subsequent blog)
I get that future-proofing may not necessarily be a top priority for everyone, and hard decisions must be made as to how to invest limited funds across so many complicated challenges. So, if you’re a municipality that is comfortable that you have all your worst-case scenarios covered and you are comfortable with your IT systems investment and controls, then such scale might seem like overkill, I guess. But, if the dangers to your community seem like they might not abide by the lines on a map, then the ability to draw on resources in places you hadn’t even considered yesterday might not seem so far-fetched.
