ISO/IEC 15693-3:2009

Identification cards - Contactless integrated circuit cards - Vicinity cards - Part 3: Anticollision and transmission protocol

ISO/IEC 15693-3:2009 specifies: protocol and commands, other parameters required to initialize communications between a vicinity integrated circuit card and a vicinity coupling device, methods to detect and communicate with one card among several cards ("anticollision"), optional means to ease and speed up the selection of one among several cards based on application criteria.

Cartes d'identification — Cartes à circuit(s) intégré(s) sans contact — Cartes de voisinage — Partie 3: Anticollision et protocole de transmission

General Information

• Status: Withdrawn
• Publication Date: 05-Apr-2009
• Withdrawal Date: 05-Apr-2009
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: ISO/IEC JTC 1/SC 17 - Cards and security devices for personal identification
• Drafting Committee: ISO/IEC JTC 1/SC 17/WG 8 - Integrated circuit cards without contacts
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 23-Apr-2019
• Completion Date: 30-Oct-2025

Relations

• Amended By: ISO/IEC 15693-3:2009/Amd 4:2017 - Identification cards - Contactless integrated circuit cards - Vicinity cards - Part 3: Anticollision and transmission protocol - Amendment 4: Security framework
• Effective Date: 21-Aug-2021
• Amended By: ISO/IEC 15693-3:2009/Amd 2:2015 - Identification cards - Contactless integrated circuit cards - Vicinity cards - Part 3: Anticollision and transmission protocol - Amendment 2: Clarification of use of Data Elements
• Effective Date: 14-Aug-2021
• Amended By: ISO/IEC 15693-3:2009/Amd 3:2015 - Identification cards - Contactless integrated circuit cards - Vicinity cards - Part 3: Anticollision and transmission protocol - Amendment 3: Extended VICC memory organisation
• Effective Date: 23-Apr-2020
• Revised: ISO/IEC 15693-3:2019 - Cards and security devices for personal identification - Contactless vicinity objects - Part 3: Anticollision and transmission protocol
• Effective Date: 22-Apr-2017
• Revises: ISO/IEC 15693-3:2001 - Identification cards - Contactless integrated circuit(s) cards - Vicinity cards - Part 3: Anticollision and transmission protocol
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 15693-3
Second edition
2009-04-15
Identification cards — Contactless
integrated circuit cards — Vicinity
cards —
Part 3:
Anticollision and transmission protocol
Cartes d'identification — Cartes à circuit(s) intégré(s) sans contact —
Cartes de voisinage —
Partie 3: Anticollision et protocole de transmission

Reference number
©
ISO/IEC 2009
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2009 – All rights reserved

Contents Page
Foreword. v
Introduction . vi
1 Scope. 1
2 Normative references. 1
3 Terms, definitions, symbols and abbreviated terms. 2
3.1 Terms and definitions. 2
3.2 Abbreviated terms. 2
3.3 Symbols. 2
4 Definition of data elements. 3
4.1 Unique identifier (UID). 3
4.2 Application family identifier (AFI) . 3
4.3 Data storage format identifier (DSFID) . 6
4.4 CRC. 6
5 VICC memory organization. 6
6 Block security status. 7
7 Overall protocol description. 7
7.1 Protocol concept. 7
7.2 Modes. 8
7.2.1 Addressed mode. 8
7.2.2 Non-addressed mode . 8
7.2.3 Select mode. 8
7.3 Request format. 9
7.3.1 Request flags. 9
7.4 Response format. 10
7.4.1 Response flags . 11
7.4.2 Response error code. 11
7.5 VICC states. 12
7.5.1 Power-off state. 12
7.5.2 Ready state. 12
7.5.3 Quiet state. 12
7.5.4 Selected state. 12
8 Anticollision. 14
8.1 Request parameters . 14
8.2 Request processing by the VICC . 15
8.3 Explanation of an anticollision sequence . 17
9 Timing specifications . 19
9.1 VICC waiting time before transmitting its response after reception of an EOF from the
VCD. 19
9.2 VICC modulation ignore time after reception of an EOF from the VCD . 19
9.3 VCD waiting time before sending a subsequent request . 19
9.4 VCD waiting time before switching to the next slot during an inventory process . 20
9.4.1 When the VCD has started to receive one or more VICC responses . 20
9.4.2 When the VCD has received no VICC response . 20
10 Commands . 21
10.1 Command types . 21
10.1.1 Mandatory. 21
10.1.2 Optional. 21
© ISO/IEC 2009 – All rights reserved iii

