What GBT Means
Large messages are split, sent, checked, and reassembled
General Block Transfer, or GBT, is the GBCS mechanism for carrying a Remote Party Message when the message is too large to fit into one normal protocol data unit. Instead of changing the business message, GBT wraps it in a series of smaller blocks.
The sender applies the normal cryptographic protection first, then cuts the protected message into block data. Each block carries routing details and a GBT header so the receiver can tell which series it belongs to, whether it is command or response traffic, and which block number it is.
For a command, the ACB or HHT starts the GBT series and the target device receives it. For a response, the device starts the series back to the ACB or HHT. The receiver waits until it has the final block and all earlier blocks before processing the original message. If blocks are missing, it can ask for those blocks to be resent.
A row marked Always GBT means this SRV/use-case/device/direction is expected to use GBT. A row marked Not always GBT means GBT can apply for that scoped case, but only when the actual message size or content requires it.
Message stream
A GBT Message Series is the full stream of GBT messages needed to carry one complete Remote Party Message. The initiator is the ACB or HHT for a command to a device; for a response or alert, the device starts the stream back to the ACB or HHT. The routing header ties every block in that stream back to the same original message, using the business originator, business target, message code, and originator counter.
Blocks
The original message is fully built and cryptographically protected first. Only then is it split into block data. Each block carries up to 1,149 octets of the protected message, starts at block number 1, and increments by one until the final block. The final block is marked with a last-block flag. The receiver does not process the original command or response until it has the final block and every earlier block number.
Flow control
GBT uses a streaming window so the sender can send several blocks before it needs a reply. For commands the normal window is 6 GBT messages. For responses the normal window is 63. If a response needs more than 63 blocks, the receiver acknowledges each complete set of 63 sequential blocks before the device sends the next set.
Retries
If the receiver reaches the final block but one or more earlier block numbers are missing, it sends a Request Block Resend for the missing block numbers. Recovery can happen before the end of a streaming window, so the receiver does not have to wait until the whole stream has failed. Resend and acknowledgement messages carry the routing and GBT headers but no block data.
Timeouts and malformed blocks
A device sending a GBT stream must be able to resend blocks for a period after it first sends the stream, until either the stream is acknowledged as complete or 24 hours has elapsed. A device receiving a stream may discard it if resend recovery does not succeed within the allowed time. Devices also discard malformed GBT messages, such as a block numbered zero or an acknowledgement for a block number the recipient has never sent.
Summary source: SEC Schedule 8 GBCS v4.4 section 7.2.11 and its subsections.