Data transmission protocol (ISO/IEC 14 433-4)
A half-duplex block transmission protocol that is tailored to the specific requirements of a contactless system is defined in Part 4 of ISO/IEC 14 433-4. This protocol is largely based on the T = 1 protocol defined in the ISO/IEC 7816-3 standard, which is widely used throughout the world. This simplifies the implementation of dual-interface cards, since they anyhow must support a contact-type transmission protocol. For Type-A cards, the standard defines an activation sequence that must be executed before starting the actual protocol. During this sequence, parameters for the subsequent data transmission are specified and exchanged between the terminal and the card. These parameters relate to things such as the bit rate in each direction and the required waiting times between frames. Type-B cards do not need any special activation sequence. They can immediately initiate the actual data transmission protocol after being selected. With such cards, the necessary parameters for data transmission are specified and exchanged during the initialization and selection processes, as described in the previous section.

Mifare DESFire EV1 8K Pre-printed Cards,Mifare DESFire EV1 8K Proximity Cards,Mifare DESFire EV1 8K Contactless Smart Cards

Figure 3.121 Example of an anticollision sequence with three Type-B cards (Part 1 of 2)

 

Protocol activation for Type-A cards
After a Type-A PICC has been successfully selected, as previously described, the terminal executes an activation sequence as illustrated by the flow chart shown in Figure 3.122.
From the SAK (Select Acknowledge) transmitted by the card at the end of the anticollision loop, the terminal can recognize whether the card supports the standard data transmission
protocol. If it does not, the terminal issues a HLTA command to place the card in the Halt state. If the protocol defined in ISO/IEC 14 433-4 is supported, the terminal sends a RATS (request for answer to select) command to the card. The RATS command and the ATS (answer to reset) returned by the card are used to exchange data and parameters in order to determine the data transmission options supported by the card and the terminal. Following this, the values of the modifiable parameters can be selected using PPS (protocol and parameter selection) to make optimum use of the capabilities of the card and the terminal. In order to make inexpensive, technically simple implementations possible, default values are defined for the modifiable parameters. In the simplest case, the card supports only these default values. In this case, the PPS sequence is unnecessary, and the terminal can immediately start exchanging data using the block protocol after receiving the ATS.

Mifare DESFire EV1 8K Smart Card,Mifare DESFire EV1 8K Proximity Cards,Mifare DESFire EV1 8K ISO Printing cards,HF 13.56MHz DESFire 8K Proximity Cards

 

Figure 3.122 Activation of a Type-A card by a terminal

Request for answer to select (RATS)
The RATS command contains a parameter byte specifying the maximum frame size that the terminal can receive (‘frame size for proximity coupling card’, or FSDI) and the card identifier (CID) assigned to the card for the duration of its active state. Starting with the reception of the RATS command, the card uses this CID as its logical identifier.

Mifare DESFire D81 ISO Card,Mifare DESFire EV1 8K Contactless Cards ,Mifare DESFire 8K Printing Card ,Mifare DESFire 8K Offset Printing Card

Figure 3.123 Format of the RATS (Request for Answer to Select) command

Mifare DESFire 8K Card,NXP MF3ICD81 Cards,Mifare DESFire EV1 8K Contactless Cards,Mifare DESFire EV1 8K Blank White Cards,

Figure 3.124 Format of the Parameter byte of the RATS command. The CID defines the logical number of the addressed card and has a range of 0 through 14; 15 is reserved for future use. FSDI codes the maximum frame size (FSD) that the terminal can receive

Table 3.28 Coding of bits b8–b5 of the Parameter byte of the RATS command

Mifare DESFire EV1 8K Card,NXP MF3ICD81 Cards,Mifare DESFire 8K ISO14443A Cards,Mifare DESFire EV1 8K Offset Printing Cards,

Answer to Select (ATS)
A Type-A card responds to a RATS command with an Answer to Select (ATS). The ATS
identifies the set of parameters supported by the card. These parameters may include:
–the maximum frame size
–the bit rates in both directions supported by the card
–the waiting time between frames
–the specific frame guard time
–support for NAD and CID.
Default values are specified for cards that do not offer any selection of parameters. In the
simplest case, which is when only the default values are supported, the ATS consists of only
the length byte and the CRC bytes.

