Previous | Table of Contents | Next |
The poor protocol layering of the T=0 protocol is not the product of poor design. Rather, it is the result of an attempt to make the protocol as responsive as possible in order for communication between the reader and the card to be as efficient as possible. The data transmission speed across the reader-to-card interface is relatively slow (nominally 9600 bits per second) and this channel is in the critical path of all transactions that involve the card. To maximize consumer satisfaction, it is desirable that such transactions proceed as quickly as possibleinstantaneously would be very nice. Consequently, in the T=0 protocol, the error handling and the application protocol support are optimized to minimize the amount of information which flows across the reader-to-card interface and thereby minimize the transaction time.
The T=0 protocol is a byte-oriented protocol. Like all other ISO-compliant smart card protocols, it functions in a command-response mode in which the reader-side of the connection issues a command to the card, which then performs the commanded operation and sends back a response.
Note:
Byte-oriented means that a byte is the unit of information transferred across a channel and that error handling is handled one byte at a time as well.
In the T=0 protocol, error detection is done by looking at the (even) parity bit on each byte transferred across the reader-to-card interface. The transfer of each byte of information requires the use of 10 bits, as illustrated in Figure 4.2. The parity bit is cleared or set to make the total number of bits set (per character transferred) be an even number. The receiver side of the channel can look at the bit values transferred prior to the parity bit and determine whether the parity bit should be set. If the actual parity bit transferred does not match what was expected, then it can be assumed that an error exists in the byte of data just transferred and some recovery procedure must be undertaken. The recovery procedure used with the T=0 protocol is triggered by the receiving side, which, on detecting a parity error, signals that it expects the transmitting side to retransmit the byte (that was received in error). It provides the signal to the transmitting side by holding the I/O line in a low state. Normally, the I/O line is in a high state immediately preceding the transfer of a byte, so a low state acts as an error feedback signal to the transmitter. On detecting this, the transmitting side of the channel waits for at least two character times and then again sends the byte that was previously received in error.
Figure 4.2. Reader/card byte transfer and error feedback loop.
Those well versed in communication protocols might see this error detection and recovery mechanism as being somewhat prone to less-than-perfect behavior. This indeed tends to be the case in actual practice. For most readers, however, the channel tends to be very good or very bad. If its very good, then this error detection and recovery mechanism is seldom used; if its very bad, then the error detection and recovery mechanism is likely to fail at some point. This leads to the transmitting and receiving sides of the channel getting out of synchronization. If this situation is detected by the card, it will usually be programmed to go mute and quit responding to commands from the reader. At this point, or if the reader detects the ambiguous state first, the reader issues a reset signal to the card that forces the communication protocol to be brought up from scratch.
The TPDU for the T=0 protocol comprises two distinct data structures: one that is sent from the reader to the card (as a command) and one that is sent from the card to the reader (as a response). The command header (sent from the reader to the card) includes five fields:
The procedure bytes, which are sent from the card to the reader, are used to respond to the readers command and include three required fields and one optional field:
Previous | Table of Contents | Next |