PROTOCOL PARAMETER SELECTION (PPS)
The smart card specifies various data transmission parameters in the interface characters of the ATR, such as the transmission protocol and the character waiting time. If a terminal wants to modify one or more of these parameters, it must perform a protocol parameter selection (PPS) procedure in accordance with ISO/IEC 7816-3 before the transmission protocol is actually used. This allows the terminal to modify certain protocol parameters if this is permitted by the card. Prior to 1997, protocol parameter selection was called protocol type selection (PTS). PPS can be performed in two different modes. In the negotiable mode, the standard values of the divider F and the bit rate adjustment factor D remain unchanged until a PPS is successfully executed. If the card uses the specific mode, the values of F and D specified by the ATR must be used for transmitting the PPS. The card indicates which of these two modes it supports in the TA2 byte. The PPS request must be made immediately after theATR has been received by the terminal. If the card allows the requested changes to the protocol parameters, it sends the received PPS bytes back to the terminal. In principle, this is an echo of the received data. Otherwise, the card sends nothing, and the terminal must perform a new reset sequence to cause the card to exit this state. PPS may be performed only once, immediately after the ATR. Repeated transmission of the PPS is prohibited by ISO/IEC 7816-3. In practice, it is very rarely necessary to perform a PPS, since the transmission parameters of the smart cards being used are exactly matched to the requirements of the terminal. The data element following the PPSS is the format character (PPS0). It is also a required component of each PPS. It may optionally be followed by up to three bytes, which are called the parameter characters and are designated PPS1, PPS2 and PPS3. They encode various parameters for the transmission protocol to be used following the PPS. Data element PPS3 is reserved for future use, so it cannot yet be described here. The final byte of the PPS is called the control character (PCK). It contains the XOR checksum of all previous bytes, starting with PPSS. Unlike the other data elements, which are optional, PCK is a mandatory component of the PPS, as are PPSS and PPS0. If the card can interpret the PPS and modify the transmission protocol accordingly, it acknowledges this by sending the received PPS back to the terminal. If the PPS request contains items that the card cannot process, it simply waits until the terminal executes a reset. The main disadvantage of this procedure is that a large amount of time can be lost before the actual transmission protocol is used.

The PPS just described cannot be used for protocol switching with terminals that cannot execute a PPS but that nonetheless have their own special transmission protocols. This is precisely the situation with German card phones, for example. A special procedure has been devised to permit protocol switching despite this limitation. Since all terminals perform multiple reset sequences if they do not recognize the ATR, it was decided that the smart card should switch transmission protocols after every reset. This can best be illustrated by an example. After the first reset, the card sends theATR for T=14 and is then ready to communicate using the T=14 protocol. After the second reset, it sends an ATR for T = 1 and is then ready to communicate using the T = 1 protocol. After the third reset, it is again prepared to use the T = 14 protocol. This is not an ideal technical solution, since a device should always behave the same after every reset, but it is a fully practical solution for a heterogeneous terminal world. It is possible to mitigate this objection by having the smart card always respond with the same ATR after a power-on reset (cold reset). In this case, the card always executes a cold reset directly after it has been inserted in the card reader and the activation sequence has been completed. A reset that it triggered via the card’s reset line (warm reset), on the other hand, switches the transmission protocol. The card thus behaves the same after every ‘real’ reset, while any supplementary triggering of a reset causes it to switch to a different transmission protocol.