10.1.3 Custom. 21
10.1.4 Proprietary. 21
10.2 Command codes . 22
10.3 Mandatory commands . 22
10.3.1 Inventory. 22
10.3.2 Stay quiet. 23
10.4 Optional commands. 24
10.4.1 Read single block. 24
10.4.2 Write single block . 25
10.4.3 Lock block. 26
10.4.4 Read multiple blocks . 26
10.4.5 Write multiple blocks . 28
10.4.6 Select. 29
10.4.7 Reset to ready. 29
10.4.8 Write AFI. 30
10.4.9 Lock AFI. 31
10.4.10 Write DSFID command . 32
10.4.11 Lock DSFID . 32
10.4.12 Get system information . 33
10.4.13 Get multiple block security status . 35
10.5 Custom commands. 36
10.6 Proprietary commands . 37
Annex A (informative) Compatibility with other card standards . 38
Annex B (informative) VCD pseudo-code for anticollision . 39
Annex C (informative) Cyclic Redundancy Check (CRC) . 40
C.1 The CRC error detection method. 40
C.2 CRC calculation example . 41
Bibliography . 43

iv © ISO/IEC 2009 – 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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
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.
ISO/IEC 15693-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and personal identification.
This second edition cancels and replaces the first edition (ISO/IEC 15693-3:2001), Table 1 and 9.4.2 of which
have been technically revised and Figure 10 redrawn for clarity.
ISO/IEC 15693 consists of the following parts, under the general title Identification cards — Contactless
integrated circuit cards — Vicinity cards:
⎯ Part 1: Physical characteristics
⎯ Part 2: Air interface and initialization
⎯ Part 3: Anticollision and transmission protocol
© ISO/IEC 2009 – All rights reserved v

Introduction
ISO/IEC 15693 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.
This part of ISO/IEC 15693 describes the anticollision and transmission protocols.
This part of ISO/IEC 15693 does not preclude the incorporation of other standard technologies on the card.
Contactless card standards cover a variety of types as embodied in ISO/IEC 10536 (close-coupled cards),
ISO/IEC 14443 (proximity cards) and ISO/IEC 15693 (vicinity cards). These are intended for operation when
very near, nearby and at a longer distance from associated coupling devices, respectively.
The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC)
draw attention to the fact that it is claimed that compliance with this document may involve the use of patents.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights.
The holders of these patent rights have assured ISO and IEC that they are willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect,
the statements of the holders of these patent rights are registered with ISO and IEC. Information may be
obtained from:
JP 2561051 - Circuit Structure of Inductive OMRON Corporation
Contactless Responding Unit Intellectual Property Group
20 Igadera, Shimokaiinji
JP 2981517, JP 2129209 – Read to Verify Written Nagaokakyo-City
Kyoto 617-8510
Data
Japan
US5793324 Texas Instruments Deutschland GMBH
TIRIS
Haggarty Strasse 1
EP831618
8050 Freising
Germany
EP837412
EP845751
The subject matter of these patents is anticollision, affecting Clause 8 of this part of ISO/IEC 15693.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights other than those identified above. ISO and IEC shall not be held responsible for identifying any or all
such patent rights.
vi © ISO/IEC 2009 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 15693-3:2009(E)

