Last week, another tragic event occurred in our nation’s capital, when 12 people were gunned down at the Washington Navy Yard. According to a report published by the Atlantic Wire, first responders had some issues with in-building coverage as they moved deeper into Building 197—the headquarters for the Naval Seas Systems Command (NAVSEA)—in pursuit of the gunman. Given the size of the structure, that’s not surprising.

What I did find surprising was that interoperability also was an issue, to the point where federal officers had to resort to using runners. I’m not sure why this surprised me, other than the fact that we just marked the 12^th anniversary of the Sept. 11, 2001, terrorist attacks on New York City and Washington, D.C.  I guess I thought that interoperability would be solved by now.

Tomorrow, in a webinar sponsored by Avtec, a panel of experts will explore the current state of interoperable communications in the public-safety sector, with an emphasis on how today’s reality matches up with the vision. In fact, we’ll spend some time discussing that vision, and whether it is realistic.

The panel includes the following:

·         John Powell, chairman, National Public Safety Telecommunications Council (NPSTC) Interoperability Committee

·         Steve Graves, CIO, city of Richardson, Texas

·         Steve Devine, assistant director, Missouri Dept. of Public Safety Interoperability Center

·         Greg Warner, director of emergency communications, Bonneville County, Idaho

·         Terry Hall, chief of emergency communications, York County, Va.

·         Barbara Jaeger, 911 administrator, state of Arizona

Last week, we conducted a rehearsal call for this webinar and, as often happens, the panel launched into an interesting debate. Devine got things started by recounting a scenario in his state. Missouri’s statewide system operates on VHF frequencies, which is problematic when users are in downtown St. Louis.

“When they’re in these urban canyons and in these buildings, we want to them to move over—as seamlessly as possible—to the city’s 800 MHz system, which provides better in-building coverage,” he said. “So, we tied their switch to our switch, so now it’s one system. The user doesn’t know he’s operating on 800 [MHz], but he’s getting better and more reliable coverage, because his radio is opportunistic—it will find the best coverage, as long as you’ve told it to do so.”

 Sounds simple, doesn’t it? Of course, the devil always is in the details. In this case, the user needs to be carrying a dual-band or multiband radio for this handoff to occur, and not every agency has the financial ability to procure such devices.

Even when procurement isn’t an issue, programming them—i.e., ensuring that they are “opportunistic”—often is, according to Powell.

“Education needs to occur on two levels. First, those who are procuring these systems have to be told that these capabilities are there,” Powell said. “Second, once you have them, it’s a whole new [world] for the system manager to program these. It is not a trivial process anymore to program these advanced radios.”

And therein lies one of the challenges to establishing interoperable communications. Often, even the seemingly simple solutions have a lot of moving parts—and all too often, the solutions are anything but simple.

Here’s another example. The transition from VHF to 800 MHz that Devine described is similar to what occurs on the cellular side, where devices roam seamlessly between PCS and 800 MHz.

“You don’t care which one your device is on, as long as it’s working,” Devine said.

But Graves noted that the seamless roaming that lets Missouri statewide system users jump onto the city of St. Louis’s system, when necessary, is made much easier, because the two systems are tied together at the switch and were procured from the same vendor. Graves added that such roaming could become more challenging when disparate systems are involved, because each vendor will have its own licensing scheme.

“If I build a system that has to have extra licenses to support people who will have to roam onto my system—because, in an emergency, you have to support so many users, right?—when you look at the costs associated with that, it’s a problem.”

It is a challenge that Devine readily acknowledged.

“In order to give people access, you would have to have a number of unit IDs basically in a cache, waiting for them to draw on those IP addresses dynamically,” he said. “So in that instance, I’m going to have to go to [my vendor] and tell them that I need X amount of units that will sit here dormant until someone roams into my system and gets defined one of those. So, you will have your licensing issues—even with ISSI you’ll have them.”

Unless, as Graves suggested, APCO, NPSTC or some other entity makes a push to establish a protocol via which users could pay a reduced licensing fee in the case of large-scale, multijurisdictional emergency responses.

“Those licenses can be extremely expensive,” he said.

After listening to this interplay—during the rehearsal call, mind you—I came away with two thoughts. One was that I’m glad I don’t have to figure this stuff out. The second was that, if I did, I’d make sure I attended tomorrow’s FREE webinar (register here), which will provide opportunity for you to ask questions of our panelists, in addition to hearing their insights.

Please join us tomorrow—I am confident that you will find it time well spent.