Tag: Avaya

Fixing 911 Overload

Every year, NENA – The National Emergency Number Association – estimates that there are over 240 million calls into 911 call centers (known as Public Safety Answer Points or PSAPs). A common problem among all PSAPs continues to be non-emergency calls arriving into the center on Their specialized 911 trunks that exist specifically for emergency calls. The quantity of these trunks is typically limited in each center and and the amount has been carefully engineered to handle the normal volume of 911 calls from the community served by that agency along with a few spares and diverse CO routing where available. The problem is that when they become flooded with non-emergency traffic, legitimate emergency calls could be blocked.

This design also makes the PSAP more susceptible to SWATTING and DDoS attacks by practically anyone and from anywhere. In some areas, emergency calls into a center that is busy may overflow to an adjacent PSAP. While this seems like a logical idea from a backup perspective, let’s examine the bigger picture here.

Not only does this expand the attack face from a SWATTING and DDoS perspective, it is actually quite useless unless there is a Mutual Aid and MOU agreement in place with the other agency. Without the proper authority and the radio comms infrastructure, as well as access to the CAD, there really isn’t much that those agencies can do other than answer the call and write down the information. They then need to figure out a way to get that incident to the agency that can provide service. Typically, if there is no access to the radio network of the adjacent community, or no visibility to the computer-aided dispatch or CAD system, there is little they can actually do with the information they have. Also, remember that if the call has overflowed to them in the first place, they might not even have a way of reaching the original agency using conventional methods, Where is the problem?

The Core Problem: Dedicated 911 Trunks

The existing 911 network in the US is dependent on specialized CAMA trunks. Queries for location use the Automatic Number Identification (ANI) received with the call to determine the location of the caller, and a direct peer-to-peer relationship exists between the PSAP and the local exchange carrier 911 Central Office using these single-purpose trunks.

Since these trunks are limited in number, when a non-emergency call arrives on an emergency trunk, that line becomes tied up for the duration of that call, even if the resource that handles the call is a non-emergency resource. This creates a traffic engineering problem, because now the number of trunks reserved to handle emergency calls are taking the additional non-emergency traffic, something that totally Skews the Erlang calculations used to engineer the number of circuits.

311 to the rescue?

Many believe, and cities like NYC and Philadelphia have implemented, a localized 311 non-emergency service designed to offload non-emergency calls from 911 Call centers and call takers. The call handling technology used to deliver a 311 service is similar to that in the 911 center. This allows the 311 facility itself to become a natural choice for a disaster recovery location or if a facility is needed to house a temporary relief workforce for the 911 center due to capacity or physical damage.

The fact that a 311 center exists though, does not itself provide a solution to the problem, a little more is required. The root cause of the overload issue noted earlier is that people dial 911 when they should have dialed 311. In other words, their call is arriving on the wrong network, and that wrong network has limited resources from a trunking perspective.

Are rubber bands the fix?

While fixes for critical emergency communications from the public should never use duct tape and rubber bands, “elasticity” does bring significant value. Looking back on legacy trunking, of nearly any kind, there is the limitation of a physical circuit on a pair of copper wires. If I need one, I order one. If I need 10, then I order 10. If I need 10, but I only can get 8, then I am short by 2, and there is not much I can do about it. SIP trunking, on the other hand, is delivered over a data facility. The actual bandwidth on that facility can often be dynamic and Is commonly referred to as “a pipe.”

When thinking about the characteristics of data, often it equates very nicely to water. If I need to deliver more water, I need to get a bigger pipe; if I need to deliver more data, the same concept applies. That being said, an inherent benefit of a “data pipe” is that often the delivery medium is the same regardless of the capacity or size. Now a request to the carrier can turn-up or turn-down service capacities through software or configuration. Because of this, the size of the pipe becomes elastic and flexible to my current trends and needs.

Re-engineering with new capabilities

With this new elasticity capability in our network, let’s re-engineer things a little bit to take advantage of its capabilities.

Modern NG-911 Network on Dynamic Trunks

With all of these circuits moved to intelligent SIP trunking, I now have flexibility and sizing capabilities that allow me to be more dynamic with emergency and non-emergency call center call routing. The initial overall pipe capacity reflects best guess estimations for ALL TRAFFIC, and a new control layer of communication between my premise and the carrier networks exists to communicate any changes Required in the specific trunk route sizing required.

Sending these real-time statistics and state changes to the carrier allows real-time elasticity of IP trunking size to realize the most efficient use of resources. Calls to 911 are automatically flagged as such and routed to the 911 CPE where call takers answer. Similarly, calls to 311 are automatically flagged as such and routed to the 311 CPE, where call-takers also answer those calls. By doing this, the number of simultaneous calls to each type of service is controlled by the CPE.

Should a 911 call end up being a non-emergency situation, and the call gets transferred to the 311 center for assistance, a signal is sent to the carrier to add additional bandwidth to the inbound 911 trunk group to compensate for the non-emergency call.

How bandwidth is calculated and allocated is something that now becomes totally under the control of the receiving agency. For example, let’s go back to our disaster recovery scenario. A significant natural event is impacting the local area. An anticipated  20% increase of 911 call taker staff will require 15 additional call-taker seats. In the 311 Center, 15 seats get flagged as auxiliary 911 positions and get staffed by 911 personnel. An increase in carrier bandwidth allows for the additional call volume expected.

This scenario is just another example of why the nation needs to move to NG 911 quickly. The Legacy 911 network in the US uses analog CAMA trunks that are special-purpose and fixed in their capacity. Increases must be pre-engineered and may take weeks or months to implement or sit idly unused, causing unnecessary charges to stack up to municipalities. The technology to accomplish this architecture already exists in nearly every commercial market in existence today. We should heed the lessons learned over many years and provide the same level of innovation to our most essential call centers, ones that save lives.

Mark J. Fletcher, ENP
Chief Architect – Public Safety Solutions – AVAYA

Follow me on Twitter @Fletch911
Listen to my Podcasts

2

Testing 1-2-3 . . . PART Three – Location

By: Mark J. Fletcher, ENP
Chief Architect Public Safety Solutions – AVAYA

In PART Two of this blog, we discussed the Emergency Call
Network, that segment of the PSTN dedicated to emergency calling and connecting the PSAPs together on a regional basis. In this section, we’ll cover the mobility that modern networks provide to Enterprise users, and clearly one of the most challenging pieces of information for 9-1-1 call takers to obtain.

We learned that the Selective Router in the E911 Tandem office was responsible for connecting callers to the right PSAP. That decision is made based on the Caller ID presented with the call. Initially, this was a very valid best practice, as the network was well documented, and changes were well controlled and performed by the service provider.

One Number – One Address
Telephone numbers rarely were co-located in multiple locations (with a few
exceptions) therefore the telephone number was an excellent data point usable for determining the location of a device, and the network was designed around this fact. In the mid 80’s, the Northern Telecom DMS 100 was introduced as a digital central office platform, and AT&T introduced the ESS 5 with similar capabilities.

