Share:
English
PoC Radio Server & Dispatch Platform Guide
Share:
Most PoC projects are scoped around the handheld: band support, battery, IP rating, price per unit. Then the pilot starts and the real questions arrive — who creates the talkgroups, where the call recordings live, how the control room sees GPS, and what happens to all of it if the vendor's cloud region is not where the regulator wants the data. Those are server questions, and they are usually decided after the hardware is already on order. Getting them right early is cheaper than migrating a fleet later.
A PoC platform is the software layer that turns a group of cellular handsets into a managed radio system. Stripped of marketing, it performs six jobs:
Identity and provisioning. Registers each device, binds it to a user and a talkgroup, and controls who can call whom.
Media routing. Receives a push-to-talk stream from one handset and distributes it to the group with as little delay as the network allows.
Presence and location. Tracks who is online and, where enabled, stores GPS breadcrumbs for later replay.
Recording and audit. Captures voice, timestamps and often multimedia for compliance or incident review.
Dispatch console. Gives a control room live map, talkgroup control, emergency alerts and call injection.
Integration surface. Exposes APIs and usually a gateway to legacy radio systems so PoC and DMR users can share a talkgroup.
If a platform cannot clearly answer all six, it is a consumer push-to-talk app with a business licence attached, not a dispatch system.
| Model | What you get | Best fit | Main risk |
|---|---|---|---|
| Vendor cloud | Subscription, vendor runs everything | Fast pilots, distributed teams, no IT staff | Data residency and long-term lock-in |
| On-premise | Software on your own server, you operate it | Data sovereignty, closed sites, integration-heavy estates | You own uptime, patching and backups |
| Hybrid | Media on-premise, management in cloud (or the reverse) | Regulated sites inside a multi-country fleet | Two systems to keep in sync |
| Private / mission-critical | Dedicated instance, often standards-based | Public safety, utilities, critical infrastructure | Cost and specialist integration effort |
The decision is rarely about technology preference. It is about three constraints: where the recordings are legally allowed to live, who is contractually responsible when the service stops, and whether your existing systems need to call into it. If the answer to the first is "inside our country" and the second is "us", on-premise or a regional dedicated instance is the only honest option. If the answer to both is "the vendor", cloud is cheaper and better staffed than anything you will build in-house.
Where is the media processed and stored? Ask for the region, the backup region and the deletion policy in writing.
What is the concurrency model? Price per user is meaningless if the platform caps simultaneous talkgroups or channels at peak.
Who owns the recordings? Confirm export format, retention control and whether you can leave with the archive intact.
Is there a documented API and SDK? If integration is on your roadmap at all, assume you will need it eventually.
Can it gateway to DMR or analogue? Most real fleets end up hybrid, and a platform with no radio gateway forces a second console.
Three numbers drive server sizing, and none of them is headcount:
Peak concurrent talkgroups. Thirty truck drivers on one channel at shift change is a very different load from thirty drivers on twelve channels.
Recording retention. Voice archives grow linearly and quietly. Decide retention per talkgroup before the first call, because retroactive policy changes are politically difficult.
Uplink and latency budget. Every remote site needs enough uplink for its simultaneous calls plus headroom. Ask the platform vendor for per-call bandwidth figures and size against your worst site, not your average.
Add redundancy only where an outage has a real operational cost. A security contractor can tolerate a short cloud failover; a control room supervising hazardous plant usually cannot, and that is where a dedicated or on-premise instance earns its price.
A regional utility ran a pilot on a vendor cloud with fifty handsets. Voice worked; the programme still stalled, because the compliance team required incident recordings to remain in-country and the dispatch console could not consume the location API the utility's own GIS expected. The second phase was re-scoped around a private instance in a local data centre with a documented API, plus a DMR gateway so two legacy channels stayed reachable. Nothing about the handhelds changed. Only the server decision did — and it was the decision that had been deferred the longest.
The lesson is consistent across sectors: scope the platform before the hardware. Device choice narrows to a handful of viable models once you know whether the system must be self-hosted, whether a gateway is mandatory, and what the API has to return.
Hosting model, region and backup region — in writing.
Concurrent talkgroup limit at peak, and the price step above it.
Recording retention options, export format and deletion guarantees.
API documentation you can read before signing, not after.
DMR or analogue gateway support and which models it works with.
Exit plan: how you migrate users and archives to another platform.
On the device side, Uphone builds 4G and 5G PoC handhelds — including the L181 and L283 for compact fleets, the N630 and N660 for 5G data, and the DMR-plus-LTE L503 and L2402 for hybrid deployments — that connect to third-party dispatch platforms rather than locking you to a single console. See the range at uphonemobile.com.