DATA TRANSMISSION PROTOCOLS
After the smart card has sent anATR, possibly followed by a PPS, itwaits for the first command from the terminal. The subsequent process always corresponds to the master–slave principle, with the terminal as master and the card as slave. In concrete terms, the terminal sends a command to the card, and the latter executes it and subsequently returns a response. This back-and-forth interplay of commands and responses never changes. There are variousways in which communication with a smart card can be established. There are also a number of different methods for resynchronizing communications if a disturbance occurs. The exact implementation of the commands, the corresponding responses and the procedures used in the event of transmission errors are defined in the form of transmission protocols. A total of 15 transmission protocols have been identified and defined in terms of their basic functions. These protocols, which are designated as ‘T =’ (for ‘transmission protocol’) plus a sequential number. Two of these protocols predominate in international use. The first is the T = 0 protocol, which became an international standard in 1989 (ISO/IEC 7816-3). The other is T = 1, which was introduced in 1992 in an amendment to an international standard (at the time ISO/IEC 7816-3 Amd. 1, now ISO/IEC 7816-3). The full-duplex transmission protocol T = 2, which is strongly based on T = 1, is currently in the definition stage and will be available as an international standard in a few years. In Germany, the widely distributed card-phone system uses yet a third protocol, designated T = 14. It is defined in an internal specification of Deutsche Telekom. The data elements transported by transmission protocols are called transmission protocol data units (TPDUs). They can be regarded as protocol-dependent containers that transport data to and from the card. The actual application data are embedded in these containers. In addition to the technically complex smart card transmission protocols, there is an additional set of very simple synchronous protocols for memory cards. They are typically used with telephone cards, health insurance cards and the like. However, they do not have error-correction mechanisms, and they are based on hard-wired logic in the chip.

Synchronous data transmission
Synchronous data transmission is not used with microcontroller-based smart cards, since they only communicate with the terminal asynchronously. However, it is the standard method for memory cards, which are used in very large numbers in applications such as prepaid electronic purses for card phones. This widespread use justifies a description of the operation of synchronous data transmission. In memory cards, synchronous data transmission is very closely linked to the chip’s hardware and is designed to be as simple as possible. There is no separation of layers in the transmission protocol, nor is logical addressing present, so the application in the terminal must directly access memory locations in the chip. The protocol allows the data stored in the chip to be physically addressed and then read or written. This means that the actual data transmission process is also tied to the functions of memory addressing and management. There is also no procedure for detecting or correcting errors during data transmission, although it must be said that such errors between the card and the terminal occur very rarely. If the terminal application nonetheless detects a transmission error, it must re-read the relevant area in the card’s memory. All these restrictions serve to allow data to be transmitted between the card and the terminal at a high rate using only a small amount of logic circuitry. Since synchronous data transmission is only used to keep data transmission as simple as possible (which means using a minimum amount of logic circuitry), an almost inevitable consequence is strong hardware dependence. As a result, synchronous transmission protocols are not uniform and sometimes vary greatly from chip to chip. Only the ATR is standardized. A terminal that has to communicate with various types of memory cards must incorporate several different types of synchronous data transmission protocols. The exact designation of the type of data transmission used for memory cards is ‘clocksynchronous serial data transmission’. This clearly indicates the basic conditions that apply to this type of communication. As with asynchronous communications, data are transmitted between the card and the terminal serially, or bit by bit. However, the bits are sent synchronous to a supplementary transmit clock signal. This makes the transmission of start and stop information unnecessary. In the case of a simple memory card, there is also no error detection information, which means that neither a parity bit nor a supplementary checksum is sent. The low probability of transmission errors is due to the very low clock rate, which ranges from 10 kHz to 100 kHz. Since one bit is sent for each clock cycle, a clock rate of 20 kHz yields a transmission rate of 20 kbit/s. However, the effective data rate is lower, since additional address information must also be sent in the case of memory cards. In order to describe synchronous data transmissions for memory cards in an understandable manner, we first need to describe some of the basic features of memory cards. In their simplest form, these cards have memories that are divided into two parts, consisting of an unchangeable ROM region and an EEPROM region that can be written and erased. Both regions are bitaddressable and can be freely read, and the EEPROM can also be written and erased. The master–slave relationship is even more pronounced in memory cards than in microcontroller smart cards. For example, the terminal completely takes over physical addressing of memory. The card itself can only globally block certain areas against erasing. This is controlled by hard-wired logic located ahead of the memory. This logic also manages the very simple data transmission process.