Push-to-Talk over Cellular Meets DMR: Bridging Radio Handsets and Phone Apps

A field supervisor on a plantation is not carrying a handheld transceiver. Neither is the dispatcher in the control room, nor the manager reading a report on a laptop. They carry phones. Yet the radio channel — the one asset that still works across an entire block — is reachable only from an HT on someone's belt.

That mismatch is why this workstream exists: put a radio group on a smartphone, and make it interoperate with the radios already in the field.

Push-to-Talk over Cellular

Push-to-Talk over Cellular (PoC) is a hosted push-to-talk service delivered over IP, cellular or Wi-Fi. The client is an app, the service belongs to the operator, and traffic rides on ordinary packet data.

DMR is close to the opposite. A DMR radio talks directly over licensed RF, peer-to-peer or one-to-many, through fixed repeaters and sites. There is no IP path, no account and no per-user service. The network is something you own, license, coordinate and maintain.

• PoC over cellular: operator-hosted, IP transport, account-based, good coverage where cellular is good.
• DMR: self-hosted RF transport, licensed spectrum, radio-ID based, coverage wherever your sites and radios put it.

Neither is better. They fail in different places, which is exactly why bridging them is worth the engineering.

MAGNET's publicly documented product line includes BelFone Push-to-Talk over Cellular (PoC) radio alongside the BelFone DMR line. Beyond that, this article is about the engineering problem and the interworking architecture of the product our team is building — not a product specification.

Cross-brand handsets are the hard part

On a real site, crews carry radios from different manufacturers — Motorola, Hytera, Kenwood, Yaesu and regional brands — programmed onto the same channel. Getting them to hear each other reliably is an RF and configuration problem before it is a software problem. No amount of app polish fixes a mismatched on-air profile.

• Default profiles and feature sets. Factories ship radios with a default profile, and what is enabled by default varies by model and firmware version.
• TDMA timing and slot parameters. Two-slot DMR splits each frame between two timeslots, and radios that disagree about timing, slot assignment or colour-code handling degrade each other.
• Talkgroup and radio-ID conventions. Who owns the talkgroup list, and whether radio IDs are preprogrammed or assigned dynamically, differ by brand.
• Firmware feature mismatches. Enhanced GPS reporting, remote stun and remote kill are not implemented identically across models, or at all.
• Voice coding support. Not every model supports the same speech codec set, and a codec mismatch is an immediately one-way conversation.

In practice these get resolved by technicians with a programming cable, per radio, per site — a support cost, not an engineering solution.

The gateway pattern

The bridge accepts DMR air-interface traffic, decodes it, republishes it as a session toward the PoC service, and reconciles identities across the two systems.

[DMR handset] --(RF)--> [DMR <-> PoC gateway] --(IP)--> [PoC service] --> [smartphone / desktop client]
                                        |
                                        +<-- identity & talkgroup mapping --<

The gateway is the only component that understands both worlds. Everything else in the chain is either a radio or an IP client.

Identity and authorisation

A radio has a DMR ID and a talkgroup. A user has an account, an identity and a set of permissions. Mapping one onto the other is the whole design problem, and it has to survive an audit. Three questions must be answerable explicitly:

1. Which account corresponds to this DMR ID?
2. Which talkgroups may that account use, and in which direction?
3. What is the audit trail when someone transmits?

If the mapping is implicit — inferred, or configured by whoever set up the gateway — it is not an authorisation model. Keep it as versioned, reviewable data.

Latency and graceful degradation

PoC over cellular depends on backhaul that a radio network does not need. If a handset sits on a congested cell, or a device is outside coverage entirely, push-to-talk will fail — and it will fail differently from a radio on the same channel.

That difference should be designed rather than discovered:

• Voice should fail loudly. A user pressing to talk and hearing silence needs immediate feedback. Silent retries are worse than an error.
• Telemetry should fail quietly. A sensor that cannot reach the network should buffer and retry, because the condition may clear in seconds.
• They should not share a fate. Coupling voice availability to a data stream's retry policy lets one bad link take out both.

Licensing and spectrum in Indonesia

This is often the part that decides the architecture before engineering does.

DMR requires a radio licence and coordination on the frequencies it uses. Spectrum is allocated, coordinated against other users, and tied to sites. PoC over cellular rides on an existing cellular contract, because someone else already holds the spectrum.

The asymmetry is real:

• Adding a PoC user is a commercial and provisioning task.
• Adding DMR capacity is a regulatory and engineering project with lead times.

A bridge that lets new user types join an existing radio group without new spectrum is often the cheapest win available. That is a large part of why it is worth building.

Honest limits

• Emergency calling. A push-to-talk app is not an emergency service and does not replace a certified emergency beacon or a dedicated emergency channel.
• Battery life on the phone. An app holding a session open, scanning or retrying in a weak-signal area drains a phone faster than a radio that is simply listening.
• It is not a certified marine or VHF-class device. A phone running an app is not certified to the standards a marine VHF transceiver is certified to, and the two should never be treated as equivalent in a regulated operational context.

None of this argues against the bridge. It argues for knowing which problems it solves and which it does not.