Mifare DESFire EV1 8K Smart Card,Mifare DESFire EV1 8K Plain White Cards,Mifare DESFire EV1 8K Printed Cards

Figure 3.125 Format of ATS

Table 3.29 The data elements of the ATS and their designations according to ISO/IEC 14 433-4

Mifare DESFire 8K Card,NXP MF3ICD81 Cards,Mifare DESFire EV1 8K Contactless Cards,Mifare DESFire EV1 8K Blank White Cards,

Length byte The length byte (TL) indicates the number of bytes transmitted in the ATS, including the TL byte but excluding the two CRC bytes. The length of the ATS is not allowed to exceed the maximum frame length (FSD) given in the RATS command. This means that the maximum value of TL is not allowed to be greater than FSD – 2.
Format byte: If the length given in TL is greater than 1, the format byte (T0) is sent next. T0 consists of three parts, as follows:
–The most significant bit (b8) has a value of 0. The value 1 is reserved for future use.
–Bits b7–b5 indicate the presence of subsequent interface bytes TC1, TC2 and TC3.
–The lower nibble (b4–b1) is called the ‘frame size for proximity card integer’ (FSCI). It codes the value of ‘frame size for proximity card’ (FSC), which is the maximum frame size that can be received by the card. The default value for FSCI is 2, which corresponds to a maximum frame size of 32 bytes.

Mifare DESFire D81 ISO Card,Mifare DESFire EV1 8K Contactless Cards ,Mifare DESFire 8K Printing Card ,Mifare DESFire 8K Offset Printing Card

TA1 interface byte The TA1 interface byte consists of four parts, as follows:
–The most significant bit (b8) indicates whether different divider values can be used for the two transmission directions. The value of the etu (elementary time unit, equal to the duration of one bit) is determined by the divider D according to the formula 1 etu = 128 ÷ (D × fC). The initial value of D is 1, which yields an etu value of 128/ fC.
–Bits b7–b5, which are called ‘divisor send’ (DS), specify the bit rates supported by the card for data transmission from the card to the terminal.
–Bit b4 is set to 0. The value 1 is RFU.
–Bits b3–b1, which are called ‘divisor receive’ (DR), specify the bit rates supported by the card for data transmission from the terminal to the card. The divider values are selected by the terminal in the subsequent PPS command.

Table 3.32 Coding of the TA1 interface byte

Mifare DESFire 8K Card,NXP MF3ICD81 Cards,Mifare DESFire EV1 8K Contactless Cards,Mifare DESFire EV1 8K Blank White Cards

TB1 interface byte The TB1 interface byte is used to transfer parameters that define the frame waiting time and the start-up frame guard time. Consequently, the TB1 interface byte consists of two parts, as follows:
–The upper nibble (b8–b5) is called the ‘frame waiting time integer’ (FWI) and determines the frame waiting time (FWT). The meaning and calculation of the frame waiting time are described in the next section.
–The lower nibble (b4–b1) is called the ‘start-up frame guard time integer’ (SFGI) and is used to calculate the start-up frame guard time (SFGT). The SFGT is the time needed by the card after transmission of the ATS before it is ready to receive the next frame. The value 15 is RFU. The value 0 means that the card does not need any particular SFGT. With a value ranging from 1 through 14, the SFGT is calculated using the formula:
SFGT = (256 × 16/ fC) × 2SFGI
The default value of SFGI is 0, and itsmaximumvalue (SFGTMAX) is approximately 4949 ms.

Mifare DESFire D81 ISO Card,Mifare DESFire EV1 8K Contactless Cards ,Mifare DESFire 8K Printing Card ,Mifare DESFire 8K Offset Printing Card

Figure 3.126 Format of the TB1 interface byte

TC1 interface byte The TC1 interface byte indicates special protocol options. It consists of
the following parts:
–The six most significant bits (b8–b3) are set to’0′. All other values are RFU.
–Bits b2 and b1 indicate which optional fields in the prologe field are supported by the card (see the next section). The terminal is not obliged to actually transmit all fields that are supported, so it may omit one or more fields. However, fields that are not supported by the card may not be transmitted by the terminal to the card under any circumstances. The default value for bit b2 is 1, and the default value for b1 is 0. These values mean that CID is supported and NAD is not supported.

