NFC Activity Specification
NFC Activity Specification
Technical Specification
NFC ForumTM
ACTIVITY 1.0
NFCForum-TS-Activity-1.0
2010-11-18
RESTRICTIONS ON USE
This specification is copyright © 2005-2010 by the NFC Forum, and was made available pursuant to a
license agreement entered into between the recipient (Licensee) and NFC Forum, Inc. (Licensor) and may
be used only by Licensee, and in compliance with the terms of that license agreement (License). If you are
not the Licensee, you may read this Specification, but are not authorized to implement or make any other
use of this specification. However, you may obtain a copy of this Specification and implementation rights
at the following page of Licensor's website: http://www.nfc-forum.org/specs/spec_license after entering
into and agreeing to such license terms as Licensor is then requiring. On the date that this specification was
downloaded by Licensee, the non-implementation terms of that license were as follows:
1. LICENSE GRANT.
Licensor hereby grants Licensee the right, without charge, to copy (for internal purposes only) and share
this Specification with Licensee's members, employees and (to the extent related to Licensees use of this
Specification) consultants. This license grant does not include the right to sublicense, modify or create
derivative works based upon the Specification.
2. NO WARRANTIES.
THE SPECIFICATION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, COMPLETENESS AND
NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL LICENSOR, ITS
MEMBERS OR ITS CONTRIBUTORS BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL,
INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING
FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH
THE USE OR PERFORMANCE OF THE SPECIFICATION.
3. THIRD PARTY RIGHTS.
Without limiting the generality of Section 2 above, LICENSOR ASSUMES NO RESPONSIBILITY TO
COMPILE, CONFIRM, UPDATE OR MAKE PUBLIC ANY THIRD PARTY ASSERTIONS OF
PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS THAT MIGHT NOW OR IN THE
FUTURE BE INFRINGED BY AN IMPLEMENTATION OF THE SPECIFICATION IN ITS CURRENT,
OR IN ANY FUTURE FORM. IF ANY SUCH RIGHTS ARE DESCRIBED ON THE SPECIFICATION,
LICENSOR TAKES NO POSITION AS TO THE VALIDITY OR INVALIDITY OF SUCH
ASSERTIONS, OR THAT ALL SUCH ASSERTIONS THAT HAVE OR MAY BE MADE ARE SO
LISTED.
4. TERMINATION OF LICENSE.
In the event of a breach of this Agreement by Licensee or any of its employees or members, Licensor shall
give Licensee written notice and an opportunity to cure. If the breach is not cured within thirty (30) days
after written notice, or if the breach is of a nature that cannot be cured, then Licensor may immediately or
thereafter terminate the licenses granted in this Agreement.
5. MISCELLANEOUS.
All notices required under this Agreement shall be in writing, and shall be deemed effective five days from
deposit in the mails. Notices and correspondence to the NFC Forum address as it appears below. This
Agreement shall be construed and interpreted under the internal laws of the United States and the
Commonwealth of Massachusetts, without giving effect to its principles of conflict of law.
NFC Forum, Inc.
401 Edgewater Place, Suite 600
Wakefield, MA, USA 01880
Contents
Contents
1 Introduction.................................................................................................... 9
1.1 Objectives ...................................................................................................................... 9
1.2 Audience ........................................................................................................................ 9
1.3 Applicable Documents or References ........................................................................... 9
1.4 Administration ............................................................................................................. 10
1.5 Name and Logo Usage ................................................................................................ 10
1.6 Intellectual Property .................................................................................................... 10
1.7 Special Word Usage .................................................................................................... 10
1.8 Requirement Numbering ............................................................................................. 11
1.9 Notational Conventions ............................................................................................... 13
1.9.1 Notations ....................................................................................................... 13
1.9.2 Figures .......................................................................................................... 14
1.10 Abbreviations .............................................................................................................. 14
1.11 Glossary ....................................................................................................................... 17
1.11.1 Field .............................................................................................................. 17
1.11.2 Technology and Communication .................................................................. 17
1.11.3 Device ........................................................................................................... 19
1.11.4 Specific to This Specification ....................................................................... 20
1.11.5 Errors ............................................................................................................ 21
2 Purpose ........................................................................................................ 22
3 Listen Mode – Generic Requirements ....................................................... 24
4 Listen Mode – Configuration ...................................................................... 25
5 Listen Mode – State Machine...................................................................... 28
5.1 NO_REMOTE_FIELD State....................................................................................... 31
5.2 IDLE State ................................................................................................................... 31
5.3 READY_A Sub-state and READY_A* Sub-state ...................................................... 33
5.4 READY_A’ Sub-state and READY_A’* Sub-state .................................................... 33
5.5 READY_A” Sub-state and READY_A”* Sub-state ................................................... 34
5.6 ACTIVE_A Sub-state and ACTIVE_A* Sub-state..................................................... 35
5.7 SLEEP_A Sub-state..................................................................................................... 35
5.8 ATR_READY_A Sub-state......................................................................................... 35
5.9 TARGET_A Sub-state................................................................................................. 36
5.10 CARD_EMULATOR_4A Sub-state ........................................................................... 37
5.11 READY_B_REQU Sub-state ...................................................................................... 38
5.12 READY_B_DECL Sub-state ...................................................................................... 39
5.13 SLEEP_B Sub-state ..................................................................................................... 40
5.14 CARD_EMULATOR_4B Sub-state ........................................................................... 40
5.15 READY_F Sub-state ................................................................................................... 41
5.16 ATR_READY_F Sub-state ......................................................................................... 42
5.17 TARGET_F Sub-state ................................................................................................. 42
5.18 CARD_EMULATOR_3 Sub-state .............................................................................. 43
5.19 SLEEP_AF Sub-state .................................................................................................. 44
6 Poll Mode – Generic Requirements ........................................................... 45
7 Poll Mode – RF Collision Avoidance .......................................................... 47
8 Poll Mode – Activity and Profile Model ...................................................... 49
Figures
Figure 1: Example Flow Chart ...................................................................................................... 11
Figure 2: RF Collision Avoidance – Flow Chart........................................................................... 47
Figure 3: Activity .......................................................................................................................... 49
Figure 4: Profile............................................................................................................................. 50
Figure 5: Technology Detection Activity – Flow Chart ................................................................ 55
Figure 6: Collision Resolution Activity (Sheet 1, Entry) – Normative Flow Chart ...................... 61
Figure 7: Collision Resolution Activity (Sheet 2, connector A, NFC-A) – Flow Chart ............... 63
Figure 8: Collision Resolution Activity (Sheet 3, connector B, NFC-B) – Flow Chart ................ 68
Figure 9: Collision Resolution Activity (Sheet 4, connector F, NFC-F) – Flow Chart ................. 72
Figure 10: Device Activation Activity (Sheet 1, Entry) – Normative Flow Chart ........................ 77
Figure 11: Device Activation Activity (Sheet 2, Connector DA_1, NFC-DEP (NFC-A), Type 1, 2
& 4A Tag Platform) – Flow Chart ................................................................................................ 78
Figure 12: Device Activation Activity (Sheet 3, Connector DA_2, Type 4B Tag Platform) – Flow
Chart .............................................................................................................................................. 82
Figure 13: Device Activation Activity (Sheet 4, Connector DA_3, NFC-DEP (NFC-F)) – Flow
Chart .............................................................................................................................................. 84
Figure 14: Data Exchange Activity (Sheet 1, entry) – Normative Flow Chart ............................. 87
Figure 15: Data Exchange Activity (Sheet 2, connector DE_1, NFC-DEP) – Flow Chart ........... 88
Figure 16: Data Exchange Activity (Sheet 3, Connector DE_2, ISO-DEP) – Flow Chart ........... 89
Figure 17: Data Exchange Activity (Sheet 4, Connector DE_3, Type 1 Tag Platform) – Flow
Chart .............................................................................................................................................. 90
Figure 18: Data Exchange Activity (Sheet 5, connector DE_4, Type 2 Tag Platform) – Flow
Chart .............................................................................................................................................. 91
Figure 19: Data Exchange Activity (Sheet 6, connector DE_5, Type 3 Tag Platform) – Flow
Chart .............................................................................................................................................. 92
Figure 20: Type 3 Tag Platform Selection – Flow Chart .............................................................. 93
Figure 21: Device Deactivation Activity (Sheet 1, Entry) – Normative Flow Chart .................... 95
Figure 22: Deactivation Activity (Sheet 2, Connector DD_1, NFC-DEP) – Flow Chart.............. 96
Figure 23: Deactivation Activity (Sheet 3, connector DD_2, ISO-DEP) – Flow Chart ................ 97
Figure 24: Deactivation Activity (Sheet 4, connector DD_3, Type 2 Tag Platform) – Flow Chart
....................................................................................................................................................... 98
Figure 25: Sequential execution of profiles................................................................................... 99
Figure 26: P2P Poll Profile Resolution Process .......................................................................... 102
Figure 27: NDEF Poll Profile Resolution Process – Sheet 1 ...................................................... 104
Figure 28: NDEF Poll Profile Resolution Process – Sheet 2 ...................................................... 105
Figure 29: NDEFP2P Poll Profile Resolution Process – Main Flow .......................................... 107
Figure 30: NDEFP2P Poll Profile Resolution Process – FOUND_A Processing ....................... 108
Figure 31: NDEFP2P Poll Profile Resolution Process – FOUND_B Processing ....................... 109
Figure 32: NDEFP2P Poll Profile Resolution Process – FOUND_F Processing........................ 110
Figure 33: NDEFP2P Poll Profile Resolution Process – Device Communication ...................... 111
Figure 34: NDEFP2P Poll Profile Resolution Process – NFC-A Communication ..................... 112
Figure 35: Listen Mode – State Diagram (Informative) .............................................................. 113
Tables
Table 1: Sample Requirement ....................................................................................................... 11
Table 2: Example Requirements ................................................................................................... 12
Table 3: Notational Conventions ................................................................................................... 13
Table 4: Figure Notation ............................................................................................................... 14
Table 5: Abbreviations .................................................................................................................. 15
Table 6: Listen Mode – Configuration Parameters ....................................................................... 25
Table 7: Listen Mode – State Machine.......................................................................................... 29
Table 8: Technology Detection Activity – Configuration Parameters .......................................... 53
Table 9: Technology Detection Activity – Output Parameters ..................................................... 54
Table 10: Technology Detection Activity – Output into Greedy Collection................................. 54
Table 11: Collision Resolution Activity – Configuration Parameters ........................................... 59
Table 12: Collision Resolution Activity – Input Parameters ......................................................... 59
Table 13: Collision Resolution Activity – Input from Greedy Collection .................................... 60
Table 14: Collision Resolution Activity – Output Parameters ...................................................... 60
Table 15: Collision Resolution Activity – Output into Greedy Collection ................................... 61
Table 16: Device Activation Activity – Configuration Parameters............................................... 74
Table 17: Device Activation Activity – Input Parameters............................................................. 75
Table 18: Device Activation Activity – Input from Greedy Collection ........................................ 76
Table 19: Device Activation Activity – Output Parameters .......................................................... 76
Table 20: Device Activation Activity – Output into Greedy Collection ....................................... 76
Table 21: Data Exchange Activity – Input Parameters ................................................................. 86
Table 22: Device Activation Activity – Input from Greedy Collection ........................................ 86
Table 23: Data Exchange Activity – Output Parameters............................................................... 86
Table 24: Device Deactivation Activity – Input Parameters ......................................................... 94
Table 25: Device Deactivation Activity – Output Parameters ...................................................... 94
Table 26: Greedy Collection Information Required for Resolution Processes ........................... 100
Table 27: P2P Poll Profile Configuration Parameters ................................................................. 101
Table 28: NDEF Poll Profile Configuration Parameters ............................................................. 103
Table 29: P2PNDEF Poll Profile Configuration Parameters....................................................... 106
Table 30: Poll Mode and Listen Mode Parameter Values ........................................................... 114
Table 31: Revision History.......................................................................................................... 115
Requirements
Requirements 1: Listen Mode – Generic ....................................................................................... 24
Requirements 2: Listen Mode – NO_REMOTE_FIELD State ..................................................... 31
Requirements 3: Listen Mode – IDLE State ................................................................................. 31
Requirements 4: Listen Mode – READY_A SUB-STATE and READY_A* Sub-state .............. 33
Requirements 5: Listen Mode – READY_A’SUB-STATE and READY_A’* Sub-state............. 34
Requirements 6: Listen Mode – READY_A’’ SUB-STATE and READY_A’’* Sub-state ......... 34
Requirements 7: Listen Mode – ACTIVE_A SUB-STATE and ACTIVE_A* Sub-state ............ 35
Requirements 8: Listen Mode – SLEEP_A Sub-state ................................................................... 35
Requirements 9: Listen Mode – ATR_READY_A Sub-state ....................................................... 36
Requirements 10: Listen Mode – TARGET_A Sub-state ............................................................. 36
Requirements 11: Listen Mode – CARD_EMULATOR_4A Sub-state........................................ 37
Requirements 12: Listen Mode – READY_B_REQU Sub-state .................................................. 38
Requirements 13: Listen Mode – READY_B_DECL Sub-state ................................................... 39
Requirements 14: Listen Mode – SLEEP_B Sub-state ................................................................. 40
Requirements 15: Listen Mode – CARD_EMULATOR_4B Sub-state ........................................ 40
Requirements 16: Listen Mode – READY_F Sub-state................................................................ 41
Requirements 17: Listen Mode – ATR_READY_F Sub-state ...................................................... 42
Requirements 18: Listen Mode – TARGET_F Sub-state .............................................................. 42
Requirements 19: Listen Mode – CARD_EMULATOR_3 Sub-state .......................................... 43
Requirements 20: Listen Mode – SLEEP_AF Sub-state ............................................................... 44
Requirements 21: Generic ............................................................................................................. 45
Requirements 22: RF Collision Avoidance ................................................................................... 48
Requirements 23: Activities - General .......................................................................................... 52
Requirements 24: Technology Detection Activity ........................................................................ 56
Requirements 25: Collision Resolution Activity – NFC-A ........................................................... 64
Requirements 26: Collision Resolution Activity – NFC-B ........................................................... 69
Requirements 27: Collision Resolution Activity – NFC-F ........................................................... 73
Requirements 28: Device Activation Activity – NFC-DEP (NFC-A), Type 1, 2, & 4A Tag
Platform ......................................................................................................................................... 79
Requirements 29: Device Activation Activity – Type 4B Tag Platform....................................... 83
Requirements 30: Device Activation Activity – NFC-DEP (NFC-F) ........................................... 85
Requirements 31: Data Exchange Activity – NFC-DEP ............................................................... 88
Requirements 32: Data Exchange Activity – ISO-DEP ................................................................ 89
Requirements 33: Data Exchange Activity – Type 1 Tag Platform .............................................. 90
1 Introduction
1.1 Objectives
This document describes how the NFC Digital Protocol Specification can be used to set-up the
communication protocol with the other device.
This document describes the building blocks, called Activities, for setting up the communication
protocol.
These Activities can be used as defined in this specification or can be modified to define other
ways of setting up the communication protocol, covering the same or different use cases.
Activities are combined in Profiles. Each Profile has specific Configuration Parameters and
covers a particular use case.
This document covers corresponding Profiles for the NFC Forum use cases.
1.2 Audience
This document is intended for use by manufacturers wanting to implement an NFC Forum
Device.
1.4 Administration
The NFC Activity Specification is an open specification supported by the Near Field
Communication Forum, Inc., located at:
401 Edgewater Place, Suite 600
Wakefield, MA, 01880
Tel.: +1 781-876-8955
Fax: +1 781-610-9864
http://www.nfc-forum.org/
The NFC Devices Technical Working Group maintains this specification.
A requirement can have different numbers in different versions of the specifications. Hence, all
references to a requirement MUST include the version of the document as well as the
requirement’s number.
A figure that is labeled “flow chart” illustrates the behavior given by the corresponding
requirements tables. Figures are informative if not otherwise stated. An example is show in
Figure 1.
n n+1
yes
Turn? Blink
no n+2
Turn
n+3
Stop blinking
n+4
Continue
A requirement can be labeled as a symbol, when referring to a flow chart, indicating a particular
sequence. If the current requirement is labeled “Symbol n”, then the next requirement in the
sequence is “Symbol n+1”, unless explicitly stated differently.
1.8.1.2 Symbol n
If a car wants to turn to left or right, it MUST proceed to Symbol n+1.
Otherwise, the car MUST proceed to Symbol n+4.
1.8.1.3 Symbol n+1
The car MUST blink.
1.8.1.4 Symbol n+2
The car MUST turn.
1.8.1.5 Symbol n+3
The car MUST stop blinking.
1.8.1.6 Symbol n+4
The car MUST continue to drive straight ahead or stop.
Notation Description
XYh Hexadecimal notation.
Values expressed in hexadecimal form are followed by a lower case “h”.
For example, 27509 decimal is expressed in hexadecimal as 6B75h.
xyb Binary notation.
Values expressed in binary form are followed by a lower case “b”.
For example, 82h hexadecimal is expressed in binary as 10000010b.
[…] Optional part
xx More than one value possible
STATE States are written in COURIER FONT and in bold to distinguish them from the
text.
PARAMETER Parameters are written in Capital Letters to distinguish them from the text.
CON_ Prefix for Configuration Parameters (e.g., CON_DEVICES_LIMIT).
INT_ Prefix for variables used in the Activities (e.g., INT_COLL_PEND).
GRE_ Prefix for variables used in the Greedy Collection (e.g., GRE_POLL_A).
1.9.2 Figures
Table 4 defines the graphical notation used in the figures of this document.
Symbol Meaning
Activity
Activity
label
Connection point with dedicated label as used when a flow chart is split
into multiple figures
test Test block with one input branch and several output branches
elementary
action Elementary action block
1.10 Abbreviations
The abbreviations as used in this document are defined in Table 5.
Table 5: Abbreviations
Abbreviation Description
AFI Application Family Identifier
ALL_REQ ALL NFC-A REQuest
ALLB_REQ (AFI, N1) ALL NFC-B REQuest with matching AFI and N equal to 1
ALLB_REQ (AFI, N>) ALL NFC-B REQuest with matching AFI and N greater than 1
and if R is greater than 1
ALLB_REQ (nAFI) ALL NFC-B REQuest with not matching AFI
ANTICOLL ANTICOLLision
BITR BIT Rate
BCC Byte Check Cln
CLn Cascade Level n (1 ≤ n ≤ 3)
CMD CoMmanD
CUP Check Update Proprietary
COLL COLLision
DA Device Activation
DD Device Deactivation
DE Data Exchange
DECL DECLared
DEP_REQ Data Exchange Protocol REQuest
DSI Data rate Send by Initiator
DSL DeSeLect
Fc Carrier Frequency
FDT Frame Delay Time
FWT Frame Waiting Time
GB General Bytes
GT Guard Time
ID Identifier
ISO International Organization for Standardization
LLCP Logical Link Control Protocol
Max Maximum
Min Minimum
ms millisecond
n.a. not applicable
Abbreviation Description
N Number of slots
NDEF NFC Data Exchange Format
NFC Near Field Communication
NFC-A Near Field Communication – Type A Technology
NFC-B Near Field Communication – Type B Technology
NFC-F Near Field Communication – Type F Technology
NDEF NFC Data Exchange Format
NFCID0 NFC-B identifier.
NFCID0 is always 4 bytes long.
NFCID1 NFC-A identifier.
NFCID1 can be 4, 7, or 10 bytes long (simple, double, or triple
size).
NFCID1 CLn Contains the portion of the NFCID1 relative to the cascade level
n.
NFCID1 CLn is always 4 bytes long.
NFCID2 NFC-F identifier
NFCID2 is always 8 bytes long.
NFCID3 NFC-DEP identifier
NFCID3 is always 10 bytes long.
P2P Peer 2 Peer
RATS Request for Answer To Select
PEND PENDing
PDU Protocol Data Unit
PSL_REQ (A) Parameter SeLection REQuest with DSI indicating NFC-A
PSL_REQ (F) Parameter SeLection REQuest with DSI indicating NFC-F
PTGT Proprietary Technology Guard Time
R Randomly chosen slot number, NFC-B
RD Request Data
REQU REQUested
RF Radio Frequency
RLS ReLeaSe
SC System Code, NFC-F
SDD Single Device Detection
SEL SELection
SENSB_REQ (AFI, N1) SENS NFC-B REQuest with matching AFI and N equal to 1
Abbreviation Description
SENSB_REQ (AFI, N>) SENS NFC-B REQuest with matching AFI and N greater than 1
and if R is greater than 1
SENSB_REQ (nAFI) SENS NFC-B REQuest with not matching AFI
SLEEP_AF SLEEP NFC-A and NFC-F
TECH TECHnology
TID Initial Delay Time
TRFW RF Waiting Time
1.11 Glossary
1.11.1 Field
No Remote Field Sensed
A condition of the Remote Field that indicates the absence of remote devices. For the
definition, see [ANALOG].
Operating Field
The radio frequency field created by the NFC Forum Device in Poll Mode.
Operating Field Off
A condition of the Operating Field when the field strength is below a well-defined
threshold. For the definition, see [ANALOG].
Operating Field On
A condition of the Operating Field when the field strength is above a well-defined
threshold for a minimum period of time. For the definition, see [ANALOG].
Remote Field
The radio frequency field sensed by the NFC Forum Device in Listen Mode.
Remote Field Present
A condition of the Remote Field being stable and strong enough to put the NFC Forum
Device in a state that it can operate in Passive Communication mode. For the definition,
see [ANALOG].
Unmodulated Carrier
A condition of the Operating Field with no modulation present. For the definition, see
[ANALOG].
Collision
For NFC-A, a collision is a superposition of a ‘0’ and a ‘1’ as defined in [DIGITAL].
For NFC-B and NFC-F, a collision is a superposition of multiple Responses, resulting in
a Transmission Error.
Command
An instruction from one device to another device in order to move the other device
through a state machine.
Correct Frame
A frame without Transmission Error.
ISO-DEP Protocol
The half-duplex block transmission protocol as defined in [DIGITAL].
NFC-DEP Protocol
The half-duplex block transmission protocol as defined in [DIGITAL].
Passive Communication
A communication mode in which one device generates an Operating Field and sends
Commands to a second device. To respond, this second device uses load modulation,
which means that it does not generate an Operating Field but it draws power from a
Remote Field.
Poll Command
A Command to probe an NFC Forum Device in Listen Mode or an NFC Forum Tag:
• ALL_REQ or SENS_REQ Command for NFC-A
• ALLB_REQ or SENSB_REQ Command for NFC-B
• SENSF_REQ Command for NFC-F
Proprietary Command
Any Command from one of the NFC technologies of which the meaning is outside of the
scope of this specification. This applies in particular to the Type 1 Tag Platform, to the
Type 2 Tag Platform, and to the Type 3 Tag Platform.
Proprietary Technology
Any technology of which the Command(s) used in the Technology Detection Activity
do(es) NOT move the NFC Forum Device (in Listen Mode) out of the IDLE state.
Further specification of Proprietary Technologies is outside the scope of this document.
Reader/Writer
Role of an NFC Forum Device reached when an NFC Forum Device in Poll Mode has
gone through a number of Activities. In this mode, the NFC Forum Device behaves like a
legacy contactless reader and uses Commands from one of the Technology Subsets.
Response
Information sent from one device to another device upon receipt of a Command. The
information received by the other device should allow this other device to continue the
data exchange.
Technology
A group of transmission Parameters defined by the NFC standard that makes a complete
communication protocol. A non-exhaustive list of transmission Parameters is: RF carrier,
communication mode, bit rate, modulation scheme, bit-level coding, frame format,
protocol, and Command set. NFC defines three groups and therefore three Technologies:
NFC-A, NFC-B, and NFC-F. The three Technologies use the same RF carrier (13.56
MHz). Each Technology uses its own modulation scheme, bit-level coding, and frame
format, but may have the same protocol and Command set.
Technology Subset
A legacy platform supporting a subset of a Technology. A Technology Subset supports at
least the Poll Command of the Technology. The four Technology Subsets described in
this specification are:
• Type 1 Tag Platform, which uses a particular subset of NFC-A, excluding anti-
collision
• Type 2 Tag Platform, which uses a particular subset of NFC-A, including anti-
collision
• Type 3 Tag Platform, which uses a particular subset of NFC-F
• Type 4 Tag Platform, which uses a particular subset of NFC-A or NFC-B, including
anti-collision
Valid Block, Valid PDU
A block or PDU without Protocol Error within a Correct Frame.
Valid Command, Valid Response
A Command or Response without Protocol Error within a Correct Frame.
1.11.3 Device
Card Emulator
Role of an NFC Forum Device, reached when an NFC Forum Device in Listen Mode has
gone through a number of states or sub-states and in which the NFC Forum Device
behaves as one of the Technology Subsets.
Initiator
Role of an NFC Forum Device reached when an NFC Forum Device in Poll Mode has
gone through a number of Activities; in this mode the NFC Forum Device communicates
using the NFC-DEP Protocol.
Listen Mode
Initial mode of an NFC Forum Device when it does not generate a carrier; in this mode,
the NFC Forum Device listens for the Remote Field of another device.
NFC Forum Device
A device that supports the following Modus Operandi: Initiator, Target, and
Reader/Writer. It may also support Card Emulator.
Resolution Process
The part of the adjacent upper layer managing the Activities. The Resolution Process
decides the next Activity to perform and hands over the Parameters needed.
1.11.5 Errors
OTHER
A Protocol Error, Timeout Error, or Transmission Error. Refer to Section 5 for the usage
of OTHER.
Protocol Error
A Semantic Error or Syntax Error.
Semantic Error
A Correct Frame with no Syntax Error is received when it is not expected.
Syntax Error
A Correct Frame is received with invalid content. In this case, the coding of the
Command or the block within the frame is not consistent with [DIGITAL].
Timeout Error
No Response has been received within the Response Waiting Time. See [DIGITAL] .
Transmission Error
An incorrect frame is received. In this case, the signal modulation, the bit coding, the
frame format, the timing, or the checksum is not consistent with [DIGITAL].
2 Purpose
The Activity Specification describes a layer complementary to the Digital Protocol Specification.
This document lists the requirements of the behavior of an NFC Forum device as it can be
observed from monitoring the radio frequency field. The specification should be read as such,
focusing on the external behavior, even if the description may be interpreted as a software
implementation specification. Any implementation that creates the same external behavior as
specified–and that is therefore indistinguishable from a testing point of view–meets the
requirements.
It separately describes Listen Mode and Poll Mode.
Listen Mode is described in sections 3 to 5. These sections are composed of:
1. Generic requirements (see Section 3)
These requirements must be observed to ensure interoperability between different NFC
devices, and between NFC devices and existing contactless infrastructure, independent of the
implementation in the NFC Forum Device.
2. Configuration (see Section 4)
This section defines the Configuration Parameters that are available to configure the Listen
Mode State Machine.
3. State Machine (see Section 5)
This section contains the State Machine with a detailed description of all the states.
Poll Mode is described in sections 6 to 10. Those sections are composed of:
1. Generic requirements (see Section 6)
These requirements must be observed to ensure interoperability between different NFC
devices, and between NFC devices and existing contactless infrastructure, independent of the
implementation in the NFC Forum Device.
2. RF Collision Avoidance (see Section 7)
This section describes the process to prevent two NFC Forum Devices in proximity from both
generating an Operating Field.
3. Activity and Profile Model (see Section 8)
This section describes the model used to represent functional blocks, called Activities, and
the dependencies and order between them, called Profiles.
4. Activities (see Section 9)
This section describes process flows and Configuration Parameters for the following building
blocks:
• Technology detection: detects whether there is another device to communicate with and,
if so, what technologies it supports
• Collision resolution: detects the presence of multiple devices and enumerates the
different identifiers
Listen Mode
3.1.1.1 For entering the Listen Mode state machine, the Operating Field MUST be
in the Operating Field Off state.
3.1.1.2 If the NFC Forum Device in Listen Mode responds to a single Poll
Command with a single Response, then the NFC Forum Device MUST
maintain a single state machine.
3.1.1.3 If the NFC Forum Device in Listen Mode responds to a single Poll
Command with multiple Responses, then the NFC Forum Device MUST
maintain the equivalent number of independent state machines (i.e. a state
machine for each Response).
3.1.1.4 The start state of the NFC Forum Device in Listen Mode is the
NO_REMOTE_FIELD State.
3.1.1.5 If No Remote Field Sensed and not in state NO_REMOTE_FIELD, the NFC
Forum Device MUST conclude the state machine and therefore the Listen
Mode within a delay not greater than tFIELD_OFF. Refer to Appendix B for the
value of tFIELD_OFF.
NOTE If the NFC Forum Device in Listen Mode responds to a single Poll Command with
multiple Responses, then the NFC Forum Device should foresee Configuration
Parameters for each Response and criteria for deciding which subset of Responses to
send, if all Responses cannot be sent.
NOTE For NFC-B and NFC-F, when sending multiple Responses, the NFC Forum Device
in Listen Mode should send a single Response within a single timeslot.
NOTE If the NFC Forum Device in Listen Mode is configured to support
CON_LISTEN_DEP_F and CON_LISTEN_T3TP, it must implement two
independent state machines, according to Requirement 3.1.1.3.
NO_REMOTE_FIELD
IDLE
READY-A
READY-A’
READY-A’’
ACTIVE_A
ATR_READY_A
TARGET_A
CARD_EMULATOR_4A
SLEEP_A
READY_A*
READY_A’*
READY_A’’*
ACTIVE_A*
READY_F
ATR_READY_F
TARGET_F
CARD_EMULATOR_3
SLEEP_AF
READY_B_REQU
READY_B_DECL
SLEEP_B
CARD_EMULATOR_4B
End State
NO_REMOTE_FIELD OTHER
SLEEP_A SLP_
SLP_ REQ
DESELECT OTHER OTHER OTHER OTHER
REQ OTHE
R
READY_A* SDD_R
ALL_ ALL_
EQ
REQ REQ
CL1
READY_A’* SEL_R
SDD_RE
EQ
Q CL2
CL13
READY_A’’* SEL_REQ SDD_RE
CL24 Q CL3
ACTIVE_A* SEL_
SEL_ SEL_
REQ
REQ CL26 REQ CL3
CL15
Begin State
NO_REMOTE_FIELD
IDLE
READY-A
READY-A’
READY-A’’
ACTIVE_A
ATR_READY_A
TARGET_A
CARD_EMULATOR_4A
SLEEP_A
READY_A*
READY_A’*
READY_A’’*
ACTIVE_A*
READY_F
ATR_READY_F
TARGET_F
CARD_EMULATOR_3
SLEEP_AF
READY_B_REQU
READY_B_DECL
SLEEP_B
CARD_EMULATOR_4B
End State
READY_F SENSF
SENSF_
OTHER _
REQ
REQ
ATR_READY_F ATR_
OTHER
REQ
TARGET_F DEP_
REQ,
PSL_ DEP_
PSL_
REQ REQ,
REQ
(F) OTHER
(F),
OTHER
CARD_EMULATOR_3 CUP CUP OTHER CUP
1
Except for Valid Type 1 Tag Commands. The NFC Forum Device does not change state if it implements Type 1 Tag and received a Valid Type 1 Tag Command.
2
Except for Valid Type 2 Tag Commands. The NFC Forum Device does not change state if it implements Type 2 Tag and received a Valid Type 2 Tag Command.
3
The SEL_REQ CL1 applies for this state change only when the NFC Forum Device in Listen Mode uses a double- or triple-size NFCID1.
4
The SEL_REQ CL2 applies for this state change only when the NFC Forum Device in Listen Mode uses a triple-size NFCID1.
5
The SEL_REQ CL1 applies for this state change only when the NFC Forum Device in Listen Mode uses a single-size NFCID1.
6
The SEL_REQ CL2 applies for this state change only when the NFC Forum Device in Listen Mode uses a double-size NFCID1.
Listen Mode
5.1.1.1 In the NO_REMOTE_FIELD State, if Remote Field Present, then the NFC Forum
Device MUST enter the IDLE State within the Guard Times as defined in
[DIGITAL].
Otherwise, the NFC Forum Device MAY conclude the Listen Mode.
Listen Mode
Listen Mode
5.2.1.7 If CON_LISTEN_T4BTP =1, the NFC Forum Device MUST enter the
READY_B_REQU Sub-state and it MUST NOT send a Response after it has received
a Valid SENSB_REQ Command that contains an N greater than 1, an AFI that
matched its own AFI, and its R is greater than 1.
5.2.1.8 If CON_LISTEN_T4BTP =1, the NFC Forum Device MUST enter the
READY_B_REQU Sub-state MUST NOT send a Response after it has received a
Valid ALLB_REQ Command that contains an N greater than 1, an AFI that matches
its own AFI, and its R is greater than 1.
5.2.1.9 If CON_LISTEN_T3TP=1 and the NFC Forum Device in Listen Mode has received
a Valid CHECK or UPDATE Command as defined in [T3TOP], the NFC Forum
Device MUST send its Response and it MUST enter the CARD_EMULATOR_3 Sub-
state.
If CON_LISTEN_T3TP=1, the NFC Forum Device in Listen Mode MAY enter the
CARD_EMULATOR_3 Sub-state after it has received a Proprietary Command.
Listen Mode
5.3.1.1 Upon receipt of a Valid SDD_REQ CL1 Command, the NFC Forum Device MUST
send its NFCID1 CL1 and stay in the READY_A (READY_A*) Sub-state.
5.3.1.2 Upon receipt of a Valid SEL_REQ CL1 Command with a matching NFCID1 CL1,
an NFC Forum Device with a single-size NFCID1 MUST send its SEL_RES
Response and it MUST enter the ACTIVE_A (ACTIVE_A*) Sub-state when it is
selected with its complete NFCID1. The NFC Forum Device MUST indicate in its
SEL_RES Response that the NFCID1 is complete.
5.3.1.3 Upon receipt of a Valid SEL_REQ CL1 Command with a matching NFCID1 CL1,
an NFC Forum Device with a double- or triple-size NFCID1 MUST send its
SEL_RES Response and it MUST enter the READY_A’ (READY_A’*) Sub-state.
5.3.1.4 If OTHER, the NFC Forum Device MUST NOT send a Response.
When in the READY_A Sub-state, the NFC Forum Device MUST return to the IDLE
State.
When in the READY_A* Sub-state, the NFC Forum Device MUST return to the
SLEEP_A Sub-state.
Listen Mode
5.4.1.1 Upon receipt of a Valid SDD_REQ CL2 Command, an NFC Forum Device MUST
send its NFCID1 CL2 and stay in the READY_A’ (READY_A’*) Sub-state.
5.4.1.2 Upon receipt of a Valid SEL_REQ CL2 Command with a matching NFCID1 CL2,
an NFC Forum Device with a double-size NFCID1 MUST send its SEL_RES
Response and it MUST enter the ACTIVE_A (ACTIVE_A*) Sub-state when it is
selected with its complete NFCID1. The NFC Forum Device MUST indicate in its
SEL_RES Response that the NFCID1 is complete.
5.4.1.3 Upon receipt of a Valid SEL_REQ CL2 Command with a matching NFCID1 CL2,
an NFC Forum Device with a triple-size NFCID1 MUST send its SEL_RES
Response and it MUST enter the READY_A” (READY_A”*)Sub-state.
5.4.1.4 If OTHER, the NFC Forum Device MUST NOT send a Response.
When in the READY_A' Sub-state, the NFC Forum Device MUST return to the
IDLE State.
When in the READY_A'* Sub-state, the NFC Forum Device MUST return to the
SLEEP_A Sub-state.
Listen Mode
5.5.1.1 Upon receipt of a Valid SDD_REQ CL3 Command, an NFC Forum Device MUST
send its NFCID1 CL3 and stay in the READY_A” (READY_A”*) Sub-state.
5.5.1.2 Upon receipt of a Valid SEL_REQ CL3 Command with a matching NFCID1 CL3,
an NFC Forum Device with a triple-size NFCID1 MUST send its SEL_RES
Response and it MUST enter the ACTIVE_A (ACTIVE*) Sub-state when it is
selected with its complete NFCID1. The NFC Forum Device MUST indicate in its
SEL_RES Response that the NFCID1 is complete.
5.5.1.3 If OTHER, the NFC Forum Device MUST NOT send a Response.
When in the READY_A" Sub-state, the NFC Forum Device MUST return to the
IDLE State.
When in the READY_A"* Sub-state, the NFC Forum Device MUST return to the
SLEEP_A Sub-state.
Listen Mode
5.6.1.1 Upon receipt of a Valid SLP_REQ Command, the NFC Forum Device MUST enter
the SLEEP_A Sub-state.
5.6.1.2 Upon receipt of a Valid ATR_REQ Command, the NFC Forum Device MUST send
its ATR_RES Response and it MUST enter the ATR_READY_A Sub-state.
5.6.1.3 If CON_LISTEN_T4ATP =1, the NFC Forum Device MUST send its ATS
Response and it MUST enter the CARD_EMULATOR_4A Sub-state after it has
received a Valid RATS Command,.
5.6.1.4 If OTHER as defined in Table 7, the NFC Forum Device MUST NOT send a
Response.
When in the ACTIVE_A Sub-state, the NFC Forum Device MUST return to the
IDLE State.
When in the ACTIVE_A* Sub-state, the NFC Forum Device MUST return to the
SLEEP_A Sub-state.
An NFC Forum Device MAY respond to Valid Type 2 Tag Commands and it MAY change state
accordingly.
Listen Mode
5.7.1.1 Upon receipt of a Valid ALL_REQ Command, the NFC Forum Device MUST send
its SENS_RES Response and it MUST enter the READY_A* Sub-state.
5.7.1.2 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the SLEEP_A Sub-state.
Listen Mode
5.8.1.1 Upon receipt of a Valid DEP_REQ Command, the NFC Forum Device MUST send
its DEP_RES Response and it MUST enter the TARGET_A Sub-state.
5.8.1.2 Upon receipt of a Valid PSL_REQ Command with DSI set to 000b, the NFC Forum
Device MUST send its PSL_RES Response and it MUST enter the TARGET_A Sub-
state.
Refer to [DIGITAL] for details on DSI coding.
5.8.1.3 Upon receipt of a Valid PSL_REQ Command with DSI set to 001b or 010b, the
NFC Forum Device MUST send its PSL_RES Response and it MUST enter the
TARGET_F Sub-state.
Refer to [DIGITAL] for details on DSI coding.
5.8.1.4 Upon receipt of a Valid DSL_REQ Command, the NFC Forum Device MUST send
its DSL_RES Response and it MUST enter the SLEEP_AF Sub-state.
5.8.1.5 Upon receipt of a Valid RLS_REQ Command, the NFC Forum Device MUST send
its RLS_RES Response and it MUST enter the IDLE State.
5.8.1.6 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the TARGET_A Sub-state.
Listen Mode
5.9.1.1 Upon receipt of a Valid DEP_REQ Command, the NFC Forum Device MUST send
its DEP_RES Response and stay in the TARGET_A Sub-state.
5.9.1.2 Upon receipt of a Valid DSL_REQ Command, the NFC Forum Device MUST send
its DSL_RES Response and it MUST enter the SLEEP_AF Sub-state.
5.9.1.3 Upon receipt of a Valid RLS_REQ Command, the NFC Forum Device MUST send
its RLS_RES Response and it MUST enter the IDLE State.
5.9.1.4 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the TARGET_A Sub-state.
Listen Mode
5.10.1.1 Upon receipt of a Valid S(DESELECT) Request (as defined in [DIGITAL]), the
NFC Forum Device MUST send its S(DESELECT) Response and it MUST enter
the SLEEP_A Sub-state.
5.10.1.2 Upon receipt of a Valid Command in compliance with the Type 4A Tag Platform as
specified in [DIGITAL], the NFC Forum Device MUST send its Response and it
MUST stay in the CARD_EMULATOR_4A Sub-state.
5.10.1.3 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the CARD_EMULATOR_4A Sub-state.
Listen Mode
5.11.1.1 Upon receipt of a Valid SENSB_REQ Command that contains an N equal to 1 and
an AFI that matches its own AFI, the NFC Forum Device MUST send its
SENSB_RES and it MUST enter the READY_B_DECL Sub-state.
5.11.1.2 Upon receipt of a Valid ALLB_REQ Command that contains an N equal to 1 and an
AFI that matches its own AFI, the NFC Forum Device MUST send its SENSB_RES
and it MUST enter the READY_B_DECL Sub-state.
5.11.1.3 Upon receipt of a Valid SENSB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send
its SENSB_RES and it MUST enter the READY_B_DECL.
5.11.1.4 Upon receipt of a Valid ALLB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send
its SENSB_RES and it MUST enter the READY_B_DECL Sub-state.
5.11.1.5 Upon receipt of a Valid SENSB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device
MUST NOT send a Response and it MUST stay in the READY_B_REQU Sub-state.
5.11.1.6 Upon receipt of a Valid ALLB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device
MUST NOT send a Response and it MUST stay in the READY_B_REQU Sub-state.
5.11.1.7 Upon receipt of a Valid SLOT_MARKER Command indicating a Slot number
matching R (as calculated at the reception of the last SENSB_REQ or ALLB_REQ),
the NFC Forum Device MUST send its SENSB_RES and it MUST enter the
READY_B_DECL Sub-state.
5.11.1.8 Upon receipt of a Valid SENSB_REQ Command that contains an AFI that does not
match its own AFI, the NFC Forum Device MUST NOT send its SENSB_RES and
it MUST enter the IDLE Sub-state.
5.11.1.9 Upon receipt of a Valid ALLB_REQ Command that contains an AFI that does not
match its own AFI, the NFC Forum Device MUST NOT send a Response and it
MUST enter the IDLE Sub-state.
5.11.1.10 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the READY_B_REQU Sub-state.
Listen Mode
5.12.1.1 Upon receipt of a Valid ATTRIB Command, the NFC Forum Device MUST send
its ATTRIB Response and it MUST enter the CARD_EMULATOR_4B Sub-state.
5.12.1.2 Upon receipt of a Valid SLPB_REQ Command, the NFC Forum Device MUST
send its SLPB_RES and it MUST enter the SLEEP_B Sub-state.
5.12.1.3 Upon receipt of a Valid SENSB_REQ Command that contains an N equal to 1 and
an AFI that matches its own AFI, the NFC Forum Device MUST send its
SENSB_RES and it MUST stay in the READY_B_DECL Sub-state.
5.12.1.4 Upon receipt of a Valid ALLB_REQ Command that contains an N equal to 1 and an
AFI that matches its own AFI, the NFC Forum Device MUST send its SENSB_RES
and it MUST stay in the READY_B_DECL Sub-state.
5.12.1.5 Upon receipt of a Valid SENSB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send
its SENSB_RES and it MUST stay in the READY_B_DECL Sub-state.
5.12.1.6 Upon receipt of a Valid ALLB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send
its SENSB_RES and it MUST stay in the READY_B_DECL Sub-state.
5.12.1.7 Upon receipt of a Valid SENSB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device
MUST NOT send a Response and it MUST enter the READY_B_REQU Sub-state.
5.12.1.8 Upon receipt of a Valid ALLB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device
MUST NOT send a Response and it MUST enter the READY_B_REQU Sub-state.
5.12.1.9 Upon receipt of a Valid SENSB_REQ Command that contains an AFI that does not
match its own AFI, the NFC Forum Device MUST NOT send a Response and it
MUST enter the IDLE Sub-state.
5.12.1.10 Upon receipt of a Valid ALLB_REQ Command that contains an AFI that does not
match its own AFI, the NFC Forum Device MUST NOT send a Response and it
MUST enter the IDLE Sub-state.
5.12.1.11 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the READY_B_DECL Sub-state.
Listen Mode
5.13.1.1 Upon receipt of a Valid ALLB_REQ Command that contains an N equal to 1 and an
AFI that matches its own AFI, the NFC Forum Device MUST send its SENSB_RES
and it MUST enter the READY_B_DECL Sub-state.
5.13.1.2 Upon receipt of a Valid ALLB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send
its SENSB_RES and it MUST enter the READY_B_DECL Sub-state.
5.13.1.3 Upon receipt of a Valid ALLB_REQ Command that contains an N greater than 1,
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device
MUST NOT send a Response and it MUST enter the READY_B_REQU Sub-state.
5.13.1.4 Upon receipt of a Valid ALLB_REQ Command that contains an AFI that does not
match its own AFI, the NFC Forum Device MUST NOT send a Response and it
MUST enter the IDLE Sub-state.
5.13.1.5 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the SLEEP_B Sub-state.
Listen Mode
5.14.1.1 Upon receipt of a Valid S(DESELECT) Request (as defined in [DIGITAL]), the
NFC Forum Device MUST send its S(DESELECT) Response and it MUST enter
the SLEEP_B Sub-state.
5.14.1.2 Upon receipt of a Valid Command in compliance with the Type 4B Tag Platform as
specified in [DIGITAL], the NFC Forum Device MUST send its Response and it
MUST stay in the CARD_EMULATOR_4B Sub-state.
5.14.1.3 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the CARD_EMULATOR_4B Sub-state.
Listen Mode
5.15.1.1 Upon receipt of a Valid ATR_REQ Command, the NFC Forum Device MUST send
its ATR_RES Response and it MUST enter the ATR_READY_F Sub-state.
5.15.1.2 Upon receipt of a Valid CHECK or UPDATE Command as referred to in
[DIGITAL] and defined in [T3TOP], the NFC Forum Device MUST send its
Response and MUST enter the CARD_EMULATOR_3 Sub-state.
5.15.1.3 Upon receipt of a Valid SENSF_REQ Command, the NFC Forum Device MUST
compare the value of SC in the SENSF_REQ sequentially with the system code
values contained in CON_SYS_CODE. If the values correspond according to the
conditions defined below, the NFC Forum Device in Listen Mode MUST stop the
comparison, it must send its Response, and it MUST stay in the READY_F Sub-state.
An SC value in SENSF_REQ corresponds to the value contained in
CON_SYS_CODE at index X:
• If the value of SC in the SENSF_REQ Command is equal to FFFFh, or
• If the value of SC in the SENSF_REQ is equal to the value of
CON_SYS_CODE[X], or
• If the first byte of SC in the SENSF_REQ Command has a value of FFh and the
value of the second byte equals the value of the second byte of
CON_SYS_CODE[X], or
• If the second byte of SC in the SENSF_REQ Command has a value of FFh and
the value of the first byte equals the value of the first byte of the
CON_SYS_CODE[X]
If the NFC Forum Device will include the RD bytes in the SENSF_RES according
to the requirements given in [DIGITAL], the value of the RD bytes must be equal to
the matching CON_SYS_CODE value.
5.15.1.4 If OTHER, except for Proprietary Commands, the NFC Forum Device MUST NOT
send a Response and it MUST stay in the READY_F Sub-state.
Upon receipt of a Proprietary Command, the NFC Forum Device MAY enter the
CARD_EMULATOR_3 Sub-state.
Listen Mode
5.16.1.1 Upon receipt of a Valid DEP_REQ Command, the NFC Forum Device MUST send
its DEP_RES Response and it MUST enter the TARGET_F Sub-state.
5.16.1.2 Upon receipt of a Valid PSL_REQ Command with DSI set to 001b or 010b, the
NFC Forum Device MUST send its PSL_RES Response and it MUST enter the
TARGET_F Sub-state.
Refer to [DIGITAL] for details regarding DSI coding.
5.16.1.3 Upon receipt of a Valid PSL_REQ Command with DSI set to 000b, the NFC Forum
Device MUST send its PSL_RES Response and it MUST enter the TARGET_A Sub-
state.
Refer to [DIGITAL] for details regarding DSI coding.
5.16.1.4 Upon receipt of a Valid RLS_REQ Command, the NFC Forum Device MUST send
its RLS_RES Response and it MUST enter the IDLE Sub-state.
5.16.1.5 Upon receipt of a Valid DSL_REQ Command, the NFC Forum Device MUST send
its DSL_RES Response and it MUST enter the SLEEP_AF Sub-state.
5.16.1.6 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the ATR_READY_F Sub-state.
Listen Mode
5.17.1.1 Upon receipt of a Valid DEP_REQ Command, the NFC Forum Device MUST send
its DEP_RES Response and it MUST stay the TARGET_F Sub-state.
5.17.1.2 Upon receipt of a Valid RLS_REQ Command, the NFC Forum Device MUST send
its RLS_RES Response and it MUST enter the IDLE Sub-state.
5.17.1.3 Upon receipt of a Valid DSL_REQ Command, the NFC Forum Device MUST send
its DSL_RES Response and it MUST enter the SLEEP_AF Sub-state.
5.17.1.4 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the TARGET_F Sub-state.
Listen Mode
5.18.1.1 Upon receipt of a Valid Command in compliance with the Type 3 Tag Platform as
specified in [DIGITAL], the NFC Forum Device MUST send its Response and it
MUST stay in the CARD_EMULATOR_3 Sub-state.
Upon receipt of a Proprietary Command, the NFC Forum Device MAY send its Response and
stay in the CARD_EMULATOR_3 Sub-state
5.18.1.2 If OTHER, except for Proprietary Commands, the NFC Forum Device MUST NOT
send a Response and it MUST stay in the CARD_EMULATOR_3 Sub-state.
Listen Mode
5.19.1.4 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay
in the SLEEP_AF Sub-state.
6.1.1.1 When the NFC Forum Device in Poll Mode sets the Operating Field to the
Operating Field Off state (carrier off, as defined in [ANALOG]) other than for
NFC-A modulation purposes, then the Operating Field MUST be set to Operating
Field Off state for a time of at least tFIELD_OFF.
Refer to Appendix B for the value of tFIELD_OFF.
6.1.1.2 When the NFC Forum Device in Poll Mode generates a Poll Command initially
after setting the Operating Field to Operating Field On state or when generating
subsequent Poll Command of different technology, these MUST be preceded by a
period during which the NFC Forum Devices sends Unmodulated Carrier (as
defined in [ANALOG]). The duration of this period is referred to as Guard Time
and the NFC Forum Device MUST comply with the following Guard Times:
• GTA for NFC-A
• GTB for NFC-B
• GTF for NFC-F
If polling for NFC-F is preceded by polling for NFC-B, then GTF is equal to GTBF.
Otherwise, GTF is equal to GTFB.
For a more detailed definition of the Guard Times for each technology, see
[DIGITAL].
Refer to Appendix B for the values of GTA, GTB, GTBF and GTFB.
This does not apply to consecutive Poll Commands as well as a Poll Command following a
Sleep Command.
6.1.1.3 For the NFC Forum Device in Poll Mode, if the PSL_REQ Command is used, it
MUST be sent as the first Command of the NFC-DEP Protocol Data Exchange, i.e.,
before the first DEP_REQ Command.
• The PSL_REQ (A) as used in the state machine is a PSL_REQ with DSI set to
000b.
• The PSL_REQ (F) as used in the state machine is a PSL_REQ with DSI set to
001b or 010b.
Refer to [DIGITAL] for the coding of the PSL_REQ Command.
6.1.1.4 An NFC Forum Device MUST perform RF Collision Avoidance (see Section 7)
before generating an Operating Field.
6.1.1.5 When the NFC Forum Device in Poll Mode includes Poll Commands for one or
more Proprietary Technologies, then the Proprietary Technologies MUST be polled
after the NFC Technology(ies).
6.1.1.6 For introducing Proprietary Technologies, the NFC Forum Device MUST wait with
Unmodulated Carrier for a period after a Poll Command. The duration of this period
is the sum of FDT/FWT for the Poll Command and the Proprietary Technology
Guard Time.
The resulting timings are:
• If polling for Proprietary Technology is preceded immediately by polling for
NFC-A, then the time PTGTA + FDTA,LISTEN,MAX MUST be applied.
• If polling for Proprietary Technology is preceded immediately by polling for
NFC-B, then the time PTGTB + FWTSENSB MUST be applied.
• If polling for Proprietary Technology is preceded immediately by polling for
NFC-F, then the time PTGTF + FDTF,LISTEN,SENSF_REQ MUST be applied.
Refer to [DIGITAL] for details regarding FDTA,LISTEN,MAX, FWTSENSB, and
FDTF,LISTEN,SENSF_REQ.
Refer to Appendix B for the values of PTGTA, PTGTB, and PTGTF.
sense field
2
No Remote
Field
Yes
3
put field on
Poll Mode
7.1.1.1 Symbol 1:
The NFC Forum Device MUST check during a time TID + n × TRFW No Remote Field
Sensed.
• TID MUST be greater than 4096/fc.
• TRFW MUST be equal to 512/fc.
• The integer value of 0 ≤ n ≤ 3 MUST be randomly generated.
7.1.1.2 Symbol 2:
If No Remote Field Sensed, after having listened according to Symbol 1, the NFC
Forum Device MUST proceed to Symbol 3.
Otherwise, the NFC Forum Device MUST conclude RF Collision Avoidance.
7.1.1.3 Symbol 3:
The NFC Forum Device MUST turn the Operating Field to the Operating Field On
state, as defined in [ANALOG] and it MUST conclude RF Collision Avoidance.
Greedy
Input Activity Collection
Output
Figure 3: Activity
Initialization
Activity
Resolution
Activity
Process
Greedy
Collection
Activity
Clean-up
Figure 4: Profile
9.1.1.1 For each combination of Activities in Poll Mode, the Operating Field MUST be in
the Operating Field On state (see Section 7).
9.1.1.2 For each combination of Activities in Poll Mode, the first Activity MUST be the
Technology Detection Activity.
9.2.1 Pre-conditions
The Configuration Parameters for the Technology Detection Activity are listed in Table 8:
NOTE There is no bail-out option for NFC-F as bail-out is mandatory before polling for a
Proprietary Technology and the NFC Forum Device always checks whether an NFC
Technology has been detected. The bail-out options for NFC-A and NFC-B are
introduced to allow optimization.
There are no Input Parameters requested from the Resolution Process for this Activity.
There is no data needed from the Greedy Collection for this Activity.
9.2.2 Post-conditions
The output of the Technology Detection Activity is listed in Table 9:
NOTE The outcome of polling for proprietary technology is outside of the scope of this
specification and therefore such result does not appear as an Output Parameter.
The data returned to the Greedy Collection is listed in Table 10:
Figure 5 shows the processing flow for the NFC Forum Device during the Technology Detection
Activity.
1
FOUND_A := 0
FOUND_B := 0
FOUND_F := 0
2 8 15 21
no no no no
CON_POLL_A CON_POLL_B CON_POLL_F CON_POLL_P
=1? =1? =1? =1?
4 10 17 23
ALL_REQ / ALLB_REQ /
SENSF_REQ out of scope
SES_REQ SENSB_REQ
5 11 18
no no no
response ? response ? response ?
7 13
no no
CON_BAIL_OUT_A CON_BAIL_OUT_B
=1? =1?
yes yes
14 20
no FOUND_A, no
FOUND_A or FOUND_B or
FOUND_B FOUND_F
=1? =1?
yes yes
Poll Mode
9.2.3.1 Symbol 1:
The NFC Forum Device MUST initialize the following flags to zero:
• FOUND_A := 0
• FOUND_B := 0
• FOUND_F := 0
9.2.3.2 Symbol 2:
If the NFC Forum Device is configured to poll for NFC-A Technology (i.e.,
CON_POLL_A = 1), then the NFC Forum Device MUST proceed to Symbol 3.
Otherwise, the NFC Forum Device MUST proceed to Symbol 8.
9.2.3.3 Symbol 3:
Before proceeding, the NFC Forum Device MUST maintain an Unmodulated Carrier
for at least GTA.
Refer to [DIGITAL] for the value of GTA.
9.2.3.4 Symbol 4:
The NFC Forum Device MUST send an ALL_REQ or SENS_REQ Command and it
MUST wait for a Response afterward as defined in [DIGITAL].
9.2.3.5 Symbol 5:
If the NFC Forum Device does not receive a Response to the ALL_REQ or
SENS_REQ Commands, then NFC Forum Device MUST proceed to Symbol 8.
Otherwise, the NFC Forum Device MUST store the Response in GRE_POLL_A[]
and it MUST proceed to Symbol 6.
9.2.3.6 Symbol 6:
The NFC Forum Device MUST set FOUND_A to 1.
9.2.3.7 Symbol 7:
If the NFC Forum Device is configured for bail-out upon detection of NFC-A
Technology (i.e., CON_BAIL_OUT_A = 1), then the NFC Forum Device MUST
conclude the Technology Detection Activity.
Otherwise, the NFC Forum Device MUST proceed to Symbol 8.
9.2.3.8 Symbol 8:
If the NFC Forum Device is configured to poll for NFC-B Technology (i.e.,
CON_POLL_B = 1), then the NFC Forum Device MUST proceed to Symbol 9.
Otherwise, the NFC Forum Device MUST proceed to Symbol 15.
Poll Mode
9.2.3.9 Symbol 9:
Before proceeding, the NFC Forum Device MUST maintain an Unmodulated Carrier
for at least GTB.
Refer to [DIGITAL] for the value of GTB.
9.2.3.10 Symbol 10:
The NFC Forum Device MUST send an ALLB_REQ or a SENSB_REQ Command
with number of slots set equal to 1 (N=1) and it MUST wait for a Response afterward
as defined in [DIGITAL].
9.2.3.11 Symbol 11:
If the NFC Forum Device does not receive a Response to the ALLB_REQ or
SENSB_REQ Commands, then the NFC Forum Device MUST proceed to
Symbol 13.
Otherwise, the NFC Forum Device MUST store the Response in GRE_POLL_B[]
and it MUST proceed to Symbol 12.
9.2.3.12 Symbol 12:
The NFC Forum Device MUST set FOUND_B to 1.
9.2.3.13 Symbol 13:
If the NFC Forum Device is configured for bail-out upon detection of NFC-B
Technology (i.e., CON_BAIL_OUT_B = 1), then the NFC Forum Device MUST
proceed to Symbol 14.
Otherwise, the NFC Forum Device MUST proceed to Symbol 15.
9.2.3.14 Symbol 14:
If FOUND_A or FOUND_B has a value equal to 1, the NFC Forum Device MUST
conclude the Technology Detection Activity.
Otherwise, the NFC Forum Device MUST proceed to Symbol 15.
9.2.3.15 Symbol 15:
If the NFC Forum Device is configured to poll for NFC-F Technology (i.e.,
CON_POLL_F = 1), then the NFC Forum Device MUST proceed to Symbol 16.
Otherwise, the NFC Forum Device MUST proceed to Symbol 20.
9.2.3.16 Symbol 16:
Before proceeding, the NFC Forum Device MUST maintain an Unmodulated Carrier
for at least GTF.
For more details on GTF, see requirement 6.1.1.3.
9.2.3.17 Symbol 17:
The NFC Forum Device MUST send a SENSF_REQ Command with number of slots
equal to 4 (TSN = 03h), SC = FFFFh, RC = 00h at the bit rate configured by the
CON_BITR and it MUST wait for a Response afterward as defined in [DIGITAL].
Poll Mode
9.3.1 Pre-conditions
The Configuration Parameters for the Collision Resolution Activity are listed in Table 11:
The Input Parameters for the Collision Resolution Activity are listed in Table 12:
The data requested from the Greedy Collection is listed in Table 13:
9.3.2 Post-conditions
The Output Parameters returned to the Resolution Process are listed in Table 14:
1
yes
INT_TECH_SEL A
= 00b ?
no
2
yes
INT_TECH_SEL B
= 01b ?
no
3
yes
INT_TECH_SEL F
= 10b ?
no
0
collision res. no
supported ?
yes
1
CON_ no
ANTICOLL
=1?
22
yes
2 send
device counter := 0 RID
21 INT_COLL_PEND := 0
send 23
SENS_REQ collision in no
3 response?
select
cascade level 1 yes
24 25
4 INT_COLL_PEND := 1 INT_COLL_PEND := 0
assign SEL_CMD
26
5
store NFCID1
assign SEL_PAR
6
send
SDD_REQ
7
collision in no
response?
yes
8 13
INT_COLL_PEND := 1 INT_COLL_PEND := 0
9
yes CON_
DEVICES_LIMIT =
0?
no
10
specifiy
number of valid bits
11
send SDD_REQ
12
collision in yes
response?
no
14
send SEL_REQ
16
15
increase no NFCID1
cascade level complete ?
yes
17
Increment
device counter
18
store NFCID1
20
19
yes
send SLP_REQ resolve more ?
no
Poll Mode
9.3.4.1 Symbol 0:
If the SENS_RES is a Valid Response and indicates the bit frame SDD support, the
NFC Forum Device MUST proceed to Symbol 1.
Otherwise, the NFC Forum Device proceeds with Symbol 22.
9.3.4.2 Symbol 1:
If CON_ANTICOLL has a value of 1, the NFC Forum Device MUST proceed to
Symbol 2.
Otherwise, the NFC Forum Device proceeds with Symbol 22.
9.3.4.3 Symbol 2:
The NFC Forum Device MUST initialize the device counter with a value of 0 and
INT_COLL_PEND with a value of 0. The NFC Forum Device MUST initialize
INT_NFCIDX_SLEEP[] with 0.
9.3.4.4 Symbol 3:
The NFC Forum Device MUST select SDD cascade level 1.
9.3.4.5 Symbol 4:
The NFC Forum Device MUST assign SEL_CMD with the code for the selected
SDD cascade level.
9.3.4.6 Symbol 5:
The NFC Forum Device MUST set SEL_PAR to the value of 20h, indicating that no
data bits are following.
9.3.4.7 Symbol 6:
The NFC Forum Device MUST send the SDD_REQ Command. Refer to [DIGITAL]
for the coding of the SDD_REQ Command.
9.3.4.8 Symbol 7:
If the NFC Forum Device detects a Collision in the Response to the SDD_REQ
Command, the NFC Forum Device MUST proceed to Symbol 8.
Otherwise, the NFC Forum Device MUST proceed to Symbol 13.
9.3.4.9 Symbol 8:
The NFC Forum Device MUST set INT_COLL_PEND to a value of 1 to indicate a
pending collision.
Poll Mode
9.3.4.10 Symbol 9:
If the CON_DEVICES_LIMIT has a value of 0, then the NFC Forum Device MUST
conclude the NFC-A Collision Resolution Activity (i.e., the NFC Forum Device is
configured to perform collision detection only).
Otherwise, the NFC Forum Device MUST proceed to Symbol 10.
9.3.4.11 Symbol 10:
The NFC Forum Device MUST set SEL_PAR to a value that specifies the number of
valid bits of NFCID1 CLn. The valid bits are part of the NFCID1 CLn that was
received before a collision occurred, followed by 1b (i.e., the position of the first
collision in the Response to the previous SDD_REQ Command is set to 1b).
9.3.4.12 Symbol 11:
The NFC Forum Device MUST send the SDD_REQ Command including the data
bits as indicated by SEL_PAR.
9.3.4.13 Symbol 12:
If the NFC Forum Device detects a Collision in the Response to the SDD_REQ
Command, the NFC Forum Device MUST proceed to Symbol 10.
Otherwise, the NFC Forum Device MUST proceed to Symbol 14.
9.3.4.14 Symbol 13:
The NFC Forum Device MUST reset INT_COLL_PEND to a value of 0 and proceed
to Symbol 14.
9.3.4.15 Symbol 14:
The NFC Forum Device MUST send the SEL_REQ Command. Refer to [DIGITAL]
for the coding of the SEL_REQ Command.
9.3.4.16 Symbol 15:
The NFC Forum Device MUST check the cascade tag of the SEL_RES Response.
If the cascade tag indicates that NFCID1 is complete, then the NFC Forum Device
MUST proceed to Symbol 17.
Otherwise, the NFC Forum Device MUST proceed to Symbol 16.
9.3.4.17 Symbol 16:
The NFC Forum Device MUST increase the cascade level.
The NFC Forum Device MUST proceed to Symbol 4.
9.3.4.18 Symbol 17:
The NFC Forum Device MUST increment the device counter by 1.
9.3.4.19 Symbol 18:
The NFC Forum Device MUST store the SEL_RES Response in GRE_SEL_RES[]
and it MUST store the NFCID1 identifier in INT_NFCIDX[device counter-1].
Poll Mode
device counter := 0
number of slots := 1
1
Yes
SENSB_RES
valid ?
No
2
Yes CON_
DEVICES_LIMIT =
0?
19 No
INT_COLL_PEND := 1
3
current slot number := 0
INT_COLL_PEND := 0
4
Yes
slot empty?
18
No send
SENSB_REQ
Yes 5
SENSB_RES
7 valid ?
increment No
device counter 6
8 INT_COLL_PEND := 1
memorize
device identifier
9
resolve more ?
No
Yes
10
put device in
SLEEP
11
increment current 20
slot number send
Slot_Marker
command
12
No
last slot ?
Yes
13
No
INT_COLL_PEND
=1?
Yes
16
14 max 15
No No increase
device number of slots number of
identified? reached? slots
Yes Yes
17
Yes
resolve more ?
No
Poll Mode
9.3.5.1 Symbol 0:
The NFC Forum Device MUST assign a parameter containing the device counter and
it MUST initialize this parameter with 0.
The NFC Forum Device MUST assign a parameter containing the number of slots
and it MUST initialize this parameter with 1.
The NFC Forum Device MUST initialize INT_NFCIDX_SLEEP[] with 0.
9.3.5.2 Symbol 1:
The NFC Forum Device MUST read GRE_POLL_B[1], containing the most recent
SENSB_RES Response.
If the SENSB_RES Response is Valid, then the NFC Forum Device MUST proceed
to Symbol 3.
Otherwise, the NFC Forum Device MUST proceed to Symbol 2.
9.3.5.3 Symbol 2:
If the CON_DEVICES_LIMIT has a value of 0 (i.e., the NFC Forum Device is
configured to perform collision detection only), then the NFC Forum Device MUST
proceed to Symbol 19.
Otherwise, the NFC Forum Device MUST proceed to Symbol 3.
9.3.5.4 Symbol 3:
The NFC Forum Device MUST assign a parameter containing the current slot
number and it MUST initialize this parameter with 0.
The NFC Forum Device MUST initialize INT_COLL_PEND with 0.
9.3.5.5 Symbol 4:
If the NFC Forum Device did not receive a Response in the slot corresponding to the
current slot number, then the NFC Forum Device MUST proceed to Symbol 11.
Otherwise, the NFC Forum Device MUST proceed to Symbol 5.
9.3.5.6 Symbol 5:
If the last SENSB_RES Response that the NFC Forum Device has memorized is
Valid, then the NFC Forum Device MUST proceed to Symbol 7.
Otherwise, the NFC Forum Device MUST proceed to Symbol 6.
9.3.5.7 Symbol 6:
The NFC Forum Device MUST set INT_COLL_PEND to 1.
The NFC Forum Device MUST proceed to Symbol 11.
9.3.5.8 Symbol 7:
The NFC Forum Device MUST increment the device counter.
Poll Mode
9.3.5.9 Symbol 8:
The NFC Forum Device MUST store the NFCID0 identifier to
INT_NFCIDX[device counter-1].
9.3.5.10 Symbol 9:
If the device counter is lower than the CON_DEVICES_LIMIT, then the NFC Forum
Device MUST proceed to Symbol 10.
Otherwise, the NFC Forum Device MUST conclude the NFC-B Collision Resolution
Activity.
9.3.5.11 Symbol 10:
The NFC Forum Device MUST send a SLPB_REQ Command to put the device
resolved in the SLEEP_B Sub-state and it MUST set
INT_NFCIDX_SLEEP[device counter-1] equal to 1.
9.3.5.12 Symbol 11:
The NFC Forum Device MUST increment the current slot number, indicating the
current slot in which to receive SENSB_RES Responses.
9.3.5.13 Symbol 12:
If the current slot number is equal to the last slot, then the NFC Forum Device MUST
proceed to Symbol 13.
Otherwise, the NFC Forum Device MUST proceed to Symbol 20.
9.3.5.14 Symbol 13:
If INT_COLL_PEND has a value of 1, then the NFC Forum Device MUST proceed
to Symbol 14.
Otherwise, the NFC Forum Device MUST conclude the NFC-B Collision Resolution
Activity.
9.3.5.15 Symbol 14:
If subsequent to the last SENSB_REQ Command, the NFC Forum Device resolved
an identifier of a responding device (i.e., the identifier of the responding device has
been memorized), then the NFC Forum Device MUST proceed to Symbol 17.
Otherwise (i.e., no identifier was resolved), the NFC Forum Device MUST proceed
to Symbol 15.
9.3.5.16 Symbol 15:
If the number of slots is equal to the maximum value allowed, then the NFC Forum
Device MUST conclude the NFC-B Collision Resolution Activity.
Otherwise, the NFC Forum Device MUST proceed to Symbol 16.
The maximum value allowed for the number of slots is specified in [DIGITAL]
within the SENSB_REQ Command.
Poll Mode
0
INT_NFCIDX_SLEEP[]
:= 0
INT_COLL_PEND := 0
1
populate
INT_NFCIDX[]
2
populate
GRE_SENSF_RES[]
3
Yes
resolve more ?
4
No send SENSF_REQ
(TSN := 0Fh, RC :=
00h,SC := FFFFh)
5
update
GRE_SENSF_RES[]
update INT_NFCIDX[]
Poll Mode
9.3.6.1 Symbol 0:
The NFC Forum Device MUST set INT_COLL_PEND to 0 and it MUST initialize
INT_NFCIDX_SLEEP[] with 0.
9.3.6.2 Symbol 1:
The NFC Forum Device MUST assign a parameter device counter and it MUST
initialize this parameter with 0.
The NFC Forum Device MUST read GRE_POLL_F[], which contains the
SENSF_RES Response(s) to the preceding SENSF_REQ Commands. For each Valid
SENSF_RES Response, the NFC Forum Device MUST increment the device counter
by 1, it MUST extract the NFCID2, and it MUST store it in INT_NFCIDX[device
counter].
9.3.6.3 Symbol 2:
The NFC Forum Device MUST copy each Valid SENSF_RES Response contained in
GRE_POLL_F[] into GRE_SENSF_RES[].
9.3.6.4 Symbol 3:
If the value of device counter (the number of Valid SENSF_RES Responses retrieved
from Greedy Collection) is lower than the value of the CON_DEVICES_LIMIT
parameter, the NFC Forum Device MUST proceed to Symbol 4. Otherwise, the NFC
Forum Device MUST conclude the NFC-F Collision Resolution Activity.
9.3.6.5 Symbol 4:
The NFC Forum Device MUST send a SENSF_REQ Command with TSN set to 0fh,
RC set to 00h and SC set to FFFFh and it MUST wait for a Response afterward as
defined in [DIGITAL].
9.3.6.6 Symbol 5:
The NFC Forum Device MUST remove all entries from GRE_SENSF_RES[] and
then store any Valid SENSF_RES Response(s) received during processing of Symbol
4 in GRE_SENSF_RES[].
9.3.6.7 Symbol 6:
The NFC Forum Device MUST remove all entries from INT_NFCIDX[]. Then, the
NFC Forum Device MUST extract the NFCID2 for each entry in
GRE_SENSF_RES[] and it MUST store NFCID2 in INT_NFCIDX[].
Afterward, the NFC Forum Device MUST conclude the NFC-F Collision Resolution
Activity.
9.4.1 Pre-conditions
The Configuration Parameters for the Device Activation Activity are listed in Table 16:
The Input Parameters for the Device Activation Activity are listed in Table 17:
9.4.2 Post-conditions
The Output Parameters returned to the Resolution Process are listed in Table 19:
NOTE There is no Greedy Collection for the Type 1 Tag Platform or Type 2 Tag Platform:
NOTE For the Type 1 Tag Platform, the result of the RID Command is captured in the
NFCID, as part of the Collision Resolution Activity.
NOTE For the Type 2 Tag Platform, the outcome of the device activation (by means of a
Valid READ or WRITE Command) is part of the Data Exchange Activity.
1
Yes
INT_TECH_SEL DA_1
= 00b ?
No
2
Yes
INT_TECH_SEL DA_2
= 01b ?
no
3
Yes
INT_TECH_SEL DA_3
= 10b ?
No
Figure 10: Device Activation Activity (Sheet 1, Entry) – Normative Flow Chart
DA_1
INT_PROTOCOL
YES = 010b ?
NO
1
DEVICE IN NO
SLEEP_A SUB-
STATE?
YES
2
ALL_REQ
3
YES
NFCID1 SIZE IS
SINGLE?
NO
4 5
SEL_REQ CL1: SEL_REQ CL1:
SEL_CMD := '93' SEL_CMD := '93'
DATA = CT nfcid10 nfcid11 nfcid12 BCC DATA = nfcid10 nfcid11 nfcid12 nfcid13 BCC
6
YES
NFCID1 SIZE IS
DOUBLE?
NO
7 8
SEL_REQ CL2: SEL_REQ CL2:
SEL_CMD := '95' SEL_CMD := '95'
DATA = nfcid13 nfcid14 nfcid15 nfcid16 BCC DATA = CT nfcid13 nfcid14 nfcid15 BCC
9
SEL_REQ CL3:
SEL_CMD := '97'
DATA = nfcid16 nfcid17 nfcid18 nfcid19 BCC
10
INT_PROTOCOL YES
= 001b ?
NO
12
YES INT_PROTOCOL
= 011b ?
NO
13 11
ATR_REQ RATS
14
YES
Send
PSL_REQ? 15
NO PSL_REQ
Figure 11: Device Activation Activity (Sheet 2, Connector DA_1, NFC-DEP (NFC-A), Type 1,
2 & 4A Tag Platform) – Flow Chart
Requirements 28: Device Activation Activity – NFC-DEP (NFC-A), Type 1, 2, & 4A Tag
Platform
Poll Mode
9.4.4.1 Symbol 0:
If INT_PROTOCOL is equal to 010b, then the NFC Forum Device MUST conclude
the Activation Activity.
9.4.4.2 Symbol 1:
If INT_NFCIDX_SLEEP[INT_INDEX] is equal to 1b (i.e., the device is in SLEEP_A
Sub-state), then the NFC Forum Device MUST proceed to Symbol 2.
Otherwise, the NFC Forum Device MUST proceed to Symbol 10.
9.4.4.3 Symbol 2:
The NFC Forum Device MUST send an ALL_REQ Command.
9.4.4.4 Symbol 3:
If the SENS_RES indicates a single size NFCID1, then the NFC Forum Device
MUST proceed to Symbol 5.
Otherwise, the NFC Forum Device MUST proceed to Symbol 4.
9.4.4.5 Symbol 4:
If INT_NFCIDX [INT_INDEX] indicates a double- or triple-size NFCID1, then the
NFC Forum Device MUST first select cascade level 1 by sending a SEL_REQ
Command with SEL_CMD = 93h and NFCID1 CL1, before continuing with cascade
level 2.
The NFC Forum Device MUST proceed to Symbol 6.
9.4.4.6 Symbol 5:
The NFC Forum Device MUST send a SEL_REQ Command with SEL_CMD = 93h
and NFCID1 CL1 (of INT_NFCIDX [INT_INDEX]).
9.4.4.7 Symbol 6:
If INT_NFCIDX[INT_INDEX] indicates a double-size NFCID1, then the NFC
Forum Device MUST proceed to Symbol 7.
Otherwise, the NFC Forum Device MUST proceed to Symbol 8.
9.4.4.8 Symbol 7:
The NFC Forum Device MUST send a SEL_REQ Command with SEL_CMD = 95h
and NFCID1 CL2 (of INT_NFCIDX [INT_INDEX]).
The NFC Forum Device MUST proceed to Symbol 10.
Poll Mode
9.4.4.9 Symbol 8:
If INT_NFCIDX[INT_INDEX] indicates a triple-size NFCID1, then the NFC Forum
Device MUST first select cascade level 2 by sending a SEL_REQ Command with
SEL_CMD= 95h and NFCID1 CL2, before continuing with cascade level 3. Refer to
[DIGITAL] for SENS_RES coding.
9.4.4.10 Symbol 9:
The NFC Forum Device MUST send a SEL_REQ Command with SEL_CMD = 97h
and NFCID1 CL3 (of INT_NFCIDX [INT_INDEX]).
9.4.4.11 Symbol 10:
If INT_PROTOCOL is equal to 001b, then the NFC Forum Device MUST proceed to
Symbol 11.
Otherwise, the NFC Forum Device MUST proceed to Symbol 12.
9.4.4.12 Symbol 11:
The NFC Forum Device MUST send a RATS Command as specified in [DIGITAL],
containing the CON_RATS. The NFC Forum Device MUST handle the RATS
Response as specified in [DIGITAL]. If a Valid RATS Response is received, the
NFC Forum Device MUST store the RATS Response to GRE_RATS and it MUST
conclude the NFC-A Activation Activity.
9.4.4.13 Symbol 12:
If INT_PROTOCOL is equal to 011b, then the NFC Forum Device MUST conclude
the NFC-A Activation Activity.
Otherwise, the NFC Forum Device MUST proceed to Symbol 13.
9.4.4.14 Symbol 13:
The NFC Forum Device MUST send an ATR_REQ Command as specified in
[DIGITAL], containing the identifier INT_NFCIDX [INT_INDEX]. The NFC Forum
Device MUST handle the ATR_RES Response as specified in [DIGITAL]. If a Valid
ATR_RES Response is received, the NFC Forum Device MUST
• Set INT_NFCIDX_SLEEP[INT_INDEX] equal to 0b
• Store the ATR_RES Response to GRE_ATR
• Conclude the NFC-A Activation Activity
Poll Mode
NOTE For activation of a Type 2 Tag Platform, the NFC Forum Device send a Valid Read
or Write Command in compliance with the Type 2 Tag Platform as specified in
[DIGITAL], handles the Response as specified in [DIGITAL], and concludes
NFC-A Device Activation Activity.
NOTE If DSI has been set to 001 or 010b and a valid PSL_RES Response has been
received, the further communication uses NFC-F technology.
DA_2
0
DEVICE IN NO
SLEEP_B SUB-
STATE?
YES
1
ALLB_REQ
ATTRIB
Figure 12: Device Activation Activity (Sheet 3, Connector DA_2, Type 4B Tag Platform) –
Flow Chart
Poll Mode
9.4.5.1 Symbol 0:
If INT_NFCIDX_SLEEP[INT_INDEX] is equal to 1b (i.e. the device is in SLEEP_B
Sub-state), then the NFC Forum Device MUST proceed to Symbol 1.
Otherwise, the NFC Forum Device MUST proceed to Symbol 3.
9.4.5.2 Symbol 1:
The NFC Forum Device MUST send an ALLB_REQ Command as specified in
[DIGITAL].
9.4.5.3 Symbol 2:
The NFC Forum Device MUST set INT_NFCIDX_SLEEP[0:n] equal to 0b
9.4.5.4 Symbol 3:
The NFC Forum Device MUST send an ATTRIB Command as specified in
[DIGITAL], containing the NFCID0 included in INT_NFCIDX. If a Valid ATTRIB
Response is received, the NFC Forum Device MUST store the ATTRIB Response to
GRE_ATTRIB and it MUST conclude the NFC-B Activation Activity. Refer to
[DIGITAL] for the definition of the ATTRIB Command and Response.
DA_3
0
Yes
INT_PROTOCOL
= 100b ?
No
1
ATR_REQ
Send Yes
PSL_REQ? 3
No PSL_REQ
Figure 13: Device Activation Activity (Sheet 4, Connector DA_3, NFC-DEP (NFC-F)) – Flow
Chart
Poll Mode
9.4.6.1 Symbol 0:
If INT_PROTOCOL is equal to 100b, then the NFC Forum Device MUST conclude
the Activation Activity.
9.4.6.2 Symbol 1:
The NFC Forum Device MUST send an ATR_REQ Command as specified in
[DIGITAL], containing the identifier included in INT_NFCIDX. The NFC Forum
Device MUST handle the ATR_RES Response as specified in [DIGITAL]. If a Valid
ATR_RES Response is received, the NFC Forum Device MUST store the ATR_RES
Response to GRE_ATR.
9.4.6.3 Symbol 2:
The NFC Forum Device MUST proceed to Symbol 3 if the following conditions
apply
• PSL_REQ/RES is supported
• The Bitrate specified by CON_BITR_NFC_DEP is different that the current Bit
rate
• The device identified by INT_INDEX is the only device that the NFC Forum
Device activates during execution of the active Profile
Otherwise, the NFC Forum Device MUST conclude the NFC-F Activation Activity.
The NFC Forum Device MAY also proceed to Symbol 3 if it wants to change the Length
Reduction Values by using the FSL parameter of PSL_REQ as defined in [DIGITAL].
9.4.6.4 Symbol 3:
The NFC Forum Device MUST send a PSL_REQ.
• If CON_BITR_NFC_DEP is equal to 1, then the NFC Forum Device MUST set
DSI equal to 000b.
• If CON_BITR_NFC_DEP is equal to 2, then the NFC Forum Device MUST set
DSI equal to 001b.
• If CON_BITR_NFC_DEP is equal to or larger than 3, then the NFC Forum
Device MUST set DSI equal to 010b.
The PSL_REQ Command MUST be coded as specified in [DIGITAL].
The NFC Forum Device MUST handle the PSL_REQ Response as specified in
[DIGITAL].
If a Valid PSL_RES Response is received, the NFC Forum Device MUST:
• Set CON_BITR_NFC_DEP according to the Bitrate specified by the DSI
parameter in PSL_REQ
• Conclude the NFC-F Activation Activity
NOTE If DSI has been set to 000 and a valid PSL_RES Response has been received, the
further communication uses NFC-A technology.
9.5.1 Pre-conditions
There are no Configuration Parameters defined for this Activity.
The Input Parameters for the Device Activation Activity are listed in Table 21:
9.5.2 Post-conditions
The Output Parameters returned to the Resolution Process are listed in Table 23:
1
Yes
INT_PROTOCOL DE_1
= 000b ?
NFC-DEP
No Data Exchange
2
Yes
INT_PROTOCOL DE_2
= 001b ?
ISO-DEP
No Data Exchange
3
Yes
INT_PROTOCOL DE_3
= 010b ?
Type 1 Tag
No Data Exchange
4
Yes
INT_PROTOCOL DE_4
= 011b ?
Type 2 Tag
No Data Exchange
5
Yes
INT_PROTOCOL DE_5
= 100b ?
Type 3 Tag
No Data Exchange
Figure 14: Data Exchange Activity (Sheet 1, entry) – Normative Flow Chart
DE_1
1 2
continue data Yes
DEP_REQ
exchange ?
No
Figure 15: Data Exchange Activity (Sheet 2, connector DE_1, NFC-DEP) – Flow Chart
Poll Mode
DE_2
1 2
continue data Yes
send command
exchange ?
No
Figure 16: Data Exchange Activity (Sheet 3, Connector DE_2, ISO-DEP) – Flow Chart
Poll Mode
DE_3
1 2
continue data Yes
send command
exchange ?
No
Figure 17: Data Exchange Activity (Sheet 4, Connector DE_3, Type 1 Tag Platform) – Flow
Chart
Poll Mode
DE_4
1 2
continue data Yes
send command
exchange ?
No
Figure 18: Data Exchange Activity (Sheet 5, connector DE_4, Type 2 Tag Platform) – Flow
Chart
Poll Mode
DE_5
1 2
continue data Yes
send command
exchange ?
No
Figure 19: Data Exchange Activity (Sheet 6, connector DE_5, Type 3 Tag Platform) – Flow
Chart
Poll Mode
9.5.9 Flow Chart and Requirements for Type 3 Tag Platform selection
To select a Type 3 Tag Platform with a specific system code, the NFC Forum Device in Poll
Mode needs to send a SENSF_REQ Command with the corresponding parameter settings. This
includes the selection of Type 3 Tag Platforms that are NDEF enabled.
Figure 20 illustrates the Type 3 Tag Platform Selection flow chart.
SENSF_REQ
Poll Mode
9.5.9.1 Symbol 1:
If the NFC Forum Device needs to select a specific Type 3 Tag Platform, the NFC
Forum Device MUST send a SENSF_REQ Command with the parameter values set
by the adjacent upper layer.
To select an NDEF-enabled Type 3 Tag Platform, the NFC Forum Device MUST set
SC to 12FCh and RC to 00h.
The NFC Forum Device MUST handle the SENSF_RES Response as specified in
[DIGITAL].
If Valid SENSF_RES Responses are received, the NFC Forum Device MAY use the data
contained in a SENSF_RES Responses (e.g. NFCID2) during the further communication in the
Data Exchange Activity instead of the data associated to INT_INDEX .
9.6.1 Pre-conditions
There are no Configuration Parameters defined for this Activity.
The Parameters requested from Resolution for the Device Deactivation Activity are listed in
Table 24:
There is no data needed from the Greedy Collection for this Activity.
9.6.2 Post-conditions
The Output Parameters returned to the Resolution Process are listed in Table 25:
1
Yes
INT_PROTOCOL DD_1
= 000b ?
NFC-DEP
No Deactivation
2
Yes
INT_PROTOCOL DD_2
= 001b ?
ISO-DEP
No Deactivation
3
Yes
INT_PROTOCOL
= 010b ?
No
4
Yes
INT_PROTOCOL DD_3
= 011b ?
Type 2 Tag
No Deactivation
5
Yes
INT_PROTOCOL
= 100b ?
No
Figure 21: Device Deactivation Activity (Sheet 1, Entry) – Normative Flow Chart
DD_1
1
DSL_REQ /
RLS_REQ
2
Set
INT_NFCIDX_SLEEP
Figure 22: Deactivation Activity (Sheet 2, Connector DD_1, NFC-DEP) – Flow Chart
Poll Mode
9.6.4.1 Symbol 1:
The NFC Forum Device MUST send a RLS_REQ Command or DSL_REQ as
specified in [DIGITAL].
9.6.4.2 Symbol 2:
Upon receipt of a RLS_RES, the NFC Forum Device MUST set
INT_NFCIDX_SLEEP[INT_INDEX] equal to 0b.
For NFC-A, upon receipt of a DSL_RES, the NFC Forum Device MUST set
INT_NFCIDX_SLEEP[INT_INDEX] equal to 1b.
For NFC-F, upon receipt of a DSL_RES, the NFC Forum Device MUST set
INT_NFCIDX_SLEEP[INT_INDEX] equal to 0b.
DD_2
DESELECT
2
Set
INT_NFCIDX_SLEEP
Figure 23: Deactivation Activity (Sheet 3, connector DD_2, ISO-DEP) – Flow Chart
Poll Mode
9.6.5.1 Symbol 1:
The NFC Forum Device MUST send an S(DESELECT) Request, as specified in
[DIGITAL].
9.6.5.2 Symbol 2:
Upon receipt of the S(DESELECT) Response, the NFC Forum Device MUST set
INT_NFCIDX_SLEEP[INT_INDEX] is equal to 1b.
DD_3
SLP_REQ
Figure 24: Deactivation Activity (Sheet 4, connector DD_3, Type 2 Tag Platform) – Flow
Chart
Poll Mode
9.6.7.1 Symbol 1:
The NFC Forum Device MUST send a SLP_REQ Command, as specified in
[DIGITAL].
yes no
Poll Mode?
yes
Continue?
no
For the purpose of this document, only a limited set of Profiles is defined. For these definitions,
the focus is on realizing the NFC Forum Communication use cases. These use cases are covered
through three Profiles: P2P, NDEF, and P2PNDEF. Each Profile is defined to run without user
intervention during the communication process.
NOTE User intervention may be required prior to the communication process to set up the
Profiles.
Parameter P2P
CON_POLL_A 0b
CON_POLL_B 0b
CON_POLL_F 1b
CON_POLL_P 0b
CON_BAIL_OUT_A 0b
CON_BAIL_OUT_B 0b
CON_DEVICES_LIMIT 01h
CON_ADV_FEAT 0b
CON_ATR As defined in [DIGITAL]
CON_GB LLCP Parameters
CON_RATS n.a.
CON_ATTRIB n.a.
CON_BITR_NFC_DEP 31
1
Start at 424 and stay at this bit rate
P2P
Technology
Detection
no
FOUND_F := 1b?
yes
INT_TECH_SEL := 10b
NFCDEPDevices := 0
Next NFCIDX no no
NFCDEPDevices = 1?
available?
yes yes
Current NFCIDX
Device Activation
no
indicates NFC-DEP
capability?
Device Deactivation
no
NFCDEPDevices > 1?
yes
Parameter NDEF
CON_POLL_A 1b
CON_POLL_B 1b
CON_POLL_F 1b
CON_POLL_P 0b
CON_BAIL_OUT_A 0b
CON_BAIL_OUT_B 0b
CON_DEVICES_LIMIT 04h
CON_ADV_FEAT 0b
CON_ATR n.a
CON_GB None
CON_RATS As defined in [DIGITAL]
CON_ATTRIB As defined in [DIGITAL]
CON_BITR_NFC_DEP 0
NDEF
Technology
Detection
no no no
FOUND_A := 1b? FOUND_B := 1b? FOUND_F := 1b?
Collision_Resolution Collision_Resolution
yes yes
Data Exchange Data Exchange Data Exchange Data Exchange Data Exchange
Detect NDEF according to Detect NDEF according to Detect NDEF according to Detect NDEF according to send SENS_F with SC=12FC,
[T1T OP]. [T4T OP]. [T2T OP]. [T4T OP]. TSN := 03h, RC=0h
no no NDEF device(s) no
NDEF detected? NDEF detected?
detected?
no NDEF device
found?
yes
1
Device Deactivation can be skipped in case NDEF was detected, no other NDEF and NFC-DEP capable devices have been detected before and the current device is
the last device to be investigated.
yes yes
yes yes
INT_INDEX := current index INT_INDEX := current index INT_INDEX := current index INT_INDEX := current index INT_INDEX := current index
INT_PROTOCOL := 010b INT_PROTOCOL := 001b INT_PROTOCOL := 011b INT_PROTOCOL := 001b INT_PROTOCOL := 100b
Data Exchange Data Exchange Data Exchange Data Exchange Data Exchange
Sequence of commands in Sequence of commands in Sequence of commands in Sequence of commands in Sequence of commands in
accordance to accordance to accordance to accordance to accordance to
[T1T OP] [T4T OP] [T2T OP] [T4T OP] [T3T OP]
Parameter NDEF
CON_POLL_A 1b
CON_POLL_B 1b
CON_POLL_F 1b
CON_POLL_P 0b
CON_BAIL_OUT_A 0b
CON_BAIL_OUT_B 0b
CON_DEVICES_LIMIT 04h
CON_ADV_FEAT 0b
CON_ATR As defined in
[DIGITAL]
CON_GB LLCP Parameters
CON_RATS As defined in
[DIGITAL]
CON_ATTRIB As defined in
[DIGITAL]
CON_BITR_NFC_DEP 3
P2PNDEF
Technology
Detection
no no no One device no
FOUND_A = 1b? FOUND_B = 1b? FOUND_F = 1b?
found?
FOUND_A
processing
INT_TECH_SEL := 00b
Collision_Resolution
Next NFCIDX no
available?
yes
Device Deactivation1
no
NDEF detected?
yes
1
Device Deactivation can be skipped in case NDEF was detected, no other NDEF and NFC-DEP capable devices have been
detected before and the current device is the last device to be investigated.
FOUND_B
processing
INT_TECH_SEL := 01b
Collision_Resolution
Next NFCIDX no
available?
yes
no 14443-4 protocol
supported?
yes
INT_INDEX := current index
INT_PROTOCOL := 001b
Device Activation
Data Exchange
Detect NDEF according to
[Type 4 Tag].
Device Deactivation1
no
NDEF detected?
yes
Remember device
yes
1
Device Deactivation can be skipped in case NDEF was detected, no other NDEF and NFC-DEP
capable devices have been detected before and the current device is the last device to be
investigated.
FOUND_F
processing
INT_TECH_SEL := 10b
Next NFCIDX no
available?
yes
Current index := index of next INT_INDEX := 1
NFCIDX INT_PROTOCOL := 100b
Data Exchange
no send SENS_F with SC := 12FC,
NFC-DEP supported? TSN := 03h, RC := 0h
yes
no
Remember device NDEF device(s)
detected?
yes
no More than one
Remember device(s)
Device found?
yes
Device
communication
current index :=
index of found device
yes yes
NFC-DEP yes
supported?
No (device is
Type 3 Tag)
NFC-A INT_INDEX := current index INT_INDEX := current index INT_INDEX := current index
communication INT_PROTOCOL := 001b INT_PROTOCOL := 100b INT_PROTOCOL := 000b
NFC-A
communication
yes
INT_INDEX := current index INT_INDEX := current index INT_INDEX := current index INT_INDEX := current index
INT_PROTOCOL := 010b INT_PROTOCOL := 001b INT_PROTOCOL := 011b INT_PROTOCOL := 000b
OTHER
SLEEP_B
DESELECT
ALLB_REQ (AFI, N1)
SLPB_REQ
OTHER CARD
ALLB_REQ (AFI, N>) READY_B_ ATTRIB
OTHER
EMULATOR
DECL
ALLB_REQ (nAFI) 4B
OTHER
OTHER
SLEEP_A OTHER SENSF_REQ ATR_REQ ATR_
IDLE READY_F
READY_F CUP
RLS_REQ
DEP_REQ,
ALL_REQ SENS_REQ PSL_REQ (F),
RLS_REQ PSL_REQ (A)
ALL_REQ OTHER
OTHER OTHER
OTHER
OTHER SDD_REQ CL1
DSL_REQ
OTHER
READY_A * SDD_REQ CL1 READY_A TARGET_F
OTHER
SEL_REQ CL1 OTHER SEL_REQ CL1
DSL_REQ
SEL_REQ
CL1 SEL_REQ CL1
RATS
READY_A
DEP_REQ,
DESELECT RLS_REQ PSL_REQ (A), DSL_REQ
OTHER ALL_REQ
OTHER
CARD
EMULATOR TARGET_A
4A OTHER
B. Values
Throughout this document, symbols are used to identify the values of Parameters. The actual
values of the Parameters are listed in Table 30. For some of the Parameters, a minimum and
maximum value is defined. Other Parameters are defined by a single value.
Parameters have a value for the NFC Forum Device in Poll Mode and for the NFC Forum Device
in Listen Mode. Unless otherwise specified, the value for Poll Mode has to be used when the
parameter is referenced in a Poll Mode requirement. The value for Listen Mode has to be used
when referenced in a Listen Mode requirement.
C. Revision History
The following table outlines the revision history of NFC Activity Specification.