NG911: Too Little Data – 2ManyApps?
This Avaya CONNECTED Blog
is also available as an MP3 Audio File
NG911 promises to bring public safety into the 20th century from a communications perspective. In the legacy E911 network, we are limited to analog-based voice only communications, and the location data is tied directly to a telephone number, which in today’s environment, is one of the last pieces of data that is relevant to a location of the communications device. In 2011, NENA, the National Emergency Number Association, published their specification 08-003 as the Detailed Functional and Interface Standard for the NENA i3 Solution. The specification built upon prior NENA publications including i3 requirements and architecture documents.
In version 1 of this document the i3 solution supports end to end IP connectivity with gateways used to accommodate legacy wireline and wireless origination networks that are non-IP. It also introduced the concept of an Emergency Services IP network or ESInet. The ESInet is an IP-based internetwork (network of networks) that is shared by all public safety agencies, and eventually provide coverage coast-to-coast, internationally, and ultimately around the globe.
The value behind the ESInet to public safety, is as great as the Internet was to the general public. It wasn’t that long ago that data was not easily shareable between two points on the planet. Today, with Facebook, Twitter and the thousand other social media outlets, sharing data has become a ubiquitous part of our daily lives.
It only makes sense that social media, and the additional data that it carries, will become part of our public safety networks. Yet another reason that our current legacy E911 infrastructure is unable to perform its required task of connecting the general public with public safety using the forms of communication that are in common use.
This change in the data that we want to communicate with public safety, as well as the mechanisms in which we communicate that information, has created a technology gap between the people who need help, and the people that can provide that help. 2012 saw the emergence of several Personal Emergency Applications or PEAs (pronounced peas) trying to capture the popular App market. Unfortunately for the developers of these applications, they were quickly shunned by the emergency services community, as quite often the developers did not take into consideration the public safety side of the application. One particular application, CrimeWatch, provided users with a simple one touch interface for police, fire, and medical assistance. Not a bad deal for $.99, right? The only problem is, that application had no connectivity to the public safety network, and when a user used it, after entering in all of the pertinent data, it offered to dial 911. This horror story quickly circled the public safety community, and the application got an incredible amount of that press.
In another incident, concerns were raised about letters that were sent by 911 Emergency Assist (911 EA) to many PSAPs advising them of the launch of their product. The letter was worded in such a way that led several 911 administrators to believe this product was more than it actually was, and NENA had to step in and “assist” in addressing PSAPs training and how they are marketing their product.
[Ed. Note: A recent Google search on Crime Watch and 911 EA came back with dead links]
As the NENA i3 framework continues to evolve, version 2 of this specification adds in additional functionality and, among other things, the concept of additional data. Additional data about a 911 call can be provided in the form of a SIP URI that the public safety answer point can query for more details about a specific call event. One of the primary challenges of this topology is the sheer number of endpoints where that additional data can exist. To solve this problem, Additional Data Aggregators have emerged that provide common collection points and repositories that the public and public safety can access to store and retrieve additional information data.
Although similar in nature, core differences exist between each solution. And with the lack of an industry “standard”, there could be significant operational differences. In examining both solutions, the primary difference is: where the data is stored. Smart911 is made up of two components. The first is a scalable method for public safety to allow citizens to opt in to providing critical information. The second is a scalable and secure method for aggregating data from external sources and displaying it in the proper context during the call taking process. No matter where I travel if the PSAP uses Smart911, my profile will be available.
Safetown, on the other hand is tied to a specific computer aided dispatch or CAD system, and is typically stored locally. Although similar data is provided by both systems, the inherent problem is sharing that data across to regional boundaries or with different CAD systems within a single jurisdiction for example fire and police. Unless agencies share their network and data with each other, my personal profile data, although useful locally, is not available to other agencies outside of my area.
Not an issue for location specific data, as my home and office are fixed points, but my personal data is relevant anywhere I go in the US, or globally for that matter.
The purpose of this blog is not to compare these two companies against each other, or any others that are barking up this new tree of opportunity. The point that I’m bringing out is that additional data is going to become a big part of next generation 911 and that universal guidance on accessing that data is going to become a paramount problem for the 6100 public safety answer points, as well as training for the 200,000 911 call takers in the US alone. There simply is no room for vendor specific applications and processes. The collection, correlation, and presentation of this information needs to be standardized and promulgated throughout the industry.
Ask anyone at NENA or EENA; The emergency network in the US as well as the EU is on the verge of a radical change in technology. For most of us, social media, collaboration, video conferencing, and living in a “connected world” is of no consequence to our daily existence. Public safety on the other hand has been relegated to using 1970s technology for the last 45 years, and needs to play catch-up fairly quickly. Fortunately, the first wave of “connected citizens” are now of age and actively working in this industry. Many of them have even obtained positions in their agencies where their new way of thinking can make a radical change. Just as we saw voice over IP become the new paradigm in communications over the last few decades, next generation emergency services, and the vast amounts of additional data that will be brought along with it, will form the framework of the next paradigm of public safety communications.
How lucky are we to be able to watch its birth, and evolution?
Want more on E9-1-1? E9-1-1 Talk Podcast
Subscribe to my weekly E9-1-1 Talk Podcast here
Thanks for stopping by and reading the Avaya CONNECTED Blog on E9-1-1, I value your opinions, so please feel free to comment below or if you prefer, you can email me privately.
Public comments, suggestions, corrections and loose change is all graciously accepted 😉
Until next week. . . dial carefully.
Be sure to follow me on Twitter @Fletch911
APN is Powered by Cachefly
CacheFly is the world’s fastest CDN, delivering rich-media content up to 10x faster than traditional delivery methods. With a proven track record and over a decade’s worth of CDN experience, companies around the world choose the CacheFly CDN for reliable and unbeatable performance. For more information, visit www.cachefly.com