Push-to-talk (PTT) and, eventually, mission-critical PTT (MCPTT) services are foundational applications that will determine how the NPSBN is adopted and the impact on interoperability. The successful integration of PTT/MCPTT with disparate LMR and LTE networks is the biggest challenge to interoperability. MCPTT technology is accelerating at a rapid pace, and public safety has to decide how to best implement this technology to allow for interoperable public-safety communications between existing LMR networks and public-safety wireless broadband partners.

The Problem
The ultimate implementation of PTT/MCPTT may take place via a variety of technologies, methods and forms from over-the-top (OTT) app-based implementations to network-level integration with devices. Local jurisdictions are likely to use a variety of commercial carriers in addition to the FirstNet offering. If the proper architecture is implemented by the NPSBN, interoperability concerns can be alleviated. Unfortunately, the offering for prioritized, network-level PTT/MCPTT voice from AT&T/FirstNet implemented by Motorola Solutions will work only on AT&T devices and within AT&T’s network and will not support the necessary connections for cross-carrier interoperability. For jurisdictions that are not FirstNet subscribers, ensuring interoperability is difficult.

The implementation of an MCPTT solution without interoperability with other networks outside AT&T would severely impact voice communications on roaming networks where coverage is poor or in jurisdictions that choose other vendors and will affect all users on competing mobile networks. Not having MCPTT work across mobile networks could have a detrimental impact on nationwide and state-level interoperability.

While options to implement an open, standards-based interface between LTE and LMR are being developed, it is unclear what form the interface implementation will take in the AT&T/FirstNet offering. If the ultimate solution is not completely interoperable with LMR systems, it will, by definition, create interoperability problems for first responders.

The need for cross-carrier MCPTT with LTE broadband is significant. Integration of MCPTT with LMR will be the critical factor for long-term adoption of LTE technology. Jurisdictions perform mutual aid, not only working border-to-border but outside of their states. An interoperable, open MCPTT system would be a cost-effective solution and be put to use by undercover agents, task forces, support staff and LMR users.

Network-Based PTT
PTT services over cellular (PoC) have been available for nearly 20 years with commercial network solutions such as iDEN from Nextel. Sprint’s QChat-enabled and Kodiak-enabled services for Verizon and AT&T continued this concept of carrier-deployed PTT. Each of these services provides integration into LMR networks and feature-rich PTT services, but they are currently offered as noninteroperable solutions. For example, a department using Sprint and another using Verizon that both have PoC services can’t communicate with each other directly on PoC.

However, there is no technical reason why these networks cannot directly communicate over PoC. Kodiak, now owned by Motorola Solutions, offered hosted services to both Verizon, marketed as PTT+, and to AT&T, marketed as Enhanced PTT. Last year, Sprint announced it would transition to a Kodiak-enabled solution marketed as Direct Connect Plus. Therefore, three of the four nationwide carriers use the same hosted solution, and all have the capability to communicate on the same talkgroups across carrier network boundaries. FirstNet has stated that its application network is closed, and PTT services will be offered on its network with no cross-carrier network interoperability. It is unknown if the same will be true for MCPTT implementation.

Verizon’s hosted PTT+ service from Kodiak Networks offers radio over IP (RoIP) and Project 25 (P25) Inter RF Subsystem Interface (ISSI) LMR interworking via a virtual private network (VPN) connection from the agency interface to the Verizon/Kodiak hosted solution. Verizon offers some quality of service (QoS) differentiation with its private network traffic management solution. However, to service public safety, Verizon has committed to upgrade to MCPTT with priority and pre-emption capabilities at no additional cost to users.

Verizon is the only operator currently offering cross-carrier support for PTT with the Kodiak solution. Because the Kodiak solution is hosted in the cloud, it provides service from the same system to Verizon, AT&T and Sprint. In theory, this service could be used on other LTE networks such as rural and regional carriers using an internet connection.

