iOS 12 – Legacy 911 Meets its Match

On Monday, September 17, 2018, the very first nail in the coffin of the legacy 911 network will be firmly planted and driven home. Apple is set to release iOS 12 that contained several new features and enhancements, one of them being “EES,” Enhanced Emergency Services. In a white paper published in August of this year, Apple announced their Hybridized Emergency Location (HELo) technology providing precise, high integrity location data to 911 centers.

The white paper states, “Apple devices contain a variety of location sensors. […] Apple devices can “fuse” information from various sensors, such is [GPS] and Wi-Fi. [The technology provides] a low uncertainty, high integrity estimate of the devices location.”

As it was in the past
HELo is a radical and revolutionary step forward. Currently, the only source for location on a cellular device has been the wireless carriers, who provide this location information through often very inaccurate triangulation calculations. These give much less precise location information, or even worse, merely the cell tower handling the call. This causes a significant problem for those who cannot communicate precisely where they are because they either don’t know or are not capable of speaking. This is a problem for the deaf and hard of hearing community, as well as for individuals with speech disabilities. These individuals are forced through relay centers, outside of the 911 network, that have zero visibility into any location information.

As it will be going forward
HELo is the United States adaptation, of a technology that’s been operating in the European Union for a few years, called AML (Advanced Mobile Location) and operating on Android devices since last year. The concept is simple and initiated initially by John Medland at BT in England. HELo, AML operate nearly the same, conceptually, and even the European eCall (the EU version of OnStar) initiative follows a similar approach on the backend consumption of the data.

How it works

Screenshot 2018-09-16 14.07.49
When your cellular device initiates an emergency call, the voice call is sent to the legacy 911 network as it is today. The wireless carrier uses the cell tower information to route your request to the closest Public Safety Answer Point or 911 PSAP. At the exact same time, HELo takes the location data from your phone (the precise same location data that Uber and Domino’s uses in their app) and places that in a National NexGen 911 Clearinghouse Data Repository with your telephone number as the index reference. When the 911 center gets your emergency call, they initiate the standard database queries to the carrier and are displayed the legacy location parameters, but many 911 desktop application providers have added the functionality to immediately make a secondary query to the National NexGen 911 Clearinghouse Database. The location from that response is often exact and considered to be “high fidelity”. The 911 call taker gets a second plot displayed on their display along with the original location accuracy estimates from the carrier.

Where it will work
While native support for EED will be available to compatible Apple devices when they do the free software update to iOS 12, some carrier networks may block or impair the service from operating as designed. For example, not all networks support simultaneous voice and data. So, if a carrier prevents the outbound data connection, the device would only be able to communicate the location payload over a Wi-Fi connection. I experienced this phenomenon two years ago when Avaya was testing similar technology being accessed through HTML 5. Our initial tests went perfectly, but we happened to make a check in an area where my connection was downgraded from LTE to 3G. Under these conditions, my carrier blocked external data connections during a voice call that was an emergency. It was a perfect example of legacy thinking bubbling through current technology impeding innovation. I had to actually file formal complaints with the FCC against several carrier networks to get this practice changed and removed, under the basis that it had no merit in today’s environment.

Privacy – Everyone’s concern
I am sure that Apple is going to maintain confidentiality and security as a core value. Apple has stated that they will take “extra steps to ensure that our products and services protect the confidentiality, integrity, and availability of our users data during an emergency call.” to enforce this stance on the issue, Apple plans to use Geofiltering to minimize the potential for disclosure even to trusted parties that are not associated with the incident. Also, if the PSAP servicing the user’s location has not opted in to receive this new information, the data is dropped and not stored.

Security – Data Encryption
Data between the user’s device, the RapidSOS clearinghouse database, and the PSAP is all encrypted with strong ciphers and long keys. Additionally, the data remains encrypted while in transit, and even at rest in the databases.

Data Longevity
To prevent a future data breach from yielding information about previous events, Apple discards all data that fails to match geolocation criteria of a PSAP servicing that location, and all data is deleted after 12 hours. Any information that is sent to the RapidSOS clearinghouse database follows the same guidelines. Any data that is ultimately transmitted to a PSAP, state and local records retention laws apply and are up to the receiving agency to enforce as with all data they received today.

Thanks – Not for me . . .
I sat racking my brain trying to figure out a reason why you would NOT want this service activated, but unfortunately, came up blank. Even with that being the case, Apple has provided an opt-out capability, and EED, although enabled by default, can be easily deactivated and disabled in the settings app of an iOS device at any time.

I’m excited
While this new capability is currently limited to Apple iOS 12 devices, this puts in place a key component for next-generation emergency services in the United States. The National NG 911 Clearinghouse, officially known as an ADR (additional data repository) is a crucial element in the transition from the legacy network to next-generation 911 capabilities for all devices. This element must exist for originating devices to place their data in and will serve as a DMZ boundary for PSAP’s to reliably trust adding explicit information to emergency call events.

While the legacy 911 databases remain an essential source of information today, the implementation of architectures like this allows intelligent networks and devices with relevant information not only about the location but situational awareness of the environment, to now have a mechanism and pathway to public safety first responders that can utilize this information.

Knowing that Mark Fletcher sits at cube 2C – 231 is irrelevant information that isn’t actionable because first responders have no idea where that is without a map of my building. Now I can provide them with a floor plan, as well as the fact that it’s 185° at that location. Hmmmm . . . That’s a little warm. Maybe something’s on fire?

That’s actionable data, and worth formulating a system to collect, correlate and propagate to public safety.

