ISO / IEC 14443 Type-B initialization and anticollision

Type-B initialization and anticollision

Type-B proximity cards use a ‘dynamic slotted ALOHA procedure’ for selection. In this procedure, cards within the working range of a terminal transmit their data to the terminal in predefined time slots. The time slots are selected randomly, and the number of slots can be determined by the terminal. If only a few slots are provided and significantly more cards are present in the working range of the terminal than the number of available slots, the probability that a card can transmit its data without interference is small. In such situations, interferencefree data transmission can generally only occur if each time slot is used by only one card, or in the event that a slot is used by more than one card, if one of these cards is significantly closer to the terminal than the others, so the signal levels for its data prevail at the terminal. Although increasing the number of slots increases the probability of interference-free transmission, it has the disadvantage of increasing the amount of time required to execute the polling loop, since each card must wait for the duration of all of the time slots provided for cards that might be within range of the terminal.
To make it easier to understand this procedure, which is specified in ISO/IEC 14443-3, we will first explain it using a simplified example before describing it in detail. The terminal needs two commands to execute this algorithm:
–REQUEST: This command causes every card within the working range of the terminal to transmit its identifier in a subsequent time slot. In our example, four time slots will be provided.
–SELECT: This command transmits a previously determined identifier to cards within the range of the terminal, causing the card with the matching identifier to be activated. Cards having other numbers remain passive and respond only to REQUEST or SELECT commands with matching identifiers.
When the terminal is in the operational state, it periodically transmits REQUEST commands. Here we assume that six cards having identifiers 1 through 6 are concurrently brought within the working range of the terminal. All six cards recognize the next REQUEST command, and they select time slots at random for transmitting their identifiers to the terminal (see Figure 3.104). In this example, collisions occur in time slots 1 and 3, while identifiers 2 and 3 are transmitted without interference in time slots 2 and 4. The terminal can now select one of these two cards using a SELECT command, and then communicate with the selected card without any further collisions.

Figure 3.102 Flow chart of the anticollision loop as seen by the terminal. The step numbers (‘Step 1’, Step 2’ etc.) refer to the algorithm steps listed in Table 3.12

Figure 3.103 Sample initialization and anticollision sequence for Type-A cards. For the sake of simplicity, only the essential elements of the communications are shown

Figure 3.104 Example anticollision process for Type-B contactless smart cards. Collisions occur in time slots 1 and 3, so only identifiers 2 and 4 are transmitted without interference. This example is explained in detail in the text

When communication with the selected card is terminated, the terminal can search for other cards by again transmitting REQUEST commands. If it does not receive any error-free identifiers on the first attempt, it repeats the REQUEST command until it receives a valid identifier. Now that the basic principle of this anticollision procedure has been explained, we can give our detailed attention to the commands and the timing behavior of the cards and the terminal, as specified in ISO/IEC 14 433-3 for Type-B cards. This standard defines a set of commands that allow various types of anticollision loops to be implemented. This gives users a certain amount of freedom for system optimization.

Formats and timing specifications for characters and frames

The terminal and the cards transmit data bytes in the form of characters, with several characters grouped into frames. For error detection, a 2-byte CRC checksum (CRC B) computed according to ISOIEC 13 239 is appended to the characters in the frame. An example of the computation of CRC B is given in Annex B of ISOIEC 14 443-3. Each character consists of one start bit (logic 0) followed by eight data bits (with the least significant bit first) and one stop bit (logic 1).

Figure 3.105 Character format

Each pair of characters is separated by a gap called the ‘extra guard time’ (EGT), which allows the transmitter and receiver to prepare for the next character. For data transmission to the card, this guard time ranges from 0 to 57 μs, while in the opposite direction it ranges from 0 to 19 μs. Several characters are grouped together to form frames for transmission in each direction. A frame starts with a start of frame (SOF) character, followed by the characters to be transmitted and ending with an end of frame (EOF) character. The SOF character consists of a single falling edge followed by 10 etu of logic 0, with a rising edge in the eleventh etu, followed by a logic 1 for at least 2 and at most 3 etu.

Figure 3.106 Timing of the start of frame (SOF) character

Figure 3.107 Timing of the end of frame (EOF) character

