ISO/IEC 14443-4:2016

INTERNATIONAL ISO/IEC
STANDARD 14443-4
Third edition
2016-06-01
Identification cards — Contactless
integrated circuit cards — Proximity
cards —
Part 4:
Transmission protocol
Cartes d’identification — Cartes à circuit intégré sans contact —
Cartes de proximité —
Partie 4: Protocole de transmission
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope .1
2 Normative references .1
3 Terms and definitions .1
4 Symbols and abbreviated terms . 2
5 Protocol activation of PICC Type A .4
5.1 Request for answer to select . 5
5.2 Answer to select . 7
5.2.1 Structure of the bytes. 7
5.2.2 Length byte . 7
5.2.3 Format byte . 7
5.2.4 Interface byte TA(1) . 8
5.2.5 Interface byte TB(1) . 9
5.2.6 Interface byte TC(1) . 9
5.2.7 Historical bytes . . .10
5.3 Protocol and parameter selection request .10
5.3.1 Start byte .10
5.3.2 Parameter 0 .11
5.3.3 Parameter 1 .11
5.4 Protocol and parameter selection response .11
5.5 Activation frame waiting time .12
5.6 Error detection and recovery .12
5.6.1 Handling of RATS and ATS .12
5.6.2 Handling of PPS request and PPS response .12
5.6.3 Handling of the CID during activation .13
6 Protocol activation of PICC Type B .13
7 Half-duplex block transmission protocol .13
7.1 Block format .14
7.1.1 Length field .15
7.1.2 Prologue field .15
7.1.3 Information field .18
7.1.4 Epilogue field .18
7.2 Frame waiting time .18
7.3 Frame waiting time extension .19
7.4 Power level indication .20
7.5 Protocol operation .20
7.5.1 S(PARAMETERS) blocks .20
7.5.2 Multi-Activation .21
7.5.3 Chaining .21
7.5.4 Block numbering rules .22
7.5.5 Block handling rules .23
7.5.6 PICC presence check .24
7.5.7 Error detection and recovery .24
8 Protocol deactivation of PICC Type A and Type B.25
8.1 Deactivation frame waiting time .25
8.2 Error detection and recovery .25
9 Activation of bit rates and framing options in the PROTOCOL state .25
10 Frame with error correction .29
Annex A (informative) Multi-Activation example .36
© ISO/IEC 2016 – All rights reserved iii

Annex B (informative) Protocol scenarios .37
Annex C (informative) Block and frame coding overview .46
Annex D (normative) Bit rates of 3fc/4, fc, 3fc/2 and 2fc from PCD to PICC .48
Annex E (informative) CRC_32 encoding.50
Annex F (informative) Frame with error correction .52
Annex G (informative) Framing options .54
Bibliography .55
iv © ISO/IEC 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 17, Cards and
personal identification.
This third edition cancels and replaces the second edition (ISO/IEC 14443-4:2008), which has been
technically revised. It also incorporates the Amendments ISO/IEC 14443-4:2008/Amd 1:2012,
ISO/IEC 14443-4:2008/Amd 2:2012, ISO/IEC 14443-4:2008/Amd 3:2013 and ISO/IEC 14443-
4:2008/Amd 4:2014.
ISO/IEC 14443 consists of the following parts, under the general title Identification cards — Contactless
integrated circuit cards — Proximity cards:
— Part 1: Physical characteristics
— Part 2: Radio frequency power and signal interface
— Part 3: Initialization and anticollision
— Part 4: Transmission protocol
© ISO/IEC 2016 – All rights reserved v