With these new digital switching platforms, the layout inside the Central
Office radically changed from one that was mechanical stepper-motor-based to one that used a digital switching matrix, and with this automation fewer and fewer CO’s were staffed with technicians, as the building role became merely a wire center with a cross connection point for dial tone to street pairs. With the digital evolution these switches brought was a new series of custom calling features.

A Star is Born
Customers did however get some very new features, like Caller ID and feature ‘STAR-codes.’
Missed a call? Dial *69 to be connected with the last number that called. *72
along with a telephone number would forward any calls to the new destination, and depending on the services provisioned in the CO, various other features became available to customers. Many of these features took advantage of Caller ID information that was now available with the call. For the very first time, the called person could know the identity of the caller displayed on their telephone device. Caller ID (better known as Automatic Number Identification or ANI) now provided 911 centers with information about who was calling, or at least the number they were calling from. Now, if a silent call came in, or there was a question about the address and location, the original color could be easily reached. 911 centers also played games with the electrical properties on the phone lines, and it was common practice not to pass any answer or disconnect supervision from the PSAP. This providing for a simple way to keep the line open simply by
not hanging up on the public safety end.

Location, Location, Location
Without a service address, it’s impossible to send any help at the time of an
emergency. To solve this problem, 911 centers begin taking the ANI (phone
number) they were receiving with calls, in making a query back into the carrier network database that routed the call. This ALI Automatic Location Information added location to the context for wireline calls, however the cellular industry didn’t catch up, and continued to report only Phase 1 location information, which was the latitude and longitude of the radio tower the cell phone happened to connect through. With the white density of cell towers, compared to today, the effective service areas were quite large spending several miles. When cellular towers were installed on mountaintops they often lined up with political borders, once again exasperating the location problem if you’re located across the state lines hitting a remote tower due to height and proximity. This problem remained for many years, and only began to be solved as devices started to contain GPS radio receivers, but there was still an underlying problem at the network layer level.

Can You SEE Me Now?
As the density and placement of cellular towers increased, Basic radio
coverage and interoperability became commonplace. Carriers started to
interoperate with each other, and cellular handoff became a commonplace feature spanning the entire coast. Making a call with simple, but making a 911 call remained problematic. Don’t get me wrong, calls could be received and routed quite simply, however since the 911 network is a legacy analog based network, and no data channel exists to pass information on, 911 centers went into making a query to the cellular carrier asking them what visibility was available out of their network. Despite the device itself having an excellent location awareness, due to Wi-Fi fingerprints, access points, cellular towers, as well as a GPS signal when outside, the location of you what is the network looking in, and what the device had (known as handset-based location accuracy) was simply unavailable to the PSAPs, and no mechanism existed to communicate anything other than a voice path between the caller and the call taker.

Google Can Find Me . . .
Yes, I am well aware that Google, Domino’s Pizza, and a plethora of other
services are you able to locate your cellular device with incredible accuracy; in the first responders at 911 that are trying to save your life, cannot. The primary reason behind this is that because the device is utilizing an application. Also, the application has access to the device-based  location information held in the memory. This particular location information uses all of the data points that we discussed earlier, and that information is communicated back over the Internet to the host application. Once again, this is where the train goes way off the rails.

The information that is contained within the device is like having a trans-Atlantic Ocean liner that is landlocked in a lake in the middle of Kentucky. Regardless of the level of luxury, the number of passengers it holds, or the amazing abilities contained within the ship, without any use cases or access to the ocean, you’re going to have a rusting pile of steel in just a few years.

Unfortunately, this is the exact state at our Legacy PSTN network exists in
today. Consumer-based technology, the information age of the Internet, and the digital transformation that has occurred in commercial businesses, have connected the world at levels never before conceived. The devices we carry our hands and our pockets, are capable of blinding fast speeds and connectivity levels never dreamed of before. I can call, I can video, I can text, and I can email anyone on the planet; except 9-1-1. My daughter, halfway around the world on a beach in Waikiki with her boyfriend can transmit real-time high definition video from her handheld device to my handheld device 4,882 miles away with practically zero latency, but if she had a medical emergency and needed help, she would be stuck with a voice call and location inaccuracy about half mile or more if she called 911.

In any commercial enterprise space, despite be vast amount of digital
information we have available about the emergent event, the situational
awareness about the emergency, or even lifesaving information about the caller, no matter what the technology is at the origination point, the network in the receiving agency are relegated too low fidelity text based information. Why? I’m not sure I’ve gotten a good answer to that . . . . yet. But I know a few young entrepreneurs that took the problem head-on, and drove a paradigm shift change in an industry that was half a century old and very much stuck in its ways.

In Part Four of this series, we will dive into over-the-top applications, that
utilize the Internet in the open connectivity that exists nearly everywhere to take a short cut around the technology roadblocks that lay between citizens who need help, in the public safety first responders that can provide that help.

Please remember to follow me on Twitter @Fletch 911, check
out all of our other podcasts at http://www.Avaya.com/APN

Listen and subscribe on iTunes, Google Play Music, and
SoundCloud, as well as our featured content on the iHeart radio network.

0

Tackling Enterprise 911

Kari’s Law goes into effect for ALL SYSTEMS nationwide on February 16, 2020, after the expiration of a 2-year grace period allowing system administrators to become compliant. Kari’s Law requires businesses entities with multi-line telephone systems to provide the following capabilities on all phones:

  • Allow direct dialing to 911, without any prefix
  • Provide On-Site Notification when 911 is called
  • Route 911 calls directly to the local 911 PSAP

Avaya Partner Altura Communications has started a public awareness campaign in conjunction with Avaya and 911 Secure that is designed to inform customers of the issues at hand and offer solutions that are both functionally efficient and financially affordable. You can read their 3 part Blog series by Hank Hunt, Mark Fletcher, and Kevin Kito on the topic here:

Read the Blog: 
A Daughters Cry Goes Unanswered

In part one of our three-part series examining how Kari’s Law came about, guest blogger and Kari’s father, Hank Hunt recalls that terrible night when his life changed forever

Read the Blog: 
A Grandfather’s Cry for Help Gets Answered

In part two of our three-part series examining how Kari’s Law came about, guest blogger Mark Fletcher – ENP, Avaya’s Chief Architect for Worldwide Public Safety Solutions recounts how he becomes involved

Read the Blog: 
Making Next Generation 911 a Reality

In part three of our series, Kevin Kito, CEO of 911 Secure discusses how 911 Secure brought the SENTRY™ solution to the market

A Message from Hank Hunt

0

Moving the Yardstick With Innovation

Raymond Sims Baum (August 18, 1955 – February 9, 2018) was an American lawyer, lobbyist, and politician. His Wikipedia page notes:

Baum was born and raised in La Grande, Oregon. He studied at Brigham Young University and Willamette University College of Law. Baum was admitted to the Oregon bar in 1983 and practiced law in La Grande. Baum served in the Oregon House of Representatives in 1988. He was majority leader in the state house for the Republican Party starting in 1995 but did not seek reelection in 1996. In 2003 Ted Kulongoski appointed Baum a member of the Oregon Public Utility Commission. He served there until 2011, serving as chairman starting in 2010. Baum worked for the National Association of Broadcasters and served as vice-president of government affairs. He died at Suburban Hospital in Bethesda, Maryland from prostate cancer.

