Send/receive sequence counter
Each information block in the T = 1 protocol has a send sequence number consisting of only one bit located in the PCB byte. This number is incremented modulo 2, which means that it alternates between 0 and 1. The send sequence counter is also designated N(S). Its starting value at protocol initiation is 0. The counters in the terminal and the smart card are incremented independently of each other. The primary purpose of the send sequence counter is to support requests for resending blocks received with errors, since individual data blocks can be unambiguously addressed via N(S).

Waiting times
Several waiting times are defined to provide transmitters and receivers with precisely specified minimum and maximum intervals for various actions during data transmission. They also provide defined ways to terminate communications in order to prevent deadlocks in case of errors. Default values are defined for all of these waiting times in the standard, but these may be modified to maximize the transmission rate. The modified values are indicated in the specific interface characters of the ATR.

Character waiting time (CWT)
The character waiting time is defined as the maximum interval between the leading edges of two consecutive characters within a block. The recipient starts a countdown timer on each leading edge, using the character waiting time as the initial value. If the timer expires and no leading edge for a new bit has been detected, the recipient assumes that the transmission block has been received in full. The ‘CWT reception criterion’ can thus be generally used for end-of-block detection. However, this considerably reduces the data transmission rate, since the time for each block is increased by the duration of the CWT. It is thus better to detect the end of the block by counting received bytes. With a clock frequency of 3.5712 MHz and a divider value of 372, this yields an interval of 0.85 seconds. This interval, which is specified in the standard as the default setting, is too long for fast data communications. In practice, the usual value of CWI is between 3 and 5. This means that for a normal transmission sequence, in which the characters follow each other without any time delay, the receiver waits for an interval of one to two bytes before detecting the end of the block or interruption of communications. Normally, the reception routine detects the end of a block from the block length information in the LEN field. However, if the content of this field is erroneous, the character waiting time can be used as an additional means to terminating reception. This problem only manifests itself when the length information is too long, since in this case the receiver would wait for additional characters that never arrive. This would block the transmission protocol, and this situation could only be cleared by a card reset. The character waiting time mechanism gets around this problem.

Block waiting time (BWT)
The purpose of the block waiting time is to allow communications to be terminated in a defined manner if the smart card does not respond. The block waiting time is the maximum allowed interval between the leading edge of the last byte of a block sent to the card and the leading edge of the first byte returned by the card. In terms of a conventional T = 1 block, this is the allowed maximum interval between the leading edge of the XOR byte in the epilogue field of the command block and the leading edge of the NAD byte in the response from the card. If this waiting period expires without a response being received from the card, the terminal may assume that the card is faulty and initiate an appropriate response. This could for example be a card reset, followed by a new attempt to establish communication. The BWT is specified in abbreviated form in the interface characters of the ATR by the BWI parameter. As can be seen, this value is quite generous. In practice, a value of 3 is often used for BWI, which yields a blockwaiting time of 0.8 s. Typical command processing times in the card are usually around 0.2 s. A BWT of the above duration thus represents a compromise between normal command processing times and quick detection of a smart card that is no longer responding to commands.

Block guard time (BGT)
The block guard time is defined as the minimum interval between the leading edge of the final byte and the leading edge of the first byte in the opposite direction. It is the opposite of the BWT, which is defined as the maximum time between the two specified leading edges. Another difference is that the block guard time is obligatory for both parties and must be observed, while the block waiting time is only significant for the smart card. The purpose of the block guard time is to provide the sender with a minimum time interval in which to switch over from transmitting to receiving. The block guard time has a standard fixed value of 22 etu. In a smart card running at 3.5712 MHz with a divider value of 372, this yields an interval of approximately 2.3 ms.

Transmission protocol mechanisms
Waiting time extension
If the smart card needs more time to generate a response than the maximum time allowed by the block waiting time (BWT), it can request a waiting time extension from the terminal. It does so by sending a special S block requesting an extension, and it receives a corresponding S block from the terminal in acknowledgement. The terminal is not allowed to refuse this request. A byte in the information field informs the terminal of the length of the extension. This byte, multiplied by the block waiting time, gives a new block waiting time. This extension is only valid for the most recently sent I block.

Block chaining
One of the essential performance features of the T = 1 protocol is the block chaining function. This allows either party to send data blocks that are larger than the size of its transmit or receive buffer. This is particularly useful in light of the limited memory capacities of smart cards. Chaining is permitted only for information blocks, since only such blocks can contain large amounts of data. In the chaining process, the application data are partitioned into individual blocks that are sent to the recipient one after the other. The application layer data must be partitioned such that none of the resulting segments is larger than the maximum block size of the recipient. The first segment is then placed in an information field in accordance with the T = 1 protocol, supplied with prologue and epilogue fields and sent to the recipient. The M bit (‘more data’ bit) is set in the block’s PCB field to indicate to the recipient that the block chaining function is being used and that chained data are located in the following blocks. As soon as the recipient has successfully received this information block with the first segment of the user data, it indicates that it is ready to receive the next chained I block by returning an R block whose sequence number N(R) is the same as the send sequence count N(S) of the next I block. The next block is then sent to the recipient. This reciprocal exchange of I and R blocks continues until the sender issues an I block with an M bit in the PCB field indicating that it is the last block in the chain (M bit = 0). After this block has been received, the recipient has all the application layer data and can process the full data block. There is a restriction with regard to the block chaining mechanism. Within a single command–response cycle, chaining may proceed in one direction only. For example, if the terminal is sending chained blocks, the card may not send chained blocks in response. There is another restriction that has nothing to do with the mechanism itself, but rather with the very limited amount of memory in smart cards. Implementing the block chaining mechanism involves extra overhead, and its usefulness is very limited, since commands and responses are not especially long and thus do not normally require chaining. If the card’s receive buffer in RAM is not large enough to store all of the data passed using block chaining, it must be moved to the EEPROM. This leads to a sharp reduction in the transmission rate, since the EEPROM (in contrast to the RAM) cannot be written at the full speed of the processor. Consequently, many T = 1 implementations have no block chaining function, as the cost/benefit ratio often does not justify it. This is a typical example of the fact that standards are often interpreted very liberally in actual practice. In this case, the interpretation amounts to considering block chaining to be a supplementary option in T = 1 that is not absolutely necessary. This can lead to significant compatibility problems in practice.

Error handling
The T = 1 protocol has elaborate error detection and handling mechanisms. If an invalid block is received, the protocol attempts to restore error-free communications by means of precisely defined procedures. Seen from the terminal’s perspective, there are three synchronization stages. In the first stage, the sender of a faulty block receives an R block indicating an EDC/parity bit error or a general error. The recipient of this R block (the original sender) must then retransmit the last block that it sent. If it proves impossible to restore an error-free connection using this mechanism, the next stage is invoked. This means that the smart card receives a resynchronization request from the terminal in an S block. The terminal expects a resync response in reply. The terminal and card then both reset their send and receive counters to zero, which corresponds to the protocol state immediately following the ATR. Starting from this situation, the terminal attempts to restore communications. The first two stages affect only the protocol layer. They have no effect on the actual application. However, the third synchronization stage does affect all layers in the smart card. If the terminal cannot establish an error-free connection using the first two synchronization stages, it triggers a smart card reset via the reset lead. This unfortunately means that all the data and states of the current session are lost. Following the reset, communications must be completely re-established from the bottom up. If even this procedure fails to produce a working connection after three attempts, the terminal deactivates the card. The user then usually receives an error message to the effect that the card is defective.