Verizon cross-carrier interoperability service is in use by a few agencies, and Verizon could begin marketing it this year. AT&T, T-Mobile and Sprint have declined to interoperate with Verizon talkgroups on its solution; thus, a new Verizon talkgroup definition must be added to manage these users. Verizon supports advanced encryption standard (AES) 256 bit, and the carrier is looking at federal information processing standard (FIPS) 140-2-compliant devices, but the cost seems prohibitive.

Verizon is also committed to providing ISSI and Console Subsystem interface (CSSI) console interfaces into a Third Generation Partnership Project (3GPP) MCPTT solution. The carrier is pushing Kodiak/Motorola to provide it with a 3GPP MCPTT-compliant solution by mid-2018. Verizon is also creating an Excel template that can be provided to agencies to define talkgroups in a common schema. This spreadsheet can then be automatically uploaded to the MCPTT application server with all the proper talkgroups defined.

From a QoS perspective, a major issue for MCPTT support is from the device vendors, although the current Kodiak solution supports both iOS and Android devices on multiple carriers globally. The Kyocera Duraforce Pro and Sonim XP5 are the only devices that support PTT+ and QCI on Verizon’s network, but the carrier is working to provide this capability to a majority of its device portfolio in the future for MCPTT.

Over-the-Top PTT
With the advent of carrier-agnostic applications for Android and Apple, the PTT application space is inundated with feature-rich, cost-effective systems that work across networks. OTT PTT applications have had success in both the commercial and public-safety markets. Google Play has more than 150 applications that purport to offer PTT functionality available for download. Two years ago there were only 16 such apps. An advantage of nearly all OTT PTT applications is the ability to work on multiple broadband access technologies such as Wi-Fi, LTE and even 3G data on multiple platforms. Innovation is the other benefit of OTT applications. Without the constraints of the network or standards process, they can integrate data sharing, video, photos, text and location-awareness capabilities enabled from a device.

Integration into Digital Mobile Radio (DMR), LMR and P25 ISSI is available with many solutions. A major advantage of OTT applications is that they can work on a variety of devices and across multiple carrier networks because these are application-layer-enabled systems.

The biggest issue with OTT PTT is that once a vendor is selected for the application, everyone needs to have the same application. For instance, a Harris BeOn PTT system cannot directly communicate to a Motorola Wave PTT system. This quickly destroys interoperability and becomes a large-scale management problem. Therefore, a globally recognized MCPTT that adheres to the 3GPP standards should be implemented. Because of this common need for voice communications, MCPTT in 3GPP development has been accelerated for the past two years.

MCPTT Standards
MCPTT is a global standard that is being led by system architecture group six (SA6) of 3GPP. The seminal document for MCPTT is “3GPP TS 23.279 Functional Architecture and Information Flows to Support Mission Critical Push-To-Talk (MCPTT).” This document was initially part of the 3GPP Release 13 specification, and the latest version reflects Stage 2 requirements for 3GPP Release 15. This document specifies the functional architecture, features and data flows for MCPTT, and it addresses making MCPTT calls on multiple networks.

MCPTT requires an integrated client application of the LTE device and an MCPTT server that connects to the LTE core network. The MCPTT server can also run the database functions, as this is all software implemented. The use of the IP multimedia system (IMS) is optional for MCPTT. MCPTT without the IMS function can simplify call processing, reduce cost and allow for unique deployments such as backpack deployable systems. Unlike voice over LTE (VoLTE), which mandates use of IMS, MCPTT offers some flexibility. It is likely, though, that MCPTT delivered from an operator will use the same IMS core as VoLTE.

The primary interface from the MCPTT application server to LMR will be accomplished via the interworking function (IWF) interface, defined in “3GPP TS 23.283 Mission Critical Communication Interworking with LMR Systems.” Interworking in this context is a means of communications between MCPTT and LMR systems, whereby users obtaining service from a MCPTT system can communicate with LMR users who are obtaining service from an LMR network. The purpose of the IWF is to adapt LMR data and signaling to MCPTT data flows, which means that there will be no direct connection between a P25 ISSI and the NPSBN without an IWF implemented. As of the latest version of the document for Release 15, there remains a tremendous amount of work to further define the IWF.