Table 3.33 Coding of the TC1 interface byte

Mifare DESFire 8K Card,NXP MF3ICD81 Cards,Mifare DESFire EV1 8K Contactless Cards,Mifare DESFire EV1 8K Blank White Cards

Historical bytes The historical bytes (T1 through Tk) are optional. Their contents are defined in ISO/IEC 7816-4 (see also Section 6.2, ‘Answer to Reset (ATR)’). The maximum possible number of historical bytes can be determined from the maximum length of the ATS.

Protocol and parameter selection
If the card indicates in the ATS that it supports modifiable parameters, the terminal can change the parameters for the subsequent protocol by using the PPS (protocol and parameter selection) command. If the card does not support any modifiable parameters, it is not required to support the PPS command (see Figure 3.122). In this case, the protocol will continue with unaltered parameters. If we assume that the card has indicated in the ATS that it supports modifiable parameters, the terminal can now evaluate whether it wants to utilize the modification options indicated by the card. If so, it transmits a PPS Request command having the structure shown in Figure 3.127.

Mifare DESFire EV1 8K Smart Card,Mifare DESFire EV1 8K Proximity Cards,Mifare DESFire EV1 8K ISO Printing cards,HF 13.56MHz DESFire 8K Proximity Cards,

Figure 3.127 Format of the PPS Request (protocol and parameter selection request) command

Start byte: The start byte (PPSS) consists of two parts:
–The upper nibble (b8–b5) is set to’D'to identify the PPS. All other values are RFU.
–The lower nibble (b4–b1), which is called the ‘card identifier’ (CID), defines the logical number of the addressed card.
Parameter 1 Parameter 1 indicates which of the possible values of DS and DR in the TA1 interface byte have been selected. This determines the transmission rates for subsequent data transmissions.

DESFire 8K Cards,Mifare DESFire EV1 8K ISO Printing Cards,Mifare DESFire EV1 8K Contactless Cards,NXP Mifare DESFire D81 ISO Card

Protocol and parameter selection response
The card confirms correct reception of the protocol and parameter selection request by means of a protocol and parameter selection response, which consists of only the PPSS start byte and the two checksum bytes (CRC 1 and CRC 2). After this, the terminal and the card use only the selected parameters for data transmission.

Activation frame waiting time
In order to avoid unnecessarily long waiting times in case of transmissions errors, ISO/IEC 14 433-4 specifies the maximum time between when a Type-A card receives the end of a frame and when it sends a response. This time is called the ‘activation frame waiting time’, and it is set to 65,536/ fC (≈4833 μs). If a card does not respond within this interval, the terminal knows that communications with the card are impaired.

Error detection and correction
In a system using contactless cards, it must be expected that errors will occur more often during data transmission than is usual with contact-type cards. For example, with contact-type cards it is relatively uncommon for a card to be removed from a terminal while it is communicating with the terminal. With contactless cards, interruptions to communications can occur more often, since the cards are free to move within the working range of the terminal during use and can unintentionally leave the working range. It is thus important to have methods available that allow such interruptions to be recognized as quickly as possible and allow communications to be resumed in a state that is as well defined as possible. In order to avoid having every type of error completely interrupt communications and force re-initiation of the entire process, ISO/IEC 14 433-4 defines rules for error detection and correction during the protocol activation phase for Type-A cards. Rather than describe these rules in detail, we refer you to the appropriate section of the standard, where they are presented in an illustrative manner.

Half-duplex protocol in accordance with ISO/IEC 14 433-4
The transmission protocol defined in Part 4 of ISO/IEC 14 433-4 takes into account the special requirements imposed by the use of contactless cards. For instance, it allows a terminal to communicate with several cards in parallel. Like the T=1 protocol for contact-type cards, this protocol supports a clean separation of layers in accordance with the OSI reference model. Separation of layers means that data belonging to a higher level layer are transmitted completely transparently with respect to lower lever layers. This protocol is based on the frames defined for both types of cards (Type A and Type B) in Part 3 of the standard. Four layers are distinguished:
–the physical layer (byte transmission in accordance with 14 433-3)
–the data link layer (for exchanging data blocks in accordance with 14 433-3)
–the session layer (coupled to the data link layer in order to minimize overhead)
–the application layer (where the commands are processed).