Introduction
ISO/IEC 14443 is one of a series of International Standards describing the parameters for identification
cards as defined in ISO/IEC 7810, and the use of such cards for international interchange.
The protocol, as defined in this part of ISO/IEC 14443, is capable of transferring the application protocol
data units as defined in ISO/IEC 7816-4. Thus, application protocol data units may be mapped as defined
in ISO/IEC 7816-4 and application selection may be used as defined ISO/IEC 7816-5.
ISO/IEC 14443 is intended to allow operation of proximity cards in the presence of other contactless
cards conforming to ISO/IEC 10536 and ISO/IEC 15693 and near field communication (NFC) devices
conforming to ISO/IEC 18092 and ISO/IEC 21481.
The International Organization for Standardization (ISO) and International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this International
Standards may involve the use of patents.
vi © ISO/IEC 2016 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 14443-4:2016(E)
Identification cards — Contactless integrated circuit cards
— Proximity cards —
Part 4:
Transmission protocol
1 Scope
This part of ISO/IEC 14443 specifies a half-duplex block transmission protocol featuring the special
needs of a contactless environment and defines the activation and deactivation sequence of the protocol.
This part of ISO/IEC 14443 is intended to be used in conjunction with other parts of ISO/IEC 14443 and
is applicable to proximity cards or objects of Type A and Type B.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
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 14443-2, Identification cards — Contactless integrated circuit cards — Proximity cards —
Part 2: Radio frequency power and signal interface
ISO/IEC 14443-3, Identification cards — Contactless integrated circuit cards — Proximity cards —
Part 3: Initialization and anticollision
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
bit duration
one elementary time unit (etu), calculated by the following formula:
1 etu=×128/ Dfc
()
the initial value of the divisor D is 1, giving the initial etu as follows:
1 etu=128/ fc
where fc is the carrier frequency as defined in ISO/IEC 14443-2
© ISO/IEC 2016 – All rights reserved 1

3.2
block
special type of frame, which contains a valid protocol data format
Note 1 to entry: A valid protocol data format includes I-blocks, R-blocks or S-blocks.
3.3
invalid block
type of frame, which contains an invalid protocol format
Note 1 to entry: A time-out, when no frame has been received, is not interpreted as an invalid block.
3.4
frame
sequence of bits as defined in ISO/IEC 14443-3
Note 1 to entry: The PICC independent from its type may use the frame with error correction defined in Clause 10.
Alternatively, the PICC Type A can use one of the standard frames defined for Type A and the PICC Type B can use
the frame defined for Type B. This Type B frame is called standard frame, too, within this part of ISO/IEC 14443.
4 Symbols and abbreviated terms
For the purposes of this part of ISO/IEC 14443, the following symbols and abbreviated terms apply.
A Hamming control bits generation matrix (6 rows, 56 columns)
ACK positive ACKnowledgement
ATS Answer To Select
ATQA Answer To reQuest, Type A
ATQB Answer To reQuest, Type B
CID Card IDentifier
CRC Cyclic Redundancy Check, as defined for each PICC Type in ISO/IEC 14443-3
CRC1 most significant byte of CRC (b16 to b9)
CRC2 least significant byte of CRC (b8 to b1)
CRC_32 Cyclic Redundancy Check error detection code used within enhanced block
c Hamming control bit n
n
vector containing 56 data bits
d
d data bit n
n
D Divisor
DR Divisor Receive (PCD to PICC)
DRI Divisor Receive Integer (PCD to PICC)
DS Divisor Send (PICC to PCD)
DSI Divisor Send Integer (PICC to PCD)
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
FWT Frame Waiting Time
2 © ISO/IEC 2016 – All rights reserved