In honor of his career, the Repack Airwaves Yielding Better Access for Users of Modern Services Act of 2018 or the RAY BAUM’S Act of 2018 was raised in his namesake as a testament to his service to the American people.

The RAY BAUM’s ACT  has picked up many small provisions where those issues on their own didn’t warrant, or could not muster support for their cause in a separate bill. An item particularly intriguing within this act, is in Title IV, under Section 506. It states,

“The FCC must conclude a proceeding to consider adopting rules to ensure that dispatchable location is conveyed with 9-1-1 calls, including calls from multi-line telephone systems, regardless of the technological platform used. “Dispatchable location” means the street address of the calling party and additional information necessary to adequately identify the location of the calling party.”

While I am certainly NOT a lawyer, nor do I play one on TV, I can most certainly read and write the English language. The first 10 words of Section 506 say it all; “The FCC must conclude a proceeding to consider adopting rules”. That’s right, they have to finish making up their mind about having to make up their mind, or in other words, Get Ready to Get Ready. That’s it, end of the story – period.

Once again, the legacy database providers (a.k.a. the providers about to lose large revenues from database management fees) are running around telling their clients that the sky is falling, and they need to be compliant with a dispatchable location, pawning that off as individual station level reporting to the PSAP. Why? This seeds their coffers with revenue but actually provides very little actionable information to 1st responders.

For the record, I am NOT against providing detail to those responding to an emergency. In fact, I am all for that practice. What I take issue with is forcing a consumer to provide detail that is useless, at great expense and hardship, only to create revenue for those who store the data for public safety. Most often my arguments are deflected with the response, “Any small level of detail can be helpful when trying to locate a person in an emergency, and seconds count!”

Yes, seconds DO count. That is my precise argument. Instead of providing great detail that isn’t actionable (an EMT has no idea where cubicle 2C-231 is located in my building) why are we not using technology to create intelligent displays in the lobby that actually SHOWS a responder where they are needed, and how to get there in the event there is no one on site to guide them? The legacy Automatic Location Identification (ALI) record used today to convey information to first responders) is a text-only record just over 500 characters in length. There are minimal fields in there that provide the ability to include any relevant textual data.

NG911, on the other hand, is IP based and extensible. Information can contain text and URLs to additional data that can be retrieved dynamically if needed, and wherever it exists. The one problem that remains is the legacy voice network, capable of transmitting one thing and one thing only, VOICE. How do we get the data over this network?

SIMPLE: YOU CAN’T

We have been waiting for a decade or more for the NG911 ESInet to be built, but that is coming in dribs and drabs, and access is anything but ubiquitous, so we did the next best thing. We took the information we had in our SENTRY™ solution in the Shelby County Buildings Department and delivered that information to RapidSOS during a 911 call. The call reached the Memphis Police Department in Shelby County, and they were able to retrieve the associated floor plans and information about the station that placed the 911 call.

ADDITIONAL, ADDITIONAL DATA

Along with floor plan information and emergency contact context, the SENTRY™ management console allowed text notes to be added to the incident record, and those additional notes were displayed to the call taker. History was made, and we moved the yardstick.

Follow me on Twitter @Fletch911

0

FIXED: Cellular E911 Location

The two biggest issues with cellular emergency services:
Text to 911 and Cellular Location Accuracy

But the question is, how can this be so in today’s ultra-modern broadband connected world?

The answer, it turns out, is simple. The Emergency services network no matter where you are located is, for the most part, an analog-based legacy infrastructure with only the ability to convey VOICE calls and no data services. Because of this simple fact, we have pigeonholed ourselves into a quagmire of isolation from the modern communications capabilities that have become commonplace and inherent in the devices nearly all of us seem to be carrying.

How do we extract ourselves from this destitute pit of captivity? The answer is quite simple. We need a rope, and it just so happens that Google has decided to provide that lifeline, with of course a brand-new acronym; AML for Advanced Mobile Location.

Currently, on the network side AML is  only deployed in Estonia and in the United Kingdon however, the functionality (which has been code-named ‘Thunderbird’) is actually embedded in every current  Android device with operating systems from Gingerbread forward. To discuss the history of Thunderbird, and how it came to be, I sat down for a Podcast with European Emergency Number Association Executive Director, and colleague of many years, Gary Machado.

Listen to the Podcast here:

Fletch:
The big story in the news is location and emergencies in cellular phones, and you guys have really come up with something that’s pretty interesting over in Europe. Tell us about AML?

Gary:
Thank you, Fletch. Yes, we came up with AML, which stands for Advanced Mobile Location, a few years ago. Actually, the idea is not ours. The Advanced Mobile Location was created in the UK in 2014 by a guy named John Medland, who works for BT 999/112 emergency services.

He basically lost faith in the EU’s ability to regulate of the sector and to contribute to the improvement of caller location in Europe, so he decided to start talking with the handset manufacturers and the mobile operators here in Europe, what in the US you call I think carriers, and he came up with a simple idea: how can we find an easy way to retrieve the location data that is in the phone that we all use everyday to order pizza, to order Uber, et cetera, and how can we take this data and deliver it to the PSAPs as easily as possible?

That’s how the project started. John led the whole project in the UK. It started slowly in 2014 with AGC, the handset manufacturer, and one mobile operator named EE, and since then, AML has been very successful. We have about 85% of locations that are below 50 meters, within 50 meters, and AML has been extended to other handset manufacturers, namely Alcatel, Sony Mobile, Samsung devices, and extended also to other mobile operators in the UK.

Fletch:
I think the big thing was when Google jumped onboard. Google saw what John had proposed doing, and basically in a nutshell, the way I explain it to people is, when the carrier, when the mobile operator looks from the network towards the handset, it’s one view, but when the handset looks out towards the world, they can see much more. It’s like looking through a peephole on a hotel room door the wrong way, right?

From the carrier side, you get a very myopic view of where that device is, but the device can take advantage of cellular, it can take advantage of GPS, it can take advantage of WiFi signals that [can be seen], not necessarily connected to, but just seen, and then all of that information together [delivers] a much more accurate resolution. One number that I saw published was 4,000 times more accurate?

Gary:
Yes. Fletch, I want to say I love the way you describe it, which is exactly correct. What happens, we actually happened to meet Google at the right time, were starting to look into the project, they were wondering on how to get this information delivered to the PSAPs, and so we actually bridged between BT in the UK, Google and ourselves and we started to have about a conference call per week, basically, and we started to progress, let’s say, the Google way, which is very fast. Yes, as you said, Google wanted to benefit from the use of their Google fused location provider and have this accurate location information we use everyday installed on all Android devices in the world. That was what they were trying to achieve. Since they saw the success of the project in the UK, which was running on Android devices already, on Android-based smartphone manufacturers, they decided to work with us and