The EOF character also begins with a falling edge, followed by 10 etu of logic 0 and a rising edge within the eleventh etu.To prevent the transmission protocol from ‘hanging’ in the event of an error, and to provide the card with defined minimum and maximum times for its internal activities, the times between two frames transmitted in opposite directions are specified in the standard. After the card has recognized the EOF of a frame transmitted by the terminal, it waits for the duration of the guard time (TR0) before generating the unmodulated subcarrier. After waiting for the duration of the synchronization time (TR1), the card starts to modulate the subcarrier. The minimum value for TR0 is 64/ fS, while the maximum value in an anticollision loop (for an ATQB) is 256/ fS. For all other types of frames, the maximum value is calculated using the formula TR0max = (256/ fS) × 2FWI

The value ofFWIranges from 0 to 14 and is supplied to the terminal in theATQB. The minimum value of the synchronization time (TR1) is 80/ fS, and the maximum value is 200/ fS.

Figure 3.108 Definition of the guard time (TR0) and synchronization time (TR1)

Once the terminal recognizes the end of a frame transmitted by the card, it waits for an interval of at least 32/ fS before starting to send a new frame. During this interval, the card switches off the subcarrier within 2 etu of the end of the transmitted frame.

Figure 3.109 Definition of the waiting time between a frame transmitted by the card and the following frame transmitted by the terminal. The card switches off the subcarrier only after the end of the EOF character

Card selection procedure

If a Type-B card enters the working range of a terminal, the microprocessor in the card is supplied with power and enters the Idle state following the power-on reset. Just like Type-A cards, Type-B cards must enter the Idle state within 5 ms of receiving sufficient operating power from the field of the terminal. In the Idle state, the card is not allowed to send any frames. Instead, it must wait to receive a valid REQB or WUPB command. These commands contain a parameter indicating the number of time slots used by the terminal, along with an application family identifier (AFI) that can be used to prescribe a specific application group. This produces a type of preselection, since only those cards whose applications belong to the indicated ‘application family’ will respond.

The REQB / WUPB command

The terminal transmits the REQB / WUPB command to determine whether any Type-B cards are present within its working range. The WUPB command is specifically used to wake up any cards that may be in the Halt state. A REQB / WUPB command consists of an anticollision prefix (APf) with a value of ’05′, followed by the AFI byte, a parameter byte (PARAM) indicating the number of available time slots and two CRC-B bytes.

Figure 3.111 Format of the REQB/WUPB command

Table 3.13 Coding of the Application Family Identifier (AFI) byte

Table 3.14 Coding of the PARAM byte. Bit b4 = 0 marks a REQB command (all cards in the Idle or Ready states respond to this command). Bit b4 = 1 marks a WUPB command (all cards in the Idle, Ready or Halt states respond to this command)

Table 3.15 Coding of N (number of slots). The probability that a card responds in the first time slot is 1/N. If only one time slot is used, the probability that a card responds in this slot depends on the value of N

After a card has received a valid REQB command, it checks to see whether it supports the applications identified by the AFI. If it does, it evaluates the PARAM byte in order to obtain the value of N, which specifies the number of available slots. The card is now in the Ready Requested state. If N = 1, the card transmits an ATQB (Answer to Request, Type B) and switches to the Ready Declared state. If N > 1, the card generates a random number R with a uniform distribution over the range of 1 to N. If R = 1, the card transmits an ATQB (Answer to Request, Type B) and switches to the Ready Declared state. If R > 1, two different options are provided in the standard in order to support two different algorithms:
Option 1: This option is for cards that do not support selecting specific time slots. At this point, the card returns to the Idle state. It cycles through this loop repeatedly until R = 1 occurs by chance (‘probabilistic approach’) or the terminal sets the value of N to 1. This option does not actually use a time-slot method in the true sense, since only one time slot is used. This option is easy to implement and adequate for systems in which only a few cards are concurrently present within the working range of the terminal.
Option 2: This option is for cards that support time slot selection. In this case, the card waits until it receives a Slot Marker command with a matching time slot number (slot number = R) before transmitting an ATQB and switching to the Ready Declared state.

The Slot Marker command

The terminal sends a Slot Marker command at the start of each time slot. The format of this command is shown in Figure 3.112. The coding of the ‘anticollision prefix byte’ (APn) is APn =’n5′, where n is the number of the following slot. Slot Marker commands may be transmitted in any desired order; they do not have to be transmitted in increasing order of slot number. After the Slot Number command has been transmitted, the terminal waits for an interval of TR0max = 256/ fS before checking to see whether a card has started to transmit an ATQB.If the terminal does not detect an ATQB, it can immediately transmit the next Slot Marker command.