FWT temporary Frame Waiting Time
TEMP
H
matrix needed to calculate Hamming syndrome s (6 rows, 62 columns)
h′ element in row m and column n of matrix H′
m,n
H′ matrix needed to get matrix A (6 rows, 62 columns)
column vector of matrix H′
h′
n
HLTA HALT Command, Type A
I 6 by 6 Identity matrix
6 × 6
I-block Information block
INF INformation field
LEN two bytes LENgth field used within enhanced block
m row index
MAX index to define a MAXimum value
MIN index to define a MINimum value
n column index
NAD Node ADdress
NAK 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 Protocol and Parameter Selection parameter 0
PPS1 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 Use by ISO/IEC
6-bit vector containing Hamming syndrome
s
s′ error position code
s error position
S-block Supervisory block
SAK Select AcKnowledge
SFGI Start-up Frame Guard time Integer
SFGT Start-up Frame Guard Time
SYNC SYNChronization sequence
WUPA Wake-UP command, Type A
WTX Waiting Time eXtension
WTXM Waiting Time eXtension Multiplier
y
64-bit vector ( y′ with no padding bits)
64-bit vector containing received modified Hamming sub-block
y′
y′ received bit n in each modified Hamming sub-block
n
© ISO/IEC 2016 – All rights reserved 3

For the purposes of this part of ISO/IEC 14443, the following notations apply.
— (xxxxx)b data bit representation;
— ‘XY’ hexadecimal notation, equal to XY to the base 16.
5 Protocol activation of PICC Type A
The following activation sequence shall be applied.
— PICC activation sequence as defined in ISO/IEC 14443-3 (request, anticollision loop and select).
— The SAK byte shall be checked to get information if the PICC is compliant with ISO/IEC 14443-4. The
SAK byte is defined in ISO/IEC 14443-3.
— The PICC may be set to HALT state, using the HLTA Command as defined in ISO/IEC 14443-3, if e.g.
no ISO/IEC 14443-4 protocol is used at the PCD.
NOTE The PCD cannot continue the activation sequence in that case.
— If the PICC is compliant to ISO/IEC 14443-4, the RATS may be sent by the PCD as next command after
receiving the SAK.
— The PICC shall send its ATS as answer to the RATS. The PICC shall only answer to the RATS if the
RATS is received directly after the selection.
— If the PICC supports any changeable parameters in the ATS, a PPS request may be used by the PCD
as the next command after receiving the ATS to change parameters.
— The PICC shall send a PPS Response as answer to the PPS request.
A PICC does not need to implement the PPS, if it does not support any changeable parameters in the ATS.
The PCD activation sequence for a PICC Type A is shown in Figure 1.
4 © ISO/IEC 2016 – All rights reserved

Figure 1 — Activation of a PICC Type A by a PCD
5.1 Request for answer to select
This Clause defines the RATS with all its fields (see Figure 2).
© ISO/IEC 2016 – All rights reserved 5

Figure 2 — Request for answer to select
The parameter byte consists of two parts (see Figure 3).
— The most significant half-byte b8 to b5 is called FSDI and codes FSD. The FSD defines the maximum
size of a frame the PCD is able to receive. The coding of FSD is given in Table 1.
— A PCD setting FSDI = ‘D’–’F’ is not compliant with this part of ISO/IEC 14443. Until the RFU values
‘D’–’F’ are assigned by ISO/IEC, a PICC receiving value of FSDI = ‘D’–’F’ should interpret it as FSDI = ‘C’
(FSD = 4 096 bytes).
NOTE This PCD recommendation is added for PCD’s compatibility with future PICC’s when ISO/IEC defines
the behaviour for the RFU values of ‘D’–’F’.
— The least significant half byte b4 to b1 is named CID and it defines the logical number of the
addressed PICC in the range from 0 to 14. The value 15 is RFU. The CID is specified by the PCD and
shall be unique for all PICCs, which are in the ACTIVE state at the same time. The CID is fixed for the
time the PICC is active and the PICC shall use the CID as its logical identifier, which is contained in
the first error-free RATS received;
— A PCD setting CID = 15 is not compliant with this part of ISO/IEC 14443. For PICC behaviour see
5.6.1.2 c).
Figure 3 — Coding of RATS parameter byte
6 © ISO/IEC 2016 – All rights reserved