Identification cards — Contactless integrated circuit cards —
Vicinity cards
Part 3:
Anticollision and transmission protocol
1 Scope
This part of ISO/IEC 15693 specifies:
⎯ protocol and commands,
⎯ other parameters required to initialize communications between a vicinity integrated circuit card and
a vicinity coupling device,
⎯ methods to detect and communicate with one card among several cards ("anticollision"),
⎯ optional means to ease and speed up the selection of one among several cards based on application
criteria.
2 Normative references
The following referenced documents are indispensable for the application of this document. 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-6:2004, Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for
interchange
ISO/IEC 13239, Information technology — Telecommunications and information exchange between
systems — High-level data link control (HDLC) procedures
ISO/IEC 15693-1, Identification cards — Contactless integrated circuit(s) cards — Vicinity cards —
Part 1: Physical characteristics
ISO/IEC 15693-2, Identification cards — Contactless integrated circuit cards — Vicinity cards — Part 2: Air
interface and initialization
© ISO/IEC 2009 – All rights reserved 1

3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 15693-1, ISO/IEC 15693-2 and
the following apply.
3.1.1
anticollision loop
algorithm used to prepare for and handle a dialogue between a VCD and one or more VICCs from several in
its energizing field
3.1.2
byte
string that consists of 8 bits of data designated b1 to b8, from the most significant bit (MSB, b8) to the least
significant bit (LSB, b1)
3.2 Abbreviated terms
AFI application family identifier
CRC cyclic redundancy check
DSFID data storage format identifier
EOF end of frame
LSB least significant bit
LSByte least significant byte
MSB most significant bit
MSByte most significant byte
RFU reserved for future use
SOF start of frame
UID unique identifier
VCD vicinity coupling device
VICC vicinity integrated circuit card
3.3 Symbols
fc frequency of operating field (carrier frequency)
2 © ISO/IEC 2009 – All rights reserved

4 Definition of data elements
4.1 Unique identifier (UID)
The VICCs are uniquely identified by a 64 bits unique identifier (UID). This is used for addressing each VICC
uniquely and individually, during the anticollision loop and for one-to-one exchange between a VCD and a
VICC.
The UID shall be set permanently by the IC manufacturer in accordance with figure 1.
MSB LSB
64 57 56 49 48 1
'E0' IC Mfg code IC manufacturer serial number
Figure 1 — UID format
The UID comprises
⎯ The MSByte (bits 64 – 57) shall be 'E0',
⎯ The IC manufacturer code (bits 56 – 49) according to ISO/IEC 7816-6:2004,
⎯ A unique serial number (bits 48 – 1) assigned by the IC manufacturer.
4.2 Application family identifier (AFI)
AFI (Application family identifier) represents the type of application targeted by the VCD and is used to extract
from all the VICCs present only the VICCs meeting the required application criteria.
It may be programmed and locked by the respective commands.
AFI is coded on one byte, which constitutes 2 nibbles of 4 bits each.
The most significant nibble of AFI is used to code one specific or all application families, as defined in table 1.
The least significant nibble of AFI is used to code one specific or all application sub-families. Sub-family codes
different from 0 are proprietary.
© ISO/IEC 2009 – All rights reserved 3

Table 1 — AFI coding
AFI most AFI least Meaning
Examples / note
VICCs respond from
significant significant
nibble nibble
‘0’ ‘0’ All families and subfamilies No applicative preselection
X '0' All sub-families of family X Wide applicative preselection
X Y Only the Yth sub-family of family X
‘0’ Y Proprietary sub-family Y only
‘1' ‘0’, Y Transport Mass transit, Bus, Airline
'2' ‘0’, Y Financial IEP, Banking, Retail
'3' ‘0’, Y Identification Access control
'4' ‘0’, Y Telecommunication Public telephony, GSM
‘5’ ‘0’, Y Medical
'6' ‘0’, Y Multimedia Internet services
'7' ‘0’, Y Gaming
'8' ‘0’, Y Data storage Portable files
'9' ‘0’, Y EAN-UCC system for Application Managed by ISO/IEC JTC 1/SC 31
Identifiers
'A' ‘0’, Y Data Identifiers as defined in Managed by ISO/IEC JTC 1/SC 31
ISO/IEC 15418
'B' ‘0’, Y UPU Managed by ISO/IEC JTC 1/SC 31
'C' ‘0’, Y IATA Managed by ISO/IEC JTC 1
'D' ‘0’, Y RFU Managed by ISO/IEC JTC 1/SC 17
'E' ‘0’, Y RFU Managed by ISO/IEC JTC 1/SC 17
‘F’ ‘0’, Y RFU Managed by ISO/IEC JTC 1/SC 17

