Testing 1-2-3 . . . PART Two – 911 Networks

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

In PART One of this blog, we talked about originating the call in the enterprise and the importance caller ID has in identifying the origination point of the call accurately to the PSAP.

Now that our emergency call has made its way out of the MLTS, navigated through the local Central Office (hopefully unmodified and intact), it has now landed within the 911 tandem Central Office where it is ready for location digestion and termination at the PSAP. The selective router, typically a Northern Telecom DMS 100, or a Lucent E5, has the specific job of providing connectivity between local area PSAP’s and the local Central office switches that serve dial tone to the public. While no hard fast rule exists, it is common to find that selective routers provide service in a specific geographic area that often (but NOT always) aligns with local calling area LATA jurisdiction. Once again, it is important to keep in mind that there is no hard fast rule here. While this legacy design has worked for years, the architecture happens to be one of the many things about the legacy network that is stifling innovation today.

Enterprise telecom providers and installers should be familiar with a few essential points here regarding the local selective router service areas. As they are often tasked with provisioning the MLTS properly. Generally speaking, the selective router tandem offices are designed in a hub and spoke fashion. They supply dial tone to PSAPs through specialized analog loop start CAMA trunks. While these trunks are in fact special, from a use perspective, the technology behind them is actually quite old, and has questionable value in today’s environment, given the changing mission and the need to include data elements and multimedia with the call.

Because CAMA trunks are analog based, loop start circuits, they are electrically no different that the POTS line that feeds your home. One important difference is that instead of normal DTMF tones, they utilize MF Tone signaling. Despite this, the most important characteristic is that they are ANALOG and NOT DIGITAL circuits. This means that any signalling between the endpoints of the circuit MUST be either voltage changes on the line (called battery), or in-band audio, leading directly to the first important point.

Caller ID / Location and E911
For calls transferred into the 911 tandem from the Local Central Office, the Caller ID takes on a level of implied authentication, and is matched against a selective router database table (SRDB) that determines the appropriate ESN or Emergency Service Number of the PSAP responsible for that physical address.

You can think of this Selective Router Service Area environment similar to a localized CENTREX model, with all of the PSAP’s interconnected by analog CAMA trunks. Calls can be transferred from one PSAP on the same selective router, to another PSAP on the same selective router simply by issuing a flash-hook on the CAMA trunk, and then dialing the ESN of the desired destination PSAP.

When this occurs, the call taker in the original PSAP can stay on the line with the call taker of the transferred to PSAP to ensure a warm handoff of the call and verbal information. This is done verbally as the interconnection is typically only voice. Once they’re no longer needed, the transferring PSAP can stay or disconnect, leaving the originating caller and the transferred to PSAP talking (now connected by the selective router).

This architecture eliminates the need for the transferring PSAP to hold the bridge on the call, which would tie up dual trunks to initiate the transfer and hold up the call connection. However, it limits where calls can be transferred, as the destination PSAP must be getting service from the same selective router as the originating PSAP. The exception to this rule would be in areas such as New Jersey, where the four selective routers servicing the state are interconnected with an SS7 network, and any PSAP can transfer to any other PSAP within the state network.

In areas where there is no inter-selective router connectivity, transfers to a PSAP that exists in a remote selective router must be accomplished using a 10 digit administrative line over the PSTN. BUT – because this call is going through the public toll network, the transferring PSAP must hold the bridge together between the caller and the transferred to PSAP.

Another downfall of PSTN based transfers is that it is often impossible to pass any data with that call (even caller ID), as these circuits are capable of voice only traffic, and the foreign exchange PSAP may not have access to the originating PSAP E911 network ANI/ALI database. Since selective router service areas never cross state borders, adjoining states with large population centers within their boundaries can find it very difficult, if not impossible, to pass calls between them efficiently.

A scenario causing a challenging problem for cellular telephones is the fact that electromagnetic radio waves never honor or limit themselves to a political border, and in fact, freely travel well beyond them. Exasperating this problem are areas where adjoining counties obtain service from different selective router facilities, such as Orange County Florida and Osceola County Florida.

