The National Emergency Number Association (NENA) will release version 2 of its i3 architecture standard—the key technical guidelines for the implementation of next-generation 911 technology to support public-safety answering points (PSAPs)—sometime in the fourth quarter, said Roger Hixson, NENA’s technical issues director in an interview with Urgent Communications. The original version of the standard was approved in June 2011.

Hixson described the timetable for the release of i3 version 2 as “pretty soon,” hopefully as early as October.

“It’s in review at the moment, and the only issue is whether we’re going to include data schemas that are worked out to be NENA compliant,” Hixson said. “There are some timing and cost issues around that.”

The revision will add a few new items to the standard, but primarily will provide clarification on several others, Hixson said. Such revisions are common, as standards typically evolve over time, he said.

“Many of these items were referenced in the first version, but they weren’t as detailed as they needed to be,” Hixson explained. “And there were certain items that we knew we weren’t going to be able to cover in version 1, because there just wasn’t time or related information wasn't yet available.”

The revisions contained in version 2 reflect vendor feedback, as well as the results of NENA’s Industry Collaboration Event (ICE) interoperability testing, Hixson said.

The revisions include the following:

·         More support for PSAP call-control features;

·         An update to the Location-to-Service Translation (LoST) protocol—used to determine the PSAP that should receive an emergency call, based on the call’s location—to include references to the Internet Engineering Task Force’s remote function call (RFC) interface;

·         An update to the protocols that govern delivery of text-to-911 communications to PSAPs;

·         Additional detailing of the Geographic Information Systems (GIS) data-layer replication process—specifically the Spatial Information Function (SIF) layer replication protocol, which governs the exchange of GIS information between functional elements;

·         More details related to core services logging; and

·         Additional detailing about how wireless routing codes will be converted.

According to Hixson, the i3 architecture eventually will enable the call’s location data to be attached to the call itself, which will greatly simplify the process. The last item in the list above addresses what will happen in the meantime.

“When a call comes into NG-911 from a carrier, a routing code is provided that needs to be converted at the front end of the NG-911 system to a related location, so that location can be used to route the call to the appropriate PSAP that serves that location,” Hixson said.

The core services logging element of the standard is important, from both legal and troubleshooting perspectives, Hixson said.

“You need to know how the call got handled in each functional element, so that, in the rare case where a problem occurred, you can trace back and see where something didn’t go right for whatever reason, and what that reason was,” he said.

“You might have something in the database that’s not quite correct, or there could be an actual failure of some kind. We always have to design 911 systems to be as failure-proof as possible, but when there are failures, you have to build in capabilities to deal with them.”

Hixson anticipates future iterations of the i3 standard, particularly after the First Responder Network Authority (FirstNet) designs and engineers the much-anticipated nationwide broadband communications network for first responders that will operate on 20 MHz of spectrum in the 700 MHz band.

“Interoperability is the key thing here,” Hixson said. “As they move forward and better define how they’re going to have things work, hopefully that will take into account the NG-911 operational process.

“For instance, they may encounter a certain circumstance where they come back to us and say, ‘This will work more smoothly if we can get this particular data item,’ which may not be included in the current definition, because we didn’t know it was needed.”

 FirstNet may be more open to a collaborative effort with the 911 sector today than it would have been a year ago, because attitudes toward the 911 sector have changed significantly, Hixson said.

“There has been recognition of the interdependency” between communications in the field and those that occur in the PSAP, he said.