NOTE X = ‘1’ to ‘F’, Y = ‘1’ to ‘F’.
The support of AFI by the VICC is optional.
If AFI is not supported by the VICC and if the AFI flag is set, the VICC shall not answer whatever the AFI
value is in the request.
If AFI is supported by the VICC, it shall answer according to the matching rules described in table 1.
4 © ISO/IEC 2009 – All rights reserved

Inventory
Request
Received
No
Answer
AFI Flag Set
Yes
No
AFI Supported
NO Answer
by VICC
Yes
No
AFI Value = 0
Yes
No
AFI Value
NO Answer
= VICC's AFI
Answer
Yes
Answer
NOTE "Answer" means that the VICC shall answer to the Inventory request.
Figure 2 — VICC decision tree for AFI
© ISO/IEC 2009 – All rights reserved 5

4.3 Data storage format identifier (DSFID)
The Data storage format identifier indicates how the data is structured in the VICC memory.
It may be programmed and locked by the respective commands. It is coded on one byte. It allows for instant
knowledge on the logical organisation of the data.
If its programming is not supported by the VICC, the VICC shall respond with the value zero ('00').
4.4 CRC
The CRC shall be calculated in accordance with ISO/IEC 13239.
The initial register content shall be all ones: 'FFFF'.
The two bytes CRC are appended to each request and each response, within each frame, before the EOF.
The CRC is calculated on all the bytes after the SOF up to but not including the CRC field.
Upon reception of a request from the VCD, the VICC shall verify that the CRC value is valid. If it is invalid, it
shall discard the frame and shall not answer (modulate).
Upon reception of a response from the VICC, it is recommended that the VCD verifies that the CRC value is
valid. If it is invalid, actions to be performed are left to the responsibility of the VCD designer.
The CRC is transmitted least significant byte first.
Each byte is transmitted least significant bit first.
LSByte MSByte
LSB MSB LSB MSB
CRC 16 (8 bits) CRC 16 (8 bits)
↑ first transmitted bit of the CRC
Figure 3 — CRC bits and bytes transmission rules
5 VICC memory organization
The commands specified in this part of ISO/IEC 15693 assume that the physical memory is organized in
blocks (or pages) of fixed size.
⎯ Up to 256 blocks can be addressed.
⎯ Block size can be of up to 256 bits.
⎯ This leads to a maximum memory capacity of up to 8 kBytes (64 kBits).
NOTE The structure allows for future extension of the maximum memory capacity.
The commands described in this part of ISO/IEC 15693 allow the access (read and write) by block(s). There is
no implicit or explicit restriction regarding other access method (e.g. by byte or by logical object in future
revision(s) of this part of ISO/IEC 15693 or in custom commands).
6 © ISO/IEC 2009 – All rights reserved

6 Block security status
The block security status is sent back by the VICC as a parameter in the response to a VCD request as
specified in clause 10 (e.g. Read single block). It is coded on one byte.
It is an element of the protocol. There is no implicit or explicit assumption that the 8 bits are actually
implemented in the physical memory structure of the VICC.
Table 2 — Block security status
Bit Flag name Value Description
0 Not locked
b1 Lock_flag
1 Locked
b2 to b8 RFU 0
7 Overall protocol description
7.1 Protocol concept
The transmission protocol (or protocol) defines the mechanism to exchange instructions and data between the
VCD and the VICC, in both directions.
It is based on the concept of "VCD talks first".
This means that any VICC shall not start transmitting (i.e. modulating according to ISO/IEC 15693-2) unless it
has received and properly decoded an instruction sent by the VCD.
a) the protocol is based on an exchange of
⎯ a request from the VCD to the VICC
⎯ a response from the VICC(s) to the VCD
The conditions under which the VICC sends a response are defined in clause 10.
b) each request and each response are contained in a frame. The frame delimiters (SOF, EOF) are
specified in ISO/IEC 15693-2.
c) each request consists of the following fields:
⎯ Flags
⎯ Command code
⎯ Mandatory and optional parameters fields, depending on the command
⎯ Application data fields
⎯ CRC
© ISO/IEC 2009 – All rights reserved 7