Since they saw the success of the project in the UK, which was running on Android devices already, on Android-based smartphone manufacturers, they decided to work with us and BT to, let’s say, upgrade all the devices in the world with this accurate location. Now, where are we right now? All Android devices in the world back to Gingerbread have been upgraded with Advanced Mobile Location, so it’s in every Android phone in the world, besides a few phones that haven’t been updated because they haven’t been charged or connected to the WiFi and didn’t get the update, of course, but otherwise it’s already

Now, where are we right now? All Android devices in the world back to Gingerbread have been upgraded with Advanced Mobile Location, so it’s in every Android phone in the world, besides a few phones that haven’t been updated because they haven’t been charged or connected to the WiFi and didn’t get the update, of course, but otherwise it’s already in your phone. If you have an Android phone, AML is there. You just have to check your phone, look for the Google Play Services, and if you have a version of Google Play Services which is something like 9.0+, then you have AML in your phone. AML

You just have to check your phone, look for the Google Play Services, and if you have a version of Google Play Services which is something like 9.0+, then you have AML in your phone. AML is deployed in two countries in Europe. It is fully deployed in the UK and Estonia.

That means that everyday, UK and Estonian emergency services receive extremely accurate location information, again, 85% at below 50 meters using GPS or WiFi location, and yes, when we look at the figure, it’s about 3,000 to 4,000 times more accurate than what we get in Europe currently, which is only the primarily cell ID.

Fletch:
Before everyone runs out and turns on AML and expects this incredible accuracy to be there, there is the other side of this, and that’s the 911 center, the emergency center, the PSAP has to be able to, or the network I should say, has to be able to receive this data. One of the pieces of AML is a destination for this information to be sent, so that’s got to be in place, too. Now that’s the carrier responsibility.

Gary:
Yes. I would say the beauty of this project is its simplicity. When you dial an emergency number, 112, 911, it will trigger AML in your phone if you’re in a country where the service has been activated; in other words, where PSAPs are able to receive the information. Once you dial this number, it triggers the AML for 20 seconds, collects the location information and sends it over to the PSAPs over a mobile network.

Now there are two ways of doing that. The first way is using SMS. There are two kinds of SMSs that are used. I will not get into the specificity of those, but these two SMSs are working. One of these two can be implemented in any country. Either the message can be sent to an SMS endpoint, which is what both BT, our organization, EENA, and Google recommends, because it works in most cases, SMS, and it’s actually extremely reliable. So it can be sent to an SMS endpoint or it can be sent over HTTPS to the emergency services. Emergency services are free to choose.

In Europe, we work at the country level. [Governments] are free to choose whether they want SMS or if they want HTTPS. For now, in Europe, we have SMS installations, but other countries are deploying an HTTPS endpoint to be able to receive the AML data.

Fletch:
I’m going to assume that when you bring your handset online and you get your configuration from the carrier that this AML destination would be part of that provisioning.

Gary:
Yes. Actually, it’s managed by Google. Google defines the emergency numbers that should activate the service in a country. If a country has several emergency numbers, those numbers will trigger the AML service, which will turn on for 20 seconds and collect the location data, and then send it over to this endpoint selected by a country or a region or a county. Basically, what’s to be done by the PSAPs, the authorities and/or the mobile operator or carrier in the US, it’s very simple. Google needs to know the endpoint to be able to deliver that message. They need to be provided by an endpoint. The carrier needs to, for instance, in case of an SMS, allow it to be free of charge, and that’s what we have in most countries in Europe already with SMS for the deaf and hard of hearing, and/or they need to provide for an HTTPS endpoint to be set up, which often in the US I believe has been at the carriers rather than in the PSAPs. In Europe, we have a different setup for these things.

Fletch:
The very first thing people are going to complain about it is, “Hey, wait a second, Gary, if this thing gets turned on, Google’s going to start tracking my location. It’s bad enough that they know every website I go to and they’re putting cookies all over my phone, now they’re going to be tracking my specific locations and what I’m doing. I’ve already got the NSA in the US doing that. I don’t need Google on top of that doing the same thing.” Is there going to be pushback?

Gary:
As you can guess, we get it over here in Europe even more than in North America. People are very, very concerned about it here. I can say I have myself a certain interest for these issues. I actually help some of the privacy activist organizations here in Brussels on my private time, let’s say, and I never switch on my location on my own, for instance, but in case of emergency service, I want to have my location turned on. The beauty of this project and working with Google for more than a year, they have been extremely cautious with that. The location just turns on for the time of triggering the AML and turns off after 20 seconds. Google does not store that location. Google doesn’t want to see that location. That location is retrieved and is sent over to the PSAPs in an SMS or HTTPS, and that’s it. Google doesn’t want to see that location. I think, honestly, no one is [inaudible 00:11:05]. Google has plenty of locations everyday. I don’t think they are looking for more of that project. That’s not what they are looking for.

The location just turns on for the time of triggering the AML and turns off after 20 seconds. Google does not store that location. Google doesn’t want to see that location. That location is retrieved and is sent over to the PSAPs in an SMS or HTTPS, and that’s it. Google doesn’t want to see that location. I think, honestly, no one is [inaudible 00:11:05]. Google has plenty of locations everyday. I don’t think they are looking for more of that project. That’s not what they are looking for.

Fletch:
So they never even get the data to be able to store it. It goes directly into the public safety networks.

Gary:
Exactly.

Fletch:
Let’s face it, if you’re having an emergency, your location is something that you probably want to share. 

Gary:
Yes, exactly. That’s the case, and I’m sure it’s the same in the US, but in Europe, we have the proper legislation for that, that in case of emergency call, caller location is authorized. Yes, that’s one of the very few times where you actually need and you want your location to be used.

Fletch:
I’ve got to tell you, when I first saw this back in 2014 over in Europe, I was a little hesitant. I was a little hesitant because it was operating system-specific. At that time it was carrier-specific and even handset-specific, and [I thought], interesting idea, but it’s going to be the adoption that really makes this happen, and although it’s taken a couple of years, it is actually a great idea. It’s very simple in its form, it’s very basic. It doesn’t require a big uplift in the network. It doesn’t require huge upgrades in the PSAPs. It’s just a simple activation of information that’s already there, and it’s information that most devices already have anyway. Again, like you said before, if I want to order a pizza or if I want to order an Uber, they know exactly where I am with incredible accuracy, so it’s just activating that function that’s already there and creating the mechanism to transport that over to the PSAP, the people that actually need to use that. Really kind of a brilliant idea and John, John’s a great guy and I’ve known John for many years over at BT. It really took a lot of stamina just to keep pounding his foot down and saying, “This will work,” and getting Google in there is a big deal. Obviously the big question, what about iOS and Apple and Microsoft? What’s happening with those guys? Have they mentioned anything about this?

It’s very simple in its form, it’s very basic. It doesn’t require a big uplift in the network. It doesn’t require huge upgrades in the PSAPs. It’s just a simple activation of information that’s already there, and it’s information that most devices already have anyway. Again, like you said before, if I want to order a pizza or if I want to order an Uber, they know exactly where I am with incredible accuracy, so it’s just activating that function that’s already there and creating the mechanism to transport that over to the PSAP, the people that actually need to use that. Really kind of a brilliant idea and John, John’s a great guy and I’ve known John for many years over at BT. It really took a lot of stamina just to keep pounding his foot down and saying, “This will work,” and getting Google in there is a big deal. Obviously the big question, what about iOS and Apple and Microsoft? What’s happening with those guys? Have they mentioned anything about this?

