What's an ERL and Why Should I Care?

One of the dangers of immersing yourself in a particular technology is the tendency to assume everyone has the same level of knowledge on the subject that you do. This point hit home recently when I got a support call from an installer about our LENS product. He couldn’t get it to work.

Without going into too many details, the issue was this: LENS was installed in a High School near the school’s CS 1000 (where it belongs, incidentally). One Alert Agent was installed in the office at the high school; another was installed at a nearby middle school. The customer wanted to monitor 911 calls originating in either building, but they wanted the middle school to be notified only on 911 calls from the middle school, and the high school to be notified only on calls from the high school. Given that LENS was designed for precisely that purpose, I was surprised they were having problems.

After a bit of gentle prodding, I determined that the ERL filtering wasn’t enabled on their Alert Agents. It was a simple fix, or so I thought. Just have them turn on ERL filtering in each of their Alert Agents and all will be right with the world. I wasn’t too worried when I was asked, “How do I do that?” No one ever reads manuals anyway, so I talked him through the simple process (click Tools | Options | ERL Filtering and enter the ERLs you want to receive alerts for). I became slightly uneasy when he asked me what values to enter for ERL. I suggested that he enter the middle school‘s ERLs in the middle school agent, and high school’s ERLs in the high school agent. “What’s an ERL?” he asked me. Now I was concerned.

I had fallen into the trap. During the development of LENS and Locate911 over the past year, I had been immersed in the technology, but hadn’t stopped to consider that there are CS 1000 installers in the field who have no idea what ERLs are, how to configure them in the Call Server, or how to map them to physical locations.

This is the definition of ERL, which was conceived by the National Emergency Number Association (NENA):

Emergency Response Location (ERL)
A location to which a 9-1-1 emergency response team may be dispatched. The location should be specific enough to provide a reasonable opportunity for the emergency response team to quickly locate a caller anywhere within it. (See http://www.nena.org/media/files/NENA00-001_V1020070605.pdf, p. 28).

A fantastic video explanation on ERLs and how to configure them can be seen here:

In this customer’s particular case, they had only deployed a single Emergency Location Identification Number (ELIN) covering both buildings. This means that anytime anyone at either location dials 911, operators at the Public Safety Answering Point (PSAP) will only see a single address, and not necessarily the address of the building where the call originated. Imagine expanding this issue to an entire school district spread across many square miles, and you’ll begin to appreciate the scope of the problem. Fortunately, this is precisely the problem that Nortel and eTelemetry address with these products.

The Nortel CS 1000, release 5.0 and later, has native support for the ERL concept. Once a site’s ERLs are mapped to physical locations, each ERL can be assigned an ELIN, and each ELIN can be provisioned in the local PSAP. Now no matter where inside an ERL a 911 call is placed, PSAP operators get much more accurate and valid location information. They know where to send help, even if the individual on the other end of phone can’t speak or the call has been disconnected. Provisioning and changing information in the Public Safety database is both costly and time-consuming. Using ERLs for E911 location provides a huge advantage in this area. Once an ELIN is established, there is hardly any reason ever to change it, saving both time and money.

Once we understood the problem, the fix was simple. We defined two ERLs in the Call Server, 100 and 200. I recommended this approach for future expansion. As the school decides to get more and more granular with their ERLs, they won’t have to start over. ERLs 100-199 were reserved for the high school, and 200-299 for the middle school. These ranges were entered into the respective Alert Agents’ ERL filtering so that each school received the appropriate notifications. Both ERLs use the same ELIN for now, until a new ELIN and address for the other school can be provisioned with Public Safety. Until then, Public Safety still gets a single location, which is far from ideal. Because they are using LENS, however, school officials know not only that a 911 call was placed, but from which school.

In the future, this particular school system can further eliminate confusion by implementing more ERLs locally, such as

• 110: Cafeteria
• 120: Science Labs
• 130: Gymnasium
• and so forth.

They can do this freely, even without updating Public Safety's database. The important thing to understand is that although Public Safety may not know that a 911 call came from the library, local on-site personnel will, can direct local first-responders there quickly, and have people ready to guide public safety responders to the appropriate location when they arrive.

As Voice over IP (VoIP) phones gain more and more traction in the education and business worlds, locating a moving phone is becoming ever more critical. Trying to update Public Safety’s database with every potential phone move is impractical, if not impossible. Not only is it expensive, it’s slow. Implementing ERLs solves this problem by provisioning locations with Public Safety once, and then by relying on a local discovery manager such as Locate911 to keep the Call Server updated with each phone’s location, enabling it to use the appropriate ELIN during a 911 call. Furthmore, by utilizing an appropriate on-site notification solution, like LENS, local first-responders know precisely when and where a 911 call has occurred.

In a future post, I'll describe a strategy to minimize the use of ELINs at the PSAP, while maximizing the number of distinct locations that can be reported internally.