A True Story that Prompted this Section
Recently, while driving west on Interstate 4, leaving NENA in Orlando, I witnessed a motor vehicle accident on the access road next to the highway. It had just happened, and were obviously going to require police assistance and a tow truck. Unknown to me, the actual location of the accident was just inside of the Osceola County border, but when I dialed 911 from my cell phone, my call was connected by the cell tower the the Orange County Sheriff’s Department 911 Center. I proceeded to explain the situation the best I could to the Orange County 911 call taker, who quickly determined that the incident was just beyond their border in Osceola County. She advised me she was transferring the call and not to hang up, and within 10 to 15 seconds, I heard the Osceola County 911 call taker come on the line. They advised them this was a transfer from a cell caller with an accident report and told me to go ahead.

I painstakingly recanted everything that I had just explained to Orange County, but the Osceola County call taker, questioned the location. I then asked if they got Phase 2 location on me, to help narrow down exactly where I was. I was then informed that because the transfer occurred as a 10-digit PSTN transfer, no ANI or ALI information was available to them.

Fortunately, both call takers were familiar with this troublesome location. Also, from the sound of it, both had their own techniques for coaxing the exact location out of the caller. However, it highlights a significant technology failure within the core E911 infrastructure, that is often masked by the hard-working dedication of our 911 call takers. Help gets to where it needs to be, despite the networking inefficiencies and technology roadblocks (like having to transfer emergency calls over the public switched telephone network) that blocks critical information from our nation’s 911 centers.

Given this example, with our cellular networks and mobility, you can only imagine the problematic environment that we’ve created in MLTS systems that’ll allow working from home with hard phones and softphones on laptops, and the connected world that we live in.

In PART Three, we’ll look at enterprise mobility, to better understand the problem, and start to explore potential fixes. 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.

Testing 1-2-3 . . . Where is your emergency?

PART ONE – The Originating Network
By: Mark J. Fletcher, ENP
Chief Architect – Public Safety at AVAYA

At Avaya, whenever a customer decides to review the implementation of emergency calling capabilities within their corporate telephone systems, we always stress two specific things.

The Plan:
First and foremost, is the implementation plan. Deciding exactly what the workflow needs to be – based on specific customer use cases that take their facility into consideration – as well as the various actions that make up that workflow. Critical details such as the reported response area size and the complexity of the internal floorplan must be taken into consideration, as well as the anticipated population of the facility, and the number and location of area entrances and egress points that would be usable during an emergency situation.

Testing:
Another important aspect is testing of the response plan. this must be done regularly to ensure that the plan is functional and provides an appropriate level of response. Also, the system itself needs to be assessed to ensure that the appropriate level of performance is being delivered, and that the proper level of information is being delivered to the PSAP.

While I am reasonably sure that no one would intentionally program 911 incorrectly, so that calls could not be dialed or that a wrong location would be purposely reported thereby delaying emergency response personnel, it is essential that the MLTS administrator clearly understands the various components and that the system is receiving the proper data, as well as operating nominally.

The most common mistake is one where no testing is done. Under this circumstance, the MLTS administrator makes the dangerous assumption that 911 is programmed correctly, and this leads directly to my question:

How does one know for certain that 911 is provisioned properly, without actually picking up the phone and dialing 911?

While this is the ultimate test, that does tie up valuable time and resources at public safety answer points across the country. With Kari’s Law legislation pending in the upcoming months (February 16, 2020), PSAP’s could be inundated with testing requests all the while fighting their constant internal battle of being already overworked and understaffed.

Unfortunately, without actually making a call to 911, the only way to ensure proper provisioning has been a “stare and compare exercise” by an MLTS technician or an MLTS administrator. First, they would log in to your system and extract a copy of your programming. Then, the person would manually walk through the dial plan steps, one by one, ensuring that an appropriate outbound trunk facility was being selected and that the calling line ID being sent over that trunk was appropriate for a 911 call, and was what they intended it to be to reflect the proper response address and internal location as per the design plan. While this simple exercise certainly caught any major programming problems and configuration errors, it did not provide a complete level of assurance that the system was actually working correctly.