Really kind of a brilliant idea and John is a great guy.  I’ve known him for many years over at BT. It really took a lot of pounding his foot down and saying, “This will work,” and getting Google in there is a big deal. Obviously the big question, what about iOS and Apple and Microsoft? What’s happening with those guys? Have they mentioned anything about this?

Gary:
First, I want to join you here in saying I really admire what John has done. He’s taken this idea, he’s been fighting for it. He’s been going step by step. He’s very cautious. He wanted to validate every step of the project. We owe John a lot, as all in the public safety community, I believe. I also want to thank the guys at Google, of course, and also congrats to the Estonians. The Estonians implemented AML in less than six months with Google and they are one of the countries that are fully enabled right now. About Apple and Microsoft, we are in contact with Microsoft, trying to get some information, some progress on this. At this stage, we do not see a lot, but we are hopeful that it will progress. We are also trying to get in touch with Apple. We’ve informed Apple via many emails, conference calls and so on. We haven’t seen a lot back from Apple, though we actually discovered just by Googling one day that Apple has published a patent on the location topic, which seems to be rather an idea pretty similar to what we’ve just talked about during this podcast. Very interesting. Very interesting. We’re hopeful that Apple will join the project. We also started to see the first articles, one article in Estonia last week, clearly explain that they believe that Apple will start joining the

We haven’t seen a lot back from Apple, though we actually discovered just by Googling one day that Apple has published a patent on the location topic, which seems to be rather an idea pretty similar to what we’ve just talked about during this podcast. Very interesting. Very interesting. We’re hopeful that Apple will join the project. We also started to see the first articles, one article in Estonia last week, clearly explain that they believe that Apple will start joining the project, because people will think of Google’s Android phone as the safe phones. That was an opinion written in an Estonian article, which is in English.

Fletch:
I have to agree with that. If somebody’s going to make a telephone purchase and this one has got safety features that this one does not, that’s going to become a decision. If I’m going to buy a phone for my daughter who’s going off to college now, I’m going to make sure she’s got a phone that’s going to provide her with as much safety as possible. That’s going to bring the financial model into play and it’s not going to be long before somebody over in Cupertino says, “Hey, wait a second, sales are going down. We need to turn this on,” and Microsoft’s going to do the same.

Gary:
Let’s hope so. Apple Keynote is coming out soon, so, let’s wait.

Fletch:
Listen, Gary, it’s always a pleasure to talk to you. It’s been a while since we’ve chatted. I really appreciate you taking the time to talk about this. Tremendous progress on this. Congratulations to everybody over at EENA who drove this, and of course to John Medland over at BT, who had the brainchild and the fortitude to get this program moving.

Gary:
Thanks, Fletch. Bye-bye.

0

What you never knew about IoT – and were afraid to ask

Every year the IT industry has to come up with a new acronym for some new technology that technology writers expound upon. Clearly, the undisputed winner for 2016, has to be nothing other than, “IoT – the Internet of Things.”

AN AUDIO VERSION OF THIS BLOG IS AVAILABLE ON SoundCloud Here:

Forbes, an obvious reputable resource, defines IoT as, “connecting any device with an on and off switch to the Internet (and/or to each other)”, TechTarget basically agrees with Forbes, but puts their own spin by adding in animals or people as long as they have, “unique identifiers and the ability to transfer data over a network.” So, this means that my pet Bengal, Diego, could be an IoT device if he was on the net and by definition, I myself are an Internet of Thing device. That’s a scary thought.

Of course, for the real truth, we need to go to Wikipedia. Here we’ll find an answer that is somewhat in the middle, and in my opinion, correct. The great Wiki says the Internet of Things is, “the network of physical devices, vehicles, buildings and other items—embedded with electronics, software, sensors, actuators, and network connectivity that enable these objects to collect and exchange data.”

Taking a step back from all of this, looking at commonality in the definitions we find the following criteria making up IoT:

  • Physical electronic device (potentially connected to an animal)
  • Connected to the network (ideally the Internet is assumed)
  • Communicates with neighboring devices (contributing and consuming information)

Assuming that basic premise is true and correct, what exactly does this mean for the enterprise IT professional? First and foremost, it means that anything and everything is going to be on the network. Initially this will create a massive drive towards IPv6, as a MAC address signifies the unique identifiers required in the basic networking communications architecture. One potential detour around the massive migration to IPv6 devices, would be to use a networking technology such as the Avaya Shortest Path Bridging fabric architecture to isolate islands of IPv4 devices, and segregate them from the public wide area network with an IPv6 to IPv4 Gateway device.

This is nothing new to IT professionals, and the construct has been used with public IP addresses versus private IP addresses in the past. Just think of how many consumer grade routers have been sold that handout 192.168.1.X addresses in our homes. Part of the job of the router is to segregate those IP addresses effectively hiding them from the WAN.

CONNECTIVITY

So we now know the devices are going to exist, and they’re going to show up on our networks. In fact, based on a recent report by research firm International Data Corporation (IDC), the spending on IoT in the U.S. alone is slated to grow at a 16.1% compound annual growth rate (CAGR) through 2019 reaching an estimated $357 billion, according to a recent article.

MANAGEMENT

With these devices now present on our network, they need to be managed. We need to understand where they are, what they are, what data they’re consuming, and what data they’re creating. Imagine, if every light switch in your facility suddenly became an Ethernet connected temperature sensor, the microbursts of data that 1000 devices may produce, could potentially cause traffic contention for critical data required to run your business. So, while it would be very convenient to know ambient temperatures in each individual room, as well as the status of the ambient lighting, possibly combined with measurements of the lumens in the room, that information can’t conflict with the credit card transactions or other sensitive information required to keep the doors open and customers happy.

We already see this today, with video networks. They have replaced the coaxial based camera network with IP Cat6 cabling, but it remains a completely separate infrastructure with home runs back to the video head-end. Why not put the cameras on the network? “It won’t handle the multicast traffic from the cameras, and the overall network would suffer,” is the most common answer. With the right network topology and architecture, this is no longer true, Avaya Fabric solved this issue years ago, as proven at InterOp.

SECURITY

With potentially tens of thousands of devices now present on your network, security remains as a number one concern, but that concern is exacerbated by the sheer number of additional “touch points” to your networking infrastructure. For example, take the breach that retail giant Target experienced when their HVAC system was compromised. This gave hackers a convenient on-ramp to the network, where they proceeded to gain access to information that was assumed to be secure. While several failures in security can be attributed to this, the primary cause was the Layer 1 physical access entry point that was compromised.