d) each response consists of the following fields:
⎯ Flags
⎯ Mandatory and optional parameters fields, depending on the command
⎯ Application data fields
⎯ CRC
e) the protocol is bit-oriented. The number of bits transmitted in a frame is a multiple of eight (8), i.e. an
integer number of bytes.
f) a single-byte field is transmitted least significant bit (LSBit) first.
g) a multiple-byte field is transmitted least significant byte (LSByte) first, each byte is transmitted least
significant bit (LSB) first.
h) the setting of the flags indicates the presence of the optional fields. When the flag is set (to one), the field
is present. When the flag is reset (to zero), the field is absent.
i) RFU flags shall be set to zero (0).
7.2 Modes
The term mode refers to the mechanism to specify in a request the set of VICC’s that shall answer to the
request.
7.2.1 Addressed mode
When the Address_flag is set to 1 (addressed mode), the request shall contain the unique ID (UID) of the
addressed VICC.
Any VICC receiving a request with the Address_flag set to 1 shall compare the received unique ID (address)
to its own ID.
If it matches, it shall execute it (if possible) and return a response to the VCD as specified by the command
description.
If it does not match, it shall remain silent.
7.2.2 Non-addressed mode
When the Address_flag is set to 0 (non-addressed mode), the request shall not contain a unique ID.
Any VICC receiving a request with the Address_flag set to 0 shall execute it (if possible) and shall return a
response to the VCD as specified by the command description.
7.2.3 Select mode
When the Select_flag is set to 1 (select mode), the request shall not contain a VICC unique ID.
The VICC in the selected state receiving a request with the Select_flag set to 1 shall execute it (if possible)
and shall return a response to the VCD as specified by the command description.
Only the VICC in the selected state shall answer to a request having the select flag set to 1.
8 © ISO/IEC 2009 – All rights reserved

7.3 Request format
The request consists of the following fields:
⎯ Flags
⎯ Command code (see clause 10)
⎯ Parameters and data fields
⎯ CRC (see 4.4)
Command
SOF Flags Parameters Data CRC EOF
code
Figure 4 — General request format
7.3.1 Request flags
In a request, the field "flags" specifies the actions to be performed by the VICC and whether corresponding
fields are present or not.
It consists of eight bits.
Table 3 — Request flags 1 to 4 definition
Bit Flag name Value Description
0 A single sub-carrier frequency shall be used by the VICC
b1 Sub-carrier_flag
1 Two sub-carriers shall be used by the VICC
0 Low data rate shall be used
b2 Data_rate_flag
1 High data rate shall be used
0 Flags 5 to 8 meaning is according to table 4
b3 Inventory_flag
1 Flags 5 to 8 meaning is according to table 5
0 No protocol format extension
Protocol
b4
Extension_flag
1 Protocol format is extended. Reserved for future use

NOTE 1 Sub-carrier_flag refers to the VICC-to-VCD communication as specified in ISO/IEC 15693-2.
NOTE 2 Data_rate_flag refers to the VICC-to-VCD communication as specified in ISO/IEC 15693-2.
© ISO/IEC 2009 – All rights reserved 9

Table 4 — Request flags 5 to 8 definition when inventory flag is not set
Bit Flag name Value Description
Request shall be executed by any VICC according to the
setting of Address_flag
b5 Select_flag
Request shall be executed only by VICC in selected
1 state. The Address_flag shall be set to 0 and the UID
field shall not be included in the request.
Request is not addressed. UID field is not included. It
shall be executed by any VICC.
b6 Address_flag
Request is addressed. UID field is included. It shall be
1 executed only by the VICC whose UID matches the UID
specified in the request.
Meaning is defined by the command description. It shall
be set to 0 if not otherwise defined by the command.
b7 Option_flag
1 Meaning is defined by the command description.
b8 RFU 0
Table 5 — Request flags 5 to 8 definition when inventory flag is set
Bit Flag name Value Description
0 AFI field is not present
b5 AFI_flag
1 AFI field is present
0 16 slots
b6 Nb_slots_flag
1 1 slot
Meaning is defined by the command description. It shall
be set to 0 if not otherwise defined by the command.
b7 Option_flag
1 Meaning is defined by the command description.
b8 RFU 0
7.4 Response format
The response consists of the following fields:
⎯ Flags
⎯ one or more parameter fields
⎯ Data
⎯ CRC (see 4.4)
SOF Flags Parameters Data CRC EOF
Figure 5 — General response format
10 © ISO/IEC 2009 – All rights reserved