This block-oriented protocol starts after the activation sequence has been completed. The terminal is entitled to make the first transmission. This means that after the activation sequence, the card must wait until it receives a block from the terminal. The card responds to each block that it receives by transmitting a response block within a defined frame waiting time. After the response block has been sent, the terminal again holds transmit authorization and the card switches back to reception mode. Communications continue in this manner, with transmit authorization alternately held by the terminal and the card. The protocol allows several cards to be concurrently activated by a terminal. It can switch back and forth among several cards without having to spend time deactivating a card and activating another card each time it switches cards. As already mentioned, the probability of errors in data transmissions is higher in systems using contactless cards than in comparable systems using contact-type cards. It is thus especially important for communications between the terminal and the card to take place in the shortest possible time. The data transmission rate, which has a default value of 106 kbit/s, is elatively high compared with the default value of 9.6 kbit/s for the T=0 and T=1 transmission protocols.

Block structure
Each transmission block consists of a leading prolog field, an optional information field and a trailing epilog field. The information field contains data for the application layer.
There are three different types of blocks:
–Information blocks, which are used for the transparent exchange of data belonging to the application layer.
–Reception confirmation blocks (R blocks), which do not contain information fields and serve to indicate positive or negative confirmation of reception.
–System blocks (S blocks), which are used to exchange control data for the protocol. Two types of S blocks are defined: WTX, which is an S block for extending the frame waiting
time and has a single-byte information field, and DESELECT, which is an S block with no information field that is used to place the card in the Halt state.

Mifare DESFire EV1 8K Offset Printing Cards,Mifare DESFire EV1 8K Contactless Cards,Clamshell MIFARE DESFire EV1 8K Card,

Figure 3.128 Block structure

Prologue field The prologue field consists of the protocol control byte (PCB), an optional card identifier (CID) and an optional node address (NAD). The coding of the protocol control byte is shown in Table 3.36.

Prologue field The prologue field consists of the protocol control byte (PCB), an optional card identifier (CID) and an optional node address (NAD). The coding of the protocol control byte is shown in Table 3.36.
Table 3.36 Coding of a the protocol control byte (PCB)

Mifare DESFire EV1 8K Printed Cards,Mifare DESFire 8K Printing Card,RFID Mifare DESFire EV1 8K Printing Cards

Card identifier (CID) The card identifier field is used to identify a particular card, and it also contains information about the power supplied to the card. The most significant two bits (b8 and b7) indicate the power level provided to the card by the terminal. Bits b6 and b5 are set to 0, with 1 being reserved for future use. Bits b4–b1 code the card identifier.

Mifare DESFire 8K Offset Printing Card,Mifare DESFire EV1 8K Printing Cards,HF 13.56MHz DESFire 8K Proximity Cards,

Figure 3.129 Format of the card identifier field

The coding of CID is defined in the PPS command for Type-A cards and in the ATTRIB command for Type-B cards. The following rules apply to evaluating the CID field:
–A card that does not support CID ignores all blocks containing a CID.
–A card that supports CID responds to blocks containing its CID by sending back its CID. It ignores blocks that contain other CIDs, and it responds to any block containing a CID of 0 by returning a block with no CID.

These rules allow the terminal to communicate concurrently with several active cards without having to deactivate cards that are not being addressed.
Table 3.37 Coding of the power level indication

Mifare DESFire 8K Pre-printed Cards,NXP Mifare DESFire EV1 8K Smart Card,ISO MIFARE DESFire EV1 8K Card

Node address (NAD): The third byte of the prologue field is called the ‘node address’. The node address is used to establish and address certain types of logical connections between the card and the terminal. Node addresses are used in the same manner as for contact-type cards. They are defined in ISO/IEC 7816-3 and described in Chapter 6.
Information field (INF): In I blocks, the information field acts as a container for data for the application layer. The content of this field is transferred fully transparently. In S blocks, the information field is used to control extending the frame waiting time.

