Field Guide · term

Also known as: MBC, Multi-Block Control, multi-block CSBK

A DMR Multi-Block Control (MBC) message carries a control payload too large to fit in a single CSBK.1 Where a CSBK is one 96-bit block, an MBC spreads its content across a header block followed by one or more continuation blocks, with the final block flagged as the last (LB=1). Each block is carried by the same BPTC(196,96) coding as a CSBK, so a receiver decodes and error-checks every block the same way, then reassembles the whole message once the terminator arrives.2

Headeropcode · FID Continuation ContinuationLB = 1 reassembled control payload each block BPTC-decoded and CRC-checked before assembly
An MBC begins with a header block and ends at the block whose last-block flag is set; the receiver concatenates the blocks, each independently BPTC-protected, into one message.

Assembly and lifecycle

The assembler keys each in-progress message on the burst’s colour code, so two messages interleaved on the same physical channel but different colour codes do not collide. A header block (slot-type DTMBCHeader) opens a fresh assembly and records the CSBK-style leader — the last-block and protect flags, the CSBKO opcode, and the feature-set ID — from its first two octets. Each continuation block (DTMBCContinuation) appends its raw content. When a block arrives with LB=1, the assembly is closed and dispatched; the opcode and reassembled payload identify the message.

Two guards keep a lost burst from wedging the decoder. A block limit (8) caps an assembly whose terminator never arrives, and an age limit (one second) evicts a stale partial assembly so a dropped LB=1 on one message cannot shadow the next header on the same colour code. A continuation that arrives with no open header — the receiver joined mid-message or lost the header burst — has nothing to attach to and is discarded. This mirrors the general trunking posture: never act on a half-assembled control message.

What GopherTrunk parses

The header block’s octets 2–9 reuse the validated 8-octet CSBK grant layout, so the channel-grant opcodes (private and talkgroup voice grants, and the data grants) are structurally parsed straight out of an MBC header and published exactly as their single-block CSBK counterparts would be — a voice grant retunes and follows, a data grant is only recorded for the band-plan learner. Every other opcode is assembled and surfaced at debug level but not force-parsed. This is deliberate honesty: there is no real off-air MBC capture pinning the multi-block payload layouts or the last-block CRC convention, and the CSBK CRC history in this codebase is a standing warning that an unverified convention can silently reject every genuine frame. Rather than guess a layout and emit garbage, the assembler leans on each block’s BPTC FEC for protection and logs the unrecognised message “pending capture validation” — the same cautious stance the Connect Plus and Hytera vendor CSBKs get.

Relevance to SDR

internal/radio/dmr/tier3/mbc.go implements the assembler: ParseMBCBlock reads one decoded 12-byte block, handleMBC routes header and continuation bursts and enforces the block and age limits, and dispatchMBC concatenates the blocks and dispatches the grant opcodes through the shared ParseTVGrant / ParsePVGrant / ParseDataGrant parsers. Because each block passes through the same decodeInfoBlock BPTC path as a CSBK, a burst too corrupted to correct is rejected before it ever reaches the assembler, so an MBC is only ever built from blocks that already cleared their per-block FEC. The result is a decoder that can follow the large control messages standard Tier III occasionally needs without pretending to understand payload layouts it has not yet been able to validate against real signals.

Sources

  1. Digital mobile radio — Wikipedia, on DMR control signalling and Tier III trunking. ↩

  2. ETSI TS 102 361-1 — ETSI, §9 defining the multi-block control structure carried over the DMR air interface. ↩

See also