ATQB (Answer to Request, Type B)
The format of ATQB, which is sent in response a REQB/WUPB or Slot Marker command, is shown in Figure 3.113.

Figure 3.113 Format of ATQB (Answer to Request, Type B)

ATQB contains information regarding important parameters of the smart card, which the terminal needs in order to select the card. The pseudo-unique PICC identifier (PUPI) is the identification number of the PICC for the anticollision loop. This may be a number that is permanently assigned to the card, or it may be a random number generated by the card following power-on reset. The Application Data field contains information about the applications present in the card. This information allows the terminal to select the desired card if several cards are present within its working range. The meaning of the application data parameter depends on the content of the application data coding (ADC) parameter in the Protocol Info field (described below), which specifies whether the ‘CRC B compressing method’ or proprietary coding is used. If the CRC B compressing method is used, the Application Data field is formatted as shown in Figure 3.114. The Protocol Info field shows important parameters supported by the card. These parameters allow the terminal to optimally adapt itself to the performance capacity of the card for the subsequent application protocol or adapt itself to cards that do not meet all the requirements of the standard.

Figure 3.114 Format of the Application Data field. The coding of the AFI parameter is given in Table 3.13. It indicates the family of the application for a multiapplication card. CRC B (AID) is the ISO/IEC 7816-5-compliant CRC B checksum of the application identifier (AID) of an application in the card corresponding to the AFI sent in the REQB / WUPB command. The Number of Applications field indicates the number of additional applications present in the card. The upper nibble of this byte indicates the number of applications corresponding to the AFI, where’0′means ‘no applications’ and’F’ means ‘15 or more applications’. The lower nibble indicates the total number of applications present in the card, with the same meaning (’0′= ‘no applications’,’F'= ‘15 or more applications’)

The frame waiting time integer (FWI) specifies the maximum amount of time needed by the card to start transmitting a response after it has fully received a command from the terminal. If a card does not respond within this interval, the terminal can assume that communications with the card have been interrupted. The frame waiting time (FWT) is calculated using the following formula:
FWT = (256 × 16/ fC) × 2FWI
The value of FWI lies between 0 and 14, with 15 being reserved for future use (RFU). The following minimum and maximum values for the frame waiting time can be calculated using this formula:
–minimum value (FWI = 0): FWTmin ≈ 302 μs
–minimum value (FWI = 14): FWTmax = 4949 ms
The Protocol Type field indicates whether the card supports the ISO/IEC 14 443-4 transmission protocol. The coding of this field is shown in Table 3.19.

Table 3.19 Protocols supports by the card. All other values are reserved for future use (RFU)

In the Max Frame Size field, the card indicates the maximum frame size it can receive. This is limited by the size of the receive buffer in the card’s RAM. Inexpensive chips typically have only a small amount of RAM, so they can only receive small frames. The Bit Rate capability field indicates the data transmission rates supported by the card, as shown in Table 3.21.

As already mentioned, the card changes to the Ready Declared state after it transmits its ATQB (see Figure 3.111). In this state, the card responds only to the REQB/WUPB, ATTRIB and HLTB commands. It responds to a REQB/WUPB command in the same way as when it is in the Idle state. If the card recognizes a valid ATTRIB command in which the PUPI matches the PUPI of the card, it transmits an Answer to ATTRIB frame and changes to the Active state. If the PUPI parameters do not match, the card remains in the Ready Declared state and waits for an ATTRIB command with the proper PUPI. The card responds to an appropriate HALTB command (containing the proper PUPI) by transmitting an Answer to HALTB and changing to the Halt state. In the Active state, the card has a card identifier (CID) that is assigned to it by the ATTRIB command. As a result, it is in a higher protocol layer and responds to suitable application commands having the proper CID and correct CRC B checksum. Special commands belonging to this higher protocol layer can put the card into the Idle or Halt state. When it is in the Active state, the card is not allowed to respond to REQB/WUPB, Slot Marker andATTRIB commands. In the Halt state, the card is passive and can only be reset to the Idle state by a valid WUPB command with the proper PUPI.

Format and coding of the ATTRIB command

The ATTRIB command is transmitted by the terminal to the card and contains information needed to select a card. It also contains information regarding the parameters supported by the terminal for subsequent communications and those required by the card for error-free communications. This includes parameters such as the minimum value of the guard time (TR0), the minimum value of the synchronization time (TR1), whether the card can suppress SOF and/or EOF to accelerate communications, the maximum frame size and selection of the optimum bit rate.

Figure 3.116 Format of the ATTRIB command. ‘Identifier’ contains the value of the PUPI, which is sent by the card in the ATQB. The format of Param 1 is shown in Figure 3.117

Figure 3.117 Format of Parameter 1

The value of the ‘Minimum TR0’ parameter defines the minimum time that the card must wait before responding to a command received from the terminal. This is the time needed by the terminal to switch from transmit mode to receive mode, which depends on the performance of the terminal.

Table 3.22 Coding of the Minimum TR0 parameter

The value of the ‘Minimum TR1’ parameter defines the minimum delay between the activation of the subcarrier and the start of data transmission (see Figure 3.107). The terminal needs this time for synchronization with the card.
Table 3.23 Coding of the Minimum TR1 parameter

Bits b3 and b4 indicate to the terminal whether the card supports suppression of EOF and/or SOF from the card to the terminal in order to reduce communications overhead. This capability is optional for the card.

The lower nibble of Parameter 2 (bits b4–b1) specifies the maximum size of a frame that can be received from the terminal. The upper nibble is used to select the bit rates in both directions. The terminal can make this choice, since it already knows the bit rates supported by the card from the ATQB. The lower nibble of Parameter 3 is used to confirm the protocol type. The coding corresponds to that shown in Table 3.19. The upper nibble is set to ’0′. All other values are reserved for future use.
Table 3.26 Coding of bits b4–b1 in Parameter 2, which specify the maximum frame size

Table 3.27 Coding of bits b8–b5 in Parameter 2, which select the transmission bit rate

Parameter 4 also consists of two parts. The lower nibble is called the ‘card identifier’ (CID) and defines the logical number of the addressed card, with a range of 0 to 14. The value 15 is reserved for future use. The card identifier is specified by the terminal and is unique for each active card. If the card does not support CID, a value of’0′is used. The upper nibble is set to ’0′. All other values are reserved for future use. The ‘Higher-Layer Inf’ field can be used to transfer any desired higher level commands. The ability to process such commands is optional for the card.

Response to the ATTRIB command

The card responds to every valid ATTRIB command (having the proper PUPI and correct CRC B checksum) as shown in Figure 3.118.

Figure 3.118 Format of the response to an ATTRIB command

If the terminal receives a valid response to an ATTRIB command (one having the same CID and a correct CRC B checksum), it knows that card selection was successful. The lower nibble of the first byte in the response (bits b4–b1) contains the CID. The upper nibble of the first byte (bits b8–b5) is called the ‘maximum buffer length index’ (MBLI). The card uses the MBLI to tell the terminal the maximum size of its input buffer. This allows the terminal to avoid causing the input buffer of the card to overflow by sending too many chained frames. If MBLI is set to 0, the card does not provide any information about the size of its internal buffer. If MBLI is greater than 0, the maximum internal buffer length (MBL) can be calculated using the following formula:

MBL = (PICC maximum frame size) × 2(MBL−1)

The card sends its maximum frame size parameter to the terminal in the ATQB. When the terminal transmits chained frames, it must ensure that the cumulative length does not exceed the value of MBL.

The HLTB command

The HLTB command is used to place a card in the Halt state, so that it no longer responds to REQB commands. After responding to this command, the card ignores all subsequent commands except WUPB.

Figure 3.119 Format of the HLTB command

The Identifier parameter contains the PUPI of the card to be placed in the Halt state. The format of the card’s response to a valid HLTB command is shown in Figure 3.120.

Figure 3.120 Format of the response to a HLTB command

Example of an anticollision sequence with three Type-B cards The standard gives the developer the freedom to implement various types of anticollision strategies. This corresponds to the basic function of a standard, which is to make interoperability possible while providing as much latitude as possible for implementation in order to avoid hindering technical progress. An example of an anticollision sequence is shown in Figure 3.121. This example, which is also contained in the annex to the standard, serves to illustrate the processes and commands described in the previous section. It makes no claim to being a technically superior implementation.

原文出處：http://www.gorferay.com/iso-iec-14443-type-b-initialization-and-anticollision/