How you ask? Simple, it’s called a false positive condition, and in 911 it could be deadly.

False Positives:
A false positive is a test result that indicates that there is no problem, when, in fact, one does exist. In the MLTS world, several things exist that could trigger a false positive when testing 911. Before we dig too deep into that, let’s understand the primary components involved in a 911 call between the MLTS and the PSAP.

When 911 is dialed, the call leaves the PBX on a specific facility. There are two pieces of information associated with the call at that point:

1.) The outbound Caller ID applied to the call, and
2.) The number as dialed by the originator (the called number)

The very first culprit of a false positive could be a physical one on the trunk facility itself. The CALLED number is simply established and is likely 911. However, the caller ID could originate from several different sources.

The very first thing to mention here is that the various types of trunks have different capabilities. Many like analog POTS lines, for resiliency, however, a little known fact is that when sending your 911 calls over analog loop or ground start trunks, the caller ID that is seen by the public network is the telephone number that is associated with that specific trunk.

Because the circuit is an analog circuit, custom caller ID cannot be applied, but this is precisely what gets your call routed to the right 911 PSAP, and the index they use to retrieve location information. Therefore, if you’re reporting uses building zones or the station location itself (both of which require dynamic caller ID) it is impossible to deploy this strategy using a POTS line, as the caller ID would always be the same for any calls on this trunk facility.

To utilize dynamic caller ID and any logic that is more granular than the building street address, the call must egress from the system on a facility that is digital, such as PRI or BRI, or direct SIP. This is true as these are digital protocols that support the transmission of a device identifier (telephone number).

Next-in-line is the originating central office. The responsibility of this central office is to connect local calls to other local endpoints on the same central office, and forward all other traffic to the toll switch and onto the long-distance network. For emergency calls, the local CO typically routes calls directly to the E911 tandem, also known as a Selective Router.

At the local CO level, applicable to digital circuit facilities only, there have been instances where the local central office provisioning on the inbound trunk group has been modified for 911 emergency calls. this can create a problem.

I have personally seen cases, where the inbound caller ID was modified, based on a previous trouble ticket. It turns out that improper programming on the MLTS caused invalid caller ID for 911 calls. To correct the issue, a central office technician implemented a translation table that forced any call with a destination of 911, through a table that stripped off any, correct or not, originating caller ID – replacing it with the main billing telephone number of the business owning the trunk group. Problem fixed – Sort of.

Since technology had not advanced yet, and an MLTS typically only served a single unique location, this logic corrected that particular problem of bad caller ID. Unfortunately, this apparent “fix” now masked the actual issue and created a whole new error condition if caller ID was to be used for location identification. Even more problematic, is that documentation is rarely kept current on why changes like this are made. Now, when they rear their head, it takes an incredible amount of effort and time troubleshooting to find the proverbial needle in the haystack, creating the issue at hand.

Now that we have our call into the actual 911 network, next up in Part Two, we will analyze what the network does with our call request, and what control we have over what takes place and how.

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.

Kari’s Law – Countdown to Compliance

At the time I’m writing this, 477 days have passed since I stood in the Oval Office along with Hank Hunt as we witnessed Kari’s Law becoming the law of the land. While not strongly worded as such, the intent of the law was that, from that day forward, an MLTS phone system installed or put into service would be compliant with direct access to 911 without an access code, any calls to 911 would route directly to the PSAP and not be intercepted internally, and unless an upgrade was required, the system would provide some mechanism of notification that an emergency call took place.

Any existing MLTS systems that were installed prior to that date would have a two-year grace period in which to make their system compliant, with February 16, 2020 as the final date when legislatively this would be required. While system administrators and vendors have had almost 16 months to deal with the issue, many still have not. Now, with the deadline approaching quickly, the mad rush is on to secure system capabilities, and provide safe work environments for employees and guests.

Last year at the Avaya ENGAGE Event, Hank Hunt (Kari’s Dad) graciously sat down and recorded this video message:

Hank Hunt on Kari’s Law

Just a little more than a month after Kari’s Law was signed, the president signed Ray Baum’s Act, named in honor of a popular political figure that had recently passed away. The primary purpose of this act was to reauthorize the Federal Communications Commission and establish its operating budget.

With this act being a ”must pass” piece of legislation, it is popular for many other bills that will not stand on their own to become attached to it. One of those pieces of legislation is known as section 506 of the Ray Baum’s Act, and it has recently caused a bit of a stir in the MLTS community.

In this legislation, it establishes a requirement that the FCC conclude a proceeding within 18 months examining it further requirements are needed for location reporting on multi line telephone systems. The due date for that proceeding conclusion is September 23 of this year. This section calls off the need for a dispatchable location to be provided to public safety answer points when and MLTS initiates a 911 call. BUT, as I’ve said many times before, the most critical piece of any law is the definition of specific terms, and the same is applicable here.

In the Act, a dispatchable location is defined as one that, “means the street address of the calling party, and additional information such as room number, floor number, or similar information necessary to adequately identify the location of the calling party”.

Unfortunately, this is being hyped as requiring the exact room or cube number of the caller being delivered directly to the PSAP, when in fact that information is completely irrelevant without additional context. The fact that I sit in cube 2C-231, has no meaning to anyone outside of my company.

1st responders don’t know where 2C-231 is within the building, or even what floor it is on, so it has little relevance. It is very relevant, to internal first responders within the facility, and it could be provided to public safety first responders on an electronic display, and now with context, like a floor plan. This can now be provided directly with the 911 call itself, thanks to new over-the-top NG 911 technology provided by the Rapid SOS NG911 Clearinghouse.

Screen Pop information made available to internal 1st responders and now deliverable to PSAPs via the RapidSOS NG911 Clearinghouse
Additional Context Available in the Enterprise

In the past, establishing 911 database records for every station within the facility created two problems. The first, was that every single device needed a unique and dialable public telephone number in order to identify itself, and secondly a unique record for each device needed to exist in the 911 ANI/ALI database, which incurred a significant monthly recurring cost. While at the surface, this seems to be useful information, it actually creates a false sense of security, as well as an administrative management nightmare, while providing minimal useful information. This is because in legacy solutions, the ability to pass additional context such as a floorplan is next to impossible.

Is this too much work, with no time to complete it?

Depending on the size and complexity of the enterprise, the 911 plan can be quick and simple to implement, or it may become a long drawn out process. This is where a waiver can help tremendously providing some additional time, where warranted. One of the initial states to adopt legislation was the State of Texas, Kari’s home State. During various hearings that took place in Austin, I suggested that waivers be granted to those that specifically apply for them, and as part of the application, the MLTS make and model number, as well as its software release be put on file, as well as evidence that a good faith effort was made to purchase a new system.

This simple clause solved a couple of primary issues. First and foremost, it forced businesses to make an effort and investigate what their situation was, and secondly it created a list of compliant MLTS systems, and release levels, which prevented unscrupulous distributors from up selling the general public when it wasn’t warranted. The waivers were good for one year, and needed to be renewed each September.

Since 2016 when the law went into place, the number of waivers filed each year has dropped by 20%, as more and more noncompliant systems were replaced with those that were compliant. As the graph below shows, in 2016, the very first year, 630 wavers we’re granted. In 2017, that number dropped significantly to 386, and in 2018 it was further reduced to only 252. Those systems granted a waiver also needed to make sure that users of their system we’re well aware of how to dial 911, with very specific placard requirements. Obviously, any new system purchased what have to be compliant upon installation.

MLTS Waivers Issued (and projected) by Texas CSEC 2016 – 2020

911 is the most critical call you may ever have to make. As manufacturers of systems globally, we make sure that our users are well aware of this problem, and that’s why we stood behind Hank Hunt’s initiative on Kari’s Law from the very beginning.

Follow me on Twitter @Fletch911
Check out my Podcasts on APN

WordPress.com.

Up ↑