Table 1 — FSDI to FSD conversion
FSDI ‘0’ ‘1’ ‘2’ ‘3’ ‘4’ ‘5’ ‘6’ ‘7’ ‘8’ ‘9’ ‘A’ ‘B’ ‘C’ ‘D’-‘F’
FSD (bytes) 16 24 32 40 48 64 96 128 256 512 1 024 2 048 4 096 RFU
5.2 Answer to select
This Clause defines the ATS with all its available fields (see Figure 4).
In the case that one of the defined fields is not present in an ATS sent by a PICC, the default values for
that field shall apply.
Figure 4 — Structure of the ATS
5.2.1 Structure of the bytes
The length byte TL is followed by a variable number of optional subsequent bytes in the following order:
— format byte T0;
— interface bytes TA(1), TB(1), TC(1);
— historical bytes T1 to Tk.
5.2.2 Length byte
The length byte TL is mandatory and specifies the length of the transmitted ATS including itself. The
two CRC bytes are not included in TL. The maximum size of the ATS shall not exceed the indicated FSD.
Therefore, the maximum value of TL shall not exceed FSD-2.
5.2.3 Format byte
The format byte T0 is optional and is present as soon as the length is greater than 1. The ATS can only
contain the following optional bytes when this format byte is present.
T0 consists of three parts (see Figure 5).
— The most significant bit b8 shall be set to (0)b. The value (1)b is RFU.
© ISO/IEC 2016 – All rights reserved 7

— The bits b7 to b5 contain Y(1) indicating the presence of subsequent interface bytes TC(1), TB(1)
and TA(1).
— The least significant half byte b4 to b1 is called FSCI and codes FSC. The FSC defines the maximum
size of a frame accepted by the PICC. The default value of FSCI is 2 and leads to a FSC of 32 bytes. The
coding of FSC is equal to the coding of FSD (see Table 1).
— A PICC setting FSCI = ‘D’–’F’ is not compliant with this standard. Until the RFU values ‘D’–
’F’ are assigned by ISO/IEC, a PCD receiving value of FSCI = ‘D’–’F’ should interpret it as
FSCI = ‘C (FSC = 4 096 bytes).
NOTE This PICC recommendation is added for PICC’s compatibility with future PCDs when ISO/IEC defines
the behaviour for the RFU values ‘D’–’F’.
Figure 5 — Coding of format byte
5.2.4 Interface byte TA(1)
The interface byte TA(1) consists of four parts (see Figure 6).
— The most significant bit b8 codes the possibility to handle different divisors for each direction.
When this bit is set to 1 the PICC is unable to handle different divisors for each direction.
— The bits b7 to b5 code the bit rate capability of the PICC for the direction from PICC to PCD, called
DS. The default value shall be (000)b.
— The bit b4 shall be set to (0)b and the other value is RFU.
— The bits b3 to b1 code the bit rate capability of the PICC for the direction from PCD to PICC, called
DR. The default value shall be (000)b.
Figure 6 — Coding of interface byte TA(1)
8 © ISO/IEC 2016 – All rights reserved

