Trunked Radio

Trunking is a resource-allocation scheme for land mobile radio. A conventional repeater dedicates a channel to a user group even while that group is silent. A trunked system instead keeps a pool of radio resources and assigns one to a call only for the duration of that call. Users select a talkgroup, not a carrier frequency; infrastructure maps the logical group to a temporarily available traffic channel.

This distinction matters most for push-to-talk fleets whose calls are short and bursty. Pooling increases utilization, but it also creates shared control, queuing, and failure mechanisms that do not exist in a simple fixed-channel system.

The call-grant loop #

sequenceDiagram
    participant U as Calling radio
    participant C as Control channel
    participant S as Site/controller
    participant G as Affiliated group radios
    U->>C: Random-access call request (talkgroup, service)
    C->>S: Request and subscriber context
    S->>S: Check authorization, priority, and free resources
    S-->>C: Channel grant
    C-->>U: Tune to assigned traffic channel
    C-->>G: Group call grant / late-entry information
    U->>G: Voice or data on traffic channel
    S-->>C: Release after call end or hang time

A typical sequence is:

1. A radio registers at a site and affiliates with its selected talkgroup. The system therefore knows which sites currently need that group's calls.
2. When the user presses PTT, the radio requests service on an inbound control path.
3. The controller checks identity, permissions, call type, priority, and resource availability.
4. A grant tells the participating radios which physical traffic resource to use. A resource may be an FDMA channel or a TDMA timeslot; trunking itself does not prescribe either access method.
5. When the transmission ends, a short hang time may retain the resource for a quick reply. It is then returned to the common pool.

The outbound control channel must continuously advertise enough system identity, site, access, and grant information for idle radios to follow the system. Late entry lets a radio that arrives, powers on, or finishes another call join a group call already in progress.

Why pooling helps #

Suppose ten groups each need a channel only occasionally. Ten dedicated channels can still block one busy group while channels belonging to nine silent groups sit unused. A ten-channel trunked pool lets any authorized group use any free resource.

The design calculation is statistical, not just number of groups <= number of channels. If blocked calls are cleared rather than queued, Erlang B gives the blocking probability for offered load $A$ and $m$ identical traffic resources:

$$B(A,m)=\frac{A^m/m!}{\sum_{k=0}^{m}A^k/k!}.$$

For $A=5\ \text{Erlang}$ and $m=10$,

$$B(5,10)=0.01838 \approx 1.84\%.$$

This is a model, not a coverage promise. Real systems may queue requests, reserve resources for emergency traffic, carry mixed call durations, or lose capacity during failure. A control channel and guard/overhead capacity also do not become ordinary voice resources merely because they occupy spectrum.

Congestion and priority #

When no eligible traffic resource is free, the system can reject or queue the request. A useful congestion design specifies all of these explicitly:

• whether the caller hears a busy indication or remains queued;
• the queue order and maximum wait;
• which services may pre-empt an existing lower-priority call;
• whether emergency calls receive reserved capacity or only higher priority;
• how a group call spanning several sites consumes resources at each site;
• how long hang time keeps a channel unavailable to other users.

Priority and pre-emption are operational policy implemented through standardized signalling and system configuration. They do not create capacity: admitting one emergency call by pre-emption terminates or delays something else.

Sites, roaming, and simulcast #

A single-site system has one coverage area and one local channel pool. A wide-area system links sites through a core or switching network. Registration and affiliation allow it to route a talkgroup call only to sites where members are present, or to a configured wider set for operational reasons.

Roaming selects a usable site as the radio moves. The target system must reconcile signal quality with policy: a strong but unauthorized or overloaded site is not necessarily a valid choice. During a wide-area call, backhaul and controller state become part of the call path even though the user experiences a radio link.

In simulcast, multiple transmitters send the same information on the same frequency to enlarge coverage without multiplying frequencies. Overlap is demanding: differences in arrival time and channel response can produce self-interference. Transmitter timing, waveform compatibility, site geometry, receiver equalization, and delay-spread testing are therefore system concerns, not mere installation details.

Trunked mode is not direct mode #

Many professional systems also support radio-to-radio operation without the trunking infrastructure. ETSI calls this TETRA Direct Mode Operation (DMO); other ecosystems use terms such as direct, simplex, or talk-around. It is valuable outside network coverage or after infrastructure loss, but it changes the service:

• no central channel grant or wide-area routing;
• shorter radio-to-radio range and no repeater gain unless a gateway/repeater is available;
• reduced dispatcher visibility and different recording/location behavior;
• potentially different authentication, encryption, and keying assumptions.

Direct mode is therefore a separately designed operating mode, not a transparent fallback. Whether and when radios may enter it must be an explicit fleet policy.

Standards families and what conformance means #

Three common digital professional-mobile-radio families illustrate that the architecture and air interface are separate layers:

Interoperability is always scoped. Radios can share a basic group-voice profile yet differ in authentication, encryption suites, key management, data applications, location services, console interfaces, or inter-system roaming. NIST's P25 Compliance Assessment Program exists precisely because independent test evidence is more useful than assuming every nominally conforming combination works.

Security is more than voice encryption #

Several controls answer different questions:

• authentication: is this subscriber or system allowed to participate?
• authorization: may it use this talkgroup and service?
• confidentiality: can an observer recover user traffic?
• integrity and replay protection: can signalling or traffic be altered or reused?
• key management: how are keys loaded, rotated, revoked, and recovered after compromise?

Encrypting the traffic payload does not necessarily hide control-channel metadata such as system identity, activity timing, talkgroup addressing, or channel assignments. Nor does it protect a receiver that silently enters an unencrypted mode after a configuration error. A secure deployment makes mode indication, downgrade policy, lost-radio disablement, rekeying, and audit behavior explicit and tests them end to end.

Failure modes to rehearse #

The decisive diagnostic split is control plane versus traffic plane. Hearing noise-free traffic channels does not prove that radios can request or receive grants; seeing healthy registrations does not prove that an assigned voice path has usable RF quality.

A practical acceptance test #

A meaningful field test uses representative radios from every required vendor/profile and verifies more than a successful bench call:

1. registration, affiliation, and group call setup at every site class;
2. late entry, call hang time, queued call, busy indication, and emergency pre-emption;
3. roaming during idle, during a call, and after site/core isolation;
4. encrypted and unencrypted policy, wrong-key behavior, rekey, and lost-radio handling;
5. direct-mode operation as a distinct procedure;
6. reduced capacity, failed traffic resource, failed control channel, and restored-service registration load;
7. audio intelligibility and data success at coverage edges and simulcast overlap zones;
8. dispatcher, logging, recording, and time synchronization behavior.

The system is ready only when the operational behavior under congestion and partial failure is known. A clear idle-channel call demonstrates the waveform; it does not validate the trunking system.