7.4.1 Response flags
In a response, it indicates how actions have been performed by the VICC and whether corresponding fields
are present or not.
It consists of eight bits.
Table 6 — Response flags 1 to 8 definition
Bit Flag name Value Description
0 No error
b1 Error_flag
1 Error detected. Error code is in the "Error" field.
b2 RFU 0
b3 RFU 0
0 No protocol format extension.
b4 Extension_flag
1 Protocol format is extended. Reserved for future use.
b5 RFU 0
b6 RFU 0
b7 RFU 0
b8 RFU 0
7.4.2 Response error code
When the Error_flag is set by the VICC, the error code field shall be included and provides information about
the error that occurred. Error codes are defined in table 7.
If the VICC does not support specific error code(s) listed in table 7, it shall answer with the error code '0F'
("Error with no information given").
Table 7 — Response error code definition
Error code Meaning
'01' The command is not supported, i.e. the request code is not recognized.
'02' The command is not recognized, for example: a format error occurred.
'03' The command option is not supported.
'0F' Error with no information given or a specific error code is not supported.
'10' The specified block is not available (doesn’t exist).
'11' The specified block is already locked and thus cannot be locked again.
'12' The specified block is locked and its content cannot be changed.
'13' The specified block was not successfully programmed.
'14' The specified block was not successfully locked.
'A0' – 'DF' Custom command error codes.
all others RFU
© ISO/IEC 2009 – All rights reserved 11

7.5 VICC states
A VICC can be in one of the 4 following states:
⎯ Power-off
⎯ Ready
⎯ Quiet
⎯ Selected
The transition between these states is specified in figure 6.
The support of power-off, ready and quiet states is mandatory.
The support of selected state is optional.
7.5.1 Power-off state
The VICC is in the power-off state when it cannot be activated by the VCD.
7.5.2 Ready state
The VICC is in the Ready state when it is activated by the VCD. It shall process any request where the select
flag is not set.
7.5.3 Quiet state
When in the quiet state, the VICC shall process any request where the Inventory_flag is not set and where the
Address_flag is set.
7.5.4 Selected state
Only a VICC in the selected state shall process requests having the Select_flag set.
12 © ISO/IEC 2009 – All rights reserved

PoPowweerr--ofofff
InIn F Fiieleldd
OOuut oft of FFiieleldd
AAnnyy ot othheerr Com Commmandand
OOuut oft of FFiieleldd
ReadReadyy
wwhherere Se Seelleecctt_fl_flaagg iiss not not sseett
ResReseet tt too ReaReaddyy
OOuut oft of FFiieleldd
SSttayay qu quietiet ((UUIIDD))
SSeelleecctt ( (UUID)ID)
ResReseett t too ReadyReady
wwhhereree S Seelleecctt_F_Fllaagg iiss s seett
oror SSeelleecctt ( (ddiiffferferentent U UIID)D)
SSeelleecctt ( (UUIDID))
QuietQuiet SelSelectecteded
StStayay qu quiieett ((UUIDID))
AAnnyy ot othheerr c coommmmaand nd wwhhereree t thhee
AnyAny ot otherher cocommmmaanndd
AAddddrresesss__ffllagag iiss s seett
AAND ND wwhherere ie innvevennttororyy__ffllagag isis not not  sseett

NOTE 1 The intention of the state transition method is that only one VICC should be in the Selected state at a time.
NOTE 2 The VICC state transition diagram shows only valid transitions. In all other cases the current VICC state
remains unchanged. When the VICC cannot process a VCD request (e.g. CRC error, etc.), it shall stay in its
current state.
NOTE 3 The Selected state is represented with a dotted line to show its support by the VICC is optional.
Figure 6 — VICC state transition diagram