The selection of a specific divisor D for each direction may be done by the PCD using PPS.
A PICC setting b4 = 1 is not compliant with this part of ISO/IEC 14443. A received value of TA(1)
with b4 = 1 should be interpreted by the PCD as (b8 to b1) = (00000000)b (only ~106 kbit/s in both
directions).
5.2.5 Interface byte TB(1)
The interface byte TB(1) conveys information to define the frame waiting time and the start-up frame
guard time.
The interface byte TB(1) consists of two parts (see Figure 7).
— The most significant half-byte b8 to b5 is called FWI and codes FWT (see 7.2).
— The least significant half byte b4 to b1 is called SFGI and codes a multiplier value used to define
the SFGT. The SFGT defines a specific guard time needed by the PICC before it is ready to receive
the next frame after it has sent the ATS. SFGI is coded in the range from 0 to 14. The value of 15 is
RFU. The value of 0 indicates no SFGT needed and the values in the range from 1 to 14 are used to
calculate the SFGT with the formula given below. The default value of SFGI is 0.
Figure 7 — Coding of interface byte TB(1)
SFGT is calculated by the following formulae:
SFGI
SFGT = (256 × 16/fc) × 2
SFGT = minimum value of the frame delay time as defined in ISO/IEC 14443-3
MIN
SFGT = minimum value of the frame delay time as defined in ISO/IEC 14443-3
DEFAULT
SFGT = (256 × 16/fc) × 2 (~4 949 ms)
MAX
A PICC setting SFGI = 15 is not compliant with this part of ISO/IEC 14443. Until the RFU value 15 is
assigned by ISO/IEC, a PCD receiving SFGI = 15 should interpret it as SFGI = 0.
A PICC setting FWI = 15 is not compliant with this part of ISO/IEC 14443. Until the RFU value 15 is
assigned by ISO/IEC, a PCD receiving FWI = 15 should interpret it as FWI = 4.
5.2.6 Interface byte TC(1)
The interface byte TC(1) specifies a parameter of the protocol.
The specific interface byte TC(1) consists of two parts (see Figure 8).
— The most significant bits b8 to b3 shall be (000000)b and all other values are RFU.
— The bits b2 and b1 define which optional fields in the prologue field a PICC does support. The PCD is
allowed to skip fields, which are supported by the PICC, but a field not supported by the PICC shall
never be transmitted by the PCD. The default value shall be (10)b indicating CID supported and NAD
not supported.
© ISO/IEC 2016 – All rights reserved 9

— A PICC setting (b8 to b3) <> (000000)b is not compliant with this part of ISO/IEC 14443. The PCD
should ignore (b8 to b3) and its interpretation of (b2,b1), or of any other field of the whole frame
shall not change.
Figure 8 — Coding of interface byte TC(1)
5.2.7 Historical bytes
The historical bytes T1 to Tk are optional and designate general information. The maximum length of
the ATS gives the maximum possible number of historical bytes. ISO/IEC 7816-4 specifies the content of
the historical bytes.
5.3 Protocol and parameter selection request
PPS request contains the start byte that is followed by two parameter bytes (see Figure 9).
Figure 9 — Protocol and parameter selection request
5.3.1 Start byte
PPSS consists of two parts (see Figure 10).
— The most significant half byte b8 to b5 shall be set to (1101)b and identifies the PPS.
— The least significant half byte b4 to b1 is named CID and it defines the logical number of the
addressed PICC.
Figure 10 — Coding of PPSS
10 © ISO/IEC 2016 – All rights reserved

5.3.2 Parameter 0
PPS0 indicates the presence of the optional byte PPS1 (see Figure 11).
A PCD setting (b4 to b1) <> (0001)b and/or setting (b8 to b6) <> (000)b is not compliant with this part
of ISO/IEC 14443. A PICC receiving (b4 to b1) <> (0001)b and/or receiving (b8 to b6) <> (000)b shall
apply 5.6.2.2 b).
Figure 11 — Coding of PPS0
5.3.3 Parameter 1
PPS1 consists of three parts (see Figure 12).
— The most significant half byte b8 to b5 shall be (0000)b and all other values are RFU.
— The bits b4 and b3 are called DSI and code the selected divisor integer from PICC to PCD.
— The bits b2 and b1 are called DRI and code the selected divisor integer from PCD to PICC.
— A PCD setting (b8 to b5) <> (0000)b is not compliant with this part of ISO/IEC 14443. A PICC receiving
(b8 to b5) <> (0000)b shall apply 5.6.2.2 b).
Figure 12 — Coding of PPS1
For the definition of DS and DR (see 5.2.4).
The coding of D is given in Table 2.
Table 2 — DRI, DSI to D conversion
DRI, DSI (00)b (01)b (10)b (11)b
D 1 2 4 8
5.4 Protocol and parameter selection response
The PPS response acknowledges the received PPS request (see Figure 13) and it contains only the start
byte (see 5.3.1).
© ISO/IEC 2016 – All rights reserved 11

