BP Engage Enterprise Architecture - rallytac/pub GitHub Wiki

A common requirement we see is customers' desires to integrate external communications systems like two-way radio systems with their Engage systems. Most often, these radio systems are tactical in nature - that being that they're generally deployed in far-off places that may or may not have connectivity to an enterprise network through connectivity via a cloud (private or public).

What most often goes along with this is a need for Engage-based user applications - say on desktop or mobile devices - to communicate with those radio systems when they're available. The key term here is "when they're available" - meaning that the folks using their Engage apps would like to be able to talk to the folks using radios when the radios are actually in use. When the radios are not active or present, the Engage users still want to be able to speak to each other. Only the radio users are not going to participate - mainly because they're not using radios at that point.

While this all seems pretty striaghtforward you'll be surprised by how often we see people gettting wrapped around the axle regarding the radios being available or not. This document attempts to clear up this confusion and present a simple architecture that pretty much anyone can deploy.

OK, the first thing to embrace here is that radio systems are really nothing special, frankly. A radio is mostly just a microphone and speaker in a small box that has an attenna on it. When you hit PTT on the radio, your voice is captured by the microphone, encoded in some way for transport, and then transported over the wireless connection provided by the attenna. On the receiving end, that radio's attenna picks up the traffic which is then decoded and played out the speaker. Yeah, this totally glosses over all the cool stuff that radios do but this is the fundementals of how radio systems work.

On the non-radio side of things - say a bunch of Enagage-powered apps on a network - its pretty much the same deal. User devices capture audio from a microphone, encode it, transport the resulting traffic over a network of some sort (usually IP but not always), and play out the receiving end's speaker.

More fundamentally, what we're really saying here - be it for radio systems or non-radio systems - is that we just have a way to transport voice traffic between multiple devices; most often using a Push-To-Talk metaphor. Essentially an intercom system. And that's just it - we're really just putting fancy monikers on an intercom system.

OK, now that we've managed to totally trash all the fancy teminology and marketing around radio systems and glossed over the awesome techinical achievements of the two-way radio industry; let's continue.

So ... if we view PTT-style communications on radios or on devices likes mobile phones and desktops as, fundamentally, intercom systems; we can take some liberties with terminology (as if we haven't already) and also free ourselves of thinking about channels ("groups" in Engage-speak) being associated with radios. Rather, let's imagine that we'd rather be designing solutions for users to be able to communicate with each other - and only then think about what kinds of devices they're likely to be using. It also means that we give names to channels that are not radio-ish. For example: instead of naming a channel "San Diego, Radio Channel 1", rather name it something like "San Diego Security". Just a simple naming convention like this changes the way that you think about how and with whom you communicate rather than what devices those people are using. Frankly, the device really should be irrelevant.

Alright, you may think this a silly example but you'll be surprised how often we see folks naming their channels with (technical?) radio-like terms rather than their intended use and in the process limit there thinking and, therefore, the solution they put together.

Let's get to it by way of example. Now because we deal so often with military customers who have some unique requirements that most non-military organizations don't we'll tackle those environments.

Let's look at at few characteristics that one see in military systems:

PS. We promise we're not giving away military secrets here. We're not that crazy - these people are secretive, badass, have guns, and the might of their government behind them. So there's that.

Anyway ...

1. Military folks generally operate in a variety of highly complex networking enviroments including enterprise-style IP LANs and WANs, and satellite systems. These are fairly common across all organizations - so nothing special there. But then we start running into specialized environments such as operating on ultra-low bandwidth IoT networks, geostationery satellite systems (these things are VERY far away from Earth), MANETs (Mobile Ad-hoc Networks), and so on. (We won't get into what "and so on" means.)
2. Legacy military radios (often called CNR, or "Combat Net Radios") go back for years and are hardworking and ultra-reliable. Now, because they're so reliable (and also because they cost so much), these things are used extensively in modern times even though some of them were already in broad use when Elvis was still around.
3. Fast-forward, and modern military radios are very fancy indeed. They are hard-core computing devices running on some very sexy networks like MANETs. These MANET radios very often can interface directly with IP networks because they are very often, themselves, IP networks at the core.