The Webster Dictionary defines “Unified” as “Brought together as one.” Under the public-safety Incident Command (IC) structure, “Unified” means “Unified Command (UC): In incidents involving multiple jurisdictions, a single jurisdiction with multiagency involvement, or multiple jurisdictions with multiagency involvement, Unified Command allows agencies with different legal, geographic, and functional authorities and responsibilities to work together effectively.” (For more information about Incident Command see FEMA.)
Based on both meanings of “Unified,” I would like to suggest that public safety leave “interoperability” and “PTT interoperability” (Push-To-Talk interoperability) behind and replace these terms with “Unified.” This might make it easier to explain exactly what is needed by the public-safety community when it comes to push-to-talk. Perhaps later, “Unified” will come to describe unified data, unified video, and other technologies and services that should be available to all public-safety agencies, particularly those that use FirstNet. While it may still require action on the part of the first responder to enable “Interoperable,” I envision activation of “Unified” as being more automatic, perhaps by selecting a single key or button on the device.
My definition of Unified PTT is a voice service that is available to every first responder both on the FirstNet network and their own Land Mobile Radio (LMR) network, which is easily accessed from either a broadband or LMR device. I believe Unified PTT can be implemented using technologies already in the field. However, it will take someone or some group to bust through vendor reluctance and become compatible with other PTT services and for vendors to realize that a network-based solution does not offer the flexibility public safety requires in the field.
The Question Remains
Simply because I have suggested a name change for Interoperable PTT does not mean we can now move ahead and make it happen. We still need a balancing act to work with the various vendors.
Unified Public-Safety Push-To-Talk
To understand what Unified PTT is, a series of definitions and operability standards need to be developed (they already have been but they need to be included in a document (set of standards?). Unless this is done, we could end up back where we are today with seven Certified FirstNet (Built with AT&T) push-to-talk standards, no roadmap for creating a unified system, and several vendors that want to lead the parade as long as their own flavor of PTT is the de facto standard.
My first set of recommendations starts with a list of what a Unified PTT environment would look like.
- Every FirstNet user must be able to communicate by voice PTT to any other FirstNet user on the FirstNet system.
- Every FirstNet user should have PTT interoperability at least over their own LMR network (no matter the technology) using either an LMR radio or a FirstNet device.
- Over a specified period of time, every PTT device using FirstNet and LMR networks must be able to send both Unit ID and location data when in use. Of these two, I believe location information is the most important. (See Winding Down section.)
- Unified PTT must be fully compatible with all FirstNet-Certified devices using either Android or iOS (Apple) operating systems and the devices must be able to run FirstNet-Certified applications.
The issue that remains: How will public safety convince those already committed to a PTT-Certified application for FirstNet to become part of a Unified solution? I believe there is a way to jumpstart Unified PTT for public safety and I have detailed how it might work at the end of this article.
A Little PTT History
While the FirstNet Authority was planning for the new nationwide broadband network, some vendors were providing push-to-talk over cellular. However, somehow, those within the federal government who were working with the 3GPP standards body were pushing the 3GPP to developing a Mission-Critical PTT (MCPTT) application. At the time, the idea sounded good to many vendors and the first-responder community at large.
However, there are some questions. When will the 3GPP MCPTT standard be available on all FirstNet (Built with AT&T) devices? and What do you do for PTT over FirstNet until that time? The 3GPP is a large organization with contributions from many vendors and other interested parties. The 3GPP typically works on network interface standards as opposed to application standards, and in the network arena it often takes a long time for the 3GPP to reach a consensus. Following publication of a new standard or a revision to a standard, there can be a considerable amount of time required for vendors to develop and operators to release upgrades to networks and products.
With false starts and delays, it took a long time for the 3GPP to develop its Mission Critical Push-To-Talk standard. It took even longer for vendors to build devices that were “compliant” with the standard. Further, as of today, the talk-around (Pro Se) function does not provide for essential off-network communications.
During the wait for MCPTT and compliant devices, FirstNet (Built with AT&T) certified a number of non-MCPTT applications. Today, there are seven FirstNet-Certified PTT vendors and, inexplicably, some agencies are using non-certified and non-encrypted PTT over FirstNet. As a result, not all agencies using FirstNet can communicate with all other agencies using FirstNet PTT, yet it is one of the most used applications on the network.
If you count all the agencies using PTT over FirstNet today, you will find that the majority are using one of four PTT applications. The first is AT&T’s Enhanced Push-To-Talk (EPTT), a Motorola product acquired from Kodiak Networks. EPTT was among the first applications to be “FirstNet-Certified,” as it was already part of the AT&T portfolio. Today, Enhanced PTT is used by many public-safety agencies over FirstNet, and it is available on some FirstNet state contracts for a small charge or for free.
The EPTT servers are integrated into the AT&T core network, thereby augmenting EPTT with Quality of Service (QoS). The downside of “carrier-integrated” PTT offerings is that they do not provide direct interoperability to users across wireless carriers. Therefore, EPTT users cannot communicate with Verizon PTT Plus users (also from Motorola) without the use of hardware gateways or special applications.
Next are three companies that also provide FirstNet-Certified PTT over FirstNet. These three include ESChat, Tango Tango, and JPS VIA, all of which use a hosting architecture that provides native cross-carrier interoperability (without gateways or special applications). These products also take advantage of the enhanced QoS benefits that FirstNet and Verizon Frontline provide to their users. One of the most significant advantages of these products is that they can facilitate cross-agency communication, regardless of which wireless carrier is being used and without gateway solutions.
Why is inter-carrier PTT communication important? As much as we would like all agencies to choose FirstNet, not all will. Therefore, a Unified PTT experience will require all PTT solutions to be able to communicate with each other regardless of which carrier the agency is using. (And when non-FirstNet users move to FirstNet, their PTT platform comes with them.)
If statistics were available to rank the percentage of FirstNet users who are using some form of PTT over FirstNet, I believe these four companies would have more PTT users up and running than all other FirstNet PTT vendors combined.
The Way Forward
At this point, several things are evident: First, the two companies that have announced devices that support MCPTT are late to market, limited in scope, and only Android devices are represented. Apple has yet to commit to providing devices (iPhones or iPads) that will support features required for MCPTT, so for now I am leaving these devices and MCPTT out of Unified PTT discussions.
Several Attempts to Get It Right!
Over the last five years or so, several vendors have tried to develop multi-vendor solutions. The hang-up is that when one vendor talks to another, they usually do not agree to share specifics of their software. However, at least one county worked with its PTT vendor, and the resultant system has been up and running for few years in Chilton County, Alabama:
Chilton County started out using iDen on the Southern Linc cellular network. When Southern Linc transitioned to LTE, the County tried the next flavor of Southern Linc PTT but, at that time, it went with the AT&T (Kodiak/Motorola) Enhanced PTT service from its FirstNet account representative. As it turned out, Tango Tango later became a white-label dealer for FirstNet-Certified ESChat.
In 2017, Tango Tango transitioned to its own PTT solution built on technology licensed from ESChat. Tango Tango’s new solution provided more opportunities since many of its customers were using multiple cellular networks. The move to ESChat’s “over the top” architecture enabled the new Tango Tango application to provide PTT across multiple cellular networks and to communicate over any existing LMR PTT systems.
What Chilton County is doing should be considered a roadmap for Unified PTT. Unlike the vendor that asked Motorola if it offered an interoperable PTT solution and was shut down, Tango Tango worked with the County and local agencies. This resulted in a Countywide PTT system that provides Unified PTT services for agencies within the County over Enhanced PTT, Tango Tango PTT (ESChat), and both analog VHF and 700/800-MHz P25 systems. The system has been up and running long enough now to prove it works well and enables every agency within the County hold PTT communications sessions with any other agency.
This system uses Radio over IP (RoIP) technology that requires hardware gateways and doner radios to connect the various systems. In today’s world, it could combine more advanced (and in many cases, standards-based) interoperability technologies including: ISSI, CSSI, AIS, ISI, RoIP, and other wireline protocols available for integration of various LMR, Console, and broadband PTT services.
A Starting Point
When broadband systems can interoperate with one another, LMR, and Console networks using existing standards-based protocols we will have a starting point.
If other counties or agencies decided to move forward using this model, they would be able to provide a system that would connect the majority of FirstNet (Built with AT&T) PTT users with a number of different gateways for various forms of LMR.
This model would not preclude other PTT vendors from joining what could easily become a truly Unified PTT nationwide system. If new technologies are developed to make it easier to upgrade PTT services, all the better.
Moving ahead using this model, broadband systems will be able to interoperate with each other, LMR, and Console networks using existing standards-based protocols. In most cases, this starting point will not require vendor-to-vendor cooperation since networks to be Unified are already in service and belong to public safety as well. Since FirstNet is licensed to the FirstNet Authority, and AT&T is the contractor building the network to serve public safety, vendor-to-vendor cooperation is not usually necessary for FirstNet either.
Perhaps it is time for public safety to stop listening to vendors whose primary goal is to create income for their stockholders and move forward with implementation of Unified PTT.
With this approach, there would not be a single vendor at the top of the heap that might push its own PTT application ahead of others. There would not be any issues about monthly cost of service since the cost will be negotiated with public-safety agencies and not with some large vendor whose “cloud” would be the common back-end for the system. Instead, this would be a true Unified nationwide PTT network that could be up and running within months, not years.
Our Advocate Survey will remain live until the end of IWCE. So far, the results are quite interesting. For example, the number of agencies willing to wait for MCPTT to become a dominant PTT solution is smaller than expected. Most of the responses so far indicate agencies are moving ahead with their own choices of FirstNet-Certified vendors. However, the bad news is that a number of agencies have elected to use non-certified FirstNet PTT applications. Some of these do not appear to provide a reliable level of encryption, thus it is easy for non-public-safety users to listen in using a variety of ways to gain access.
Two other points worth noting: The majority of respondents indicate off-network is best left to LMR because LTE off-network is not truly viable today with broadband off-network solutions. The overall consensus of respondents is that a true, nationwide PTT system that provides PTT access to all FirstNet/LMR users is imperative and should be a priority for both FirstNet organizations.
When I talk to people who are involved with PTT for both broadband and LMR, I continue to learn a lot. For example, in several discussions I have stated that transmitting the unit ID across FirstNet/LMR integrated systems is a must-have. However, I have been receiving some push-back on that recently. There seem to be some similarities between LMR and FirstNet devices when it comes to who actually has the device on any given day.
I am hearing that in both the LMR and FirstNet worlds, device ID does not always equate to the user ID in many cases since the radios are not permanently issued to a specific first responder (with the exception of the top Brass). If I had thought this through better, perhaps I would have come to this conclusion some time ago. Vehicle devices and LMR handhelds are not normally assigned to a specific person.
Now, if you add in FirstNet devices you will find that they too can change hands. So, I am told, the idea of a unit ID, while helpful in some cases, is not a big deal for those operating in the field. The next part of this is that when it comes to FirstNet devices, especially those using PTT, there are several types of distribution. For example, Company Brass might have their own devices and stop carrying their LMR radio. Then there are bring-your-own-device folks, fleets of devices shared across shifts and, in some cases, permanently assigned smartphones and tablets. So, I am also revising my thoughts about how important unit ID really is. However, I still think location data, if available, should be sent during PTT sessions so those in the PTT group know where other personnel are located.
The next issue I have become aware of is the need for someone or some organization responsible for keeping track of all the smartphone (and LMR) devices. I have been told by several agencies that as units are handed around and people change positions, retire, or change agencies, it is easy to lose track of devices. It will be interesting to see how various agencies keep track of where all the devices are and who has them. I know from my own experience working with several agencies that are trying to update a list of devices that has not been updated in a while is an almost impossible task. Once, I identified a number of devices that were unaccounted for. When I asked about them, I was given several different answers: “Oh, I think that unit was assigned to Fred,” “I think we loaned that unit out to XYZ,” or “I don’t have a clue where it is.”
It is possible to make sure all units on a P25 trunked system are legitimate, but in the LMR and FirstNet worlds, unless someone is tasked not only with tracking but also with assuring each device has the latest software onboard, it can turn into a disaster. Thankfully, there are a number of management packages for tracking these devices. Even so, I am hearing from those in the field that after a while it becomes a burden for someone within the organization to constantly update the device lists, keep track of when they were last updated, and verify who has which unit or where the cache of devices is located.
As more agencies adopt broadband, LMR and LTE devices become mixed. It will be interesting to watch how various departments deal with the need to know everything possible about a device, including where it is!
Until Next Week…
Andrew M. Seybold
©2022, Andrew Seybold, Inc.