The new bit rates shall become effective in the PICC immediately after it has sent the PPS response. A
PCD that changes the bit rate when the PPS response is missing or invalid or when the PPSS returned by
the PICC is not identical with the PPSS sent by the PCD is not compliant with this part of ISO/IEC 14443.
Figure 13 — Protocol and parameter selection response
5.5 Activation frame waiting time
The activation frame waiting time defines the maximum time for a PICC to start sending its response
frame after the end of a frame received from the PCD and has a value of 65 536/fc (~4 833 µs).
NOTE The minimum time between frames in any direction is defined in ISO/IEC 14443-3.
5.6 Error detection and recovery
5.6.1 Handling of RATS and ATS
5.6.1.1 PCD rules
When the PCD has sent the RATS and receives a valid ATS the PCD shall continue operation.
In any other case, the PCD may retransmit the RATS before it shall use the deactivation sequence as
defined in Clause 8. In case of failure of this deactivation sequence, it may use the HLTA command as
defined in ISO/IEC 14443-3.
5.6.1.2 PICC rules
When the PICC has been selected with the last command and
a) receives a valid RATS, the PICC
— shall send back its ATS, and
— shall disable the RATS (stop responding to received RATS);
b) receives a valid block (HLTA), the PICC
— shall process the command and shall enter HALT state;
c) receives an invalid block or RATS with CID = 15, the PICC
— shall not respond and shall enter IDLE state or HALT state as specified in ISO/IEC 14443-3:2016,
Figure 7.
5.6.2 Handling of PPS request and PPS response
5.6.2.1 PCD rules
When the PCD has sent a PPS request and received a valid PPS response, the PCD shall activate the
selected parameters and continue operation. In any other case, the PCD may retransmit a PPS request
and continue operation.
12 © ISO/IEC 2016 – All rights reserved

5.6.2.2 PICC rules
When the PICC has received a RATS, sent its ATS and
a) received a valid PPS request, the PICC
— shall send the PPS response,
— shall disable the PPS request (stop responding to received PPS requests), and
— shall activate the received parameter;
b) received an invalid block, the PICC
— shall disable the PPS request (stop responding to received PPS requests), and
— shall remain in receive mode;
c) received a valid block, except a PPS request, the PICC
— shall disable the PPS request (stop responding to received PPS requests), and
— shall continue operation.
5.6.3 Handling of the CID during activation
When the PCD has sent a RATS containing a CID = n not equal to 0 and
— received an ATS indicating CID is supported, the PCD
— shall send blocks containing CID=n to this PICC, and
— shall not use the CID=n for further RATS while this PICC is in ACTIVE state;
— received an ATS indicating CID is not supported, the PCD
— shall send blocks containing no CID to this PICC, and
— shall not activate any other PICC while this PICC is in ACTIVE state;
When the PCD has sent a RATS containing a CID equal to 0
— received an ATS indicating CID is supported, the PCD
— may send blocks containing CID equal to 0 to this PICC, and
— shall not activate any other PICC while this PICC is in ACTIVE state;
— received an ATS indicating CID is not supported, the PCD shall
— send blocks containing no CID to this PICC, and
— not activate any other PICC while this PICC is in ACTIVE state.
6 Protocol activation of PICC Type B
The activation sequence for a PICC Type B is described in ISO/IEC 14443-3.
7 Half-duplex block transmission protocol
The half-duplex block transmission protocol addresses the special needs of contactless card
environments and uses the frame format as defined in ISO/IEC 14443-3.
© ISO/IEC 2016 – All rights reserved 13