Security is driving new fundamental functions that were considered a “nice to have” at one point in time. In order to manage this perfect storm of device influx into the network, as well as the number of BYOD devices appearing every day, network connectivity, especially wireless connectivity, cannot be taken for granted. Even the smallest enterprise will need to consider Identity Engine functionality within their network to manage devices that show up, both expected and unexpectedly, and be able to detect and mitigate any rogue device presence that is perceived as a potential threat. For example, even though Target was compromised through the HVAC system, shouldn’t the network have noticed the thermostats talking to the secure customer information databases? That abnormal traffic flow should have been detected, and the questionable device should have been moved into a Virtual Service ID where it was isolated from other areas on the network. This would’ve allowed human intervention and approval or denial of the communications.

ANALYTICS

An area that needs to be improved upon within the enterprise corporate network is the analytics applied to the network performance. Once again, functions that were considered a “nice-to-have” at one point in time, are now critical to day-to-day operations. The sheer number of devices, the amount of big data that’s being produced, and information from the identity management system all need to be examined, historically catalogued, and then referenced during future operations. If a device or process falls out of the normal scope, where a device starts generating traffic flows that are in excess of what they are expected to be generating, various thresholds are exceeded, the device or process is isolated, and human intervention is applied either stopping the device, or verifying its purpose and  creating a new rule that allows the anticipated behavior.

CONCLUSION

I don’t believe there’s a single industry that is not affected by this new trend. Smartphones have become so ubiquitous; their level of connectivity has become persistent. As we roam around going about our daily business, we are constantly connecting, disconnecting, and reconnecting to various networks and hotspots. We often don’t pay attention to our online status, and honeypot phishing is at an all-time high. Like it or not, the devices we carry are part of the Internet of Things. Not only do the networks need to protect themselves from the multitude of devices touching them, consumers also need to be conscious of what their devices are touching!

“HEY! Get that network out of your mouth! You have no idea where it’s been!”

Follow me on Twitter @Fletch911
Read my other AVAYA CONNECTED Blogs

Mark J. Fletcher, ENP is the Chief Architect for Worldwide Public Safety Solutions at Avaya. As a seasoned professional with nearly 30 years of service, he directs the strategic roadmap for Next Generation Emergency Services in both the Enterprise and Government portfolios at Avaya. In 2014, Fletcher was made a member of the NENA Institute Board in the US, in 2014 – 2015 he served as co-chair of the EENA NG112 Committee in the European Union, providing valuable insight to State and Federal legislators globally driving forward both innovation and compliance.

0

999 – The history of the ‘Hooter’

For and AUDIO version of my Blog – Check it out here on SoundCloud:

While the digits 9-1-1 win the popularity contest for the most popular emergency service globally, the very first emergency number ever to be put into circulation was ‘across the pond’ in London on June 30, 1937, by British Telecom.

As is typically the case it, the need for the service was inspired by a disaster involving to tragic loss of several lives. In November of 1935, five women died during a fire on Wimpole Street. As the story goes, neighbors who saw the fire, tried desparately to report it by dialing zero and asking the operator for the fire services. This method for summoning the fire department had been the long standard practice since 1927. Unfortunately, on this particular occasion, the telephone operator switchboard had been particularly jammed with non-emergency calls; therefore the emergency callers were unable to get through to report the emergency.

General-post-office-logoThe General Post Office, who at the time ran the telephone network in London, decided that a new, easy to remember three-digit number was needed, allowing citizens to reach emergency services quickly. Ensuring calls received the appropriate level of priority by BT operators; an alert signal would be triggered indicating the emergency call. Using the latest technology available in the late 1930’s, a flashing light accompanied by an audio device -dubbed as a “Hooter”.

I’ll give you all a moment to recover from your snickering – All done? Great, then let’s continue with today’s history lesson.

The trigger for the lights and their accompanying Hooter was the number 9-9-9. If you are a tech history geek like myself and are interested in the full story behind choosing 999 as the number, Gary Holland from the BBC wrote an interesting article on this very topic telling the entire story.

Logo_112_20100929Currently, across the European Union member states, 112 is recognized as the official emergency number, and along with 911 are recommended by the IETF as the preferred primary emergency numbers. Despite 112 being in place, in most places, the historical and legacy numbers continue to operate. According to EENA the European Emergency Number Association, technology is not always the primary concern. The most troubling hindrance is the lack of knowledge by citizens. Even though 112 has been the EU-wide emergency number for some time, according to recent surveys, only single-digit percentage growths have been seen over the past several years with three out of four European citizens still not aware that they can dial 112 all over Europe.

PBX or MLTS administrators, when addressing their emergency call dialing, should examine their user base and understand the need to support additional emergency numbers. 911 and 9-911 are distinct entries in your emergency dialing tables, but if you find that you have a large employee base that includes folks from Europe, it would be wise or to provision 112 and 9-112 or 999 and 9-999 as valid dialing patterns in the PBX as well. Just make sure that you translate anything that is not 911 to the digits 911 as today’s landline carrier networks are likely not provisioned to recognize emergency numbers beyond 911.

Oddly enough, this isn’t the case on most cellular networks today. In fact, not only does my iPhone understand 911 is an emergency number, others such as 112, 999, 000, 114 and 118, and likely several others, are treated the same. Dialing any of these will put the device into “emergency mode”, invoking functionality or disabling others as defined by the carrier profile. The phone never actually ‘dials’ anything, it merely indicates to the network that the user is making an emergency call. This mechanism is how multiple numbers are all supported and translated to the proper emergency service in the country where you are located.

In turn, the network then connects me as if I had dialed 911, or the appropriate local emergency number, directly.

DISCLAIMER: 
PLEASE TAKE MY WORD ON THIS, AND TRUST ME THAT THIS WORKS.
DO NOT TRY TO TEST THIS YOURSELF. YOU’LL SIMPLY TIE UP EMERGENCY LINES WITH NON-EMERGENCY TRAFFIC, PUTTING LIVES AT RISK. THE 9-1-1 OPERATOR WILL NOT SEE ANYTHING DIFFERENT THAN IF YOU DIAL 9-1-1, THE NORMAL EMERGENCY NUMBER, OR EVEN KNOW THAT YOU HAVE DIALED ANYTHING DIFFERENTLY.

As we move forward with new communication technologies and modalities, SIP will be the primary protocol used for transport. Based on this, phone numbers will become less and less relevant, and an endpoint or destination name will replace it. My identity, and how to reach me will shift from 908-848-2602 to something more like my email address FletcherM@Avaya.com. Which is another reason why routing emergency calls based on telephone numbers is an archaic construct that does not fit the next generation 911 model, and we must STOP relying on phone numbers as a location cross-reference.

While the people that manage those databases have the financial incentive to keep customers locked into this irrelevant technology, maintaining phone number to location correlation, there’s far too much automation, complexity, and expense associated with that to remain as the right way forward.

Emergency services need to be able to migrate to simply “SOS” as an emergency destination address, and location information needs to be conveyed in the PIDF-LO location object in the SIP header. If the financial model has to change for some providers, then so be it; these folks must learn to adapt, or cease their operations. We are talking about life safety services, and profits need to be put on the back burner. While there is nothing wrong with cost recovery of sensible technology, 9-1-1 is not a license to steal.

0

Does 911 Work in Government Buildings?

