Goals

Provide mobile, reliable, secure, grid-independent/grid-down voice communications for community support organizations operating in an urban environment spanning tens of blocks.

System Architecture

Each individual has a DMR HT (Baofeng DM-1701).

When the group is close enough, voice comms go directly between DMR HTs over UHF. (Experimentally this means within about 0.5 or 0.75 miles.) All HTs are set to the same frequency & encryption key, and operate in simplex mode.

When the group is too dispersed for direct simplex DMR communications (more than about a half mile, several blocks apart), we start a bunch of comms infrastructure:

• An ad-hoc mesh IP network. Manet, IP on 802.11s mesh network, running on 802.11ah HaLow radios.

• Two mobile DMR Hotspots. The hotspots are set to different frequencies, but both use the same encryption key.

• One DMR Master server.

Each of the two DMR Hotspots is positioned to reach an area of interest. People in the covered area configure their HT to use the Hotspot's frequency.

The DMR Master server runs on one of the Hotspots.

The Manet mesh nodes are geographically positioned to provide a network path connecting the two Hotspots.

Deployment example / Main use case

The group is fielding several roving teams within a relatively small area. Everyone has line of sight to each other. Everyone carries a Baofeng DM-1701 DMR HT, set to a single common frequency and encryption key.

The group decides to split into two subgroups. The two subgroups will not have line of sight to each other, but everyone within each subgroup will have line of sight to everyone else in that subgroup.

In preparation for splitting up we power up a bunch of equipment:

• several Manet nodes
• one DMR Master
• two DMR Hotspots

Each Manet node is a rugged battery powered computer, less than 1 liter, less than 1 kg.

Each DMR Hotspot is a rugged battery powered computer, less than 1/2 liter, les than 1/2 kg.

The DMR Master is a process running on one of the DMR Hotspots, doesn't matter which. (It can run on a separate computer if needed but it's more convenient to share hardware with a DMR Hotspot.)

The Manet nodes connect to each other and build an ad-hoc mesh IP network. Each Manet node in addition makes a normal Wifi Access Point. Each DMR Hotspot connects to the Wifi AP of a particular Manet node. The DMR Hotspots find the DMR Master using mDNS.

Note: The DMR Hotspot hardware we're using can only connect to 2.4 GHz Wifi, not 5 GHz. Special care must be taken to set the Manet APs to 2.4 GHz.

The DMR Hotspot for subgroup A is configured to receive and transmit using the frequency and encryption key from the original group. The users in subgroup A do not need to change their HT radio config.

The DMR Hotspot for subgroup B is configured to receive and transmit using the same encryption key, but a different frequency. This prevents the two hotspots from picking up each others traffic over the air and creating a transmit loop. The users in subgroup B need to change their HT radio configs to the new frequency. FIXME: is this multi-frequency setup needed?

When a person in one of the subgroups keys their radio, their transmission is heard immediately by everyone in their subgroup (because they have line of sight). Their transmission is also heard by their DMR Hotspot. The DMR Hotspot sends the transmission over the IP mesh network to the DMR Master, which sends it to the other subgroup's DMR Hotspot. The other subgroup's DMR Hotspot transmits the audio on its frequency and it is heard by all the HTs of that subgroup.

Shortcomings of the proposed system

Hotspots are isolated from each other by frequency. Each Hotspot uses a different frequency. Each Hotspot operates in simplex mode: it uses the same frequency for receiving and transmitting on.

Each HT is bound to a specific Hotspot by configuring the HT to use the Hotspot's frequency.

Audio transmission walkthrough:

1. a user sends an audio transmission from their HT
2. all HTs in range that are configured for that frequency hear the audio directly
3. a Hotspot in range configured for that frequency hears the audio
4. the Hotspot sends the audio to the DMR Master
5. the DMR Master sends the audio to the other Hotspot
6. the other Hotspot sends the audio out on its (different) frequency
7. all HTs in range of the other Hotspot (and configured for its frequency) receive the audio

This system scales poorly.

Problem 1: Adding a Hotspot requires allocating a new unique frequency for it.

Problem 2: Since each HT is bound to a specific Hotspot by its frequency, we can't easily extend the reach of the DMR coverage by just powering up more Hotspots: we'd have to also reconfigure the HTs in the new Hotspot's geographic area to talk to it.

Problem 3: Moving an HT from one Hotspot to the other requires changing the channel of the HT. HTs can't easily "roam" from one Hotspot to another.

Proposed solution:

• one Hotspot per medic team
• each Hotspot uses a different Talk Group
• each HT is associated with a specific Hotspot via its Talk Group
• Hotspots rewrite talkgroups on send and receive

Audio transmission walkthrough:

1. A user sends an audio transmission from their HT. This transmission goes out on a specific frequency, with a specific TG.
2. All HTs in that user's group receive the transmission directly.
3. The user's group's Hotspot receives the transmission
4. the user's group's Hotspot rewrites the TG from the group's TG to the "all users" TG and sends it to the Master
5. The Master sends the audio to all other groups' Hotspots
6. Each group's Hotspot rewrites the TG From the "all users" TG to that group's TG and transmits
7. All users in range of that Hotspot and configured for that Hotspot's TG hear the audio

Alternate Solution (Dynamic Nodes)

Rather than deploying static DMR hotspots, each team:

1. is assigned to a DMR talk group
2. carries one DMR hotspot configured for that team's talk group
3. carries one manet node to attach to the mesh

each member within the team carries an HT configured with:

1. the talk group for the team
2. the main talk group in case of emergency mesh-down line-of-sight fallback

Future work / Stretch goals

• location tracking
• text communication
• mesh health monitoring
  • show a map of the area of operations
  • show the location of each mesh node
  • show RSSI of each node-node link
  • this would let us keep the mesh healthy by dynamically adding nodes where they're needed
• support multiple independent DMR talk groups for sub-teams