Figure 1 shows the configuration of a single TSBK. As you can
see, the first two octets are used for the LB, P and Opcode infor-
mation. The following 8 octets are used for the arguments or the
actual message information. The final two octets are used for the
TSBK CRC that is a validation check that the data was processed
correctly.
Figure 1: Single Block TSBK Format
Multi-Block Messaging Operation
Multiple Block Messaging consists of a number of Data Blocks to
provide more robust data information from the RFSS to the SU
and vice versa. Again, it is important to realize that a network con-
figured for explicit messaging can also use single block messages
as they relate to various overhead, or control messages, besides
the actual channel grant messages that control the
channel/frequency allocations to the radio.
The primary difference between single block messages and multi-
block messages is that the single block message formats contain
"complete" or whole messages, where the multi-block messages
disperse the information over one, two or three data blocks. Multi-
block messages include a header block that contains information
on how many data blocks are required for the message. The
header block dictates how many data blocks follow the header.
Figure 2 shows the configuration for Multi-Block messages.
Figure 2: Multi-Block Message Formats.
It is important to understand that there are different types of head-
er blocks depending on the information being sent. Data (non
voice) message transmission uses a confirmed header block
(requires an acknowledgement that the data has been received
correctly). Voice communication trunking messages use an
unconfirmed header block. For the purpose of this application
note we will focus on those used with the various trunked voice
modes, specifically the Group Voice Channel Grant Explicit
Channel Form, the Unit to Unit Voice Channel Grant - Extended
Format and the Telephone Interconnect Channel Grant - Explicit
Channel Form.
Figure 3 shows the Alternative Trunking Control Packet Header
Block format. This format is used with the above referenced
channel grant messages.
Figure 3: Alternative Trunking Control Packet Header Block
The header block indicates the type of message being sent via the
Opcode field (Alternative Trunking Control Packet Header Block).
This is important in the explicit messaging mode. When used with
the channel grant message, the opcode indicates that the
following data blocks dictate the TX and RX frequencies that are
associates with the Channel Grant message. For example, the
opcode for a Group Voice Channel Grant is %000000. The
opcode is the same for either a single block implicit or a
multi-block explicit message. Additional fields are identified as
follows:
BBiitt 77 ooff oocctteett 00::
indicates that the message has multiple blocks.
TThhee AANN bbiitt::TThhiiss bbiitt,, wwiicchh iiss
number 6 of octet 0, is set to 0 to
indicate that it is unconfirmed.
TThhee IIOO bbiitt::
is set to 1 for outbound or 0 for inbound messages.
FFoorrmmaatt::
is the type of header, either unconfirmed for Multiple
Block Trunking or Alternative Multiple Block Trunking format for
trunking control.
=%10101 - Unconfirmed multi-block trunking control
=%10111 - Alternate multi-block trunking control
TThhee SSAAPP iidde
ennttiiffiieerr::
indicates the service access point to where the
data is directed. 61 indicates a non-protected Trunking control,
while 63 indicates a protected trunking control message.
TThhee MMFFIIDD::
or the Manufacturer ID identifies the manufacturer ID
for non-standard control channel messaging. Throughout this
document, the Manufacturer's ID field is to assume the standard
Project 25 Manufacturer's ID of 00.
BBlloocckkss ttoo ffoollllooww::
are a simple indication of the number of blocks
after the header.
HHeeaaddeerr CCRRCC::
is a Cyclical Redundancy Check that verifies the
reassembled transmitted bits are coded properly. The user can-