Father
Professional
- Messages
- 2,602
- Reaction score
- 795
- Points
- 113
CLOSE ACTION CARDS
Identification cards. Contactless integrated circuit cards. Proximity cards. Transmission protocol.
Foreword
1. PREPARED by the Federal State Unitary Enterprise "Research Institute of Standardization and Certification in Mechanical Engineering" (VNIINMASH) and the Technical Committee for Standardization TC 22 "Information Technologies" on the basis of its own authentic standard specified in paragraph 4
2. INTRODUCED by the Technical Committee for Standardization TC 22 "Information Technologies".
3. APPROVED AND PUT INTO EFFECT by the Order of the Federal Agency for Technical Regulation and Metrology.
4. This standard is identical to the international standard ISO/IEC 14443-4:2008 * "Identification cards. Contactless integrated circuit cards. Close-range cards. Part 4. Transmission protocol (ISO/IEC 14443-4: 2008" Identification cards - Contactless integrated circuit cards - Proximity cards - Part 4: Transmission protocol "), including changes A1: 2012 and A2: 2012.
* Access to international and foreign documents mentioned in the text can be obtained by contacting the User Support Service. - Note from the manufacturer of the database.
Changes to the specified international standard, adopted after its official publication, were introduced into the text of this standard and are highlighted by a double vertical line located in the margins from the corresponding text, and the designation and year of adoption of the change are shown in brackets after the corresponding text.
When applying this standard, it is recommended to use, instead of the reference international standards, the corresponding national standards, information about which is given in the additional appendix YES.
5. INTRODUCED FOR THE FIRST TIME
6. Certain provisions of the International Standard referred to in clause 4 may be the subject of patent rights. The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) are not responsible for the identification of such patent rights.
The rules for the application of this standard are established in GOST R 1.0-2012 (section 8). Information on changes to this standard is published in the annual (as of January 1 of the current year) information index "National Standards", and the official text of changes and amendments is published in the monthly information index "National Standards". In case of revision (replacement) or cancellation of this standard, the corresponding notice will be published in the next issue of the information index "National Standards". Relevant information, notice and texts are also posted in the public information system - on the official website of the Federal Agency for Technical Regulation and Metrology on the Internet
Introduction
ISO/IEC 14443 is one of a series of standards describing the parameters of ISO/IEC 7810 ID cards and their use in information exchange.
A protocol in accordance with this standard is capable of transferring an ISO/IEC 7816-4 application protocol data unit. Thus, the application protocol data block can be converted in accordance with ISO/IEC 7816-4, and the selection of the application can be in accordance with ISO/IEC 7816-5.
This International Standard is intended to enable proximity cards to operate in the presence of contactless cards compliant with ISO/IEC 10536 and ISO/IEC 15693 and near field communication (NFC) devices compliant with ISO/IEC 18092 and ISO/IEC 21481.
NFC - Near Field Communication.
The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) draw attention to the statement that compliance with this standard may result in the use of a patent.
ISO and IEC take no position on the existence, validity and scope of this patent right.
The holders of this patent right have assured ISO and IEC that they are ready to negotiate with applicants from around the world for a license on reasonable and non-discriminatory terms, including time limits. This statement by patent holders is registered with ISO and IEC. Information can be obtained from:
The following companies may have a patent relating to this standard but have not provided details of the patents or agreed to grant licenses:
Attention is drawn to the fact that certain elements of this standard may be the subject of patent rights in addition to those identified above. ISO and IEC are not responsible for identifying some or all of these rights.
ISO/IEC 14443-4 was prepared by Subcommittee No. 17, Cards and Identity, of the ISO/IEC Joint Technical Committee No. 1, Information Technology (ISO/IEC JTC 1/SC 17).
1 Area of use
This standard defines a block half-duplex protocol, describing the specific requests of non-contact equipment, as well as the sequence of activation and deactivation of the protocol.
This International Standard is intended to be used in conjunction with other parts of ISO/IEC 14443 and is applicable to Type A and Type B cards or close-range objects.
2 Normative references
This standard uses references to the following International Standards *. For dated references, only the edition cited should be used; for undated references, the latest edition of the referenced document should be used, including any amendments:
* The table of conformity of national standards to international ones, see the link. - Note from the manufacturer of the database.
ISO/IEC 7816-3 Identification cards. Integrated circuit cards. Part 3. Cards with contacts. Electrical interface and transmission protocols (ISO/IEC 7816-3, Identification cards - Integrated circuit cards - Part 3: Cards with contacts - Electrical interface and transmission protocols)
ISO/IEC 7816-4 Identification cards. Integrated circuit cards. Part 4. Organization, security and commands for interchange (ISO/IEC 7816-4, Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange)
ISO/IEC 14443-2 Identification cards. Integrated circuit cards are contactless. Close range cards. Part 2. Radio frequency power and signal interface (ISO/IEC 14443-2, Identification cards - Contactless integrated circuit cards - Proximity cards - Part 2: Radio frequency power and signal interface)
ISO/IEC 14443-3 Identification cards. Integrated circuit cards are contactless. Close range cards. Part 3. Initialization and anticollision (ISO/IEC 14443-3, Identification cards - Contactless integrated circuit cards - Proximity cards - Part 3: Initialization and anticollision)
3 Terms and definitions
The following terms are used in this standard with the corresponding definitions:
3.1 bit durationone elementary time unit (etu), calculated by the following formula:
1 etu = 128/(D fc).
With the initial value of the divisor D equal to 1, the initial etu takes on the value:
1 etu = 128/fc,
where fc is the carrier frequency in accordance with ISO/IEC 14443-2.
3.2 block: A special type of frame that contains a valid protocol data format.
NOTE - A valid protocol data format contains I-boxes, R-boxes, or S-boxes.
3.3 invalid block: A frame type that contains an invalid protocol format.
NOTE - If no frame has been received after the timeout has elapsed, then the block is not considered invalid.
3.4 frame: A sequence of bits in accordance with ISO/IEC 14443-3
NOTE - A Type A PICC uses a standard frame defined for Type A, and a Type B PICC uses a frame defined for Type B.[/FONT]
4 Symbols and abbreviations
5 Protocol activation in PICC type A
The following activation sequence should be applied:
- PICC activation sequence in accordance with ISO/IEC 14443-3 (query, anti-collision cycle and selection);
- The SAK byte must be checked to determine if the PICC complies with the requirements of this standard. The SAK byte is defined in ISO/IEC 14443-3;
- The PICC can be set to the HALT state using the HALT command in accordance with ISO/IEC 14443-3 if, for example, the PCD does not use a protocol conforming to the requirements of this standard.
NOTE:
- In this case, the PCD cannot continue the activation sequence;
- If the PICC complies with the requirements of this standard, then the PCD may then send the RATS command after receiving the SAK;
- The PICC sends its ATS as a response to the RATS. The PICC shall only respond to RATS if RATS is received immediately after selection;
- If the PICC supports any changeable parameters in the ATS, then the PPS request can be used by the PCD as the next command after receiving the ATS to change the parameters.
- The PICC shall send the PPS response as a response to the PPS request.
PICC does not need to implement PPS if it does not support mutable parameters in the ATS.
The PCD activation sequence for Type A PICCs.
5.1 Request for Answer to Choice
This subclause defines a RATS with all fields.
The parameter byte consists of two parts:
- The most significant nibble from b8 to b5 is called FSDI, it encodes FSD, which defines the maximum frame size that the PCD can receive. FSD coding is shown in Table 1;
- A PCD setting FSDI = 'D' - 'F' does not meet the requirements of this standard. Unless RFU values 'D' - 'F' are assigned by ISO/IEC, a PICC accepting FSDI = 'D' - 'F' shall interpret these values as FSDI = 'C' (FSD = 4096 bytes) ...
NOTE - This is an additional recommendation for PCD compatibility with future PICCs when ISO/IEC defines behavior for RFU values 'D' - 'F';
- The least significant nibble from b4 to b1 is called the CID, it defines the logical number of the addressed PICC in the range from 0 to 14. The value 15 is the RFU. The CID is specified by the PCD and must be unique for all PICCs that are ACTIVE at the same time. The CID is set when the PICC is active. The PICC shall use the CID as its logical identifier, which is contained in the first correctly received RATS;
- A PCD setting CID = 15 does not meet the requirements of this standard. For PICC behavior see 5.6.1.2, p.
Table 1 - Convert FSDI to FSD
5.2 Answer to choice
This subclause defines the ATS with all of its valid fields (see Figure 4).
If one of the defined fields is missing from the ATS sent by the PICC, then the default values for that field shall be used.
5.2.1 Byte structure
A byte of length TL is followed by a variable number of additional bytes in the following order:
- byte of T0 format,
- interface bytes TA (1), TB (1), TC (1) and
- history bytes from T1 to Tk.
5.2.2 Byte length
The TL length byte is mandatory. It indicates the length of the transmitted ATS, including itself. The two CRC bytes are not included in the TL. The maximum ATS size must not exceed the specified FSD, so the maximum TL value must not exceed FSD-2.
5.2.3 Format Byte
The T0 format byte is optional and is present only when the length is greater than 1. The ATS may contain the following additional bytes when T0 is present.
T0 consists of three parts:
- the most significant bit of b8 must be set to 0. Value 1 is RFU;
- bits from b7 to b5 contain Y (1), indicating the presence of subsequent bytes of the TC (1), TB (1) and TA (1) interface;
- The least significant nibble from b4 to b1 is called FSCI, it encodes FSC, which defines the maximum frame size received by the PICC. The default value for FSCI is 2, which gives an FSC of 32 bytes. FSC coding is similar to FSD coding (see table 1);
- A PCD setting FSDI = 'D' - 'F' does not meet the requirements of this standard. Unless RFU values 'D' - 'F' are assigned by ISO/IEC, a PCD assuming FSDI = 'D' - 'F' shall interpret these values as FSDI = 'C' (FSD = 4096 bytes) ...
NOTE This is an additional recommendation for PICC compatibility with future PCDs when ISO/IEC defines behavior for RFU values 'D' - 'F'.
5.2.4 TA interface byte (1)
The TA interface byte (1) consists of four parts:
- the most significant bit b8 encodes the ability to handle different dividers for each direction. If this bit is set to 1, then the PICC is unable to handle different dividers for each direction;
- Bits b7 to b5 encode the possible PICC baud rates for the PICC to PCD direction, called DS. The default should be (000) b;
- bit b4 must be set to (0) b, and other values - RFU;
- Bits b3 to b1 encode the possible PICC bit rates for the PCD to PICC direction, called DR. The default should be (000) b.
The choice of a specific divider D for each direction can be done by PCD using PPS.
A PICC setting b4 = 1 is not compliant with this standard. The received TA (1) value with b4 = 1 should be interpreted by the PCD device as (b8 to b1) = (00000000) b (at a speed in both directions only ~ 106 kbps).
5.2.5 TV interface byte (1)
The TV interface byte (1) conveys information for determining the frame waiting time and triggering the delimiting time interval.
The TV interface byte (1) consists of two parts:
- the most significant nibble from b8 to b5 is called FWI, it encodes FWT (see 7.2);
- The least significant nibble from b4 to b1 is called SFGI, it encodes the value of the multiplier used to determine the SFGT. The SFGT defines a specific border interval required by the PICC before it is ready to receive the next frame after the ATS is sent. SFGI is encoded in the range 0 to 14. The value 15 is RFU. A value of 0 indicates that no SFGT is needed, and values in the range 1 through 14 are used to calculate the SFGT using the formula below. The default value for SFGI is 0.
SFGT is calculated using the following formula:
SFGT = (256 16/fc ) 2SFGI.
SEGT MIN is the minimum frame delay time in accordance with ISO/IEC 14443-3.
SFGT DEFAULY is the minimum frame delay time in accordance with ISO/IEC 14443-3.
SFGT MAX = (256 16/fc ) 2 (~ 4949 ms).
A PICC setting SFGI = 15 is not compliant with this standard. Until RFU value 15 is assigned by ISO/IEC, a PCD receiving SFGI = 15 shall interpret it as SFGI = 0.
A PICC setting FWI = 15 is not compliant with this standard. Until RFU value 15 is assigned by ISO/IEC, a PCD receiving FWI = 15 shall interpret it as FWI = 4.
5.2.6 TC interface byte (1)
The TC interface byte (1) sets the protocol parameters.
The specific byte of the TC interface (1) consists of two parts:
- the most significant bits from b8 to b3 shall be (000000) b, and the other values are RFU;
- Bits b2 and b1 determine which additional fields in the prologue field the PICC supports. The PCD can skip fields that are supported by the PICC, but a field that is not supported by the PICC will never be transmitted by the PCD. The default should be (10) b. It indicates that the CID is supported and the NAD is not supported;
- A PICC setting (b8 to b3) <> (000000) b does not meet the requirements of this standard. The PCD shall ignore (b8 to b3) and the interpretation of (b2, b1) or any other fields in the whole frame shall not change.
5.2.7 History Bytes
The history bytes T1 to Tk are optional and define general information. The maximum length of the ATS provides the maximum number of history bytes possible. ISO/IEC 7816-4 defines the content of the history bytes.
5.3 Request for selection of protocol and parameters
The PPS request contains a start byte followed by two parameter bytes.
5.3.1 Start Byte
PPSS consists of two parts:
- the most significant nibble from b8 to b5 shall be set to (1101) b, it defines the PPS;
- The least significant nibble from b4 to b1 is called CID, it defines the logical number of the PICC to be addressed.
5.3.2 Parameter 0
PPS0 indicates the presence of an additional byte PPS1 (see Figure 11).
A PCD stating (b4 to b1) <> (0001) b and/or (b8 to b6) <> (000) b does not meet the requirements of this standard.
A PICC accepting (b4 to b1) <> (0001) b and/or (b8 to b6) <> (000) b shall apply the rules given in 5.6.2.2, b).
5.3.3 Parameter 1
PPS1 consists of three parts:
- the most significant nibble from b8 to b5 shall be (0000) b, and the other values are RFU;
- bits b4 and b3 are called DSI, they encode the selected integer divider from PICC to PCD;
- bits b2 and b1 are called DRI, they encode the selected integer divider from PCD to PICC;
- A PCD stating (b8 to b5) <> (0000) b does not meet the requirements of this standard. A PICC receiving (b8 to b5) <> (0000) b shall apply the rules given in 5.6.2.2, b).
DS and DR are defined in 5.2.4.
D coding is shown in Table 2.
Table 2- Convert DRI, DSI to D
5.4 Response to selection of protocol and parameters
The PPS response acknowledges the received PPS request (see Figure 13) and contains only the start byte (see 5.3.1).
The PICC starts using the new baud rates as soon as it sends the PPS response. A PCD that changes baud rates does not comply with this standard if the PPS response is missing or invalid, or if the PPSS value returned by the PICC does not match the PPSS value sent by the PCD.
5.5 Activation frame waiting time
The wake-up frame timeout defines the maximum time for the PICC to send its response frame after the end of the frame received from the PCD, and has a value of 65536/fc (~ 4833 ?s).
NOTE - The minimum time between frames in any direction is specified in ISO/IEC 14443-3.
5.6 Error detection and correction
5.6.1 RATS and ATS handling
5.6.1.1 Rules for PCD
If the PCD has already sent RATS and received a valid ATS, then it should proceed.
In any other case, the PCD may retransmit RATS before using the deactivation sequence defined in clause 8. If the deactivation sequence is not followed, it may use the HLTA command in accordance with ISO/IEC 14443-3.
5.6.1.2 Rules for PICC
If PICC was selected with the last command and
a) has received a valid RATS, then the PICC must:
- return your ATS and
- transfer to inactive state RATS (stop responding to received RATS);
b) has received a valid block (HLTA), then the PICC must:
- process the command and enter the HALT state;
c) received an invalid block or RATS with CID = 15, then PICC:
- shall not respond, but shall enter the IDLE or HALT state as specified in Figure 7 () "PICC Type A state diagram" in ISO/IEC 14443-3.
There is a typo in ISO/IEC 14443-4.
5.6.2 PPS request and PPS response processing
5.6.2.1 Rules for PCD
If the PCD has already sent a PPS request and received a valid PPS response, then it should activate the selected options and continue. Otherwise, the PCD can retransmit the PPS request and continue.
5.6.2.2 Rules for PICC
If the PICC received RATS, sent its ATS and
a) has received a valid PPS request, then the PICC shall:
- send a PPS response;
- deactivate the PPS request (stop responding to received PPS requests) and
- activate the received parameters;
b) received an invalid block, then the PICC shall:
- deactivate the PPS request (stop responding to received PPS requests) and
- stay in receive mode;
c) has received a valid block other than the PPS request, then the PICC shall:
- deactivate the PPS request (stop responding to received PPS requests) and
- continue work.
5.6.3 Handling CIDs During Activation
If the PCD has already sent a RATS containing a CID = n not equal to 0, and:
a) has received an ATS indicating that the CID is supported, then the PCD:
- must send blocks containing CID = n to this PICC and
- shall not use CID = n for further RATS while this PICC is in the ACTIVE state;
b) has received an ATS indicating that the CID is not supported, then the PCD:
- must send blocks that do not contain a CID to this PICC, and
- shall not activate another PICC while that PICC is in the ACTIVE state.
If the PCD has already sent a RATS containing a CID of 0 and:
a) has received an ATS indicating that the CID is supported, then the PCD:
- can send blocks containing a CID equal to 0 for this PICC and
- shall not activate another PICC while this PICC is in the ACTIVE state;
b) received an ATS indicating that the CID is not supported, then the PCD:
- must send blocks that do not contain a CID to this PICC, and
- shall not activate another PICC while that PICC is in the ACTIVE state.
6 Protocol activation in PICC type B
The activation sequence for Type B PICCs is described in ISO/IEC 14443-3.
7 Block half-duplex protocol
The block half-duplex protocol is used for special requests in the contactless card environment and uses the frame format defined in ISO/IEC 14443-3.
The relevant frame format elements are:
- block format;
- maximum frame waiting time;
- power indication and
- protocol operations.
This protocol is designed in accordance with the layering principle of the OSI Reference Model, with particular attention to minimizing interactions across borders. Four levels are defined:
- the physical layer where bytes are exchanged in accordance with ISO/IEC 14443-3;
- the link layer at which bytes are exchanged as defined in this clause;
- session layer combined with data link layer while minimizing interaction;
- the application layer at which the command processing takes place. It includes at least one block or block chaining in any direction.
NOTE Application selection can be made in accordance with ISO/IEC 7816-4. Implicit application selection is not recommended for PICCs with multiple applications.
A special mechanism is provided to introduce additional protocol functions that may be defined in this standard or in other standards using this standard as a basis.
7.1 Block format
The block format (see Figure 14) consists of a prologue field (required), an information field (optional), and an epilogue field (required).
NOTE Items in square brackets indicate optional requirements.
7.1.1 Prologue field
The prologue field is required and can be 1, 2, or 3 bytes: PCB is required and CID and NAD are optional.
7.1.1.1 Protocol Control Byte Field
PCB is used to transmit information required to control data transmission. The protocol defines three main types of blocks:
- l-block used to transfer information at the application level;
- R-block used to transmit positive or negative acknowledgments. The R block never contains INF. Acknowledgment refers to the last received block;
- S-box used to exchange control information between PCD and PICC. S (PARAMETERS) block support is optional for PCD and PICC. Three different types of S-boxes are defined:
1) "timeout extension" containing INF of 1 byte;
2) "DESELECT", not containing INF,
3) "PARAMETERS" containing INF of length n -bytes, when n is 0.
NOTE - FSD and FSC must be large enough to contain the expected number of S (PARAMETERS) blocks.
PCB coding depends on its type and is defined in Figures 15-17. PCB coding not specified in this standard is either used in other parts of ISO/IEC 14443 or is an RFU. The coding of I-boxes, R-boxes and S-boxes is shown in Figures 15, 16 and 17.
A PICC or PCD setting b6 <> (0) b in an I-box, b2 <> (1) b in an R-box, b1 <> (0) b in an S-box are not compliant with this standard.
7.1.1.2 Card ID field
The CID field is used to identify a specific PICC and has three parts:
- The two most significant bits b7 and b8 are used to record the power level readings received by the PICC from the PCD. These two bits must be set to (00) b for PCD to PICC transmission. Power level indication is covered in 7.4;
- bits b6 and b5 are used to convey additional information that is not defined and should be set to (00) b, other values are RFU;
- A PICC or PCD setting (b6, b5) <> (00) b does not meet the requirements of this standard. Bits (b6, b5) <> (00) b should be treated as a protocol error;
- bits b4 to b1 encode the CID.
CID coding is given in 5.1 for type A and in ISO/IEC 14443-3 for type B.
CID processing:
A PICC that does not support CID must:
- ignore any block containing a CID;
A PICC that supports CID must:
- respond to blocks containing a CID using your CID,
- ignore blocks containing other CIDs, and
- in the case of CID = 0, respond also to blocks that do not contain a CID, without using their own CID.
7.1.1.3 Field with host addresses
NADs in the prologue field are reserved for creating and referring to various logical connections. The NAD application shall comply with ISO/IEC 7816-3 when the b8 and b4 bits are 0. All other values are RFU.
A PICC or PCD setting b8 <> 0 and/or b4 <> 0 is not compliant with this standard. Bits b8 <> 0 and/or b4 <> 0 should be considered a protocol error.
When using NAD, the following definitions apply:
a) the NAD field shall only be used for I-boxes;
b) if the PCD uses NAD, the PICC shall also use NAD;
c) during clutching, NADs shall only be transmitted in the first block of the chain;
d) The PCD should not use NAD to refer to different PICCs (CID should be used to refer to different PICCs);
e) if the PICC does not support NAD, then it shall ignore any block containing NAD.
7.1.2 Information field
INF is optional. If present, INF transfers either application data in l-boxes or non-application data and state information in S-boxes. The length of the information field is calculated by counting the number of bytes in the whole block minus the length of the prologue and epilogue fields.
7.1.3 Epilogue field
The epilogue field contains the EDC of the transmitted block, which is the CRC according to ISO/IEC 14443-3.
7.2 Frame timeout
The FWT is the time that the PICC must start its reply frame after the end of the PCD frame (see Figure 19).
NOTE 1 The minimum time between frames in any direction is defined according to ISO/IEC 14443-3.
FWT is calculated using the following formula:
FWT = (256 16/fc ) 2 ,
where the FWI value ranges from 0 to 14 and the 15 value is RFU.
The default value for FWI is 4 (which gives an FWT value of ~ 4.8ms) for the following two cases:
- for type A, if we neglect TB (1);
- for S (PARAMETERS) and S (DESELECT) blocks.
The FWT value shall be used by the PCD to detect a protocol error or unresponsive PICC. The PCD is eligible for retransmission if the start of a response from the PICC is not received within FWT.
The FWI for Type B is located in the ATQB as defined in ISO/IEC 14443-3. The FWI for Type A is located in the ATS (see 5.2.5)
The PICC shall not set the FWI to an RFU value of 15. Until RFU value 15 is defined by ISO/IEC. A PCD receiving an FWI = 15 should interpret it as FWI = 4.
NOTE 2 This is an additional recommendation for PCD compatibility with future PICCs when ISO/IEC defines an RFU value of 15.
7.3 Extending Frame Timeout
When the PICC takes longer than specified by the FWT to process a received block, it shall use an S (WTX) request to extend the latency. The S (WTX) request contains a 1 byte INF, which consists of two parts (see Figure 20):
- the two most significant bits b7 and b8 encode the power level indication (see 7.4);
- A PCD not setting (b8, b7) = (00) b does not meet the requirements of this standard. The PICC shall interpret (b8, b7) <> (00) b as a protocol error;
- the least significant bits from b6 to b1 encode WTXM. WTXM is encoded in the range 1 to 59. The values 0 and 60 to 63 are RFU;
- A PICC setting WTXM = 0 or WTXM = 60-63 does not meet the requirements of this standard. When receiving WTXM = 0 or WTXM = 60-63, the PCD should interpret it as a protocol error.
The PCD shall confirm by sending an S (WTX) response containing also 1 byte INF, which is in two parts (see Figure 21) and contains the same WTXM as received in the request:
- the most significant bits b8 and b7 should be set to (00) b, and the rest of the values - RFU;
- the least significant bits b6 to b1 encode the confirmed WTXM value used to determine the intermediate FWT.
The corresponding intermediate FWT values are calculated using the following formula:
FWT TEMP = FWT WTXM.
FWT TEMP requested by the PICC begins after the PCD has sent an S (WTX) response.
FWT MAX should be used when the formula results in a value greater than FWT TEMP.
ISO/IEC 14443-4: 2008 contains a typographical error.
The intermediate FWT only applies until the PCD receives the next block.
7.4 Power level display
The power level indication is encoded as shown in Table 3 using two bits placed in the CID field (if present) and in the S-box sent by the PICC (see 7.1.1.2 and 7.3).
Table 3 - Coding of power level indication[/FONT]
NOTE - The interpretation of the PCD power level indication is optional.
7.5 Protocol mode
After the activation sequence, the PICC must wait for the block, since only the PCD is allowed to send. After sending the block, the PCD must switch to receive mode and wait for the block before switching back to transmit mode. The PICC can only transmit blocks in response to received blocks (it is insensitive to time delays). Upon response, the PICC should return to receive mode.
The PCD shall not initiate a new command/response pair if the current command/response pair has not completed or if the unresponsive frame timed out.
7.5.1 S Blocks (PARAMETERS)
After the activation sequence, the PCD may send at any time the first S (PARAMETERS) block with or without INF to check if the PICC supports S (PARAMETERS) blocks.
This first S (PARAMETERS) PCD block and the PICC response (if the PICC supports S (PARAMETERS) blocks) may contain information indicating support for different types of application protocols and/or other communication parameters.
The content of INF S (PARAMETERS) is defined in the relevant part of ISO/IEC 14443 and must comply with the ISO/IEC 7816-4: 2005 BER-TLV encoding rules for a context sensitive class.
7.5.2 Multi-activation
After the amendment A1: 2012, the subsections were renumbered.
The multi-activation function allows the PCD to keep multiple PICCs in ACTIVE state at the same time. This allows multiple PICCs to be switched at once without the need for additional time to deactivate the PICC and activate another PICC.
An example of multi-activation is given in Appendix A.
NOTE - The PCD needs to process separate block numbers for each activated PICC.
7.5.3 Clutch
The chaining function allows a PCD or PICC to transmit information that does not fit into a single block according to FSC or FSD by dividing it into multiple blocks. Each of these blocks must have a length less than or equal to FSC or FSD, respectively.
The concatenation of bits in the PCB of the l-block controls the concatenation of the blocks. Each I-box with a concatenated bit set must be acknowledged with an R-box.
A concatenation function using a 16-byte string, transmitted in three blocks.
Legend:
I (1) - l-block with bit concatenation and block number x;
I (0) - l-block with unset bit clutch (last block of the chain) and block number x;
R (ACK) - An R block that indicates a positive acknowledgment.
NOTE - The example does not use the additional NAD and CID fields.
7.5.4 Block numbering rules
7.5.4.1 Rules for PCD
Rule A. The PCD Block Number shall be assigned an initial value of 0 for each activated PICC.
Rule B. If an I-block or an R (ACK) block is received with a block number equal to the current block number, then the PCD shall toggle the current block number for that PICC before sending an additional block.
7.5.4.2 Rules for PICC
Rule C. The PICC block number must be set to an initial value of 1 when activated.
Rule D. If an I-block is received, then the PICC shall switch its block number before sending the block.
NOTE 1 If the received block number does not comply with the PCD rules, then the PICC may not switch its internal block number and not send a reply block.
Rule E. If an R (ACK) block is received with a block number not equal to the current PICC block number, then the PICC shall switch its block number before sending the block.
NOTE 2 If an R block (NAK) is received, then the block number is not toggled.
7.5.5 Block processing rules
7.5.5.1 General rules
Rule 1. The first block must be sent by the PCD.
Rule 2. If an I-block indicating concatenation is received, it shall be acknowledged with an R (ACK) block.
Rule 3. S-boxes are used only in pairs. A request block S (...) shall always be followed by a response block S (...) (see 7.3 and 8).
7.5.5.2 Rules for PCD
Rule 4. If an invalid block is received or an FWT timed out, then an R (NAK) block shall be sent (except in the case of PICC concatenation or S (DESELECT) or S (PARAMETERS)).
Rule 5. In the case of PICC concatenation, if an invalid block is received or an FWT timed out, an R (ACK) block shall be sent.
Note 1 - An R (ACK) block can only be sent by the PCD in the case of PICC concatenation, since the PICC response when receiving an R (ACK) block is otherwise undefined.
Rule 6. If an R (ACK) block is received and if its number is not equal to the number of the current PCD block, then the last l-block shall be retransmitted.
NOTE 2 - The last l-block retransmission without PCD clutch is not required. The PCD can determine the presence of a PICC by sending R (NAK) blocks at any time out of the concatenation (including before sending any l-block) and receiving R (ACK) blocks from the PICC, if present.
Rule 7. If an R (ACK) block is received and if its number is equal to the current PCD number, then concatenation must continue.
Rule 8. If the S (DESELECT)/S (PARAMETERS) request does not have an error-free response S (DESELECT)/S (PARAMETERS), then the S (DESELECT)/S (PARAMETERS) request may be retransmitted.
If the answer S (DESELECT) is not received after the request S (DESELECT), then the card can be ignored.
7.5.5.3 Rules for PICC
Rule 9. The PICC MAY send an S (WTX) block instead of an I-block or an R (ACK) block.
Rule 10. If an I-box is received that does not indicate concatenation, then it must be acknowledged with an I-box.
NOTE - If the received l-block is empty, then the mandatory sent l-block can be empty or contain any functional information (eg error code).
Rule 11. If an R (ACK) or R (NAK) block is received and if its number is equal to the current PICC block number, then the last block shall be retransmitted.
Rule 12. If an R (NAK) block is received and if its number is not equal to the current PICC block number, then an R (ACK) block shall be sent.
Rule 13. If an R (ACK) block is received and if its number is not equal to the current PICC block number and the PICC is in concatenation, then concatenation must continue.
7.5.6 Checking for the presence of a PICC
The following methods can be used to check for the presence of a PICC at any time, including before any I-box exchange.
The PCD does not check for the presence of the PICC until the current command/response pair is completed or the unresponsive frame timed out.
7.5.6.1 Method 1
The PCD can send an empty l-block and wait for an l-block to be received from the PICC.
7.5.6.2 Method 2
Before the first exchange of an l-block, the PCD may send an R (NAK) block (with block number 0) and wait for an R (ACK) block (with block number 1) from the PICC (rule 12).
After the first exchange of an l-block, the PCD can either:
a) send an R (NAK) block (with the current block number) and wait for the R (ACK) block to be received from the PICC (rule 12), in which case the PCD shall not retransmit its last l-block, as indicated in the footnote to the rule 6,
or
b) switch your block number and then send an R block (NAK) and wait for the last I-block to be received from the PICC (rule 11).
7.5.7 Error detection and elimination
If errors are found, then rules for correcting them should be used, which override the rules for processing the block (see 7.5.5).
7.5.7.1 Errors Detected by PCD
The PCD should detect the following errors:
a) transmission error (frame error or EDC error) or FWT timeout.
The PCD tries to resolve the error using the following rules, in the order listed:
- application of rules for PCD (see 7.5.5.2 );
Due to the change in ISO/IEC 14443-4: 2008/Amd.1: 2012, subclause 7.5.4.2 is renumbered 7.5.5.2
- additional application of rules for PCD (see 7.5.5.2);
- using the S request (DESELECT);
- additional use of the S (DESELECT) query (as specified in 8.2);
- ignoring PICC;
b) protocol error (violation of PCB coding or violation of protocol rules).
The PCD tries to resolve the error using the following rules, in the order listed:
- using the S request (DESELECT);
- ignoring PICC.
7.5.7.2 Errors Detected by the PICC
The PICC should detect the following errors:
a) transmission error (frame error or EDC error);
b) protocol error (violation of protocol rules).
The PICC should not attempt to correct errors. The PICC shall always return to receive mode when a transmission error or protocol error occurs, and shall receive an S (DESELECT) request at any time.
NOTE - The R block (NAK) is never sent by the PICC.
8 Deactivating PICC Type A and Type B Protocol
After the transaction operations between the PCD and the PICC are completed, the PICC must be set to the HALT state.
The PICC is deactivated using the DESELECT command.
The DESELECT command is encoded as an S-block of the protocol and consists of an S (DESELECT) request block sent by the PCD and an S (DESELECT) response sent as an acknowledgment to the PICC.
8.1 Waiting time for deactivation frame
The deactivation frame timeout defines the maximum time for the PICC to start sending an S (DESELECT) response frame after the end of the S (DESELECT) request frame received from the PCD. The deactivation frame timeout value is 65536/fc (~ 4.8 ms).
NOTE - The minimum time between frames in any direction is specified in ISO/IEC 14443-3.
8.2 Error detection and elimination
If the PCD sent an S (DESELECT) request and received an S (DESELECT) response, this means that the PICC has been successfully set to the HALT state and the CID assigned to it is reset.
If the PCD does not receive an S (DESELECT) response, it may repeat the deactivation sequence.
9 Enabling bit rates and framing options in PROTOCOL state
S (PARAMETERS) blocks must be used to negotiate baud rates and communication parameters when the PICC is in PROTOCOL state.
The information field must contain tags and values in accordance with tables 4 and 5 and figures 23 and 24.
The following rules should be applied to match these parameters:
- The PCD shall send an S (PARAMETERS) block to request parameters;
- if the PICC supports S (PARAMETERS) blocks, then it shall respond with an S (PARAMETERS) block containing values for all supported parameters. If the PICC does not support S (PARAMETERS) blocks, then it must remain in a mute state.
After the PICC sends its response and specifies its parameters, the PCD can activate one baud rate for each direction of communication according to the following rules:
- The PCD must send an S (PARAMETERS) block to activate the selected communication parameters;
- The PICC must confirm the activated parameters with the S (PARAMETERS) block and then activate the agreed parameters;
- The PCD must activate the negotiated parameters.
NOTE 1 The S (PARAMETERS) block is defined in 7.5.1 of this standard.
Table 4 - S (PARAMETERS) Tag Definition
NOTE 2 Length field according to the full BER-TLV range (see ISO/IEC 7816-4: 2005).
NOTE 3 - Only matching items should be sent. You can send an empty parent that does not have any child objects (for example, 'A0 00'), or you can send an empty S (PARAMETERS) block (that is, even without the sent parent).
An example of a bit rate activation sequence with the following parameters:
- fc/8, transfer from PCD to PICC and
- fc/2, transfer from PICC to PCD;
with a PICC pointing to:
- Support for baud rates fc/128, fc/16 and fc/8 for transfer from PCD to PICC;
- Support for baud rates fc/128, fc/16 and fc/2 for transmission from PICC to PCD;
- lack of options for frame synchronization.
Appendix A (informative)
Multi-activation example
Table A.1 shows an example of multi-activation for three PICCs.
Table A.1 - Multi-activation
NOTE - The number n in ACTIVE 
denotes CID.
Appendix B (informative)
Protocol scripts
This appendix provides scripts for error-free operation as well as error handling. These scripts can be used to generate test cases for compliance tests.
B.1 Designation
Block numbering in a script always starts with the current PCD block number for a specific PICC. The scripts start after the PICC activation sequence, and therefore the current block number starts at 0 for PCD and 1 for PICC.
B.2 Error-free operation
B.2.1 Exchange of I-boxes
Scenario 1 - Exchange of I-boxes
B.2.2 Request timeout extension
Scenario 2 - Extending Wait Time
B.2.3 DESELECT
Scenario 3 - DESELECT
B.2.4 Clutch
Scenario 4 - PCD Uses Clutch
Scenario 5 - PICC uses concatenation
B.2.5 Checking for the presence of a PICC
Scenario 6 - Checking for PICC Using Method 1
Scenario 7 - Checking for the presence of a PICC using method 2 (before exchanging the first I-block)
ISO/IEC 14443-3: 2008 contains a typo in the table for scenario 7.
Scenario 8 - Checking for the presence of a PICC using method 2, a (after exchanging the first I-block)
Scenario 9 - Checking for the presence of a PICC using method 2, b (after exchanging the first I-block)
B.2.6 Exchange of additional parameters
Amd.1.1 Script
B.3 Error handling
B.3.1 Exchange of I-boxes
Scenario 10 - Running a Protocol
Scenario 11 - Exchange of l-blocks
Scenario 12 - Exchange of l-blocks
Scenario 13 - Exchange of l-blocks
B.3.2 Request timeout extension
Scenario 14 - Request a Timeout Extension
Scenario 15 - Request a Timeout Extension
Scenario 16 - Request a Timeout Extension
Scenario 17 - Request a Timeout Extension
Scenario 18 - Request a Timeout Extension
B.3.3 DESELECT
Scenario 19 - DESELECT
B.3.4 Clutch
Scenario 20 - PCD Uses Clutch
Scenario 21 - PCD Uses Clutch
Scenario 22 - PCD Uses Clutch
Scenario 23 - PICC is using chaining
Scenario 24 - PICC is using chaining
Amd.1.2 Script
Appendix C (informative)
Brief description of blocks and frame coding.
This annex provides a brief description of the various blocks and the encoding of the frame sent by the PCD. The block type relative to the frame is indicated by the first byte.
Definitions given in ISO/IEC 14443-3:
Definitions given in this standard:
Table C.1 describes the first byte of the specified blocks and the frame coding.
Table C.1 - Blocks and frame coding
Appendix YES (reference)
Information on the compliance of the reference international standards with the national standards.
Table YES.1
Bibliography
[1] ISO/IEC 7810, Identification cards - Physical characteristics
[2] ISO/IEC 7816-5, Identification cards - Integrated circuit cards - Part 5: Registration of application providers
[3] ISO/IEC 10536-1, Identification cards - Contactless integrated circuit (s) cards - Close-coupled cards - Part 1: Physical characteristics
[4] ISO/IEC 10536-2, Identification cards - Contactless integrated circuit (s) cards - Part 2: Dimensions and location of coupling areas
[5] ISO/IEC 10536-3, Identification cards - Contactless integrated circuit (s) cards - Part 3: Electronic signals and reset procedures
[6] ISO/IEC 15693 (all parts), Identification cards - Contactless integrated circuit cards - Vicinity cards
[7] ISO/IEC 18092, Information technology - Telecommunications and information exchange between systems - Near Field Communication - Interface and Protocol (NFCIP-1)
[8] ISO/IEC 21481, Information technology - Telecommunications and information exchange between systems - Near Field Communication Interface and Protocol-2 (NFCIP-2)
UDC 336.77: 002: 006.354
OKS 35.240.15
E46
OKP 40 8470
Identification cards. Contactless integrated circuit cards. Proximity cards. Transmission protocol.
Foreword
1. PREPARED by the Federal State Unitary Enterprise "Research Institute of Standardization and Certification in Mechanical Engineering" (VNIINMASH) and the Technical Committee for Standardization TC 22 "Information Technologies" on the basis of its own authentic standard specified in paragraph 4
2. INTRODUCED by the Technical Committee for Standardization TC 22 "Information Technologies".
3. APPROVED AND PUT INTO EFFECT by the Order of the Federal Agency for Technical Regulation and Metrology.
4. This standard is identical to the international standard ISO/IEC 14443-4:2008 * "Identification cards. Contactless integrated circuit cards. Close-range cards. Part 4. Transmission protocol (ISO/IEC 14443-4: 2008" Identification cards - Contactless integrated circuit cards - Proximity cards - Part 4: Transmission protocol "), including changes A1: 2012 and A2: 2012.
* Access to international and foreign documents mentioned in the text can be obtained by contacting the User Support Service. - Note from the manufacturer of the database.
Changes to the specified international standard, adopted after its official publication, were introduced into the text of this standard and are highlighted by a double vertical line located in the margins from the corresponding text, and the designation and year of adoption of the change are shown in brackets after the corresponding text.
When applying this standard, it is recommended to use, instead of the reference international standards, the corresponding national standards, information about which is given in the additional appendix YES.
5. INTRODUCED FOR THE FIRST TIME
6. Certain provisions of the International Standard referred to in clause 4 may be the subject of patent rights. The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) are not responsible for the identification of such patent rights.
The rules for the application of this standard are established in GOST R 1.0-2012 (section 8). Information on changes to this standard is published in the annual (as of January 1 of the current year) information index "National Standards", and the official text of changes and amendments is published in the monthly information index "National Standards". In case of revision (replacement) or cancellation of this standard, the corresponding notice will be published in the next issue of the information index "National Standards". Relevant information, notice and texts are also posted in the public information system - on the official website of the Federal Agency for Technical Regulation and Metrology on the Internet
Introduction
ISO/IEC 14443 is one of a series of standards describing the parameters of ISO/IEC 7810 ID cards and their use in information exchange.
A protocol in accordance with this standard is capable of transferring an ISO/IEC 7816-4 application protocol data unit. Thus, the application protocol data block can be converted in accordance with ISO/IEC 7816-4, and the selection of the application can be in accordance with ISO/IEC 7816-5.
This International Standard is intended to enable proximity cards to operate in the presence of contactless cards compliant with ISO/IEC 10536 and ISO/IEC 15693 and near field communication (NFC) devices compliant with ISO/IEC 18092 and ISO/IEC 21481.
NFC - Near Field Communication.
The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) draw attention to the statement that compliance with this standard may result in the use of a patent.
ISO and IEC take no position on the existence, validity and scope of this patent right.
The holders of this patent right have assured ISO and IEC that they are ready to negotiate with applicants from around the world for a license on reasonable and non-discriminatory terms, including time limits. This statement by patent holders is registered with ISO and IEC. Information can be obtained from:
| US Patent US5359323 | FRANCE TELECOM |
| Center National Des | |
| 38-40 rue de Leclerc | |
| 92794 Issy-les-Moulineaux | |
| Cedex 9 | |
| France | |
| MOTOROLA | |
| Motorola ESG | |
| 207 route de Ferney | |
| P About Box 15 | |
| 1218 Grand-Saconnex | |
| Geneva | |
| Switzerland | |
| JP 2129209, JP 2561051, JP 2981517 | OMRON |
| Intellectual Property Department | |
| Contactless Responding Unit | Law & Intellectual Property HQ |
| 20, Igadera Shimokaiinji | |
| Nagaokakyo city | |
| Kyoto 617-8510 | |
| Japan | |
| Patent EP 0 492 569 B1 | ON-TRACK INNOVATIONS |
| ZHR Industrial Zone | |
| A system and method for the non-contact | P About Box 32 |
| transmission of data | Rosh-Pina 12000 |
| Israel |
The following companies may have a patent relating to this standard but have not provided details of the patents or agreed to grant licenses:
| US 4 650 981 | WAYNE S FOLETTA |
| CA 95129, USA | |
| 4760 Castlewood Drive | |
| San Jose, California CA 9512 | |
| USA | |
| US Patent No. 4, 661, 691 | JOHN W HALPERN |
| C/O Vincent M DeLuca | |
| Rothwell, Figg, Ernst & Kurz, p.c. | |
| 555 Thirteenth Street, NW | |
| Suite 701 East Tower | |
| Washington, DC 20004 | |
| WO 89 05549 A | MAGELLAN CORPORATION |
| 8717 Research Drive | |
| Irvine | |
| CA 92618 | |
| USA |
Attention is drawn to the fact that certain elements of this standard may be the subject of patent rights in addition to those identified above. ISO and IEC are not responsible for identifying some or all of these rights.
ISO/IEC 14443-4 was prepared by Subcommittee No. 17, Cards and Identity, of the ISO/IEC Joint Technical Committee No. 1, Information Technology (ISO/IEC JTC 1/SC 17).
1 Area of use
This standard defines a block half-duplex protocol, describing the specific requests of non-contact equipment, as well as the sequence of activation and deactivation of the protocol.
This International Standard is intended to be used in conjunction with other parts of ISO/IEC 14443 and is applicable to Type A and Type B cards or close-range objects.
2 Normative references
This standard uses references to the following International Standards *. For dated references, only the edition cited should be used; for undated references, the latest edition of the referenced document should be used, including any amendments:
* The table of conformity of national standards to international ones, see the link. - Note from the manufacturer of the database.
ISO/IEC 7816-3 Identification cards. Integrated circuit cards. Part 3. Cards with contacts. Electrical interface and transmission protocols (ISO/IEC 7816-3, Identification cards - Integrated circuit cards - Part 3: Cards with contacts - Electrical interface and transmission protocols)
ISO/IEC 7816-4 Identification cards. Integrated circuit cards. Part 4. Organization, security and commands for interchange (ISO/IEC 7816-4, Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange)
ISO/IEC 14443-2 Identification cards. Integrated circuit cards are contactless. Close range cards. Part 2. Radio frequency power and signal interface (ISO/IEC 14443-2, Identification cards - Contactless integrated circuit cards - Proximity cards - Part 2: Radio frequency power and signal interface)
ISO/IEC 14443-3 Identification cards. Integrated circuit cards are contactless. Close range cards. Part 3. Initialization and anticollision (ISO/IEC 14443-3, Identification cards - Contactless integrated circuit cards - Proximity cards - Part 3: Initialization and anticollision)
3 Terms and definitions
The following terms are used in this standard with the corresponding definitions:
3.1 bit durationone elementary time unit (etu), calculated by the following formula:
1 etu = 128/(D fc).
With the initial value of the divisor D equal to 1, the initial etu takes on the value:
1 etu = 128/fc,
where fc is the carrier frequency in accordance with ISO/IEC 14443-2.
3.2 block: A special type of frame that contains a valid protocol data format.
NOTE - A valid protocol data format contains I-boxes, R-boxes, or S-boxes.
3.3 invalid block: A frame type that contains an invalid protocol format.
NOTE - If no frame has been received after the timeout has elapsed, then the block is not considered invalid.
3.4 frame: A sequence of bits in accordance with ISO/IEC 14443-3
NOTE - A Type A PICC uses a standard frame defined for Type A, and a Type B PICC uses a frame defined for Type B.[/FONT]
4 Symbols and abbreviations
Code:
ACK - positive ACKnowledgement;
ATS - Answer To Select;
ATQA - Answer to Request, type A (Answer To reQuest);
ATQB - Answer to Request, type B (Answer To reQuest);
CID - card identifier (Card IDentifier);
CRC - Cyclic Redundancy Check (see ISO/IEC 14443-3 for each PICC type) (Cyclic Redundancy Check);
CRC1 - most significant byte of CRC (from b16 to b9);
CRC2 - least significant byte of CRC (b8 to b1);
D - divisor;
DR - receive a divider (from PCD to PICC) (Divisor Receive);
DRI - Divisor Receive (from PCD to PICC), an integer (Divisor Receive Integer);
DS - send a divider (from PICC to PCD) (Divisor Send);
DSI - send a divisor (from PICC to PCD), an integer (Divisor Send Integer);
EDC - Error Detection Code;
etu - elementary time unit
fc - carrier frequency;
FSC - Frame Size for proximity Card;
FSCI - Frame Size for proximity Card Integer;
FSD - Frame Size for proximity coupling Device;
FSDI - frame size for proximity coupling Device Integer;
FWI - frame waiting time, integer (Frame Waiting time Integer);
FWT - Frame Waiting Time;
FWT TEMP - intermediate frame waiting time (temporary Frame Waiting Time);
HLTA - HALT command, type A;
l-block - Information block
INF - information field (INformation Field);
MAX - index for determining the maximum value;
MIN - index for determining the minimum value;
NAD - node address (Node ADdress);
NAK - negative confirmation (Negative AcKnowledgement);
OSI - Open Systems Interconnection;
PCB - Protocol Control Byte;
PCD - Proximity Coupling Device
PICC - proximity card or object;
PPS - Protocol and Parameter Selection;
PPSS - Protocol and Parameter Selection Start
PPS0 - selection of the protocol and parameters when the parameter is equal to 0 (Protocol and Parameter Selection parameter 0);
PPS1 - selection of the protocol and parameters when the parameter is equal to 1 (Protocol and Parameter Selection parameter 1);
R-block - Receive ready block;
R (ACK) - R-block containing a positive acknowledge;
R (NAK) - R-block containing a negative acknowledge;
RATS - Request for Answer To Select
REQA - REQuest command, type A;
RFU - Reserved for future ISO/IEC use;
S-block - Supervisory block
SAK - Select AcKnowledge;
SFGI - Start-up Frame Guard time Integer;
SFGT - Start-up Frame Guard Time;
WUPA - Wake-UP command, type A;
WTX - Waiting Time eXtension;
WTXM - Waiting Time eXtension Multiplier;
(xxxxx) b - data bit representation;
'XY' is a hexadecimal number system (XY is a base 16 number).5 Protocol activation in PICC type A
The following activation sequence should be applied:
- PICC activation sequence in accordance with ISO/IEC 14443-3 (query, anti-collision cycle and selection);
- The SAK byte must be checked to determine if the PICC complies with the requirements of this standard. The SAK byte is defined in ISO/IEC 14443-3;
- The PICC can be set to the HALT state using the HALT command in accordance with ISO/IEC 14443-3 if, for example, the PCD does not use a protocol conforming to the requirements of this standard.
NOTE:
- In this case, the PCD cannot continue the activation sequence;
- If the PICC complies with the requirements of this standard, then the PCD may then send the RATS command after receiving the SAK;
- The PICC sends its ATS as a response to the RATS. The PICC shall only respond to RATS if RATS is received immediately after selection;
- If the PICC supports any changeable parameters in the ATS, then the PPS request can be used by the PCD as the next command after receiving the ATS to change the parameters.
- The PICC shall send the PPS response as a response to the PPS request.
PICC does not need to implement PPS if it does not support mutable parameters in the ATS.
The PCD activation sequence for Type A PICCs.
5.1 Request for Answer to Choice
This subclause defines a RATS with all fields.
The parameter byte consists of two parts:
- The most significant nibble from b8 to b5 is called FSDI, it encodes FSD, which defines the maximum frame size that the PCD can receive. FSD coding is shown in Table 1;
- A PCD setting FSDI = 'D' - 'F' does not meet the requirements of this standard. Unless RFU values 'D' - 'F' are assigned by ISO/IEC, a PICC accepting FSDI = 'D' - 'F' shall interpret these values as FSDI = 'C' (FSD = 4096 bytes) ...
NOTE - This is an additional recommendation for PCD compatibility with future PICCs when ISO/IEC defines behavior for RFU values 'D' - 'F';
- The least significant nibble from b4 to b1 is called the CID, it defines the logical number of the addressed PICC in the range from 0 to 14. The value 15 is the RFU. The CID is specified by the PCD and must be unique for all PICCs that are ACTIVE at the same time. The CID is set when the PICC is active. The PICC shall use the CID as its logical identifier, which is contained in the first correctly received RATS;
- A PCD setting CID = 15 does not meet the requirements of this standard. For PICC behavior see 5.6.1.2, p.
Table 1 - Convert FSDI to FSD
| FSDI | '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' | 'BUT' | 'IN' | 'FROM | 'D'-'F' |
| FSD (bytes) | 16 | 24 | 32 | 40 | 48 | 64 | 96 | 128 | 256 | 512 | 1024 | 2048 | 4096 | RFU |
5.2 Answer to choice
This subclause defines the ATS with all of its valid fields (see Figure 4).
If one of the defined fields is missing from the ATS sent by the PICC, then the default values for that field shall be used.
5.2.1 Byte structure
A byte of length TL is followed by a variable number of additional bytes in the following order:
- byte of T0 format,
- interface bytes TA (1), TB (1), TC (1) and
- history bytes from T1 to Tk.
5.2.2 Byte length
The TL length byte is mandatory. It indicates the length of the transmitted ATS, including itself. The two CRC bytes are not included in the TL. The maximum ATS size must not exceed the specified FSD, so the maximum TL value must not exceed FSD-2.
5.2.3 Format Byte
The T0 format byte is optional and is present only when the length is greater than 1. The ATS may contain the following additional bytes when T0 is present.
T0 consists of three parts:
- the most significant bit of b8 must be set to 0. Value 1 is RFU;
- bits from b7 to b5 contain Y (1), indicating the presence of subsequent bytes of the TC (1), TB (1) and TA (1) interface;
- The least significant nibble from b4 to b1 is called FSCI, it encodes FSC, which defines the maximum frame size received by the PICC. The default value for FSCI is 2, which gives an FSC of 32 bytes. FSC coding is similar to FSD coding (see table 1);
- A PCD setting FSDI = 'D' - 'F' does not meet the requirements of this standard. Unless RFU values 'D' - 'F' are assigned by ISO/IEC, a PCD assuming FSDI = 'D' - 'F' shall interpret these values as FSDI = 'C' (FSD = 4096 bytes) ...
NOTE This is an additional recommendation for PICC compatibility with future PCDs when ISO/IEC defines behavior for RFU values 'D' - 'F'.
5.2.4 TA interface byte (1)
The TA interface byte (1) consists of four parts:
- the most significant bit b8 encodes the ability to handle different dividers for each direction. If this bit is set to 1, then the PICC is unable to handle different dividers for each direction;
- Bits b7 to b5 encode the possible PICC baud rates for the PICC to PCD direction, called DS. The default should be (000) b;
- bit b4 must be set to (0) b, and other values - RFU;
- Bits b3 to b1 encode the possible PICC bit rates for the PCD to PICC direction, called DR. The default should be (000) b.
The choice of a specific divider D for each direction can be done by PCD using PPS.
A PICC setting b4 = 1 is not compliant with this standard. The received TA (1) value with b4 = 1 should be interpreted by the PCD device as (b8 to b1) = (00000000) b (at a speed in both directions only ~ 106 kbps).
5.2.5 TV interface byte (1)
The TV interface byte (1) conveys information for determining the frame waiting time and triggering the delimiting time interval.
The TV interface byte (1) consists of two parts:
- the most significant nibble from b8 to b5 is called FWI, it encodes FWT (see 7.2);
- The least significant nibble from b4 to b1 is called SFGI, it encodes the value of the multiplier used to determine the SFGT. The SFGT defines a specific border interval required by the PICC before it is ready to receive the next frame after the ATS is sent. SFGI is encoded in the range 0 to 14. The value 15 is RFU. A value of 0 indicates that no SFGT is needed, and values in the range 1 through 14 are used to calculate the SFGT using the formula below. The default value for SFGI is 0.
SFGT is calculated using the following formula:
SFGT = (256 16/fc ) 2SFGI.
SEGT MIN is the minimum frame delay time in accordance with ISO/IEC 14443-3.
SFGT DEFAULY is the minimum frame delay time in accordance with ISO/IEC 14443-3.
SFGT MAX = (256 16/fc ) 2 (~ 4949 ms).
A PICC setting SFGI = 15 is not compliant with this standard. Until RFU value 15 is assigned by ISO/IEC, a PCD receiving SFGI = 15 shall interpret it as SFGI = 0.
A PICC setting FWI = 15 is not compliant with this standard. Until RFU value 15 is assigned by ISO/IEC, a PCD receiving FWI = 15 shall interpret it as FWI = 4.
5.2.6 TC interface byte (1)
The TC interface byte (1) sets the protocol parameters.
The specific byte of the TC interface (1) consists of two parts:
- the most significant bits from b8 to b3 shall be (000000) b, and the other values are RFU;
- Bits b2 and b1 determine which additional fields in the prologue field the PICC supports. The PCD can skip fields that are supported by the PICC, but a field that is not supported by the PICC will never be transmitted by the PCD. The default should be (10) b. It indicates that the CID is supported and the NAD is not supported;
- A PICC setting (b8 to b3) <> (000000) b does not meet the requirements of this standard. The PCD shall ignore (b8 to b3) and the interpretation of (b2, b1) or any other fields in the whole frame shall not change.
5.2.7 History Bytes
The history bytes T1 to Tk are optional and define general information. The maximum length of the ATS provides the maximum number of history bytes possible. ISO/IEC 7816-4 defines the content of the history bytes.
5.3 Request for selection of protocol and parameters
The PPS request contains a start byte followed by two parameter bytes.
5.3.1 Start Byte
PPSS consists of two parts:
- the most significant nibble from b8 to b5 shall be set to (1101) b, it defines the PPS;
- The least significant nibble from b4 to b1 is called CID, it defines the logical number of the PICC to be addressed.
5.3.2 Parameter 0
PPS0 indicates the presence of an additional byte PPS1 (see Figure 11).
A PCD stating (b4 to b1) <> (0001) b and/or (b8 to b6) <> (000) b does not meet the requirements of this standard.
A PICC accepting (b4 to b1) <> (0001) b and/or (b8 to b6) <> (000) b shall apply the rules given in 5.6.2.2, b).
5.3.3 Parameter 1
PPS1 consists of three parts:
- the most significant nibble from b8 to b5 shall be (0000) b, and the other values are RFU;
- bits b4 and b3 are called DSI, they encode the selected integer divider from PICC to PCD;
- bits b2 and b1 are called DRI, they encode the selected integer divider from PCD to PICC;
- A PCD stating (b8 to b5) <> (0000) b does not meet the requirements of this standard. A PICC receiving (b8 to b5) <> (0000) b shall apply the rules given in 5.6.2.2, b).
DS and DR are defined in 5.2.4.
D coding is shown in Table 2.
Table 2- Convert DRI, DSI to D
| DRI, DSI | (00) b | (01) b | (10) b | (11) b |
| D | 1 | 2 | 4 | 8 |
5.4 Response to selection of protocol and parameters
The PPS response acknowledges the received PPS request (see Figure 13) and contains only the start byte (see 5.3.1).
The PICC starts using the new baud rates as soon as it sends the PPS response. A PCD that changes baud rates does not comply with this standard if the PPS response is missing or invalid, or if the PPSS value returned by the PICC does not match the PPSS value sent by the PCD.
5.5 Activation frame waiting time
The wake-up frame timeout defines the maximum time for the PICC to send its response frame after the end of the frame received from the PCD, and has a value of 65536/fc (~ 4833 ?s).
NOTE - The minimum time between frames in any direction is specified in ISO/IEC 14443-3.
5.6 Error detection and correction
5.6.1 RATS and ATS handling
5.6.1.1 Rules for PCD
If the PCD has already sent RATS and received a valid ATS, then it should proceed.
In any other case, the PCD may retransmit RATS before using the deactivation sequence defined in clause 8. If the deactivation sequence is not followed, it may use the HLTA command in accordance with ISO/IEC 14443-3.
5.6.1.2 Rules for PICC
If PICC was selected with the last command and
a) has received a valid RATS, then the PICC must:
- return your ATS and
- transfer to inactive state RATS (stop responding to received RATS);
b) has received a valid block (HLTA), then the PICC must:
- process the command and enter the HALT state;
c) received an invalid block or RATS with CID = 15, then PICC:
- shall not respond, but shall enter the IDLE or HALT state as specified in Figure 7 () "PICC Type A state diagram" in ISO/IEC 14443-3.
There is a typo in ISO/IEC 14443-4.
5.6.2 PPS request and PPS response processing
5.6.2.1 Rules for PCD
If the PCD has already sent a PPS request and received a valid PPS response, then it should activate the selected options and continue. Otherwise, the PCD can retransmit the PPS request and continue.
5.6.2.2 Rules for PICC
If the PICC received RATS, sent its ATS and
a) has received a valid PPS request, then the PICC shall:
- send a PPS response;
- deactivate the PPS request (stop responding to received PPS requests) and
- activate the received parameters;
b) received an invalid block, then the PICC shall:
- deactivate the PPS request (stop responding to received PPS requests) and
- stay in receive mode;
c) has received a valid block other than the PPS request, then the PICC shall:
- deactivate the PPS request (stop responding to received PPS requests) and
- continue work.
5.6.3 Handling CIDs During Activation
If the PCD has already sent a RATS containing a CID = n not equal to 0, and:
a) has received an ATS indicating that the CID is supported, then the PCD:
- must send blocks containing CID = n to this PICC and
- shall not use CID = n for further RATS while this PICC is in the ACTIVE state;
b) has received an ATS indicating that the CID is not supported, then the PCD:
- must send blocks that do not contain a CID to this PICC, and
- shall not activate another PICC while that PICC is in the ACTIVE state.
If the PCD has already sent a RATS containing a CID of 0 and:
a) has received an ATS indicating that the CID is supported, then the PCD:
- can send blocks containing a CID equal to 0 for this PICC and
- shall not activate another PICC while this PICC is in the ACTIVE state;
b) received an ATS indicating that the CID is not supported, then the PCD:
- must send blocks that do not contain a CID to this PICC, and
- shall not activate another PICC while that PICC is in the ACTIVE state.
6 Protocol activation in PICC type B
The activation sequence for Type B PICCs is described in ISO/IEC 14443-3.
7 Block half-duplex protocol
The block half-duplex protocol is used for special requests in the contactless card environment and uses the frame format defined in ISO/IEC 14443-3.
The relevant frame format elements are:
- block format;
- maximum frame waiting time;
- power indication and
- protocol operations.
This protocol is designed in accordance with the layering principle of the OSI Reference Model, with particular attention to minimizing interactions across borders. Four levels are defined:
- the physical layer where bytes are exchanged in accordance with ISO/IEC 14443-3;
- the link layer at which bytes are exchanged as defined in this clause;
- session layer combined with data link layer while minimizing interaction;
- the application layer at which the command processing takes place. It includes at least one block or block chaining in any direction.
NOTE Application selection can be made in accordance with ISO/IEC 7816-4. Implicit application selection is not recommended for PICCs with multiple applications.
A special mechanism is provided to introduce additional protocol functions that may be defined in this standard or in other standards using this standard as a basis.
7.1 Block format
The block format (see Figure 14) consists of a prologue field (required), an information field (optional), and an epilogue field (required).
NOTE Items in square brackets indicate optional requirements.
7.1.1 Prologue field
The prologue field is required and can be 1, 2, or 3 bytes: PCB is required and CID and NAD are optional.
7.1.1.1 Protocol Control Byte Field
PCB is used to transmit information required to control data transmission. The protocol defines three main types of blocks:
- l-block used to transfer information at the application level;
- R-block used to transmit positive or negative acknowledgments. The R block never contains INF. Acknowledgment refers to the last received block;
- S-box used to exchange control information between PCD and PICC. S (PARAMETERS) block support is optional for PCD and PICC. Three different types of S-boxes are defined:
1) "timeout extension" containing INF of 1 byte;
2) "DESELECT", not containing INF,
3) "PARAMETERS" containing INF of length n -bytes, when n is 0.
NOTE - FSD and FSC must be large enough to contain the expected number of S (PARAMETERS) blocks.
PCB coding depends on its type and is defined in Figures 15-17. PCB coding not specified in this standard is either used in other parts of ISO/IEC 14443 or is an RFU. The coding of I-boxes, R-boxes and S-boxes is shown in Figures 15, 16 and 17.
A PICC or PCD setting b6 <> (0) b in an I-box, b2 <> (1) b in an R-box, b1 <> (0) b in an S-box are not compliant with this standard.
7.1.1.2 Card ID field
The CID field is used to identify a specific PICC and has three parts:
- The two most significant bits b7 and b8 are used to record the power level readings received by the PICC from the PCD. These two bits must be set to (00) b for PCD to PICC transmission. Power level indication is covered in 7.4;
- bits b6 and b5 are used to convey additional information that is not defined and should be set to (00) b, other values are RFU;
- A PICC or PCD setting (b6, b5) <> (00) b does not meet the requirements of this standard. Bits (b6, b5) <> (00) b should be treated as a protocol error;
- bits b4 to b1 encode the CID.
CID coding is given in 5.1 for type A and in ISO/IEC 14443-3 for type B.
CID processing:
A PICC that does not support CID must:
- ignore any block containing a CID;
A PICC that supports CID must:
- respond to blocks containing a CID using your CID,
- ignore blocks containing other CIDs, and
- in the case of CID = 0, respond also to blocks that do not contain a CID, without using their own CID.
7.1.1.3 Field with host addresses
NADs in the prologue field are reserved for creating and referring to various logical connections. The NAD application shall comply with ISO/IEC 7816-3 when the b8 and b4 bits are 0. All other values are RFU.
A PICC or PCD setting b8 <> 0 and/or b4 <> 0 is not compliant with this standard. Bits b8 <> 0 and/or b4 <> 0 should be considered a protocol error.
When using NAD, the following definitions apply:
a) the NAD field shall only be used for I-boxes;
b) if the PCD uses NAD, the PICC shall also use NAD;
c) during clutching, NADs shall only be transmitted in the first block of the chain;
d) The PCD should not use NAD to refer to different PICCs (CID should be used to refer to different PICCs);
e) if the PICC does not support NAD, then it shall ignore any block containing NAD.
7.1.2 Information field
INF is optional. If present, INF transfers either application data in l-boxes or non-application data and state information in S-boxes. The length of the information field is calculated by counting the number of bytes in the whole block minus the length of the prologue and epilogue fields.
7.1.3 Epilogue field
The epilogue field contains the EDC of the transmitted block, which is the CRC according to ISO/IEC 14443-3.
7.2 Frame timeout
The FWT is the time that the PICC must start its reply frame after the end of the PCD frame (see Figure 19).
NOTE 1 The minimum time between frames in any direction is defined according to ISO/IEC 14443-3.
FWT is calculated using the following formula:
FWT = (256 16/fc ) 2 ,
where the FWI value ranges from 0 to 14 and the 15 value is RFU.
The default value for FWI is 4 (which gives an FWT value of ~ 4.8ms) for the following two cases:
- for type A, if we neglect TB (1);
- for S (PARAMETERS) and S (DESELECT) blocks.
The FWT value shall be used by the PCD to detect a protocol error or unresponsive PICC. The PCD is eligible for retransmission if the start of a response from the PICC is not received within FWT.
The FWI for Type B is located in the ATQB as defined in ISO/IEC 14443-3. The FWI for Type A is located in the ATS (see 5.2.5)
The PICC shall not set the FWI to an RFU value of 15. Until RFU value 15 is defined by ISO/IEC. A PCD receiving an FWI = 15 should interpret it as FWI = 4.
NOTE 2 This is an additional recommendation for PCD compatibility with future PICCs when ISO/IEC defines an RFU value of 15.
7.3 Extending Frame Timeout
When the PICC takes longer than specified by the FWT to process a received block, it shall use an S (WTX) request to extend the latency. The S (WTX) request contains a 1 byte INF, which consists of two parts (see Figure 20):
- the two most significant bits b7 and b8 encode the power level indication (see 7.4);
- A PCD not setting (b8, b7) = (00) b does not meet the requirements of this standard. The PICC shall interpret (b8, b7) <> (00) b as a protocol error;
- the least significant bits from b6 to b1 encode WTXM. WTXM is encoded in the range 1 to 59. The values 0 and 60 to 63 are RFU;
- A PICC setting WTXM = 0 or WTXM = 60-63 does not meet the requirements of this standard. When receiving WTXM = 0 or WTXM = 60-63, the PCD should interpret it as a protocol error.
The PCD shall confirm by sending an S (WTX) response containing also 1 byte INF, which is in two parts (see Figure 21) and contains the same WTXM as received in the request:
- the most significant bits b8 and b7 should be set to (00) b, and the rest of the values - RFU;
- the least significant bits b6 to b1 encode the confirmed WTXM value used to determine the intermediate FWT.
The corresponding intermediate FWT values are calculated using the following formula:
FWT TEMP = FWT WTXM.
FWT TEMP requested by the PICC begins after the PCD has sent an S (WTX) response.
FWT MAX should be used when the formula results in a value greater than FWT TEMP.
ISO/IEC 14443-4: 2008 contains a typographical error.
The intermediate FWT only applies until the PCD receives the next block.
7.4 Power level display
The power level indication is encoded as shown in Table 3 using two bits placed in the CID field (if present) and in the S-box sent by the PICC (see 7.1.1.2 and 7.3).
Table 3 - Coding of power level indication[/FONT]
| (00) b | PICC does not support power level indication |
| (01) b | Insufficient power for full functionality |
| (10) b | Powerful enough for full functionality |
| (11) b | More than enough power for full functionality |
7.5 Protocol mode
After the activation sequence, the PICC must wait for the block, since only the PCD is allowed to send. After sending the block, the PCD must switch to receive mode and wait for the block before switching back to transmit mode. The PICC can only transmit blocks in response to received blocks (it is insensitive to time delays). Upon response, the PICC should return to receive mode.
The PCD shall not initiate a new command/response pair if the current command/response pair has not completed or if the unresponsive frame timed out.
7.5.1 S Blocks (PARAMETERS)
After the activation sequence, the PCD may send at any time the first S (PARAMETERS) block with or without INF to check if the PICC supports S (PARAMETERS) blocks.
This first S (PARAMETERS) PCD block and the PICC response (if the PICC supports S (PARAMETERS) blocks) may contain information indicating support for different types of application protocols and/or other communication parameters.
The content of INF S (PARAMETERS) is defined in the relevant part of ISO/IEC 14443 and must comply with the ISO/IEC 7816-4: 2005 BER-TLV encoding rules for a context sensitive class.
7.5.2 Multi-activation
After the amendment A1: 2012, the subsections were renumbered.
The multi-activation function allows the PCD to keep multiple PICCs in ACTIVE state at the same time. This allows multiple PICCs to be switched at once without the need for additional time to deactivate the PICC and activate another PICC.
An example of multi-activation is given in Appendix A.
NOTE - The PCD needs to process separate block numbers for each activated PICC.
7.5.3 Clutch
The chaining function allows a PCD or PICC to transmit information that does not fit into a single block according to FSC or FSD by dividing it into multiple blocks. Each of these blocks must have a length less than or equal to FSC or FSD, respectively.
The concatenation of bits in the PCB of the l-block controls the concatenation of the blocks. Each I-box with a concatenated bit set must be acknowledged with an R-box.
A concatenation function using a 16-byte string, transmitted in three blocks.
Legend:
I (1) - l-block with bit concatenation and block number x;
I (0) - l-block with unset bit clutch (last block of the chain) and block number x;
R (ACK) - An R block that indicates a positive acknowledgment.
NOTE - The example does not use the additional NAD and CID fields.
7.5.4 Block numbering rules
7.5.4.1 Rules for PCD
Rule A. The PCD Block Number shall be assigned an initial value of 0 for each activated PICC.
Rule B. If an I-block or an R (ACK) block is received with a block number equal to the current block number, then the PCD shall toggle the current block number for that PICC before sending an additional block.
7.5.4.2 Rules for PICC
Rule C. The PICC block number must be set to an initial value of 1 when activated.
Rule D. If an I-block is received, then the PICC shall switch its block number before sending the block.
NOTE 1 If the received block number does not comply with the PCD rules, then the PICC may not switch its internal block number and not send a reply block.
Rule E. If an R (ACK) block is received with a block number not equal to the current PICC block number, then the PICC shall switch its block number before sending the block.
NOTE 2 If an R block (NAK) is received, then the block number is not toggled.
7.5.5 Block processing rules
7.5.5.1 General rules
Rule 1. The first block must be sent by the PCD.
Rule 2. If an I-block indicating concatenation is received, it shall be acknowledged with an R (ACK) block.
Rule 3. S-boxes are used only in pairs. A request block S (...) shall always be followed by a response block S (...) (see 7.3 and 8).
7.5.5.2 Rules for PCD
Rule 4. If an invalid block is received or an FWT timed out, then an R (NAK) block shall be sent (except in the case of PICC concatenation or S (DESELECT) or S (PARAMETERS)).
Rule 5. In the case of PICC concatenation, if an invalid block is received or an FWT timed out, an R (ACK) block shall be sent.
Note 1 - An R (ACK) block can only be sent by the PCD in the case of PICC concatenation, since the PICC response when receiving an R (ACK) block is otherwise undefined.
Rule 6. If an R (ACK) block is received and if its number is not equal to the number of the current PCD block, then the last l-block shall be retransmitted.
NOTE 2 - The last l-block retransmission without PCD clutch is not required. The PCD can determine the presence of a PICC by sending R (NAK) blocks at any time out of the concatenation (including before sending any l-block) and receiving R (ACK) blocks from the PICC, if present.
Rule 7. If an R (ACK) block is received and if its number is equal to the current PCD number, then concatenation must continue.
Rule 8. If the S (DESELECT)/S (PARAMETERS) request does not have an error-free response S (DESELECT)/S (PARAMETERS), then the S (DESELECT)/S (PARAMETERS) request may be retransmitted.
If the answer S (DESELECT) is not received after the request S (DESELECT), then the card can be ignored.
7.5.5.3 Rules for PICC
Rule 9. The PICC MAY send an S (WTX) block instead of an I-block or an R (ACK) block.
Rule 10. If an I-box is received that does not indicate concatenation, then it must be acknowledged with an I-box.
NOTE - If the received l-block is empty, then the mandatory sent l-block can be empty or contain any functional information (eg error code).
Rule 11. If an R (ACK) or R (NAK) block is received and if its number is equal to the current PICC block number, then the last block shall be retransmitted.
Rule 12. If an R (NAK) block is received and if its number is not equal to the current PICC block number, then an R (ACK) block shall be sent.
Rule 13. If an R (ACK) block is received and if its number is not equal to the current PICC block number and the PICC is in concatenation, then concatenation must continue.
7.5.6 Checking for the presence of a PICC
The following methods can be used to check for the presence of a PICC at any time, including before any I-box exchange.
The PCD does not check for the presence of the PICC until the current command/response pair is completed or the unresponsive frame timed out.
7.5.6.1 Method 1
The PCD can send an empty l-block and wait for an l-block to be received from the PICC.
7.5.6.2 Method 2
Before the first exchange of an l-block, the PCD may send an R (NAK) block (with block number 0) and wait for an R (ACK) block (with block number 1) from the PICC (rule 12).
After the first exchange of an l-block, the PCD can either:
a) send an R (NAK) block (with the current block number) and wait for the R (ACK) block to be received from the PICC (rule 12), in which case the PCD shall not retransmit its last l-block, as indicated in the footnote to the rule 6,
or
b) switch your block number and then send an R block (NAK) and wait for the last I-block to be received from the PICC (rule 11).
7.5.7 Error detection and elimination
If errors are found, then rules for correcting them should be used, which override the rules for processing the block (see 7.5.5).
7.5.7.1 Errors Detected by PCD
The PCD should detect the following errors:
a) transmission error (frame error or EDC error) or FWT timeout.
The PCD tries to resolve the error using the following rules, in the order listed:
- application of rules for PCD (see 7.5.5.2 );
Due to the change in ISO/IEC 14443-4: 2008/Amd.1: 2012, subclause 7.5.4.2 is renumbered 7.5.5.2
- additional application of rules for PCD (see 7.5.5.2);
- using the S request (DESELECT);
- additional use of the S (DESELECT) query (as specified in 8.2);
- ignoring PICC;
b) protocol error (violation of PCB coding or violation of protocol rules).
The PCD tries to resolve the error using the following rules, in the order listed:
- using the S request (DESELECT);
- ignoring PICC.
7.5.7.2 Errors Detected by the PICC
The PICC should detect the following errors:
a) transmission error (frame error or EDC error);
b) protocol error (violation of protocol rules).
The PICC should not attempt to correct errors. The PICC shall always return to receive mode when a transmission error or protocol error occurs, and shall receive an S (DESELECT) request at any time.
NOTE - The R block (NAK) is never sent by the PICC.
8 Deactivating PICC Type A and Type B Protocol
After the transaction operations between the PCD and the PICC are completed, the PICC must be set to the HALT state.
The PICC is deactivated using the DESELECT command.
The DESELECT command is encoded as an S-block of the protocol and consists of an S (DESELECT) request block sent by the PCD and an S (DESELECT) response sent as an acknowledgment to the PICC.
8.1 Waiting time for deactivation frame
The deactivation frame timeout defines the maximum time for the PICC to start sending an S (DESELECT) response frame after the end of the S (DESELECT) request frame received from the PCD. The deactivation frame timeout value is 65536/fc (~ 4.8 ms).
NOTE - The minimum time between frames in any direction is specified in ISO/IEC 14443-3.
8.2 Error detection and elimination
If the PCD sent an S (DESELECT) request and received an S (DESELECT) response, this means that the PICC has been successfully set to the HALT state and the CID assigned to it is reset.
If the PCD does not receive an S (DESELECT) response, it may repeat the deactivation sequence.
9 Enabling bit rates and framing options in PROTOCOL state
S (PARAMETERS) blocks must be used to negotiate baud rates and communication parameters when the PICC is in PROTOCOL state.
The information field must contain tags and values in accordance with tables 4 and 5 and figures 23 and 24.
The following rules should be applied to match these parameters:
- The PCD shall send an S (PARAMETERS) block to request parameters;
- if the PICC supports S (PARAMETERS) blocks, then it shall respond with an S (PARAMETERS) block containing values for all supported parameters. If the PICC does not support S (PARAMETERS) blocks, then it must remain in a mute state.
After the PICC sends its response and specifies its parameters, the PCD can activate one baud rate for each direction of communication according to the following rules:
- The PCD must send an S (PARAMETERS) block to activate the selected communication parameters;
- The PICC must confirm the activated parameters with the S (PARAMETERS) block and then activate the agreed parameters;
- The PCD must activate the negotiated parameters.
NOTE 1 The S (PARAMETERS) block is defined in 7.5.1 of this standard.
Table 4 - S (PARAMETERS) Tag Definition
| Tag (hexadecimal) | Description | Length | Value |
| 'A0' | S block information (PARAMETERS) | L | Tag function identifier (see table 5) |
NOTE 3 - Only matching items should be sent. You can send an empty parent that does not have any child objects (for example, 'A0 00'), or you can send an empty S (PARAMETERS) block (that is, even without the sent parent).
An example of a bit rate activation sequence with the following parameters:
- fc/8, transfer from PCD to PICC and
- fc/2, transfer from PICC to PCD;
with a PICC pointing to:
- Support for baud rates fc/128, fc/16 and fc/8 for transfer from PCD to PICC;
- Support for baud rates fc/128, fc/16 and fc/2 for transmission from PICC to PCD;
- lack of options for frame synchronization.
Appendix A (informative)
Multi-activation example
Table A.1 shows an example of multi-activation for three PICCs.
Table A.1 - Multi-activation
| PCD action | condition | ||
| PICC 1 | PICC 2 | PICC 3 | |
| Enabling a field | |||
| Three PICCs hit the field | IDLE | IDLE | IDLE |
| PICC activation with CID = 1 | ACTIVE (1) | IDLE | IDLE |
| Any data transfer with CID = 1 | ACTIVE (1) | IDLE | IDLE |
| PICC activation with CID = 2 | ACTIVE (1) | ACTIVE (2) | IDLE |
| Any data transmission with CID = 1, 2 | ACTIVE (1) | ACTIVE (2) | IDLE |
| PICC activation with CID = 3 | ACTIVE (1) | ACTIVE (2) | ACTIVE (3) |
| Any data transmission with CID = 1, 2, 3 | ACTIVE (1) | ACTIVE (2) | ACTIVE (3) |
| S (DESELECT) command with CID = 3 | ACTIVE (1) | ACTIVE (2) | HALT |
| S (DESELECT) command with CID = 2 | ACTIVE (1) | HALT | HALT |
| S (DESELECT) command with CID = 1 | HALT | HALT | HALT |
denotes CID.Appendix B (informative)
Protocol scripts
This appendix provides scripts for error-free operation as well as error handling. These scripts can be used to generate test cases for compliance tests.
B.1 Designation
| Any block | ===> | rightly received |
| Any block | = => | mistakenly accepted |
| Any block | = => | Received nothing (FWT timeout) |
| Demarcation line | ===== | Ending the lowest-level protocol |
| I (1) | l-block with chained bit set and block number x | |
| I (0) | l-block with unset clutch bit (last block of the chain) and block number x | |
| R (ACK) | R-box indicating positive acknowledgment | |
| R (NAK) | R-box indicating negative acknowledgment | |
| S (...) | S-block |
B.2 Error-free operation
B.2.1 Exchange of I-boxes
Scenario 1 - Exchange of I-boxes
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | I (0) | Rule 10 |
| 3. | I (0) | ===> | 1 | Regulation D | |
| 4. | Rule B | 0 | <=== | I (0) | Rule 10 |
B.2.2 Request timeout extension
Scenario 2 - Extending Wait Time
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | <=== | Request S (WTX) | Rule 9 | ||
| 3. | Rule 3 | Answer S (WTX) | ===> | ||
| 4. | Rule B | 1 | <=== | l (0) | Rule 10 |
| 5. | I (0) | ===> | 1 | Regulation D | |
| 6. | Rule B | 0 | <=== | I (0) | Rule 10 |
B.2.3 DESELECT
Scenario 3 - DESELECT
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | l (0) | Rule 10 |
| 3. | Request S (DESELEST) | ===> | |||
| 4. | <=== | Answer S (DESELEST) | Rule 3 |
B.2.4 Clutch
Scenario 4 - PCD Uses Clutch
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | I (1) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | R (ACK) | Rule 2 |
| 3. | Rule 7 | I (0) | ===> | 1 | Regulation D |
| 4. | Rule B | 0 | <=== | I (0) | Rule 10 |
| 5. | I (0) | ===> | 0 | Regulation D | |
| 6. | Rule B | 1 | <=== | I (0) | Rule 10 |
Scenario 5 - PICC uses concatenation
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | I (1) | Rule 10 |
| 3. | Rule 2 | R (ACK) | ===> | 1 | Rule E |
| 4. | Rule B | 0 | <=== | I (0) | Regulation 13 |
| 5. | l (0) | ===> | 0 | Regulation D | |
| 6. | Rule B | 1 | <=== | l (0) | Rule 10 |
B.2.5 Checking for the presence of a PICC
Scenario 6 - Checking for PICC Using Method 1
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 and Method 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | l (0) | Rule 10, note |
Scenario 7 - Checking for the presence of a PICC using method 2 (before exchanging the first I-block)
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 and Method 2 | R (NAK) | ===> | Regulation E, note | |
| 2. | No change | <=== | R (ACK) | Regulation 12 | |
| 3. | Rule 6, note and method 2 | R (NAK) | ===> | Regulation E, note | |
| 4. | Rule 6, note | No change | <=== | R (ACK) | Regulation 12 |
| 5. | l (0) | ===> | 0 | Regulation D | |
| 6. | Rule B | 1 | <=== | l (0) | Rule 10 |
Scenario 8 - Checking for the presence of a PICC using method 2, a (after exchanging the first I-block)
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | l (0) | Rule 10 |
| 3. | Method 2, a | R (NAK) | Regulation E, note | ||
| 4. | Rule 6, note | No change | <=== | R (ACK) | Regulation 12 |
| 5. | I (0) | ===> | 1 | Regulation D | |
| 6. | Rule B | 0 | <=== | I (0) | Rule 10 |
Scenario 9 - Checking for the presence of a PICC using method 2, b (after exchanging the first I-block)
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | I (0) | Rule 10 |
| 3. | Method 2b | 0 | R (NAK) | ||
| 4. | Rule B | 1 | <=== | I (0) | Rule 11 |
| 5. | I (0) | ===> | 1 | Regulation D | |
| 6. | Rule B | 0 | <=== | I (0) | Rule 10 |
B.2.6 Exchange of additional parameters
Amd.1.1 Script
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | l (0) | Rule 10 |
| 3. | S request (PARAMETERS) | ===> | |||
| 4. | <=== | Answer S (PARAMETERS) | Rule 3 | ||
| 5. | I (0) | ===> | 1 | Regulation D | |
| 6. | Rule B | 0 | <=== | I (0) | Rule 10 |
B.3 Error handling
B.3.1 Exchange of I-boxes
Scenario 10 - Running a Protocol
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | = => | ||
| 2. | Time-out | <= = | - | ||
| 3. | Rule 4 | R (NAK) | ===> | ||
| 4. | No change | <=== | R (ACK) | Regulation 12 | |
| 5. | Rule 6 | l (0) | ===> | 0 | Regulation D |
| 6. | Rule B | 1 | <=== | I (0) | Rule 10 |
| 7. | I (0) | ===> | 1 | Regulation D | |
| 8. | Rule B | 0 | <=== | I (0) | Rule 10 |
Scenario 11 - Exchange of l-blocks
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | I (0) | Rule 10 |
| 3. | I (0) | = => | |||
| 4. | Time-out | <= = | - | ||
| 5. | Rule 4 | R (NAK) | ===> | ||
| 6. | No change | <=== | R (ACK) | Regulation 12 | |
| 7. | Rule 6 | I (0) | ===> | 1 | Regulation D |
| 8. | Rule B | 0 | <=== | I (0) | Rule 10 |
| 9 | I (0) | ===> | 0 | Regulation D | |
| 10. | Rule B | 1 | <=== | I (0) | Rule 10 |
Scenario 12 - Exchange of l-blocks
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | <= = | l (0) | Rule 10 | ||
| 3. | Rule 4 | R (NAK) | ===> | ||
| 4. | Rule B | 1 | <=== | l (0) | Rule 11 |
| 5. | I (0) | ===> | 1 | Regulation D | |
| 6. | Rule B | 0 | <=== | I (0) | Rule 10 |
Scenario 13 - Exchange of l-blocks
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | <= = | l (0) | Rule 10 | ||
| 3. | Rule 4 | R (NAK) | = => | ||
| 4. | Time-out | <== | - | ||
| 5. | Rule 4 | R (NAK) | ===> | ||
| 6. | Rule B | 1 | <=== | l (0) | Rule 11 |
| 7. | I (0) | ===> | Regulation D | ||
| 8. | Rule B | 0 | <=== | I (0) | Rule 10 |
B.3.2 Request timeout extension
Scenario 14 - Request a Timeout Extension
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | <= = | Request S (WTX) | Rule 9 | ||
| 3. | Rule 4 | R (NAK) | ===> | ||
| 4. | <=== | Request S (WTX) | Rule 11 | ||
| 5. | Rule 3 | Answer S (WTX) | ===> | ||
| 6. | Rule B | 1 | <=== | l (0) | Rule 10 |
| 7. | l (0) | ===> | 1 | Regulation D | |
| 8. | Rule B | 0 | <=== | l (0) | Rule 10 |
Scenario 15 - Request a Timeout Extension
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | <= = | Request S (WTX) | Rule 9 | ||
| 3. | Rule 4 | R (NAK) | = => | ||
| 4. | time-out | <= = | - | ||
| 5. | Rule 4 | R (NAK) | ===> | ||
| 6. | <=== | Request S (WTX) | Rule 11 | ||
| 7. | Rule 3 | Answer S (WTX) | ===> | ||
| 8. | Rule B | 1 | <=== | I (0) | Rule 10 |
| 9. | I (0) | ===> | 1 | Regulation D | |
| 10. | Rule B | 0 | <=== | I (0) | Rule 10 |
Scenario 16 - Request a Timeout Extension
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | <=== | Request S (WTX) | Rule 9 | ||
| 3. | Rule 3 | Answer S (WTX) | = => | ||
| 4. | Time-out | <= = | - | ||
| 5. | Rule 4 | R (NAK) | ===> | ||
| 6. | <=== | Request S (WTX) | Rule 11 | ||
| 7. | Rule 3 | Answer S (WTX) | ===> | ||
| 8. | Rule B | 1 | <=== | l (0) | Rule 10 |
| 9. | I (0) | ===> | 1 | Regulation D | |
| 10. | Rule B | 0 | <=== | I (0) | Rule 10 |
Scenario 17 - Request a Timeout Extension
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | <=== | Request S (WTX) | Rule 9 | ||
| 3. | Rule 3 | Answer S (WTX) | ===> | ||
| 4. | <= = | l (0) | Rule 10 | ||
| 5. | Rule 4 | R (NAK) | ===> | ||
| 6. | Rule B | 1 | <=== | l (0) | Rule 11 |
| 7. | I (0) | ===> | 1 | Regulation D | |
| 8. | Rule B | 0 | <=== | 1 (0) | Rule 10 |
Scenario 18 - Request a Timeout Extension
| Note | Block N (0) | PCD | PICC | Block N (1) | Note | |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D | |
| 2. | <=== | Request S (WTX) | Rule 9 | |||
| 3. | Rule 3 | Answer S (WTX) | ===> | |||
| 4. | <= = | l (0) | Rule 10 | |||
| 5. | Rule 4 | R (NAK) | = => | |||
| 6. | Time-out | <= = | - | |||
| 7. | Rule 4 | R (NAK) | ===> | |||
| 8. | Rule B | 1 | <=== | l (0) | Rule 11 | |
| 9. | I (0) | ===> | 1 | Regulation D | ||
| 10. | Rule B | 0 | <=== | I (0) | Rule 10 |
B.3.3 DESELECT
Scenario 19 - DESELECT
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | <=== | l (0) | Rule 10 | |
| 3. | Request S (DESELECT) | = => | |||
| 4. | Time-out | <= = | - | ||
| 5. | Rule 8 | Request S (DESELECT) | ===> | ||
| 6. | <=== | Answer S (DESELECT) | Rule 3 |
B.3.4 Clutch
Scenario 20 - PCD Uses Clutch
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | I (1) | ===> | 0 | Regulation D |
| 2. | <= = | R (ACK) | Rule 2 | ||
| 3. | Rule 4 | R (NAK) | ===> | ||
| 4. | Rule B | 1 | <=== | R (ACK) | Rule 11 |
| 5. | Rule 7 | I (1) | ===> | 1 | Regulation D |
| 6. | Rule B | 0 | <=== | R (ACK) | Rule 2 |
| 7. | Rule 7 | l (0) | ===> | 0 | Regulation D |
| 8. | Rule B | 1 | <=== | l (0) | Rule 10 |
| 9. | I (0) | ===> | 1 | Regulation D | |
| 10. | Rule B | 0 | <=== | l (0) | Rule 10 |
Scenario 21 - PCD Uses Clutch
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | I (1) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | R (ACK) | Rule 2 |
| 3. | Rule 7 | I (1) | = => | ||
| 4. | Time-out | <= = | - | ||
| 5. | Rule 4 | R (NAK) | ===> | ||
| 6. | No change | <=== | R (ACK) | Regulation 12 | |
| 7. | Rule 6 | l (1) | ===> | 1 | Regulation D |
| 8. | Rule B | 0 | <=== | R (ACK) | Rule 2 |
| 9. | Rule 7 | l (0) | ===> | 0 | Regulation D |
| 10. | Rule B | 1 | <=== | l (0) | Rule 10 |
| 11. | I (0) | ===> | 1 | Regulation D | |
| 12. | Rule B | 0 | <=== | I (0) | Rule 10 |
Scenario 22 - PCD Uses Clutch
| Note | Block N (0) | PCD | PICC | Block N (1) | Note | |
| 1. | Rule 1 | I (1) | ===> | 0 | Regulation D | |
| 2. | <= = | R (ACK) | Rule 2 | |||
| 3. | Rule 4 | R (NAK) | = => | |||
| 4. | Time-out | <= = | - | |||
| 5. | Rule 4 | R (NAK) | ===> | |||
| 6. | Rule B | 1 | <=== | R (ACK) | Rule 11 | |
| 7. | Rule 7 | l (1) | ===> | 1 | Regulation D | |
| 8. | Rule B | 0 | <=== | R (ACK) | Rule 2 | |
| 9. | Rule 7 | l (0) | ===> | 0 | Regulation D | |
| 10. | Rule B | 1 | <=== | I (0) | Rule 10 | |
| 11. | I (0) | ===> | Regulation D | |||
| 12. | Rule B | <=== | I (0) | Rule 10 |
Scenario 23 - PICC is using chaining
| Note | Block N (0) | PCD | PICC | Block N (1) | Note | |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D | |
| 2. | Rule B | 1 | <=== | l (1) | Rule 10 | |
| 3. | Rule 2 | R (ACK) | = => | |||
| 4. | Time-out | <= = | - | |||
| 5. | Rule 5 | R (ACK) | ===> | 1 | Rule E | |
| 6. | Rule B | 0 | <=== | I (1) | Regulation 13 | |
| 7. | Rule 2 | R (ACK) | ===> | 0 | Rule E | |
| 8. | Rule B | 1 | <=== | I (0) | Regulation 13 | |
| 9. | l (0) | ===> | 1 | Regulation D | ||
| 10. | Rule B | 0 | <=== | l (0) | Rule 10 |
Scenario 24 - PICC is using chaining
| Note | Block N (0) | PCD | PICC | Block N (1) | Note |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D |
| 2. | Rule B | 1 | <=== | l (1) | Rule 10 |
| 3. | Rule 2 | R (ACK) | ===> | 1 | Rule E |
| 4. | <= = | I (1) | Regulation 13 | ||
| 5. | Rule 5 | R (ACK) | ===> | No change | |
| 6. | Rule B | 0 | <=== | I (1) | Rule 11 |
| 7. | Rule 2 | R (ACK) | ===> | 0 | Rule E |
| 8. | Rule B | 1 | <=== | l (0) | Regulation 13 |
| 9. | I (0) | ===> | 1 | Regulation D | |
| 10. | Rule B | 0 | <=== | I (0) | Rule 10 |
Amd.1.2 Script
| Note | Block N (0) | PCD | PICC | Block N (1) | Note | |
| 1. | Rule 1 | l (0) | ===> | 0 | Regulation D | |
| 2. | Rule B | 1 | <=== | I (0) | Rule 10 | |
| 3. | S request (PARAMETERS) | = => | ||||
| 4. | Time-out | <= = | ||||
| 5. | Rule 8 | S request (PARAMETERS) | ===> | |||
| 6. | <=== | Answer S (PARAMETERS) | Rule 3 | |||
| 7. | I (0) | ===> | 1 | Regulation D | ||
| 8. | Rule B | 0 | <=== | I (0) | Rule 10 |
Appendix C (informative)
Brief description of blocks and frame coding.
This annex provides a brief description of the various blocks and the encoding of the frame sent by the PCD. The block type relative to the frame is indicated by the first byte.
Definitions given in ISO/IEC 14443-3:
| REQA | (0100110) b (7 bit) |
| WUPA | (1010010) b (7 bit) |
| REQB/WUPB | (00000101) b |
| Slot-MARKER (type B only) | (xxxx0101) b |
| SELECT (type A only) | (1001xxxx) b |
| ATTRIB (type B only) | (00011101) b |
| HLTA | (01010000) b |
| HLTB | (01010000) b |
Definitions given in this standard:
| RATS | (11100000) b |
| PPS | (1101xxxx) b |
| l-block | (00xxxxxx) b (not (00xxx101) b) |
| R-block | (10xxxxxx) b (not (1001xxxx) b) |
| S-block | (11xxxxxx) b (not (1110xxxx) b and not (1101xxxx) b) |
Table C.1 describes the first byte of the specified blocks and the frame coding.
Table C.1 - Blocks and frame coding
| Bit | I-block PCB | R-block PCB | DESELECT PCB S-box | WTX | PARA-METERS | REQB/WUPB | Slot-MARKER | SELECT | ATTRIB | HLTA | HLTB | RATS | PPS |
| b8 | 0 | 1 | 1 | 0 | X | 1 | 0 | 0 | 0 | 1 | 1 | ||
| b7 | 0 | 0 | 1 | 0 | X | 0 | 0 | 1 | 1 | 1 | 1 | ||
| b6 | 0 (1-RFU) | 1 | 0 | 1 | 1 | 0 | X | 0 | 0 | 0 | 0 | 1 | 0 |
| b5 | Stsep-Lenie | ACK/NAK | 0 | 1 | 1 | 0 | X | 1 | 1 | 1 | 1 | 0 | 1 |
| b4 | CID | CID | CID | 0 | 0 | X | 1 | 0 | 0 | 0 | X | ||
| b3 | NAD | 0 (not NAD) | 0 (not NAD) | 1 | 1 | X | 1 | 0 | 0 | 0 | X | ||
| b2 | 1 | 1 (0 - RFU) | 1 | 0 | 0 | 0 | X | 0 | 0 | 0 | 0 | X | |
| b1 | Block number | Block number | 0 (1 - RFU) | 1 | 1 | X | 1 | 0 | 0 | 0 | X |
Appendix YES (reference)
Information on the compliance of the reference international standards with the national standards.
Table YES.1
| Designation of the referenced International Standard | Degree of compliance | Designation and title of the relevant national standard |
| ISO/IEC 7816-3 | IDT | GOST R ISO/IEC 7816-3-2013 "Identification cards. Cards on integrated circuits. Part 3. Cards with contacts. Electrical interface and transmission protocols" |
| ISO/IEC 7816-4 | IDT | GOST R ISO/IEC 7816-4-2013 "Identification cards. Cards on integrated circuits. Part 4. Organization, protection and commands for exchange" |
| ISO/IEC 14443-2 | IDT | GOST R ISO/IEC 14443-2-2014 "Identification cards. Cards on integrated circuits contactless. Short-range cards. Part 2. Radio-frequency energy and signal interface" |
| ISO/IEC 14443-3 | IDT | GOST R ISO/IEC 14443-3-2014 "Identification cards. Contactless cards on integrated circuits. Close-range cards. Part 3. Initialization and anticollision" |
| Note - In this table, the following convention is used for the degree of conformity of standards: IDT - identical standards. |
Bibliography
[1] ISO/IEC 7810, Identification cards - Physical characteristics
[2] ISO/IEC 7816-5, Identification cards - Integrated circuit cards - Part 5: Registration of application providers
[3] ISO/IEC 10536-1, Identification cards - Contactless integrated circuit (s) cards - Close-coupled cards - Part 1: Physical characteristics
[4] ISO/IEC 10536-2, Identification cards - Contactless integrated circuit (s) cards - Part 2: Dimensions and location of coupling areas
[5] ISO/IEC 10536-3, Identification cards - Contactless integrated circuit (s) cards - Part 3: Electronic signals and reset procedures
[6] ISO/IEC 15693 (all parts), Identification cards - Contactless integrated circuit cards - Vicinity cards
[7] ISO/IEC 18092, Information technology - Telecommunications and information exchange between systems - Near Field Communication - Interface and Protocol (NFCIP-1)
[8] ISO/IEC 21481, Information technology - Telecommunications and information exchange between systems - Near Field Communication Interface and Protocol-2 (NFCIP-2)
UDC 336.77: 002: 006.354
OKS 35.240.15
E46
OKP 40 8470