Although work is being done in 3GPP to define the LMR IWF gateway interface specifications, the actual specification from a LMR network to the LMR IWF gateway is not being defined by industry standards organizations.

MCPTT to LMR communications will be required to transcode from Advanced Multiband Excitation (AMBE) codec to the Adaptive Multi-Rate (AMR) audio codec. Transcoding is not a problem in itself but one of the issues with P25 implementation is that each P25 network uses its own expensive code and has unique security and encryption protocols, thus making key sharing costly and complicated. Every ISSI connection to the IWF must be separately and securely connected — making management and cost of this implementation unfeasible. Use of an ISSI hub would be a more efficient way to interconnect MPCTT to state and local LMR networks; however, there is a cost for hardware, software and maintenance of such a solution.

However, not all is well in the land of 3GPP when it comes to MCPTT interoperability. The standards process does not define the applications programming interface (API) between the MCPTT device application and the MCPTT application server on the network. This means you could have a 3GPP-compliant MCPTT application on a device from vendor A being served by a MCPTT application server from vendor B and how the device interoperates with the network is not clearly defined. This is similar to initial voice over LTE (VoLTE) implementations where there were subtle differences in IMS protocol stacks between vendors. Those working on MCPTT should learn from this and avoid this pitfall.

Lastly, MCPTT is designed to work on an LTE network, and in the current 3GPP specifications, there is no additional functionality that will be supported for non-3GPP access. This is potentially a big issue for several reasons. Current OTT applications support calls over Wi-Fi and use of corporate Wi-Fi indoors. Current MCPTT implementations would lose this capability and require innovation beyond what is being proposed in 3GPP. One of the indoor coverage solutions provided by FirstNet is use of AT&T’s more than 40,000 Wi-Fi hot spots. If MCPTT is not available while in Wi-Fi coverage, this must be addressed from either a coverage or functionality perspective to ensure MCPTT works indoors.

Recommendations and Deployment Options
MCPTT can be deployed in a variety of ways. This flexibility has caused some vendors to explore the options. There are some functional and operational differences in each deployment, but the majority of the MCPTT deployment options are business-case driven.

The following are suggested requirements that public safety should adopt in a MCPTT solution:
1. Use of a 3GPP standards-based MCPTT solution that can be software upgradeable with each system’s release in both the device client and application server.
2. The application server and client application should have open APIs for software development kits (SDKs) to allow maximum vendor interoperability and competition for best-in-class implementation, such as the Mission Critical Open Platform (MCOP) API.
3. The system should allow for both hosted and local implementations for integration into existing P25 ISSI, CSSI and non-ISSI-based systems. This includes the ability to relay simplex LMR communications on MCPTT.
4. The MCPTT service should work across all mobile operator networks used by public safety, including international roaming and Wi-Fi.
5. The MCPTT solution should be able to implement all of the various talkgroups already defined across the state, with proper authentication and security, allowing only those authorized access to specific talkgroups.
6. Support for both Android and iOS devices is required.
7. The MCPTT solution must be cost effective to implement for all agency sizes with minimal to zero impact on cost and complexity to the user.

One of the most important capabilities is the ability to operate across mobile network operators. This capability can be achieved with hosted MCPTT solutions offered by several MCPTT vendors and by carriers willing to offer this service. Based on what is known, the current AT&T/FirstNet PTT solution will not be interoperable with any other users who are not on their network, which could be a major setback to the interoperability envisioned if it is carried forward with MCPTT. However, the FirstNet network is fully capable of meeting most of the aforementioned MCPTT requirements either now or in the near future with coming MCPTT releases.

Would you like to comment on this story? Find our comments system below.

---

Emil Olbrich is president of PrimeLime and has more than 25 years of experience in the field of wireless telecommunications. Previously, Olbrich was the head of Long Term Evolution (LTE) research and development (R&D) for the Public Safety Communications Research (PSCR) program. Email comments to emil.olbrich@primelime.com.