Welcome to my page. This is the first post in a series that I hope will be valuable as we look at new ways to fill public safety’s need for effective field communications. Feel free to read; A little about myself and my blog | by Neil Horden | Mar, 2021 | Medium

Rethinking Requirements:
- Why when we think ‘Push-to-Talk’, we assume ‘Land Mobile Radio’?

When we think of public safety communications, we most often think of police, and fire, and the Two-Way radios they use. While much has changed about these systems over the years, the fundamentals of Two-Way Push-to-Talk (PTT) communications on a Land Mobile Radio (LMR) system has been a staple. So much so, that we often define our communications requirements as if PTT over LMR is the only viable solution.

There is a good historical basis for this. The development of the capabilities of Two-Way PTT over LMR, and the evolution of requirements of Public Safety communications has had a symbiotic relationship from the beginning. Public Safety was one of the first users of Two-Way PTT radio. As manufactures looked for features and functionality to add to systems, public safety was often the target market. Even as this was occurring, public safety was continuously refining its operating procedures. In these refinements, the capabilities of PTT LMR became and embedded part of the process.

This 90+ year history has created an almost 1-to-1 connection between the expectations of public safety for communication and the services delivered by these technologies. With the use of PTT communications so closely related to the evolution of LMR systems it is no wonder we have trouble separating the requirement for quick and easy (PTT) communications from their need for LMR technology. The tentacles of this relationship extend all the way into how these systems are defined and how they are procured.

So, while you may be very sure you need a new, upgraded or expanded PTT LMR system, what you really have is requirement for quick and easy communications. Those requirements may be met by LMR; however, it is your requirements that should drive your system selection, not your previous technology choice.

Years ago, procurement specifications typically described the desired system at the technology level. This included details right down to numeric values for size, power, sensitivity, and many other factors. At that time, most of the equipment from the various manufacturers was very similar, and unless you were careless (or sometimes you were being intentional) most any of the available manufacturers could supply equipment and systems compliant to your specifications.

Over time, the technology advanced, and although the industry provided equipment and systems to accomplish the same tasks, the detailed technical specifications of each manufacturers systems became different in many ways. With this, many agencies moved towards developing their procurement specifications using a “functional requirements” structure. In this way they would define what the system needs to do, while providing the manufacturers with some flexibility in how they addressed meeting the requirements. Even with this shift from technically to functionally defined requirements, the specifications developed for communications systems continue to assume the use of PTT and LMR technologies. While this assumption was fairly safe, since most all available systems were based on LMR technology, as with any embedded assumption, it made some unique and potentially valuable solutions difficult to propose as a compliant to the specification, and therefore forced suppliers to provide an “Alternative Proposal” with the inherent risk that it would be rejected.

As communications technology has continues to evolve, and with most public safety systems beginning to include other PTT technologies, such as Cellular, LTE, WiFi, etc. it is well past the time to reconsider how our systems are defined and how specifications are developed.

In the upcoming Rethinking Requirements posts we will discuss the migration from using “Functional Requirements”; which reflect your best understanding of how you expect the system to operate, to a model based on “Fundamental Requirements”; capturing what you specifically need to accomplish.

Thank you for time, and I welcome any questions or comments, either here or by email.

Neil Horden

Neil@HordenTech.com