Other relevant elements of the frame format are
— block format,
— maximum frame waiting time,
— power indication, and
— protocol operation.
A mechanism is provided in order to introduce additional protocol functions that may be defined from
time to time in this part of ISO/IEC 14443 or in other standards that use this part of ISO/IEC 14443 as
their foundation.
This protocol is designed according to the principle layering of the OSI reference model, with particular
attention to the minimization of interactions across boundaries. Four layers are defined as follows:
— physical layer exchanges bytes according to ISO/IEC 14443-3;
— data link layer exchanges blocks as defined in this Clause;
— session layer combined with the data link layer for a minimum overhead;
— application layer processing commands, which involve the exchange of at least one block or chain of
blocks in either direction.
Application selection may be used as defined in ISO/IEC 7816-4. Implicit application selection is not
recommended to be used with multi-application PICCs.
7.1 Block format
The block format depends on the frame format used for its transmission.
The standard block format as specified in Figure 14 shall be used in standard frames as defined in
ISO/IEC 14443-3 and consists of the following:
— a prologue field (mandatory);
— an information field (optional);
— a two-byte epilogue field (mandatory).
The enhanced block format specified in Figure 15 shall be used in frames with error correction as
defined in Clause 10 and consists of the following:
— a length field (mandatory);
— a prologue field (mandatory);
— an information field (optional);
— a four-byte epilogue field (mandatory).
14 © ISO/IEC 2016 – All rights reserved

Figure 14 — Standard block format
NOTE 1 The items in brackets indicate optional requirements.
Figure 15 — Enhanced block format
NOTE 2 The items in brackets indicate optional requirements.
7.1.1 Length field
The two-byte length field shall contain the total number of bytes contained in the following fields:
— length field;
— prologue field;
— information field.
Least significant byte is transmitted first, then most significant byte.
7.1.2 Prologue field
The prologue field is mandatory and may be 1, 2, or 3 bytes with PCB mandatory and CID and NAD
optional.
7.1.2.1 Protocol control byte field
The PCB is used to convey the information required to control the data transmission.
The protocol defines three fundamental types of blocks.
— I-block used to convey information for use by the application layer.
— R-block used to convey positive or negative acknowledgements. An R-block never contains an INF
field. The acknowledgement relates to the last received block.
© ISO/IEC 2016 – All rights reserved 15

— S-block used to exchange control information between the PCD and the PICC. The support of the
S(PARAMETERS) block is optional for PCDs and PICCs. Three different types of S-blocks are defined.
1) “Waiting time extension” containing a 1 byte long INF field,
2) “DESELECT” containing no INF field,
3) “PARAMETERS” containing a n-byte long INF field with n ≥ 0.
FSD and FSC should be large enough to contain the expected S(PARAMETERS) blocks.
The coding of the PCB depends on its type and is defined by the following figures. PCB coding not defined
here are either used in other clauses of ISO/IEC 14443 or are RFU. The coding of I-blocks, R-blocks and
S-blocks are shown in Figures 16, 17 and 18.
A PICC or PCD setting b6 <> 0(b) of an I-block is not compliant with this part of ISO/IEC 14443. A PICC
or PCD setting b2 <> 1(b) of an R-block is not compliant with this part of ISO/IEC 14443. A PICC or PCD
setting (b1) <> (0)b of an S-block is not compliant with this part of ISO/IEC 14443.
Figure 16 — Coding of I-block PCB
Figure 17 — Coding of R-block PCB
16 © ISO/IEC 2016 – All rights reserved