On February 22nd, 2012, President Obama signed H.R. 3630, also known as the Middle-Class Tax Relief and Job Creation Act of 2012  into  law. In this Act, under Section 6504 -REQUIREMENTS FOR MULTILINE TELEPHONE SYSTEMS- it  states explicitly that “[T]he Administrator of General Services, in conjunction with the Office, shall issue a report to Congress identifying the 911 capabilities of the multiline telephone system in use by all federal agencies in all federal buildings and properties.” The GSA, in addition to being the purchasing arm of the US Government, is the agency responsible for constructing, managing, and preserving government buildings by leasing and managing commercial real estate. According to their website, http://gsa.gov, the agency also promotes management best practices and efficient government operations through the development of government-wide policies, and their mission is “[T]o deliver the best value in real estate, acquisition, and technology services to government and the American people.” In total, they are responsible for nearly 10,000 federally owned or leased buildings, all of which would have been covered by the aforementioned GSA report that was required by Congress. It only seems logical that the US Government, a large Enterprise in itself, would have the same concerns that commercial businesses have with proper 911 access from Federal Buildings.

The Dog Ate my Homework

As of Saturday, June 18, 2016, that report remains 1308 days (three years and seven months) past due. The Act also required that no later than 90 days after the date of enactment, a notice is issued seeking comment from MLTS manufacturers on the feasibility of including within all systems manufactured mechanisms to provide sufficiently precise indications of a 911 callers location.

MLTS manufacturers have long since responded with features and functionality to address emergency calling from these types of systems systems, and most, if not all, contain the basic capabilities to deal with the situation, requiring add-on functionality for only the more complex environments. There still remains, however, a lack of awareness and in many cases these features are not properly configured or  implemented. This simple lack of awareness leaves many government employees at risk. History has proven time and time again that this problem knows no boundaries  affecting schools, businesses, hotels, and any other facility where a multi-line telephone system is used. While admittedly, surveying all 9,600 properties reportedly under the control of GSA, the mandate ordered in this Law was not to remediate the problem; the mandate was to produce a report on the scope and expanse on the problem.

What You Don’t Know MAY Hurt You

It is only with the information from this report that the facts become well understood, and assessments of the risk can be made. If nothing else, awareness of the problem will be raised.  Despite the current situation, has every new facility opened or upgraded in the past three years had this situation addressed? Likely not. The problem is well known, and documented, and to ignore it at this point is simply foolish and borderline egregious.

Case in point, the Federal Communications Commission headquarters building in Washington, DC itself was noncompliant and unable to dial 911 directly, as reported by FCC Commissioner Michael O’Reilly in his June 2, 2014, blog. Commissioner O’Reilly reported, “Our employees and any visitors must dial 9-911 to reach help in an emergency.  I asked that the agency look into options for fixing this problem.  Since then, we have learned how simple reprogramming our telephone system would be.” A short time later, Chairman Tom Wheeler ordered the system to be reprogrammed, and FCC staff are now able to dial 911 directly.

This glaring lack of compliance for basic emergency calling could have been noted on a report issued by the GSA on multiline telephone system capabilities for emergency calling, had they produced one. But unfortunately, they did not, and as of this point that report is more than a year and a half overdue. How many other buildings suffer this same ailment? Likely many if history in the Enterprise space is any indicator.

fcc-commissioner-ajit-pai-cropOn March 11, 2015, FCC Commissioner Ajit Pai sent a letter to acting GSA Administrator Denise Turner Roth asking about the status of this report directly requested by Congress, and as part of the Law enacted with HR 3630. At the time the letter was sent, the report was 843 days overdue, yet to this date, there has been nothing but silence from the GSA. One has to wonder, if we need to wait for another tragedy to occur, and an innocent life lost before we recognize this simple problem and address it? The other burning questions are; Why is the GSA withholding this information? Have they done any work at all in the past 3 1/2 years? Are they worried that they are so out of compliance that a considerable expense would be required to correct the issue?

Is is Broken? Then FIX IT!

If the GSA is responsible for facilities and the technology, I am sure this also includes maintenance coverage for ‘break-fix’ matters that come up from time to time. I will offer the point of view that if my phone system will not dial 911 effectively and report the proper information to local emergency services personnel, then that system is broken, and should be fixed. We can no longer ignore this critical life safety issue. Additionally, how bold do you have to be to ignore a formal request by an FCC Commissioner? Obviously, brave enough to also overlook a mandated order by the U.S. Congress, as designated by Federal law.

One also has to wonder, where is the US GAO in all of this? This independent, nonpartisan agency works for Congress and is often called the “congressional watchdog,” part of their job is to investigate how the federal government spends taxpayer dollars. If MLTS systems were purchased, and not able to dial 911, I would imagine that could be argued as a point of dispute, between the US Government and the supplier. At least for any system purchased and installed after Congress passed the bill and it became law.

Who’s shoulders does this fall on? According to their web page, the head of GAO, the Comptroller General of the United States, is appointed to a 15-year term by the President from a slate of candidates Congress proposes. Gene L. Dodaro became the eighth Comptroller General of the United States and head of the U.S. Government Accountability Office (GAO) on December 22, 2010, when he was confirmed by the United States Senate. He was nominated by President Obama in September of 2010 from a list of candidates selected by a bipartisan, bicameral congressional commission. He had been serving as Acting Comptroller General since March of 2008.

Who Let the Dog Out? No One

If the GAO is the “Congressional watchdog”, shouldn’t they look into this issue? I believe so. Transparency, openly ignoring authority, and failure to perform tasks that are legally obligated seems to be something that would be right in their wheelhouse.

Follow me on Twitter @Fletch911
Read my other AVAYA CONNECTED Blogs

Mark J. Fletcher, ENP is the Chief Architect for Worldwide Public Safety Solutions at Avaya. As a seasoned professional with nearly 30 years of service, he directs the strategic roadmap for Next Generation Emergency Services in both the Enterprise and Government portfolios at Avaya. In 2014, Fletcher was made a member of the NENA Institute Board in the US, in 2014 – 2015 he served as co-chair of the EENA NG112 Committee in the European Union, providing valuable insight to State and Federal legislators globally driving forward both innovation and compliance.

 

Edit

With more than 3 decades of experience, I have worked in almost every segment of the telecommunications industry; With many years in the field as a technician, as well as experience building and managing several of the world’s largest private voice networks, I have a unique view of the telecommunications industry from various perspectives, including extensive knowledge of both TDM and VoIP environments. I was honored to be the inaugural recipient of the “INNUA Partnership Award”, and in 2009 was named by The National Emergency Number Association as the 9-1-1 Professional of the Day during the National Public Safety Telecommunications Week. I proudly hold the NENA Emergency Number Professional (ENP) accreditation. In my current position as Corporate Solutions Technologist and Chief Architect for Avaya’s Public Safety Solutions, I ensures the roadmap and strategy of Avaya meets the requirements of the field with new product development and direction in both the Enterprise and Government markets, and has a solid roadmap to Next Generation Emergency Services globally. I am asked to speak at many international industry and user group events, and have been recognized internationally for my weekly Podcasts and Avaya CONNECTED Blogs. In addition to my Avaya role, I represent Avaya as an active member in several Public Safety and E911 organizations. I hold a position on the FCC Disability Advisory Committee, and the FCC Task Force for Optimized PSAP Architectures. I am proud to serve on the APCO International Standards Development Committee, as well as a regular contributor to the European Emergency Number Association activities. I am often called upon to provide technical input to legislators and regulators as well as the industry in general, in an effort to drive forward NG Emergency Services compliance.