Frame waiting time (FWT)
In order to achieve a defined termination of communications with a non-responding card in the shortest possible time, a ‘frame waiting time’ (FWT) is defined. It corresponds to the block waiting time of the T = 1 protocol for contact-type cards. The frame waiting time is the maximum interval between the end of a frame transmitted by the terminal and the start of the response frame from the card. If this interval expires without a response from the card, the terminal assumes that there is a malfunction in the card and reacquires transmit authorization in order to initiate error-detection mechanisms. As previously described, the ATS for Type-A cards contains the value of the frame waiting time integer (FWI) in the TB1 interface byte. The frame waiting time can be calculated from the FWI using the following formula:
FWT = (256 × 16 ÷ fC) × 2FWI
For Type-B cards, the FWI is defined in theATQB (Answer to Request, Type B). The minimum value of FWT, which is obtained when the value of FWI is 0, is approximately 302 μs. The
maximum value of FWT (FWTMAX), which is obtained when the value of FWI is 14, is approximately 4949 ms. The normal command processing time of the card must be taken into
account when selecting the frame waiting time. If the value of the frame waiting time is set too large, it will take longer for the terminal to detect that a card is not responding. In practice, cards can respond relatively quickly to most commands, but a few commands, such as commands involving the computation of a cryptographic algorithm, require significantly more time to execute. In order to avoid having to use a long frame waiting time for all commands just to accommodate such cases, there is a mechanism for extending the waiting time. This allows the card to request an extension of the frame waiting time for an individual command.

Extending the frame waiting time
To request an extension of the FWT, the card transmits a special S block called ‘S(STX) request’. It receives a corresponding ‘S(WTX) response’ from the terminal to confirm the request. The terminal is not allowed to deny such a request. The length of the extension to the frame waiting time is sent to the terminal using one byte in the information field of the S(WTX) S block. The new, temporary frame waiting time for processing the current command is obtained by multiplying this value by the framewaiting time.

Mifare DESFire 8K Printing Card,Mifare DESFire EV1 8K Printing Cards,Mifare DESFire EV1 8K Clamshell Proximity Card,

The temporary frame waiting time (FWTTEMP) is measured starting with the end of the S(WTX) response sent by the terminal. It is calculated using the following formula:
FWTTEMP = FWT × WTXM
If the formula yields a result greater than FWTMAX (≈4949 ms), the value of FWTMAX must be used instead of the calculated value of FWTTEMP.

Block chaining
The chaining function allows either one of the communicating parties to transmit data blocks that are too big to fit within a single frame by partitioning the data into several I frames sent in succession. Each of these chained I blocks has a length that is less than or equal to the frame length specified by FSC or FSD, as appropriate. When block chaining is used, the sender sets the chaining bit in the protocol control byte (PCD) of the first block of the chain. This indicates to the recipient that the block chaining function is being used and that the subsequent block contains chained data. If the recipient receives the first block of the chain correctly, it indicates correct reception and its readiness to receive the next block by returning an R block with the same block number as the block it just received. The next block can then be sent. This back-and-forth exchange of I blocks and R blocks continues until the sender transmits an I block in which the chaining bit is not set. On receiving this block, the recipient knows that all of the application-layer data have been received, so it can process this data block and send the associated response.

Deactivating a card
When data transmission between the terminal and the card is completely finished, the terminal places the card in the Halt state by sending it a DESELECT command, which is transmitted using an S block. The card responds to this command with an S(DESELECT) response block and enters the Halt state.

Error handling
The block transmission protocol has error-detection mechanisms that are similar to those of the T = 1 protocol and allow resynchronization at various levels in case of transmission errors. The exact rules for the protocol processes can be found in Part 4 of ISO/IEC 14 433. Extensive examples of error-free protocol processes and error handling can also be found in the Annex to the standard.

NXP Mifare DESFire D81 ISO Card,Mifare DESFire EV1 8K Contactless Cards ,Mifare DESFire 8K Printing Card ,Mifare DESFire 8K Offset Printing Card

Figure 3.121 Example of an anticollision sequence with three Type-B cards (Part 2 of 2)