Figure 18 — Coding of S-block PCB
7.1.2.2 Card identifier field
The CID field is used to identify a specific PICC and consists of three parts (see Figure 19).
— The two most significant bits b8 and b7 are used to indicate the power level indication received by a
PICC from a PCD. These two bits shall be set to (00)b for PCD to PICC communication. For a definition
of power level indication (see 7.4).
— The bits b6 and b5 are used to convey additional information, which are not defined and shall be set
to (00)b and all other values are RFU.
— A PICC or PCD setting (b6,b5) <> (00)b is not compliant with this part of ISO/IEC 14443. (b6,b5) <>
(00)b shall be treated as a protocol error.
— The bits b4 to b1 code the CID.
Figure 19 — Coding of card identifier
The coding of CID is given in 5.1 for Type A and ISO/IEC 14443-3 for Type B.
The handling of the CID by a PICC is described below:
A PICC, which does not support a CID
— shall ignore any block containing a CID.
A PICC, which does support a CID
— shall respond to blocks containing its CID by using its CID,
— shall ignore blocks containing other CIDs, and
— shall, in case its CID is 0, respond also to blocks containing no CID by using no CID.
© ISO/IEC 2016 – All rights reserved 17

7.1.2.3 Node address field
The NAD in the prologue field is reserved to build up and address different logical connections. The
usage of the NAD shall be compliant with the definition from ISO/IEC 7816-3, when the bits b8 and b4
are both set to 0. All other values are RFU.
A PICC or PCD setting b8 <> 0 and/or b4 <> 0 is not compliant with this standard. b8 <> 0 and/or b4 <>
0 shall be treated as a protocol error.
The following definitions shall apply for the usage of the NAD:
a) the NAD field shall only be used for I-blocks;
b) when the PCD uses the NAD, the PICC shall also use the NAD;
c) during chaining the NAD shall only be transmitted in the first block of chain;
d) the PCD shall never use the NAD to address different PICCs (The CID shall be used to address
different PICCs);
e) when the PICC does not support the NAD, it shall ignore any block containing the NAD.
7.1.3 Information field
The INF field is optional. When present, the INF field conveys either application data in I-blocks or non-
application data and status information in S-blocks. The length of the information field is calculated by
counting the number of bytes of the whole block minus length of prologue and epilogue field.
7.1.4 Epilogue field
The epilogue field contains the EDC of the transmitted block. A transmitted block shall be considered
correct if it is received with a valid EDC value.
The EDC of standard blocks shall be the CRC defined in ISO/IEC 14443-3. Type A PICCs shall use CRC_A
and Type B PICCs shall use CRC_B in both directions.
The EDC of enhanced blocks shall be CRC_32 as defined below.
The CRC_32 uses polynomial = ‘04C11DB7’ with initial value = ‘FFFFFFFF’ and reflected bit order
(LSB first). The final CRC value is bit-inverted before transmission and the least significant byte is
transmitted first. Refer to ISO/IEC 13239 for further details. A code sample and an example are given in
Annex E.
7.2 Frame waiting time
The FWT defines the time within which a PICC shall start its response frame after the end of a PCD
frame (see Figure 20).
Figure 20 — Frame waiting time
NOTE 1 The minimum time between frames in any direction is defined in ISO/IEC 14443-3.
18 © ISO/IEC 2016 – All rights reserved

FWT is calculated by the following formula:
FWI
FWT = 256××16/ fc 2
()
where the value of FWI has the range from 0 to 14 and the value of 15 is RFU.
The default value of FWI is 4 (which gives a FWT value of ~4,8 ms) in the following cases:
— for Type A, if TB(1) is omitted, and
— for S(PARAMETERS) and S(DESELECT) blocks.
For FWI = 0, FWT = FWT (~302 µs).
MIN
For FWI = 14, FWT = FWT (~4 949 ms).
MAX
The FWT value shall be used by the PCD to detect a protocol error or an unresponsive PICC. The PCD
obtains the right to re-transmit if the start of a response from the PICC is not received within FWT.
The FWI field for Type B is located in ATQB as defined in ISO/IEC 14443-3. The FWI field for Type A is
located in the ATS (see 5.2.5).
The PICC shall not set FWI to the RFU value of 15. Until the RFU value 15 is assigned by ISO/IEC, a PCD
receiving FWI = 15 should interpret it as FWI = 4.
NOTE 2 This C
...