Post navigation

Leave a Reply

1

Predictive Assistance via Caller Context

A concern that can exist in nearly any city, county, state, or even country, is that once an easy to remember emergency number, such as 911 in the US, 112 across the European Union, and the 999 available in the UK, has been deployed, massive misuse of the system by non-emergency calls starts to put strain on the network; equipment and even staff must now cope with the increase of non-emergency citizen outreach beyond the purpose of the service. Because there isn’t a catchall category of call types, there often isn’t a single, all-encompassing solution to the problem. Technology can help and when properly deployed, is capable of providing support for dealing with many of the strains that are put on Emergency Networks and Systems.

The Architecture Problem:

 

BLOG-PO-Pic1
Fig. 1 Silos of Call Types for Public Safety and Citizen Services

 

In the past, when we built and designed Public Safety networks, the solutions were siloed, purpose built creating disparate, disconnected islands of connectivity. An agency decided what their inbound traffic would be for that particular service, and then engineer the incoming trunks for a P.01 grade of service, meaning that 1 out of every 100 calls could be blocked during the busy hour. This is a standard level that is accepted by the Public Safety industry for Public Safety Answer Points.

But this creates a problem when a service (9-1-1 for example) receives more calls than expected. Typically, they would track analytics and call volume reports that displayed trend information. These reports guided them on the increase of the number of positions and trunks to handle the new projected call loads. You would think that expansion should not be a problem for agencies, as they are tasked with providing service to a geographic area, and when the population increases, call volumes increase and budgets should naturally increase.

Unfortunately, however, quite often population increases along with call volume, but agencies are always being asked (read demanded) to do more with less.

BLOG-PO-Pic2
Fig. 2 Interagency trunking disrupts traffic engineering formulas

While other organizations may be able to aide with the call volume, the problem of citizens dialing 9-1-1 for everything and anything still exists. Because the network was built as independent islands of service, virtual inter-agency barriers naturally evolved. In specific cases, inter-departmental trunking can be created that allows adjacent agencies to transfer calls over those facilities directly. Now the caller is communicating with the right resource that can assist them, and we have freed up the original 9-1-1 resource to allow them to take another call, but we create another problem on the back end.

 

BLOG-PO-Pic3
Fig. 3 – Emergency Services IP Network (ESInet)

Although the issue of routing is solved, the problem still exists where the limited trunking that connects the 9-1-1 center to the PSTN remains an issue and another blockage point. This blockage is easily corrected. By removing these trunks from the equation, and replacing or augmenting them with an IP pipe that is dynamically expanded and contracted as needed, based on the application of rules logic that takes into consideration the number of available 9-1-1 call takers that are currently available and ready to take calls.

 

While I realize that every Public Safety person who is reading this just got a chill up their spine, and muttered, “Your CRAZY Fletch”, this is what needs to happen to solve the problem, and is not new bleeding edge technology. in fact, local carriers have been offering SIP-based trunking to the commercial market for years. The technology has been refined and the largest contact centers in the world use this architecture to bring calls into their network, where they decide the best resource to apply to the inbound call.

BLOG-PO-Pic4With the right tools on the right network, solving these type of problems becomes simpler and a routine process in the contact center, and there is no reason why this technology and thought process cannot be applied to Public Safety Answer Points to assist in improving efficiency and reliability during large-scale national disasters. At the same time, this can also radically improve service to callers. For example, meet Ava. Ava requires 911 services on a regular basis. She is considered to be, what Public Safety has nicknamed, a ‘Frequent Flyer.’
This term is not meant to be derogatory, in fact, Ava has a medical condition that requires Emergency Transportation much more often that the average citizen, but her condition is not life-threatening.

When Ava calls 9-1-1 for medical transport, most of the time, resources are available and dispatched immediately. But on occasion, Ava’s request arrives in the middle of complete chaos. Because the 9-1-1 network is unable to differentiate Ava’s call from any other call being processed by the system, all calls are treated with the same priority level, despite the vast prior history and information that may be available. By collecting and examining this information in a context store, and associating it with a particular call event can dynamically apply specialized call handling. Simply by knowing that Ava is a frequent flyer caller, and her condition is not life-threatening, her call is answered by a Speech Recognition enabled IVR that collects the relevant information giving Ava the opportunity to escalate the call to a call taker.

N11 – More than just Emergencies

9-1-1 has been called the most widely recognized ‘brand element’ in the world. Nearly everyone is aware of the number, and despite the attempt to increase awareness of other avenues of access, 9-1-1 remains to be the winner. Unbeknownst to many in the US, several other N-1-1 services are available to citizens. In most of the cases, these are geographically routed the same way 9-1-1 emergency calls are routed to centers that are close to the caller. Following the N-1-1 format, these easy to remember numbers are as follows:

2-1-1  Reserved for the World Health Organization and Red Cross
3-1-1  Reserved for local government non-emergency services
4-1-1  Not officially reserved, but often used for local Telco information
5-1-1  Reserved for Highway and Traffic information systems
6-1-1  Not officially reserved, but often used for local Telco repair
7-1-1  TDD Relay services for Deaf, Hard of Hearing or Disability
8-1-1  Reserved for the Call before You Dig utility mark-out hotline

While these services can often provide valuable information to citizens, they are often under-publicized, and under-utilized. By consolidating connectivity in the cloud, we gain flexibility in dynamically adjusting the trunking required, and calls destined for other agency remediation. This can effectively eliminate the public education and awareness problem. While the dialed number can be an indicator of the nature of the request, calls can still be handled efficiently, and resources are no longer limited and blocked.

Proactive Citizen Outreach

When a known issue exists, reaching out to the public in an affected area can be an efficient and dynamic countermeasure that can significantly reduce the number of inquiries for more information while reassuring concerned citizens that an issue is being addressed. In addition to providing information, a query can be made to ensure no other problems exist. If the citizen does have an additional concern, the system is already ‘context aware’ of the identity of the citizen, and they can be queued up against the appropriate resource. Upon connection to the person or agency that can provide the additional information they need, information about the previous interaction can be displayed to the call taker, facilitating quicker response and better service levels.

Follow me on Twitter @Fletch911
Read my other AVAYA CONNECTED Blogs

 

Mark J. Fletcher, ENP is the Chief Architect for Worldwide Public Safety Solutions at Avaya. As a seasoned professional with nearly 30 years of service, he directs the strategic roadmap for Next Generation Emergency Services in both the Enterprise and Government portfolios at Avaya. In 2014, Fletcher was made a member of the NENA Institute Board in the US, in 2014 – 2015 he served as co-chair of the EENA NG112 Committee in the European Union, providing valuable insight to State and Federal legislators globally driving forward both innovation and compliance.

3

WordPress.com.

Up ↑