Follow me on Twitter @Fletch911
Check out my AVAYA CONNECTED Blogs

fletch-sig

 

Technology Overlaps – Kari’s Law, Panic Buttons and NG911

To listen to an audio podcast of this blog  [  CLICK HERE  ]

More than four years ago, I published an article on my Avaya CONNECTED blog written by my friend and colleague, Ty Wooten, ENP. Ty is NENA’s director of PSAP Operations and Training, and he along with Maureen Will, director of Emergency Communications at Newtown, Conn., contributed a great article on school safety.  Since that time, the relevance and importance of communications between 9-1-1, local first responders and school officials have increased even more.  Every month brings a new tragic shooting, often in a school. The lessons learned on how to minimize the impact of these events remains the same – improved communication. Recent articles out of Nassau and Suffolk Counties in New York are focusing on the deployment of a software panic button technology there, and this has an intriguing overlap with E9-1-1, Kari’s Law (first enacted in Suffolk County), and the evolution of Next Generation 9-1-1 (NG9-1-1) technologies.

The Communication Gap

It’s well-documented in several studies that most active shooter incidents are over within 5 minutes to 12 minutes.  Likewise, the average response time for public safety personnel ranges from 13 minutes to 18 minutes. The Naval Post Graduate School, the State of Massachusetts, the FBI and NYPD research projects all point to two key factors in reducing the casualty impact in these incidents:

  1. Improved communications
  2. Victim-initiated notifications

What “victim initiated” basically boils down to is the person who is closest to the situation initiates the alarm as quickly as possible, notifying authorities as well as any collateral population, such as faculty and students.  Confusion and procedural missteps can occur when a call for help gets intercepted and is“triaged” by untrained staff. One has to ask “Why?!”  It seems that all too often systems notify the administrator or front desk, where it is expected that the call will be answered and evaluated, and then responders are notified.  This scenario, to the uninitiated, may sound efficient but it’s a stark reminder of how hotels configured their PBXs to intercept calls to 9-1-1 internally. As a result of Kari Hunt, a mother of three died in 2013. Why? A failure in communications. 9-1-1 was not able to be dialed, and no notification was made to anyone.

The Rave Panic Button, which is a software solution being deployed in Long Island, N.Y.,  took the basic concept of an on-site notification that is inherent in Kari’s Law and applied it to cellular phones (where 80 percent of 9-1-1 calls originate from). 9-1-1 remains a critical communication point and needs to stay involved to properly coordinate the response. Simultaneously, individuals on-site get situational awareness around the event and can initiate appropriate preparations.  In line with this, regardless if 9-1-1 is dialed from the PBX, natively on a cell phone, or a physical device is activated either from a dedicated panic button on the wall, or an app that simulates the same capability directly, on-site notifications are sent to the designated individuals with situational awareness, while the call is directed to the 9-1-1 PSAP.

As the call is answered by 9-1-1, notifications are sent to the Rave app and update the status.– This step alone is valuable in reducing mass call events and call overload at the PSAP.  Finally, and perhaps most importantly, the call taker now has an intelligent link and the ability to push follow-on information and notifications to personnel on site. As Maureen and Ty highlighted in their article, 9-1-1 is essentially incident command for the duration of these incidents. The ability to manage all resources, including providing critical updates to individuals on-site can be invaluable.  Just imagine, if 9-1-1 had been able to provide notice to those evacuating the Parkland school that the fire alarm was false and just a diversion and that they should remain in lockdown, lives may have been saved.

 

Does this fit with NG9-1-1?

Without a doubt, I am one of the biggest proponents of Next Generation 9-1-1, but it amazes me that I still find people that feel (coupled with FirstNet), NG9-1-1 will automatically solve all of Public Safety’s communication challenges, and the world will now have rainbows and unicorns. SORRY,  that’s NOT going to happen.  While NG9-1-1 will be an enabling technology providing a base framework for powerful applications, it is not in itself the answer to the problem. Take, for example, the additional location data repository and additional caller data repository that are functional NG9-1-1 elements. The challenge is that while NG9-1-1 specifies these elements, outside of the Avaya SENTRY™ solution, we rarely see anyone providing a source of additional data for public safety’s use.  While some municipalities have gone through the exercise of collecting floor plans, these plans are usually gathered at the time of construction and are rarely updated. Data is good, but inaccurate or old data is useless. That being the case, while NG9-1-1 and FirstNet provide the architecture and pipeline to get data to first responders, we still need a source of GOOD DATA to make any impact on the operational effectiveness and response.

 

There are examples of CAD systems supporting additional data, and the Avaya SENTRY and BETA 80 example we demonstrated last year at NENA and APCO proved the “over-the-top model” we presented to the FCC in 2012. Rave also built an “over-the-top” approach, providing a simple way to “crowdsource” any additional data, validate it through a public safety approval workflow, and then keep the data updated. The data ultimately expires or is “aged” out when it becomes no longer current.  Existing NENA i3-compliant interfaces allow any application to ingest the data, as well as responders and on-site personnel directly. In fact, Rave’s mobile interface provides that exact functionality.  Indoor location accuracy continues to improve, and National Clearing House NG9-1-1 repositories from RapidSOS are emerging. There is now a huge need to collect and maintain floor plans as a key component of making the improved location information actionable for responders.

Improving safety, whether at a school or in a hotel room, is never a one-size-fits-all approach, but we owe it to the public we serve to identify ways to improve collaboration and communication around incidents that occur with alarming and increasing, frequency.