FOR AN AUDIO VERSION OF THIS BLOG: CLICK HERE
The most critical question for a 911 call taker is, “Where is your emergency?”
The post office can efficiently deal with street addresses to deliver your mail; 911 call takers can use that to get the proper resources to a residence, but what about locating you in a large, multi-story enterprise building?
Google’s headquarters in Mountain View, California, is located on a 26-acre campus located at 1600 Amphitheater Parkway. But that address encompasses several buildings with many outbuildings and internal campus roads. This so-called ‘Googleplex‘ is more of a small city than just a simple address, and it houses several thousand employees daily. How is it possible to locate an individual caller inside of 3,000,000 ft.² of a facility and communicate that in an understandable way to Public Safety? Even if I tell you it’s Building 7 office 329–4C–178–B1, that information is not relevant to a 1st responder without some visual guidance or assistance. It is as cryptic as saying my red speakers have purple shoelaces. The data is very descriptive; however, completely irrelevant. While IP telephony devices, wireless laptops with softphones, and even smartphone communicator applications can all provide an unprecedented level of mobility for the enterprise voice user, the methods for classifying devices on the network only deal with the application or role of the device or user. This information rarely considers the device location, at least at the level of actually providing a usable location of the device.
As it turns out, using a subnet or IP address range to locate a device still leaves an unacceptable amount of location ambiguity. They may provide enough detail to isolate a general area, but even that becomes a data management issue. Subnets often span multiple floors and even various buildings. They may be service-specific for an application and physically extend beyond a specific area making the location information unreliable for emergency location reporting.
FOR AN AUDIO VERSION OF THIS BLOG: CLICK HERE
Another solution to obtain better accuracy is to utilize ‘data switch port mapping,’ also referred to as Layer 2 mapping. The issue here is that the data switch port information does not indicate the actual device location without an accurate cable record database. Furthermore, any patch cable moves in the IDF closet corrupt those cable records, and the fact that a cable record database in the enterprise is as tricky to find as a black cat in a coal cellar.
Often an innovative solution to a difficult problem doesn’t evolve without ignoring the existing technology. This innovation is what occurred with the 911inform LDS Location Discovery Solution. With the penetration of cell phones being over 120% in the US, nearly everyone has one. Knowing this, why not use them as a helper’ location beacon’ to determine location? Device registration events provide user ID, the extension number, and the unique physical MAC address of each specific device, allowing multiple devices with the same number to have different unique locations.
A standard query of the network provides the information needed to determine if the device has been off-line and the physical connection information. Supposing all of that information remains the same, an assumption is made that the device has not moved. If the information is different, the 911inform LDS application can reach out to the current user and deliver a link to their smart device or email requesting location verification. Clicking that link loads an HTML5 webpage extracting the device location and presents the user with the best guess location estimation, which is typically accurate within a few feet. The user confirms their location, and the 911inform LDS internal location database entry for that device is updated. When a device is found in a corporate facility, the user is presented with a floorplan overlaid on an aerial view, and if off property, a Google Maps view is shown to the user of their location.
FOR AN AUDIO VERSION OF THIS BLOG: CLICK HERE
Then, should that device initiate an emergency call, the collected location information is instantly populated into a ‘shell record’ with the specific dispatchable location information and sent to the RapidSOS NG911 Additional Data Repository, providing the exact location of the endpoint to the PSAP. Because of this immediate delivery of the device location to Public Safety, the need to have multiple pre-populated records for each device is eliminated. This new information dramatically reduces the solution’s overall cost by eliminating the need for an external ANI/ALI database. It also eliminates the need for a system that manages that information and the recurring expense of maintaining it.
For years, the NG911 architecture has promised a better, more functional emergency services network capable of delivering multimedia and multi-modal information to public safety in near real-time. Thanks to RapidSOS, that capability is now available to over 95% of the population and is being used to collect detailed explicit location from cellular phones over 150 million times a year. Now that same technology is available to the enterprise on 911 calls placed from analog, digital, and IP devices no matter their location or connection. On-premise, working remotely at home, or out in a public space connected on a hotspot, the 911inform LDS solution locates devices when they register and provides the information needed to route emergency calls correctly, with the precise device-level location. Enterprises can now eliminate the monthly expense of managing individual legacy 911 ANI/ALI records that provide minimal information and provide relevant real-time information when seconds count the most.
FOR AN AUDIO VERSION OF THIS BLOG: CLICK HERE
For more information on the 911inform LDS solution, visit 911inform at 911inform.com/911informlds/
STAY WELL AND BE SAFE . . .
Please follow me on Twitter @Fletch911
Be sure to check out my Blogs on: Fletch.TV
© 2020, All Rights Reserved, Mark J. Fletcher, ENP
Reuse and quote permitted with attribution and URL
The World According to Fletch . . . 