Why some two-way radio networks can serve far more talkgroups than they have actual radio channels — and the real tradeoff hiding underneath that efficiency.
This is a companion question to simplex vs. half-duplex vs. full-duplex. That explainer asks how many directions a single channel can carry traffic in. This one asks a different question about the same scarce resource: when many separate talkgroups all need to share a limited set of radio channels, who gets to decide which group uses which channel, and when? Conventional and trunked systems answer that question in two fundamentally different ways, and the difference explains why a city with a few dozen radio channels can support a few hundred separate talkgroups without anyone ever seeming to run out of airtime — most of the time.
A conventional radio system assigns each talkgroup its own dedicated frequency channel, permanently. Police patrol gets channel 1, always. Public works gets channel 4, always. It doesn't matter whether that group is transmitting at this exact moment — the channel is theirs, reserved, and no other group is allowed to use it even while it sits silent. A trunked radio system instead keeps a smaller shared pool of actual radio channels and hands them out dynamically, on demand, through a computer-controlled trunking controller: whichever talkgroup needs to talk right now gets assigned whichever channel in the pool is currently free, for the duration of that transmission, and the channel goes straight back into the shared pool the instant they're done — ready for the next talkgroup that needs it.
Three talkgroups get a channel immediately; the other three wait in queue for one to free up — real, documented delay that shows up in trunked systems during large-scale incidents with many agencies or units transmitting heavily at the same time. A conventional system with a dedicated channel for every one of those 6 talkgroups would nothit this specific problem — each group already has its own channel regardless of what anyone else is doing. That protection against incident-time congestion is exactly what conventional radio trades away efficiency to get, and it's exactly what trunked radio trades away to get efficiency.
A trunked system can serve far more talkgroups than it has physical channels for exactly the same reason an airline can sell more seats across a fleet than it could if every passenger needed their own dedicated plane parked and waiting all day: most of those talkgroups, most of the time, aren't actively transmitting. Radio traffic is bursty — a talkgroup keys up for a few seconds, then goes silent for minutes. As long as the number of talkgroups trying to transmit at any given instant stays comfortably below the number of channels in the shared pool, the trunking controller can keep handing out channels fast enough that nobody notices the sharing at all. This holds up extremely well under normal, day-to-day operating conditions — which is why trunked systems are the standard choice for large public-safety and municipal radio networks. But it is a statistical assumption, not a guarantee, and assumptions like that have a specific failure mode: a situation where the assumption stops being true for everyone at once.
Not quite. Trunking's real advantage — serving far more talkgroups on far fewer actual channels — depends entirely on the statistical assumption that not every talkgroup needs to transmit at the same instant. Under normal conditions that assumption holds up well, and trunking delivers a genuine, well-documented efficiency win. But during a real major incident, where many talkgroups all need heavy traffic simultaneously, that assumption can break down: the shared channel pool can become congested, and some talkgroups experience real delay waiting for a channel to be assigned — a documented limitation of trunked systems under simultaneous mass demand. A conventional system with enough dedicated channels for every talkgroup doesn't have this specific failure mode, precisely because it never shares channels across groups in the first place — though it pays for that immunity with far less efficient spectrum use the other 99% of the time, when most of those dedicated channels sit idle. Trunking is a genuine tradeoff of normal-condition efficiency against incident-time congestion risk, not an unconditional upgrade.That's exactly why many public-safety agencies keep conventional mutual-aid and tactical channels available even after moving their primary traffic onto a trunked system.
Explains the fundamental difference between conventional two-way radio, where every talkgroup owns a permanently dedicated channel, and trunked radio, where a computer-controlled system dynamically allocates a smaller shared pool of channels across many talkgroups on demand — and the real congestion tradeoff that comes with trunking's efficiency gain during a major simultaneous-demand incident.
Because trunked systems are newer, more expensive, and used by most large public-safety and enterprise radio networks, it's easy to assume they're a strict upgrade over conventional radio in every way. That skips over what trunking actually trades: it turns a guaranteed, always-available channel per talkgroup into a statistically-shared resource. That trade pays off enormously under normal conditions, when only a fraction of talkgroups need to transmit at any moment — but it introduces a real possibility of channel-assignment delay when demand spikes across many talkgroups simultaneously, which a conventional system's dedicated-channel model simply doesn't experience in the same way.
In a conventional system, every talkgroup is programmed to a specific, fixed radio channel. Radios can often talk directly to each other, or through a simple repeater, with no central controller managing who uses what — the assignment is permanent and manual, decided once when the system is set up.
In a trunked system, radios and a trunking controller (often running over a dedicated control channel) constantly coordinate: when a user keys up, their radio requests a channel, the controller checks which channels in the shared voice-channel pool are currently free, assigns one, and signals every radio in that talkgroup to switch to it for the duration of the call. When the call ends, the channel returns to the pool immediately, available for the very next request from any talkgroup in the system.
This is the core design choice behind systems like P25 (Project 25) trunking and DMR Tier III, widely used by police, fire, EMS, transit, and public-works agencies, as well as large industrial and campus radio networks. A single trunked site might run only a handful of actual voice channels yet support dozens to hundreds of separate talkgroups, because it's statistically rare for more than a few of them to need airtime at the same instant. That same statistical dependence is why many agencies deliberately retain conventional mutual-aid, tactical, or simplex channels as a fallback — a channel that works even if the trunking controller itself is overloaded, down, or the shared pool is saturated during a major incident.
A talkgroup is a logical group of radio users who need to hear each other — a specific department, unit, or function (e.g., "Police Patrol," "Fire Dispatch"). In a conventional system a talkgroup maps to one fixed channel. In a trunked system a talkgroup is just a software-defined group that gets assigned whichever physical channel is free at the moment it needs to transmit.
Because conventional channels don't depend on any shared controller or channel pool being available. They work even if the trunking system's control infrastructure fails, is overloaded, or the voice-channel pool is fully congested during a major incident — which is exactly why conventional mutual-aid and tactical channels commonly remain in service as a fallback alongside a primary trunked system.
The next request is queued rather than granted immediately — the radio typically indicates a busy or wait condition until a channel frees up. Most trunked systems support call priority levels and emergency-call preemption, so a genuine emergency alert can bump a lower-priority call off a channel, but that only reduces the congestion risk during a mass-demand event; it doesn't eliminate it if enough high-priority talkgroups need channels simultaneously.
Yes, but it's a different failure mode: if too many individual users are crammed onto the one channel dedicated to their talkgroup, they can still collide or have to wait their turn for that single shared channel. What conventional radio avoids is cross-talkgroup congestion — one talkgroup can never be blocked by a completely different talkgroup's traffic, because they were never sharing a channel to begin with.
It varies by system size, but it's common for a single trunked site to operate with somewhere on the order of 5–20 actual voice channels (plus a dedicated control channel) while supporting anywhere from dozens to several hundred distinct talkgroups — the exact ratio depends on how much simultaneous traffic the system is engineered to handle before queuing becomes noticeable.
Try our Radio Communications Studio
More calculators, simulators, and guides for this discipline.