© ISO/IEC 2009 – All rights reserved 13

8 Anticollision
The purpose of the anticollision sequence is to make an inventory of the VICCs present in the VCD field by
their unique ID (UID).
The VCD is the master of the communication with one or multiple VICCs. It initiates card communication by
issuing the inventory request.
The VICC shall send its response in the slot determined or shall not respond, according to the algorithm
described in clause 8.2.
8.1 Request parameters
When issuing the inventory command, the VCD shall set the Nb_slots_flag to the desired setting and add after
the command field the mask length and the mask value.
The mask length indicates the number of significant bits of the mask value. It can have any value between 0
and 60 when 16 slots are used and any value between 0 and 64 when 1 slot is used. LSB shall be transmitted
first.
The mask value is contained in an integer number of bytes. LSB shall be transmitted first.
If the mask length is not a multiple of 8 (bits), the mask value MSB shall be padded with the required number
of null (set to 0) bits so that the mask value is contained in an integer number of bytes.
The next field starts on the next byte boundary.
Mask
SOF Flags Command Mask value CRC16 EOF
length
8 bits 8 bits 8 bits 0 to 8 bytes 16 bits
Figure 7 — Inventory request format
MSB LSB
0000 0100 1100 1111
Pad Mask value
Figure 8 — Example of the padding of the mask
In the example of figure 8, the mask length is 12 bits. The mask value MSB is padded with four bits set to 0.
The AFI field shall be present if the AFI_flag is set.
The pulse shall be generated according to the definition of the EOF in ISO/IEC 15693-2.
The first slot starts immediately after the reception of the request EOF.
To switch to the next slot, the VCD sends an EOF. The rules, restrictions and timing are specified in clause 9.
14 © ISO/IEC 2009 – All rights reserved

8.2 Request processing by the VICC
Upon reception of a valid request, the VICC shall process it by executing the operation sequence specified in
the following text in italics. The step sequence is also graphically represented in figure 9.
NbS is the total number of slots (1 or 16)
SN is the current slot number (0 to 15)
SN_length is set to 0 when 1 slot is used and set to 4 when 16 slots are used
LSB (value, n) function returns the n less significant bits of value
"&" is the concatenation operator
Slot_Frame is either a SOF or an EOF
SN= 0
if Nb_slots_flag then
NbS =1 SN_length=0
else NbS = 16 SN_length=4
endif
label1: if LSB(UID, SN_length + Mask_length) = LSB(SN, SN_length)&LSB(Mask, Mask_length) then
transmit response to inventory request
endif
wait (Slot_Frame)
if Slot_Frame= SOF then
Stop anticollision and decode/process request
exit
endif
if SN SN = SN +1
goto label1
exit
endif
exit
© ISO/IEC 2009 – All rights reserved 15

TThe Ihe Innvveentntororyy r reeqquesuestt
ccontontaaiinsns t thhe me maasskk v vaaluelue
and itand itss llengtength.h. T The he mmaasskk
isis padded w padded wiitthh 0'0'ss ttoo a a
wwhhoolle nume numberber o off bbyytteess
PaddiPaddingng
LSLSBB
TThe mhe maasskk v vaallue ue lleessss
tthe paddihe padding isng is loade loadedd
MMaask sk vvaalluue re reecceeiivedved i inn I Innvveennttoorryy r reeqquuestest
iinnttoo t the he ccoommppararaattoror
MSBMSB
UUpon recpon recepteption oion off tthhee
MMaasskk le lengtngthh
IInnvvententororyy requ requesestt,, t thhee
VVIICCCC r reesesettss iits slts sloott
ccountounteerr t too 0. 0.
UUpon recpon recepteption oion off anan
EEOOFF,, th thee VVIICCCC
iinncrcreemmeenntts is its ts slsloott
SSllotot c coountunteerr
ccountounterer an anand ld lod looadad ad s iitt in inttoo
tthe che coommpparataratoror,,
cconconcatateenatnated wed wiitthh tthhee
mmaasskk v vaallue ue ((llesesss
paddipadding).ng).
TThhe ce coonnccatatenenatateedd resresuulltt is is
ccoommpared wpared wiitthh t thhee
LSLSBB
MSBMSB
lleeaast sist siggnniiffiiccaannt bt biittss ooff th thee
VVIICCCC UID. UID.  If i If itt m maattcchhees,s, SSllotot num numbeberr MMaasskk v vaalluue (le (lesess s ppaaddddiinngg))
tthe VIhe VICCCC s shalhall tl trransansmmiitt
iittss r reessponsponse,e, aaccccoorrdding ting too
tthe othe other cher crriitteerriiaa (e.(e.gg.
AAFFI,I, Q Quuiieet t stastatete)).
IgnIgnoorere CCoompmpaarree
UUnniiqquuee i iddenentitiffiierer (U (UIIDD))
MSBMSB LSLSBB
NOTE When the slot number is 1 (Nb_slots_flag is set to 1), the comparison is made only on the mask (without
padding).
Figure 9 — Principle of comparison between the mask value, slot number and UID

16 © ISO/IEC 2009 – All rights reserved

8.3 Explanation of an anticollision sequence
Figure 10 summarises the main cases that can occur during a typical anticollision sequence where the
number of slots is 16.
The different steps are:
a) the VCD sends an inventory request, in a frame, terminated by a EOF. The number of slots is 16.
b) VICC 1 transmits its response in slot 0. It is the only one to do so, therefore no collision occurs and its
UID is received and registered by the VCD;
c) the VCD sends an EOF, meaning to switch to the next slot.
d) in slot 1, two VICCs 2 and 3 transmits their response, this generates a collision. The VCD detects it and
remembers that a collision was detected in slot 1.
e) the VCD sends an EOF, meaning to switch to the next slot.
f) in slot 2, no VICC transmits a response. Therefore the VCD does not detect a VICC SOF and decides to
switch to the next slot by sending a EOF.
g) in slot 3, there is another collision caused by responses from VICC 4 and 5
h) the VCD then decides to send an addressed request (for instance a Read Block) to VICC 1, which UID
was already correctly received.
i) all VICCs detect a SOF and exit the anticollision sequence. They process this request and since the
request is addressed to VICC 1, only VICC1 transmit its response.
j) all VICCs are ready to receive another request. If it is an inventory command, the slot numbering
sequence restarts from 0.
NOTE The decision to interrupt the anticollision sequence is up to the VCD. It could have continued to send EOF’s till
slot 15 and then send the request to VICC 1.

© ISO/IEC 2009 – All rights reserved 17

NOTE t1, t2 and t3 are specified in clause 9.
Figure 10 — Description of a possible anticollision sequence

18 © ISO/IEC 2009 – All rights reserved

9 Timing specifications
The VCD and the VICC shall comply with the following timing specifications.
9.1 VICC waiting time before transmitting its response after reception of an EOF from the
VCD
When the VICC has detected an EOF of a valid VCD request or when this EOF is in the normal sequence of a
valid VCD request, it shall wait for a time t1 before starting to transmit its response to a VCD request or before
switching to the next slot when in an inventory process (see 8.2 and 8.3).
t1 starts from the detection of the rising edge of the EOF received from the VCD (see ISO/IEC 15693-2).
NOTE The synchronisation on the rising edge of the VCD-to-VICC EOF is needed for ensuring the required
synchronization of the VICC responses.
The minimum value of t1 is t1min= 4320/fc (318,6 µs)
The nominal value of t1 is t1nom= 4352/fc (320,9 µs)
The maximum value of t1 is t1max= 4384/fc (323,3 µs)
t1max does not apply for Write alike requests. Timing conditions for Write alike requests are defined in the
command descriptions.
If the VICC detects a carrier modulation during this time t1, it shall reset its t1 timer and wait for a further time
t1 before starting to transmit its response to a VCD request or to switch to the next slot when in an inventory
process.
9.2 VICC modulation ignore time after reception of an EOF from the VCD
When the VICC has detected an EOF of a valid VCD request or when this EOF is in the normal sequence of a
valid VCD request, it shall ignore any received 10 % modulation during a time tmit.
tmit starts fro
...