0% found this document useful (0 votes)
76 views117 pages

NFC Activity Specification

Uploaded by

elasesino694
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
76 views117 pages

NFC Activity Specification

Uploaded by

elasesino694
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 117

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

NFC Activity Specification Page i


Contents

9 Poll Mode – Activities .................................................................................. 52


9.1 Activities - Requirements ............................................................................................ 52
9.2 Technology Detection Activity ................................................................................... 53
9.2.1 Pre-conditions ............................................................................................... 53
9.2.2 Post-conditions.............................................................................................. 54
9.2.3 Flow Chart and Requirements ...................................................................... 54
9.3 Collision Resolution Activity ...................................................................................... 59
9.3.1 Pre-conditions ............................................................................................... 59
9.3.2 Post-conditions.............................................................................................. 60
9.3.3 Flow Chart (Normative)................................................................................ 61
9.3.4 Flow Chart and Requirements for NFC-A .................................................... 62
9.3.5 Flow Chart and Requirements for NFC-B .................................................... 67
9.3.6 Flow Chart and Requirements for NFC-F .................................................... 72
9.4 Device Activation Activity .......................................................................................... 74
9.4.1 Pre-conditions ............................................................................................... 74
9.4.2 Post-conditions.............................................................................................. 76
9.4.3 Flow Chart (Normative)................................................................................ 77
9.4.4 Flow Chart and Requirements for NFC-A .................................................... 77
9.4.5 Flow Chart and Requirements for NFC-B .................................................... 81
9.4.6 Flow Chart and Requirements for NFC-F .................................................... 83
9.5 Data Exchange Activity............................................................................................... 86
9.5.1 Pre-conditions ............................................................................................... 86
9.5.2 Post-conditions.............................................................................................. 86
9.5.3 Flow Chart (Normative)................................................................................ 87
9.5.4 Flow Chart and Requirements for NFC-DEP ............................................... 87
9.5.5 Flow Chart and Requirements for ISO-DEP ................................................ 88
9.5.6 Flow Chart and Requirements for Type 1 Tag Platform .............................. 90
9.5.7 Flow Chart and Requirements for Type 2 Tag Platform .............................. 90
9.5.8 Flow Chart and Requirements for Type 3 Tag Platform .............................. 92
9.5.9 Flow Chart and Requirements for Type 3 Tag Platform selection ............... 92
9.6 Device Deactivation Activity ...................................................................................... 94
9.6.1 Pre-conditions ............................................................................................... 94
9.6.2 Post-conditions.............................................................................................. 94
9.6.3 Flow Chart (Normative)................................................................................ 94
9.6.4 Flow Chart and Requirements for NFC-DEP ............................................... 95
9.6.5 Flow Chart and Requirements for ISO-DEP ................................................ 96
9.6.6 Flow Chart and Requirements for Type 1 Tag Platform .............................. 97
9.6.7 Flow Chart and Requirements for Type 2 Tag Platform .............................. 97
9.6.8 Flow Chart and Requirements for Type 3 Tag Platform .............................. 98
10 Poll Mode – Profiles .................................................................................... 99
10.1 Greedy Collection Information.................................................................................. 100
10.2 P2P Poll Profile ......................................................................................................... 101
10.2.1 Configuration Parameters ........................................................................... 101
10.2.2 Resolution Process ...................................................................................... 101
10.3 NDEF Poll Profile ..................................................................................................... 103
10.3.1 Configuration Parameters ........................................................................... 103
10.3.2 Resolution Process ...................................................................................... 103
10.4 P2PNDEF Poll Profile ............................................................................................... 106
10.4.1 Configuration Parameters ........................................................................... 106
10.4.2 Resolution Process ...................................................................................... 106

NFC Activity Specification Page ii


Contents

A. Listen Mode – State Diagram (Informative) ............................................. 113


B. Values ......................................................................................................... 114
C. Revision History ........................................................................................ 115

NFC Activity Specification Page iii


Figures

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

NFC Activity Specification Page iv


Figures

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

NFC Activity Specification Page v


Tables

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

NFC Activity Specification Page vi


Requirements

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

NFC Activity Specification Page vii


Requirements

Requirements 34: Data Exchange Activity – Type 2 Tag Platform .............................................. 91


Requirements 35: Data Exchange Activity – Type 3 Tag Platform .............................................. 92
Requirements 36: Type 3 Tag Selection ....................................................................................... 93
Requirements 37: Deactivation Activity – NFC-DEP ................................................................... 96
Requirements 38: Deactivation Activity – ISO-DEP .................................................................... 97
Requirements 39: Deactivation Activity – Type 2 Tag Platform .................................................. 98

NFC Activity Specification Page viii


Introduction

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.3 Applicable Documents or References


The following documents contain provisions that are referenced in this specification. The latest
version including all published amendments applies unless a publication date is explicitly stated.
[ANALOG] NFC Analog,
In progress,
NFC Forum
[DIGITAL] NFC Digital Protocol,
Version 1.0,
NFC Forum
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels, RFC 2119,
S. Bradner,
March 1997,
Internet Engineering Task Force
[T1TOP] Type 1 Tag Operation Specification
Version 1.0,
NFC Forum
[T2TOP] Type 2 Tag Operation,
Version 1.0
NFC Forum
[T3TOP] Type 3 Tag Operation,
Version 1.0,
NFC Forum
[T4TOP] Type 4 Tag Operation,
Version 2.0,
NFC Forum

NFC Activity Specification Page 9


Introduction

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.

1.5 Name and Logo Usage


The Near Field Communication Forum’s policy regarding the use of the trademarks NFC Forum
and the NFC Forum logo is as follows:
• Any company MAY claim compatibility with NFC Forum specifications, whether a member
of the NFC Forum or not.
• Permission to use the NFC Forum logos is automatically granted to designated members only
as stipulated on the most recent Membership Privileges document, during the period of time
for which their membership dues are paid.
• Member’s distributors and sales representatives MAY use the NFC Forum logo in promoting
member’s products sold under the name of the member.
• The logo SHALL be printed in black or in color as illustrated on the Logo Page that is
available from the NFC Forum at the address above. The aspect ratio of the logo SHALL be
maintained, but the size MAY be varied. Nothing MAY be added to or deleted from the
logos.
• Since the NFC Forum name is a trademark of the Near Field Communication Forum, the
following statement SHALL be included in all published literature and advertising material in
which the name or logo appears:
NFC Forum and the NFC Forum logo are trademarks of the Near Field Communication
Forum.

1.6 Intellectual Property


The NFC Activity Specification conforms to the Intellectual Property guidelines specified in the
NFC Forum's Intellectual Property Rights Policy, as outlined in the NFC Forum Rules of
Procedure.

1.7 Special Word Usage


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in [RFC2119].

NFC Activity Specification Page 10


Introduction

1.8 Requirement Numbering


Requirements in this document are uniquely numbered with the number appearing next to each
requirement. Requirements can include informative statements in the italic font and MAY instead
of MUST is used. For example:

Table 1: Sample Requirement

1.8.1.1 A car MUST have four wheels.


A car MAY have alloy wheels.

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

Figure 1: Example Flow Chart

NFC Activity Specification Page 11


Introduction

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.

Table 2: Example Requirements

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.

NFC Activity Specification Page 12


Introduction

1.9 Notational Conventions


1.9.1 Notations
The notational conventions as defined in Table 3 apply to this document.

Table 3: Notational Conventions

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).

NFC Activity Specification Page 13


Introduction

1.9.2 Figures
Table 4 defines the graphical notation used in the figures of this document.

Table 4: Figure Notation

Symbol Meaning
Activity
Activity

Start of a flow chart

label
Connection point with dedicated label as used when a flow chart is split
into multiple figures

End of a flow chart

test Test block with one input branch and several output branches

elementary
action Elementary action block

processing Processing block that can be decomposed in elementary action blocks


block and/or other processing blocks

Connecting element with processing flow indicated by the direction of


the arrow

1.10 Abbreviations
The abbreviations as used in this document are defined in Table 5.

NFC Activity Specification Page 14


Introduction

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

NFC Activity Specification Page 15


Introduction

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

NFC Activity Specification Page 16


Introduction

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].

1.11.2 Technology and Communication


Byte Sequence
Concatenation of hexadecimal values.

NFC Activity Specification Page 17


Introduction

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.

NFC Activity Specification Page 18


Introduction

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.

NFC Activity Specification Page 19


Introduction

NFC Forum Tag


A contactless tag or (smart) card supporting NDEF.
NFCIDx
The identifiers NFCID0, NFCID1, NFCID2, and NFCID3 for NFC-B, NFC-A, NFC-F,
and NFC-DEP respectively. Identifiers subsumed under the term NFCIDx always belong
to the same Technology.
Poll Mode
Initial mode of an NFC Forum Device when it generates a carrier and polls for other
devices.
State
A Technology-independent state of the NFC Forum Device in Listen Mode.
Sub-state
A state of the NFC Forum Device in Listen Mode, specific to a Technology or
Technology Subset.
Target
Role of an NFC Forum Device, reached when the NFC Forum Device in Listen Mode has
gone through a number of Activities in which the NFC Forum Device communicates
using the NFC-DEP Protocol.

1.11.4 Specific to This Specification


Activity
A process within an NFC Forum Device.
Bail-out Option
A configuration option that allows the NFC Forum Device to conclude the Technology
Detection Activity, if the respective Bail-out parameter is set.
Configuration Parameters
Parameters that are determined before the first Activity of a Profile is performed.
Configuration Parameters cannot be changed when performing the sequence of Activities
belonging to a Profile.
Greedy Collection
Temporary storage for information collected as part of the Activity and used during
processing.
Poll Profile
The Profile of an NFC Forum Device when in Poll Mode.
Profile
The combination of a Resolution Process managing a set of Activities, an Initialization
that chooses a set of values as Configuration Parameters, and Clean-up.

NFC Activity Specification Page 20


Introduction

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].

NFC Activity Specification Page 21


Purpose

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

NFC Activity Specification Page 22


Purpose

• Device activation: activates a particular device to establish a communication


• Data exchange: exchange of application data
• Device deactivation: deactivates this device to end the communication and be able to
potentially activate another device
Each flow or combination of flows looks like library functions that a developer can call upon.
While it is not the intention of the specification to define or prescribe APIs, the specification
can be used for this purpose. The developer then has the choice to use the process flows and
variables as defined in the specification or develop his own.
5. Profiles (see Section 10)
This section defines values for the Configuration Parameters that, when used in combination
with the process flows defined above, cover the NFC Forum Communication use cases.
The combination of Activities and Profiles define a predictable, deterministic behavior of the
NFC Forum Device (for error-free operation). This does not limit NFC Forum Devices from
implementing other building blocks or defining other Profiles for other use cases, in addition to
the existing ones.
Listen Mode and its State Machine are a mandatory part of an NFC Forum Device
implementation (some parts of the state machine are optional).
The NFC Forum Device must implement the generic requirements of the Poll Mode to be NFC
Forum compliant.
An implementation of the Activities is optional.
If an implementation claims conformance to optional parts of the specification, all requirements
must be implemented as specified.
The Profiles defined within this document are informative; however, they are recommended.
NOTE This specification does not define Profiles for testing, as testing is outside of the
scope of this document. Nevertheless, NFC-Forum-related test documentation may
use the concept of Profiles and the underlying processes as input for the definition of
a device test application.

NFC Activity Specification Page 23


Listen Mode – Generic Requirements

3 Listen Mode – Generic Requirements


The following generic requirements apply to Listen Mode.

Requirements 1: Listen Mode – Generic

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.

NFC Activity Specification Page 24


Listen Mode – Configuration

4 Listen Mode – Configuration


Configuration Parameters need to be set before the Listen Mode state machine can be started.
They allow technology-dependent responses to be configured, and to enable and disable optional
parts. The Configuration Parameters are listed in Table 6:

Table 6: Listen Mode – Configuration Parameters

Name Format Size Description

CON_LISTEN_DEP_A binary 1 bit Controls whether to listen for NFC-A


Technology with NFC_DEP support or not.
- 1b: Listen for NFC-A Technology with
NFC-DEP support
- 0b: Do not listen for NFC-A
Technology with NFC_DEP support

CON_LISTEN_DEP_F binary 1 bit Controls whether to listen for NFC-F


Technology with NFC_DEP support or not.
- 1b: Listen for NFC-F Technology with
NFC-DEP support
- 0b: Do not listen for NFC-F
Technology with NFC-DEP support

CON_LISTEN_T3TP binary 1 bit Controls whether to listen for NFC-F


Technology with Type 3 Tag Platform
support or not.
- 1b: Listen for NFC-F Technology with
Type 3 Tag Platform support
- 0b: Do not listen for NFC-F
Technology with Type 3 Tag Platform
support

CON_LISTEN_T4ATP binary 1 bit Controls whether to listen for NFC-A


Technology with Type 4 Tag Platform
support or not.
- 1b: Listen for NFC-A Technology with
Type 4 Tag Platform support
- 0b: Do not listen for NFC-A
Technology with Type 4 Tag Platform
support

NFC Activity Specification Page 25


Listen Mode – Configuration

Name Format Size Description

CON_LISTEN_T4BTP binary 1 bit Controls whether to listen for NFC-B


Technology with Type 4 Tag Platform
support or not.
- 1b: Listen for NFC-B Technology with
Type 4 Tag Platform support
- 0b: Do not listen for NFC-B
Technology with Type 4 Tag Platform
support

CON_ADV_FEAT binary 1 bit Controls the use of advanced protocol


features.
- 1b: Support advanced protocol features
- 0b: Do not support advanced protocol
features
CON_SYS_CODE[N] Array of variable If configured for Type 3 Tag Platform, an
Byte ordered list of N system codes maintained
Sequences by the adjacent upper layer (N>0).
Otherwise, the list contains a single system
code of value FFFFh as a default value
(N=1).
CON_SENSF_RES Array of variable See SENSF_RES format in [DIGITAL].
Byte In particular:
Sequences
- NFCID2 must be configured if the
NFC Forum Device cannot generate
random numbers
- If configured for Type 3 Tag Platform,
then PAD1, MRTICHECK, MRTIUPDATE,
PAD2, and RD must be configured as
per [DIGITAL].
- Otherwise, these data elements can
have any value.
CON_ATR_RES Array of variable See ATR_RES Format in [DIGITAL].
Byte In particular:
Sequences
- NFCID3T must be configured if the
NFC Forum Device cannot generate
random numbers
- BST, BRT, TO, PPT need to be
configured
- General bytes (GT0…GTn) need to be
configured if the upper adjacent layer
wants to indicate some information
such as LLCP support.

NFC Activity Specification Page 26


Listen Mode – Configuration

Name Format Size Description

CON_ATS Array of variable See ATS format in [DIGITAL]


Byte
Sequences
CON_SENSB_RES Array of variable See SENSB_RES format in [DIGITAL]
Byte
Sequences
CON_ATTRIB_RES Array of variable See ATTRIB Response in [DIGITAL], in
Byte particular MBLI
Sequences
CON_BITR_F integer 1 Byte At least one bit of these must be set:
- b2=1: 212 kbps
- b3=1: 424 kbps

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.

NFC Activity Specification Page 27


Listen Mode – State Machine

5 Listen Mode – State Machine


Table 7 defines the Listen Mode state machine of the NFC Forum Device. It includes all possible
state transitions caused by Commands specified in [DIGITAL] for the functionality that is either
mandatory (e.g., Target) or optional (e.g., Card Emulator).
NOTE The behavior of Type 1 Tag and Type 2 Tag Commands are out of scope of this
specification and are therefore not included in this state machine.

NFC Activity Specification Page 28


Listen Mode – State Machine

Table 7: Listen Mode – State Machine


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

NO_REMOTE_FIELD OTHER

IDLE SENSB_ SENSB_


REQ REQ
Remote ALLB_
OTHER OTHER RLS_ RLS_ RLS_ RLS_ (nAFI), (nAFI),
Field OTHER 1 OTHER OTHER 2 REQ
REQ REQ REQ REQ ALLB_ ALLB_
Present (nAFI)
REQ REQ
(nAFI) (nAFI)
READY-A SENS_
SDD_
REQ,
REQ
ALL_
CL1
REQ
READY-A’ SEL_ SDD_
REQ REQ
CL13 CL2
READY-A’’ SEL_ SDD_
REQ REQ
CL24 CL3
ACTIVE_A SEL_ SEL_ SEL_
REQ REQ REQ
CL15 CL26 CL3
ATR_READY_A ATR_ ATR_
REQ REQ
TARGET_A DEP_
REQ, DEP_ PSL_
PSL_R REQ, REQ
EQ (A), OTHER (A)
OTHER
CARD_EMULATOR_4
RATS OTHER RATS
A

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

NFC Activity Specification Page 29


Listen Mode – State Machine

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

SLEEP_AF DSL_ DSL_ DSL_ DSL_


OTHER
REQ REQ REQ REQ
READY_B_REQU SENSB_ SENSB_
REQ REQ ALLB_
(AFI, N>) (AFI, N>) REQ
OTHER
, ALLB_ , ALLB_ (AFI, N>
REQ REQ )
(AFI, N>) (AFI, N>)
READY_B_DECL SENSB_
REQ
(AFI,
SENSB_
N1),
REQ ALLB_
ALLB_
(AFI, N1) REQ
REQ OTHER
, ALLB_ (AFI, N1
(AFI,
REQ )
N1),
(AFI, N1)
SLOT_
MARKE
R
SLEEP_B SLPB_
OTHER DESELECT
REQ
CARD_EMULATOR_4
ATTRIB OTHER
B

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.

NFC Activity Specification Page 30


Listen Mode – State Machine

5.1 NO_REMOTE_FIELD State


The requirements in this section apply to the NO_REMOTE_FIELD State.

Requirements 2: Listen Mode – NO_REMOTE_FIELD State

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.

5.2 IDLE State


The requirements in this section apply to the IDLE State. In this State, the NFC Forum Device is
ready to receive Poll Commands for the Technologies it is configured for.

Requirements 3: Listen Mode – IDLE State

Listen Mode

5.2.1.1 If CON_LISTEN_DEP_A=1 or CON_LISTEN_T4ATP=1, the NFC Forum Device


MUST enter the READY_A Sub-state after it has received a Valid ALL_REQ
Command and has transmitted its SENS_RES.
5.2.1.2 If CON_LISTEN_DEP_A=1 or CON_LISTEN_T4ATP=1, the NFC Forum Device
MUST enter the READY_A Sub-state after it has received a Valid SENS_REQ
Command and has transmitted its SENS_RES.
5.2.1.3 If CON_LISTEN_T4BTP =1, the NFC Forum Device MUST enter the
READY_B_DECL Sub-state after it has received a Valid SENSB_REQ Command that
contains an N equal to 1, an AFI that matches its own AFI. and after it has
transmitted its SENSB_RES.
5.2.1.4 If CON_LISTEN_T4BTP =1, the NFC Forum Device MUST enter the
READY_B_DECL Sub-state after it has received a Valid ALLB_REQ Command that
contains an N equal to 1, an AFI that matches its own AFI, and after it has
transmitted its SENSB_RES.
5.2.1.5 If CON_LISTEN_T4BTP =1, the NFC Forum Device MUST enter the
READY_B_DECL Sub-state after it has received a Valid SENSB_REQ Command that
contains an N greater than 1, an AFI that matches its own AFI, its R is 1, and after it
has transmitted its SENSB_RES.
5.2.1.6 If CON_LISTEN_T4BTP =1, the NFC Forum Device MUST enter the
READY_B_DECL Sub-state after it has received a Valid ALLB_REQ Command that
contains an N greater than 1, an AFI that matches its own AFI, its R is 1, and after it
has transmitted its SENSB_RES.

NFC Activity Specification Page 31


Listen Mode – State Machine

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.

5.2.1.10 If CON_LISTEN_DEP_F=1 or CON_LISTEN_T3TP =1 and the NFC Forum


Device in Listen Mode has received a Valid SENSF_REQ Command with one of
the bit rates as indicated in CON_BITR_F, 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 and it MUST enter the READY_F Sub-state after it has transmitted its
SENSF_RES, including CON_SENS_RES Response using the same bit rate of the
received SENSF_REQ Command.
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 intends to 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.2.1.11 If OTHER as defined in Table 7, the NFC Forum Device MUST NOT send a
Response and it MUST stay in the IDLE State.
An NFC Forum Device MAY respond to Valid Type 1 Tag Commands and it MAY change state
accordingly.

NFC Activity Specification Page 32


Listen Mode – State Machine

5.3 READY_A Sub-state and READY_A* Sub-state


The requirements in this section apply to the READY_A and READY_A* Sub-states. In these states,
the NFC Forum Device expects an SDD_REQ Command to retrieve the complete NFCID1.

Requirements 4: Listen Mode – READY_A SUB-STATE and READY_A* Sub-state

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.

5.4 READY_A’ Sub-state and READY_A’* Sub-state


The requirements in this section apply to the READY_A’ and READY_A’* Sub-states. The
READY_A’ and READY_A’* Sub-states are intermediate states that only exist for NFC Forum
Devices with double- and triple-size NFCID1. In these states, the cascade level 1 of the NFCID1
has been selected.

NFC Activity Specification Page 33


Listen Mode – State Machine

Requirements 5: Listen Mode – READY_A’SUB-STATE and READY_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.

5.5 READY_A” Sub-state and READY_A”* Sub-state


The requirements in this section apply to the READY_A” and READY_A”* Sub-states. The
READY_A” and READY_A”* Sub-states are intermediate states that only exist for NFC Forum
Devices with triple-size NFCID1. In these states, the cascade level 1 and 2 of the NFCID1 have
been selected.

Requirements 6: Listen Mode – READY_A’’ SUB-STATE and READY_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.

NFC Activity Specification Page 34


Listen Mode – State Machine

5.6 ACTIVE_A Sub-state and ACTIVE_A* Sub-state


The requirements in this section apply to the ACTIVE_A and ACTIVE_A* Sub-states. In these
states, the NFC Forum Device expects Commands for protocol activation.

Requirements 7: Listen Mode – ACTIVE_A SUB-STATE and ACTIVE_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.

5.7 SLEEP_A Sub-state


The requirements in this section apply to the SLEEP_A Sub-state. In this state, the NFC Forum
Device only responds to an ALL_REQ Command.

Requirements 8: Listen Mode – SLEEP_A Sub-state

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.

5.8 ATR_READY_A Sub-state


The requirements in this section apply to the ATR_READY_A Sub-state. In this state, the NFC
Forum Device expects a PSL_REQ or a DEP_REQ Command.

NFC Activity Specification Page 35


Listen Mode – State Machine

Requirements 9: Listen Mode – ATR_READY_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.

5.9 TARGET_A Sub-state


The requirements in this section apply to the TARGET_A Sub-state. In this state, the NFC Forum
Device expects higher layer messages.

Requirements 10: Listen Mode – 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.

NFC Activity Specification Page 36


Listen Mode – State Machine

5.10 CARD_EMULATOR_4A Sub-state


The requirements in this section apply to the CARD_EMULATOR_4A Sub-state. In this state, the
NFC Forum Device expects higher layer messages or an S(DESELECT) Request (see
[DIGITAL]).

Requirements 11: Listen Mode – CARD_EMULATOR_4A 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.

NFC Activity Specification Page 37


Listen Mode – State Machine

5.11 READY_B_REQU Sub-state


The requirements in this section apply when the NFC Forum Device is in the READY_B_REQU
Sub-state. In this state, the NFC Forum Device expects an ALLB_REQ, a SENSB_REQ, or a
corresponding SLOT_MARKER Command.

Requirements 12: Listen Mode – READY_B_REQU 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.

NFC Activity Specification Page 38


Listen Mode – State Machine

5.12 READY_B_DECL Sub-state


The requirements in this section apply when the NFC Forum Device is in the READY_B_DECL
Sub-state. In this state, the NFC Forum Device expects an ATTRIB or a SLPB_REQ Command.

Requirements 13: Listen Mode – READY_B_DECL 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.

NFC Activity Specification Page 39


Listen Mode – State Machine

5.13 SLEEP_B Sub-state


The requirements in this section apply when the NFC Forum Device is in the SLEEP_B Sub-state.
In this state, the NFC Forum Device expects an ALLB_REQ Command.

Requirements 14: Listen Mode – SLEEP_B 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.

5.14 CARD_EMULATOR_4B Sub-state


The requirements in this section apply when the NFC Forum Device is in the
CARD_EMULATOR_4B Sub-state. In this state, the NFC Forum Device expects higher layer
messages or an S(DESELECT) Request (see [DIGITAL]).

Requirements 15: Listen Mode – CARD_EMULATOR_4B 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.

NFC Activity Specification Page 40


Listen Mode – State Machine

5.15 READY_F Sub-state


The requirements in this section apply to the READY_F Sub-state. In this state, the NFC Forum
Device expects an ATR_REQ, a POLLING, a CHECK, or an UPDATE Command.

Requirements 16: Listen Mode – READY_F 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.

NOTE The READY_F state is known as MODE_0 in other, non-NFC-Forum specifications


(e.g., JIS X 6319-4).

NFC Activity Specification Page 41


Listen Mode – State Machine

5.16 ATR_READY_F Sub-state


The requirements in this section apply to the ATR_READY_F Sub-state. In this state, the NFC
Forum Device expects a PSL_REQ or a DEP_REQ Command.

Requirements 17: Listen Mode – ATR_READY_F 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.

5.17 TARGET_F Sub-state


The requirements in this section apply to the TARGET_F Sub-state. In this state, the NFC Forum
Device expects higher layer messages.

Requirements 18: Listen Mode – TARGET_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.

NFC Activity Specification Page 42


Listen Mode – State Machine

5.18 CARD_EMULATOR_3 Sub-state


The requirements in this section apply to the CARD_EMULATOR_3 Sub-state. In this state, the NFC
Forum Device expects Valid Commands according to the Type 3 Tag Platform as defined in
[DIGITAL].

Requirements 19: Listen Mode – CARD_EMULATOR_3 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.

NFC Activity Specification Page 43


Listen Mode – State Machine

5.19 SLEEP_AF Sub-state


The requirements in this section apply to the SLEEP_AF Sub-state. In this state, the device has
been deselected by means of a NFC-DEP DSL_REQ Command. The NFC Forum Device expects
an ALL_REQ, a SENSF_REQ, or a CUP Command.

Requirements 20: Listen Mode – SLEEP_AF Sub-state

Listen Mode

5.19.1.1 If CON_LISTEN_DEP_A=1 or CON_LISTEN_T4ATP=1, and upon receipt of a


Valid ALL_REQ Command, the NFC Forum Device MUST send its SENS_RES
and it MUST enter the READY_A* Sub-state.
5.19.1.2 If CON_LISTEN_DEP_F=1 or CON_LISTEN_T3TP =1, 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 enter 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 intends to 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.19.1.3 If CON_LISTEN_T3TP =1 and the NFC Forum Device in Listen Mode has
received a Valid CHECK or UPDATE Command as referenced in [DIGITAL] and
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 for the Type 3
Tag Platform.

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.

NFC Activity Specification Page 44


Poll Mode – Generic Requirements

6 Poll Mode – Generic Requirements


This section contains generic requirements that must be observed, independent of whether the
NFC Forum Device chooses to implement the Activities described in this document or not.
Requirements 21 contains the list of generic requirements.

Requirements 21: Generic

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).

NFC Activity Specification Page 45


Poll Mode – Generic Requirements

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.

NFC Activity Specification Page 46


Poll Mode – RF Collision Avoidance

7 Poll Mode – RF Collision Avoidance


Figure 2 shows the flow chart for RF Collision Avoidance that shall be applied by the NFC
Forum Device before generating an Operating Field.

sense field

2
No Remote
Field

Yes
3

put field on

Figure 2: RF Collision Avoidance – Flow Chart

Requirements 22 contains the list of RF Collision Avoidance requirements. Symbols in this


section refer to corresponding symbols in Figure 2.

NFC Activity Specification Page 47


Poll Mode – RF Collision Avoidance

Requirements 22: RF Collision Avoidance

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.

NFC Activity Specification Page 48


Poll Mode – Activity and Profile Model

8 Poll Mode – Activity and Profile Model


Activities combine elementary blocks of [DIGITAL] into functional blocks. Each functional
block has a dedicated purpose, with well defined pre-conditions and post-conditions. It provides a
level of detail on the Initiator/Reader functionality that is not already specified within
[DIGITAL].
The Activity manages the dialogue with another device, using the Commands and Responses
specified in [DIGITAL]. To perform its task, it has a well-defined set of algorithms, with one
algorithm per Technology if necessary.
Configuration

Greedy
Input Activity Collection

Output

Figure 3: Activity

An Activity may have any of the following interfaces as shown in Figure 3:


• Configuration Parameters
• Input Parameters
• Output Parameters
• Greedy Collection
Configuration Parameters and Input Parameters provide the necessary flexibility on how to use
the algorithm. As part of its processing, the Activity collects information on the other device.
While this information may not be directly relevant for this Activity, it is stored in the Greedy
Collection, so that it can be used by other Activities or the Resolution Process. Output Parameters
provide the results of the Activity into the Resolution Process.
Activities are managed by the Resolution Process, which is a decision process controlled by the
adjacent upper layer. The scope of the Resolution Process is limited to the identification of and
the Input Parameter setting for the next Activity. The other responsibilities of the adjacent upper
layer, beyond the Resolution Process (such as controlling the display, collecting user input,
performing exception handling, etc.) are outside the scope of this specification.

NFC Activity Specification Page 49


Poll Mode – Activity and Profile Model

The following rules for the framework around Activities apply:


• During normal processing, Activities are not interrupted by the adjacent upper layer. If the
adjacent upper interrupts an Activity, this is an exception.
• If an error occurs within an action block, then an error-handling task may interrupt the
Activity processing. The error-handling task may choose to proceed inside the current
Activity or to abort it. Error handling has to conform with [DIGITAL]. Care has to be taken
with the integrity of the Greedy Collection.
• The Resolution Process can start an Activity only if the pre-conditions of the Activity are
fulfilled.
• The installation of the Resolution Process and the initialization of the needed Configuration
Parameters have to be done before any Activity is started.
• The Resolution Process and the Configuration Parameters remain valid as long as a Profile
remains active (i.e., until the control is handed back to the adjacent upper layer).
A Profile is comprised of an initialization, a Resolution Process, Activities, the Greedy
Collection, and a Clean-up, as shown in Figure 4:

Initialization

Activity

Resolution
Activity
Process
Greedy
Collection

Activity

Clean-up

Figure 4: Profile

NFC Activity Specification Page 50


Poll Mode – Activity and Profile Model

The Profile is defined by:


• The Resolution Process
• The values chosen for the Configuration Parameters
During the Initialization of a Profile, the Configuration Parameters as needed by the included
Activities are set. In the case of a Poll Mode Profile, RF Collision Avoidance takes place (see
Section 7).
The Clean-up of a Profile erases the Greedy Collection and, if a Poll Mode Profile, the Operating
Field is turned to the Operating Field Off state, in accordance with Requirement 6.1.1.1.
In the absence of user intervention and errors, a Profile describes the deterministic behavior of the
included Activities.
The way a Profile unfolds and therefore the order of the Activities that are called depend on the
other device(s) encountered.
The Activities defined in this document are contained in Section 9. Building on those Activities,
Section 10 defines a set of Profiles covering the NFC Forum communication use cases.

NFC Activity Specification Page 51


Poll Mode – Activities

9 Poll Mode – Activities


An Activity uses:
• Technology-independent pre-conditions and post-conditions
• Technology-independent Configuration Parameters, except for the Technology Detection
Activity and the Device Activation Activity
• Technology-dependent Algorithms, using the Configuration Parameters in a technology-
specific manner
Configuration Parameters are independent from the other device and typically survive multiple
transactions. This distinguishes them from the Greedy Collection,which stores information
learned from the other device and therefore varies with each transaction.
The description of each Activity is structured as follows:
• The pre-conditions are described by:
• The input from the Resolution Process
• The Configuration Parameters
• The information collected previously in the Greedy Collection
• The post-conditions are described by:
• The information that can be used by the Resolution Process
• The information currently in the Greedy Collection
• The algorithm is described through:
• The flow chart
• The requirements
The defined Activities can be combined in Profiles (see Section 10).
The remainder of this section lists requirements and contains a detailed definition of each
Activity.

9.1 Activities - Requirements


This section contains requirements that must be observed when implementing the Activities
described in this document.

Requirements 23: Activities - General

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.

NFC Activity Specification Page 52


Poll Mode – Activities

9.2 Technology Detection Activity


This section describes the Technology Detection Activity. The purpose of the Technology
Detection Activity is to scan for devices of certain technologies that are within range.

9.2.1 Pre-conditions
The Configuration Parameters for the Technology Detection Activity are listed in Table 8:

Table 8: Technology Detection Activity – Configuration Parameters

Name Format Size Description

CON_POLL_A binary 1 bit 1b: Poll for NFC-A Technology


0b: Do not poll for NFC-A Technology

CON_POLL_B binary 1 bit 1b: Poll for NFC-B Technology


0b: Do not poll for NFC-B Technology

CON_POLL_F binary 1 bit 1b: Poll for NFC-F Technology


0b: Do not poll for NFC-F Technology

CON_POLL_P binary 1 bit 1b: Poll for Proprietary Technology


0b: Do not poll for Proprietary Technology

CON_BAIL_OUT_A binary 1 bit 1b: Bail-out after NFC-A


0b: No bail-out after NFC-A

CON_BAIL_OUT_B binary 1 bit 1b: Bail-out after NFC-B


0b: No bail-out after NFC-B

CON_BITR Integer 1 Byte Bit rate for NFC-F


2: 212 kbps
3: 424 kbps

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.

NFC Activity Specification Page 53


Poll Mode – Activities

9.2.2 Post-conditions
The output of the Technology Detection Activity is listed in Table 9:

Table 9: Technology Detection Activity – Output Parameters

Name Format Size Description

FOUND_A binary 1 bit 1b: NFC-A Technology found


0b: NFC-A Technology not found

FOUND_B binary 1 bit 1b: NFC-B Technology found


0b: NFC-B Technology not found

FOUND_F binary 1 bit 1b: NFC-F Technology found


0b: NFC-F Technology not found

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:

Table 10: Technology Detection Activity – Output into Greedy Collection

Name Format Size Description

GRE_POLL_A[] array of variable Each element contains a Response to an


Byte ALL_REQ or SENS_REQ Command. For NFC-
Sequences A, the array is limited to one element.

GRE_POLL_B[] array of variable Each element contains a Response to an


Byte ALLB_REQ or SENSB_REQ Command. For
Sequences NFC-B, the array is limited to one element.

GRE_POLL_F[] array of variable Each element contains a Response to an


Byte SENSF_REQ Command. For NFC-F, the array
Sequences is limited to four elements.

9.2.3 Flow Chart and Requirements


The NFC Forum Device uses a fixed polling order: NFC-A, NFC-B, NFC-F.
If bail-out is set for a particular Technology, the NFC Forum Device in Poll Mode checks
whether this Technology or a Technology polled for earlier has been detected. If so, the NFC
Forum Device stops further polling; if not, the NFC Forum Device continues polling for the
remaining technologies.
After polling for NFC-F, and therefore, before polling for a Proprietary Technology, the NFC
Forum Device always checks whether a Technology has been detected.

NFC Activity Specification Page 54


Poll Mode – Activities

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?

yes yes yes yes


3 9 16 22
wait NFC-A wait NFC-B wait NFC-F wait proprietary
guard time guard time guard time guard time

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 ?

yes yes yes


6 12 19

FOUND_A := 1 FOUND_B := 1 FOUND_F := 1

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

Figure 5: Technology Detection Activity – Flow Chart

Symbols in this section refer to corresponding symbols in Figure 5.

NFC Activity Specification Page 55


Poll Mode – Activities

Requirements 24: Technology Detection Activity

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.

NFC Activity Specification Page 56


Poll Mode – Activities

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].

NFC Activity Specification Page 57


Poll Mode – Activities

Poll Mode

9.2.3.18 Symbol 18:


If the NFC Forum Device does not receive a Response to the SENSF_REQ
Command, then the NFC Forum Device MUST proceed to Symbol 20.
Otherwise, the NFC Forum Device MUST store the Response(s) in GRE_POLL_F[]
and it MUST proceed to Symbol 19.
9.2.3.19 Symbol 19:
The NFC Forum Device MUST set FOUND_F to 1.
9.2.3.20 Symbol 20:
If FOUND_A or FOUND_B or FOUND_F 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 21.
9.2.3.21 Symbol 21:
If the NFC Forum Device is configured to poll for a Proprietary Technology (i.e.,
CON_POLL_P = 1), then the NFC Forum Device MUST proceed to Symbol 22.
Otherwise, the NFC Forum Device MUST conclude the Technology Detection
Activity.
9.2.3.22 Symbol 22:
Before proceeding, the NFC Forum Device MUST maintain an Unmodulated Carrier
for a guard time as specified in 6.1.1.2.
9.2.3.23 Symbol 23:
Further processing and output Parameters of proprietary technology is out of scope of this
specification.

NFC Activity Specification Page 58


Poll Mode – Activities

9.3 Collision Resolution Activity


This section describes the Collision Resolution Activity.

9.3.1 Pre-conditions
The Configuration Parameters for the Collision Resolution Activity are listed in Table 11:

Table 11: Collision Resolution Activity – Configuration Parameters

Name Format Size Description

CON_DEVICES_LIMIT Hexadecimal 1 Byte CON_DEVICES_LIMIT = 00h:


No identifier has to be resolved
when a collision is detected.
CON_DEVICES_LIMIT > 00h:
Number of resolved NFCIDx
device identifiers beyond which
the collision resolution process
can stop resolving when collisions
are still pending.

CON_ADV_FEAT Binary 1 bit 0b: Advanced protocol features


not activated
1b: Advanced protocol features
activated

CON_ANTICOLL Binary 1 bit 0b: Do not use anti-collision


1b: Use anti-collision

The Input Parameters for the Collision Resolution Activity are listed in Table 12:

Table 12: Collision Resolution Activity – Input Parameters

Name Format Size Description

INT_TECH_SEL binary 2 bit 00b: Resolve NFC-A Technology


01b: Resolve NFC-B Technology
10b: Resolve NFC-F Technology

NFC Activity Specification Page 59


Poll Mode – Activities

The data requested from the Greedy Collection is listed in Table 13:

Table 13: Collision Resolution Activity – Input from Greedy Collection

Name Format Size Description

GRE_POLL_A[] array of variable Each element contains a Response


Byte to an ALL_REQ or SENS_REQ
Sequences Command.
For NFC-A, the array is limited to
one element.

GRE_POLL_B[] array of variable Each element contains a Response


Byte to an ALLB_REQ or
Sequences SENSB_REQ Command. For
NFC-B, the array is limited to one
element.

GRE_POLL_F[] array of variable Each element contains a Response


Byte to an SENSF_REQ Command.
Sequences For NFC-F, the array is limited to
four elements.

9.3.2 Post-conditions
The Output Parameters returned to the Resolution Process are listed in Table 14:

Table 14: Collision Resolution Activity – Output Parameters

Name Format Size Description

INT_NFCIDX[n], array of variable Contains identifiers of the devices


n = 1 to N identifiers resolved. N denotes the number of
devices resolved. The size of each
identifier is technology dependent.

INT_NFCIDX_SLEEP[n], Binary 1 bit 0b: Device not in sleep state


n = 1 to N 1b: Device in sleep state

INT_COLL_PEND Binary 1 bit 0b: No collision pending


1b: Collisions pending

NFC Activity Specification Page 60


Poll Mode – Activities

The data returned to the Greedy Collection is listed in Table 15:

Table 15: Collision Resolution Activity – Output into Greedy Collection

Name Format Size Description

GRE_SEL_RES[] array of variable Response of each identified device.


Byte Each element contains a SEL_RES Response
Sequences from an NFC-A device.

GRE_SENSB_RES[] array of variable Response of each identified device.


Byte Each element contains a Response to an
Sequences ALLB_REQ or SENSB_REQ Command from
an NFC-B device.

GRE_SENSF_RES[] array of variable Response of each identified device.


Byte Each element contains a Response to an
Sequences SENSF_REQ Command from an NFC-F device.

9.3.3 Flow Chart (Normative)


The Collision Resolution Activity to be performed depends on the value of the INT_TECH_SEL
parameter and is defined in the normative Figure 6.

1
yes
INT_TECH_SEL A
= 00b ?

no

2
yes
INT_TECH_SEL B
= 01b ?

no

3
yes
INT_TECH_SEL F
= 10b ?

no

Figure 6: Collision Resolution Activity (Sheet 1, Entry) – Normative Flow Chart

NFC Activity Specification Page 61


Poll Mode – Activities

9.3.4 Flow Chart and Requirements for NFC-A


The purpose of the NFC-A-related part of the Collision Resolution Activity is to identify an NFC
Forum Device within range that has activated support for NFC-A Technology (subset). The
algorithm works as follows:
The algorithm selects one device after the other. Every time a collision is detected, the
algorithm continues with the valid bits of the NFCID1 CLn followed by a 1b. This way,
multiple devices can be identified by selecting all cascade levels of one device before
restarting the algorithm to select the next device. Before restarting the algorithm, the device
identified is sent to SLEEP_A Sub-state to exclude it from the remaining collision resolution
process.
The NFC Forum Device can be configured to shorten the process by using the
CON_DEVICES_LIMIT Configuration Parameters. The CON_DEVICES_LIMIT is used to
conclude the NFC-A Collision Resolution Activity after identification of a set number of devices,
even if collisions are still pending.
If the CON_DEVICES_LIMIT is set to zero, then collision detection only is performed. That is,
if a collision is detected, the NFC Forum Device concludes the NFC-A Collision Resolution
Activity indicating a collision without identifying any device.
Figure 7 describes the NFC-A-related part of the Collision Resolution Activity.

NFC Activity Specification Page 62


Poll Mode – Activities

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

Figure 7: Collision Resolution Activity (Sheet 2, connector A, NFC-A) – Flow Chart

NFC Activity Specification Page 63


Poll Mode – Activities

Symbols in this section refer to corresponding symbols in Figure 7.

Requirements 25: Collision Resolution Activity – NFC-A

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.

NFC Activity Specification Page 64


Poll Mode – Activities

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].

NFC Activity Specification Page 65


Poll Mode – Activities

Poll Mode

9.3.4.20 Symbol 19:


If INT_COLL_PEND has a value of 1 and the device counter is lower than the
CON_DEVICES_LIMIT, then the NFC Forum Device MUST proceed to Symbol 20.
Otherwise, the NFC Forum Device MUST conclude the NFC-A Collision Resolution
Activity.
9.3.4.21 Symbol 20:
The NFC Forum Device MUST send a SLP_REQ Command to put the device with
identifier INT_NFCIDX[device counter - 1] in the SLEEP_A Sub-state and it MUST
memorize the information that a SLP_REQ Command has been sent to the device by
setting INT_NFCIDX_SLEEP[device counter - 1] equal to 1.
9.3.4.22 Symbol 21:
The NFC Forum Device MUST send the SENS_REQ Command and it MUST wait
for the SENS_RES Response afterward, as specified in [DIGITAL].
The NFC Forum Device MUST proceed to Symbol 3.
9.3.4.23 Symbol 22:
The NFC Forum Device sends the RID Command as indicated in [DIGITAL].
9.3.4.24 Symbol 23:
If the NFC Forum Device detects a Collision in the Response to the RID, the NFC
Forum Device MUST proceed to Symbol 24.
Otherwise, the NFC Forum Device MUST proceed to Symbol 25.
9.3.4.25 Symbol 24:
The NFC Forum Device MUST set INT_COLL_PEND to 1b and conclude the NFC-
A Collision Resolution Activity.
9.3.4.26 Symbol 25:
The NFC Forum Device MUST set INT_COLL_PEND to 0b.
9.3.4.27 Symbol 26:
The NFC Forum Device MUST increment the device counter by 1 and store the RID
Response, including identifier UID0…UID3 in INT_NFCIDX[device counter-1], and
conclude the NFC-A Collision Resolution Activity.

NFC Activity Specification Page 66


Poll Mode – Activities

9.3.5 Flow Chart and Requirements for NFC-B


The purpose of the NFC-B-related part of the Collision Resolution Activity is to identify an NFC
Forum Device within range that has activated support for NFC-B Technology. The algorithm
works as follows:
If the Technology Detection resulted in a Valid SENSB_RES Response (i.e., no collisions),
then the NFC Forum Device extracts the identifier and stores it in INT_NFCIDX[].If there is
just one device detected or just one device is resolved, than the device is left in the
READY_B_DECL Sub-state.
If the Technology Detection resulted in an invalid SENSB_RES Response (i.e., collisions), then
the NFC Forum Device polls with the number of timeslots set to 1. The NFC Forum Device saves
each Valid Response to a SENSB_REQ or SLOT_MARKER in GRE_SENSB_RES[]. Each
Valid Response results in an identifier that is stored in INT_NFCIDX[] and each device identified
is subsequently put in the SLEEP_B Sub-state, except the last resolved device (it stays in the
READY_B_DECL Sub-state).
As long as collisions occur and no device has been identified yet, the NFC Forum Device
increments the number of time slots and sends new SENSB_REQ Commands. If there are still
collisions after having completed the collision resolution with the maximum number of time slots,
no further attempt is made to isolate the identifiers.
When at least one device has already been identified, the number of slots is not further
incremented.
The NFC Forum Device can be configured to shorten the process by using the
CON_DEVICES_LIMIT parameter. The parameter is used to conclude the NFC-B Collision
Resolution Activity after identification of a set number of devices, even if collisions are still
pending.
If this parameter is set to zero, then collision detection only is performed. That is, if a collision is
detected, the NFC Forum Device concludes the NFC-B Collision Resolution Activity.
NOTE In this version of the document, NFC Forum advanced protocol features are not
supported, and therefore, the NFC Forum Device only polls for devices not
supporting NFC Forum advanced protocol features.
Figure 8 describes the NFC-B-related part of the Collision Resolution Activity.

NFC Activity Specification Page 67


Poll Mode – Activities

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

Figure 8: Collision Resolution Activity (Sheet 3, connector B, NFC-B) – Flow Chart

Symbols in this section refer to corresponding symbols in Figure 8.

NFC Activity Specification Page 68


Poll Mode – Activities

Requirements 26: Collision Resolution Activity – NFC-B

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.

NFC Activity Specification Page 69


Poll Mode – Activities

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.

NFC Activity Specification Page 70


Poll Mode – Activities

Poll Mode

9.3.5.17 Symbol 16:


The NFC Forum Device MUST increase the number of slots to the next value
allowed. The values allowed for the number of slots are specified in [DIGITAL],
within the SENSB_REQ Command.
The NFC Forum Device MUST proceed to Symbol 18.
9.3.5.18 Symbol 17:
If the device counter is lower than the CON_DEVICES_LIMIT, then the NFC Forum
Device MUST proceed to Symbol 18.
Otherwise, the NFC Forum Device MUST conclude the NFC-B Collision Resolution
Activity.
9.3.5.19 Symbol 18:
The NFC Forum Device MUST send a SENSB_REQ Command, MUST wait for the
SENSB_RES Response afterward as specified in [DIGITAL], and it MUST proceed
to Symbol 4.
The NFC Forum Device MUST proceed to Symbol 3.
9.3.5.20 Symbol 19:
The NFC Forum Device MUST set INT_COLL_PEND to 1 and it MUST conclude
the NFC-B Collision Resolution Activity.
9.3.5.21 Symbol 20:
The NFC Forum Device MUST send a SLOT_MARKER Command indicating the
current slot.
The NFC Forum Device MUST proceed to Symbol 4.

NFC Activity Specification Page 71


Poll Mode – Activities

9.3.6 Flow Chart and Requirements for NFC-F


The purpose of the NFC-F-related part of the Collision Resolution Activity is to identify an NFC
Forum Device that has activated support for NFC-F Technology (subset). The algorithm works as
follows:
The NFC Forum Device retrieves the number of devices that already have been identified. If
this number is lower than the value of CON_DEVICES_LIMIT, then the NFC Forum Device
polls again by sending a SENSF_REQ Command with the maximum number of time slots
set.
Figure 9 describes the NFC-F related part of the Collision Resolution Activity.

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[]

Figure 9: Collision Resolution Activity (Sheet 4, connector F, NFC-F) – Flow Chart

Symbols in this section refer to corresponding symbols in Figure 9.

NFC Activity Specification Page 72


Poll Mode – Activities

Requirements 27: Collision Resolution Activity – NFC-F

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.

NFC Activity Specification Page 73


Poll Mode – Activities

9.4 Device Activation Activity


This section describes the Device Activation Activity.
The Device Activation Activity activates one device out of the set of devices identified during
Technology Detection Activity and Collision Resolution Activity. The resolution process decides
which device to activate.

9.4.1 Pre-conditions
The Configuration Parameters for the Device Activation Activity are listed in Table 16:

Table 16: Device Activation Activity – Configuration Parameters

Name Format Size Description

CON_ATR Hexadecimal 3 Bytes ATR_REQ Command parameter


- Refer to [DIGITAL] (Byte 13
of ATR_REQ) for the coding
of Byte 1.
- Refer to [DIGITAL] (Byte 14
of ATR_REQ) for the coding
of Byte 2.
- Refer to [DIGITAL] (Byte 15
of ATR_REQ) for the coding
of Byte 3.
- Refer to [DIGITAL] (Byte 16
of ATR_REQ) for the coding
of Byte 4.

CON_GB Hexadecimal n Bytes General bytes of the ATR_REQ


or Higher Layer INF of ATTRIB
Refer to [DIGITAL] Byte 17+n of
ATR_REQ and [DIGITAL] Byte
10+n for ATTRIB.
For the ATR_REQ, these bytes
contain the General Bytes
(GT0…GTn) as information for
LLCP.
For ATTRIB, these bytes contain
High Layer INF.

CON_RATS Hexadecimal 1 Byte RATS Command Parameters


Refer to [DIGITAL] (Byte 2 of
RATS Command) for the coding
of Byte 1.

NFC Activity Specification Page 74


Poll Mode – Activities

Name Format Size Description

CON_ATTRIB hexadecimal 3 Bytes ATTRIB Command Parameters


- Refer to [DIGITAL] (Byte 6
of ATTRIB Command) for
the coding of Byte 1.
- Refer to [DIGITAL] (Byte 7
of ATTRIB Command) for
the coding of Byte 2.
- Refer to [DIGITAL] (Byte 8
of ATTRIB Command) for
the coding of Byte 3.
- Refer to [DIGITAL] (Byte 9
of ATTRIB Command) for
the coding of Byte 4.

CON_BITR_NFC_DEP Integer 1 Byte Desired Bit rate


- 0: maintain the bit rate
- 1: 106 kbps
- 2: 212 kbps
- 3: 424 kbps

The Input Parameters for the Device Activation Activity are listed in Table 17:

Table 17: Device Activation Activity – Input Parameters

Name Format Size Description

INT_TECH_SEL binary 2 bit Technology to activate


- 00b: NFC-A Technology
- 01b: NFC-B Technology
- 10b: NFC-F Technology

INT_INDEX Integer 1 Byte Contains index to the identifier of the


device to be activated

INT_PROTOCOL Binary 3 bit Protocol of device to be activated


- 000b: Use NFC-DEP
- 001b: Use ISO-DEP
- 010b: Use Type 1 Tag Platform
- 011b: Use Type 2 Tag Platform
- 100b: Use Type 3 Tag Platform

NOTE Use of Type 4 Tag Platform is covered by use of ISO-DEP.


The data requested from the Greedy Collection is listed in Table 18:

NFC Activity Specification Page 75


Poll Mode – Activities

Table 18: Device Activation Activity – Input from Greedy Collection

Name Format Size Description

GRE_SEL_RES[] array of Byte variable Response of each identified device.


Sequences Each element contains a SEL_RES
Response from an NFC-A device.

GRE_SENSB_RES[] array of Byte variable Response of each identified device.


Sequences Each element contains a Response to an
ALLB_REQ or SENSB_REQ Command
from an NFC-B device.

GRE_SENSF_RES[] array of Byte variable Response of each identified device.


Sequences Each element contains a Response to an
SENSF_REQ Command from an NFC-F
device.

9.4.2 Post-conditions
The Output Parameters returned to the Resolution Process are listed in Table 19:

Table 19: Device Activation Activity – Output Parameters

Name Format Size Description

INT_INDEX Integer 1 Byte Index to the identifier of the device


activated

CON_BITR_NFC_DEP Integer 1 Byte Current Bitrate in case of NFC_DEP


activation:
- 0: maintain bit rate
- 1: 106 kbps
- 2: 212 kbps
- 3: 424 kbps

The data returned to the Greedy Collection is listed in Table 20:

Table 20: Device Activation Activity – Output into Greedy Collection

Name Format Size Description

GRE_ATR hexadecimal ≥ 17 Bytes ATR_RES Response of device activated

GRE_RATS hexadecimal ≥ 2 Bytes RATS Response of device activated

GRE_ATTRIB hexadecimal ≥ 1 Byte ATTRIB Response of device activated

NFC Activity Specification Page 76


Poll Mode – Activities

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.

9.4.3 Flow Chart (Normative)


The Device Activation Activity to be performed depends on the value of the INT_TECH_SEL
parameter and is defined in the normative Figure 10.

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

9.4.4 Flow Chart and Requirements for NFC-A


The purpose of the NFC-A-related part of the Device Activation Activity is to activate an NFC
Forum Device within range that has activated support for NFC-A Technology (subset).
Depending on the outcome of the Resolution Process of the previous Activity, the device to be
activated supports NFC-DEP Protocol, Type 4A Tag Platform, Type 2 Tag Platform, or
Type 1 Tag Platform.
Figure 11 illustrates the NFC-DEP Protocol (NFC-A), Type 4A Tag Platform,
Type 2 Tag Platform, and Type 1 Tag Platform related parts of the Activation Activity.
NOTE There is no specific action for the Type 1 Tag Platform because this platform is
activated implicitly upon completion of the NFC-A Collision Resolution Activity.
For the same reason, there is no specific action for the Type 2 Tag Platform, unless it
is in the SLEEP_A Sub-state.

NFC Activity Specification Page 77


Poll Mode – Activities

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

NFC Activity Specification Page 78


Poll Mode – Activities

Symbols in this section refer to corresponding symbols in Figure 11.

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.

NFC Activity Specification Page 79


Poll Mode – Activities

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

NFC Activity Specification Page 80


Poll Mode – Activities

Poll Mode

9.4.4.15 Symbol 14:


The NFC Forum Device MUST proceed to Symbol 15 if the following conditions
apply:
• PSL_ REQ is supported
• CON_BITR_NFC_DEP is equal to or larger than 2
• 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-A Activation Activity.
The NFC Forum Device MAY also proceed to Symbol 15 if it wants to change the Length
Reduction Values by using the FSL parameter of PSL_REQ as defined in [DIGITAL].

9.4.4.16 Symbol 15:


The NFC Forum Device MUST send a PSL_REQ.
• 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 of PSL_REQ
• Conclude the NFC-A Activation Activity

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.

9.4.5 Flow Chart and Requirements for NFC-B


The purpose of the NFC-B Device Activation Activity is to activate an NFC Forum Device
within range that has activated support for the Type 4B Tag Platform.
Figure 12 illustrates the Type 4B Tag Platform related part of the Activation Activity.

NFC Activity Specification Page 81


Poll Mode – Activities

DA_2

0
DEVICE IN NO
SLEEP_B SUB-
STATE?

YES
1

ALLB_REQ

Reset sleep flags

ATTRIB

Figure 12: Device Activation Activity (Sheet 3, Connector DA_2, Type 4B Tag Platform) –
Flow Chart

Symbols in this section refer to corresponding symbols in Figure 12.

NFC Activity Specification Page 82


Poll Mode – Activities

Requirements 29: Device Activation Activity – Type 4B Tag Platform

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.

9.4.6 Flow Chart and Requirements for NFC-F


The purpose of the NFC-F Device Activation Activity is to activate an NFC Forum Device within
range that has activated support for NFC-F Technology (subset). Such devices(?) may support
NFC-DEP Protocol or Type 3 Tag Platform.
Figure 13 illustrates the NFC-DEP Protocol (NFC-F) and Type 3 Tag Platform part of the
Activation Activity.
NOTE There is no specific action for the Type 3 Tag Platform as this platform is activated
implicitly upon completion of the NFC-F Collision Resolution Activity.

NFC Activity Specification Page 83


Poll Mode – Activities

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

Symbols in this section refer to corresponding symbols in Figure 13.

NFC Activity Specification Page 84


Poll Mode – Activities

Requirements 30: Device Activation Activity – NFC-DEP (NFC-F)

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.

NFC Activity Specification Page 85


Poll Mode – Activities

9.5 Data Exchange Activity


This section describes the Data Exchange Activity.

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:

Table 21: Data Exchange Activity – Input Parameters

Name Format Size Description

INT_INDEX Integer 1 Byte Index to the identifier of device to


exchange data with.

INT_PROTOCOL Binary 3 bit Protocol of device to exchange data with:


- 000b: Use NFC-DEP
- 001b: Use ISO-DEP
- 010b: Use Type 1 Tag Platform
- 011b: Use Type 2 Tag Platform
- 100b: Use Type 3 Tag Platform

NOTE Use of Type 4 Tag Platform is covered by use of ISO-DEP.


The data requested from the Greedy Collection is listed in Table 22:

Table 22: Device Activation Activity – Input from Greedy Collection

Name Format Size Description

GRE_ATR hexadecimal ≥ 17 Bytes ATR_RES Response of device activated

GRE_RATS hexadecimal ≥ 2 Bytes RATS Response of device activated

GRE_ATTRIB hexadecimal ≥ 1 Byte ATTRIB Response of device activated

9.5.2 Post-conditions
The Output Parameters returned to the Resolution Process are listed in Table 23:

Table 23: Data Exchange Activity – Output Parameters

Name Format Size Description

INT_INDEX Integer 1 Byte Index to the identifier of the active


device

There is no data returned to the Greedy Collection by this Activity.

NFC Activity Specification Page 86


Poll Mode – Activities

9.5.3 Flow Chart (Normative)


The Data Exchange Activity to be performed depends on the value of the INT_PROTOCOL
parameter and is defined in the normative Figure 14.

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

9.5.4 Flow Chart and Requirements for NFC-DEP


The purpose of the NFC-DEP Data Exchange Activity is to exchange data with an NFC Forum
Device within range, communicating over NFC-DEP.
Figure 15 illustrates the NFC-DEP-related part of the Data Exchange Activity.

NFC Activity Specification Page 87


Poll Mode – Activities

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

Symbols in this section refer to corresponding symbols in Figure 15.

Requirements 31: Data Exchange Activity – NFC-DEP

Poll Mode

9.5.4.1 Symbol 1, Symbol 2:


As long as data exchange continues, as controlled by the adjacent upper layer, the
NFC Forum Device MUST send a DEP_REQ Command and it MUST wait for the
DEP_RES Response afterward, as specified in [DIGITAL].

9.5.5 Flow Chart and Requirements for ISO-DEP


The purpose of the ISO-DEP Data Exchange Activity is to exchange data with an NFC Forum
Device within range, communicating over ISO-DEP .
Figure 16 illustrates the ISO-DEP-related part of the Data Exchange Activity.
NOTE The Flow Chart and Requirements in this section also include the
Type 4 Tag Platform as specified in [DIGITAL] and [T4TOP].

NFC Activity Specification Page 88


Poll Mode – Activities

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

Symbols in this section refer to corresponding symbols in Figure 16.

Requirements 32: Data Exchange Activity – ISO-DEP

Poll Mode

9.5.5.1 Symbol 1, Symbol 2:


As long as data exchange continues, as controlled by the adjacent upper layer, the
NFC Forum Device MUST send Commands and receive Responses as specified in
[DIGITAL] for ISO-DEP.

NFC Activity Specification Page 89


Poll Mode – Activities

9.5.6 Flow Chart and Requirements for Type 1 Tag Platform


The purpose of the Type 1 Tag Platform Data Exchange Activity is to exchange data with an
NFC Forum Device within range that has activated support for the Type 1 Tag Platform.
Figure 17 illustrates the Type 1 Tag Platform-related part of the Data Exchange Activity.

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

Symbols in this section refer to corresponding symbols in Figure 17.

Requirements 33: Data Exchange Activity – Type 1 Tag Platform

Poll Mode

9.5.6.1 Symbol 1, Symbol 2:


As long as data exchange continues, as controlled by the adjacent upper layer, the
NFC Forum Device MUST send Commands and receive Responses as specified for
the Type 1 Tag Platform in [DIGITAL] and [T1TOP].
The NFC Forum Device MAY send Commands and receive Responses that are proprietary for the
Type 1 Tag.

9.5.7 Flow Chart and Requirements for Type 2 Tag Platform


The purpose of the Type 2 Tag Platform Data Exchange Activity is to exchange data with an
NFC Forum Device within range that has activated support for the Type 2 Tag Platform.
Figure 18 illustrates the Type 2 Tag Platform-related part of the Data Exchange Activity.

NFC Activity Specification Page 90


Poll Mode – Activities

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

Symbols in this section refer to corresponding symbols in Figure 18.

Requirements 34: Data Exchange Activity – Type 2 Tag Platform

Poll Mode

9.5.7.1 Symbol 1, Symbol 2:


As long as data exchange continues, as controlled by the adjacent upper layer, the
NFC Forum Device MUST send Commands and receive Responses as specified for
the Type 2 Tag Platform in [DIGITAL] and [T2TOP].
The NFC Forum Device MAY send Commands and receive Responses that are proprietary for the
Type 2 Tag.

NFC Activity Specification Page 91


Poll Mode – Activities

9.5.8 Flow Chart and Requirements for Type 3 Tag Platform


The purpose of the Type 3 Tag Platform Data Exchange Activity is to exchange data with an
NFC Forum Device within range that has activated support for the Type 3 Tag Platform.
Figure 19 illustrates the Type 3 Tag Platform related part of the Data Exchange Activity.

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

Symbols in this section refer to corresponding symbols in Figure 19.

Requirements 35: Data Exchange Activity – Type 3 Tag Platform

Poll Mode

9.5.8.1 Symbol 1, Symbol 2:


As long as data exchange continues, as controlled by the adjacent upper layer, the
NFC Forum Device MUST send Commands and receive Responses as specified for
the Type 3 Tag Platform in [DIGITAL] and [T3TOP].
The NFC Forum Device MAY send Commands and receive Responses that are proprietary for the
Type 3 Tag.

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.

NFC Activity Specification Page 92


Poll Mode – Activities

SENSF_REQ

Figure 20: Type 3 Tag Platform Selection – Flow Chart

Symbols in this section refer to corresponding symbols in Figure 20.

Requirements 36: Type 3 Tag Selection

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 .

NFC Activity Specification Page 93


Poll Mode – Activities

9.6 Device Deactivation Activity


This section describes the Device Deactivation Activity.

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:

Table 24: Device Deactivation Activity – Input Parameters

Name Format Size Description

INT_INDEX integer 1 Byte Index to the identifier of device to be


deactivated

INT_PROTOCOL binary 3 bit Protocol to be deactivated:


- 000b: Using NFC-DEP
- 001b: Using ISO-DEP
- 010b: Using Type 1 Tag Platform
protocol
- 011b: Using Type 2 Tag Platform
protocol
- 100b: Using Type 3 Tag Platform
protocol

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:

Table 25: Device Deactivation Activity – Output Parameters

Name Format Size Description

INT_INDEX Integer 1 Byte Index to the identifier of the device


deactivated

There is no data returned to the Greedy Collection by this Activity.

9.6.3 Flow Chart (Normative)


The Device Deactivation Activity to be performed depends on the value of the INT_PROTOCOL
parameter and is defined in the normative Figure 21.

NFC Activity Specification Page 94


Poll Mode – Activities

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

9.6.4 Flow Chart and Requirements for NFC-DEP


The purpose of the NFC-DEP Device Deactivation Activity is to deactivate an NFC Forum
Device within range, communicating over NFC-DEP.
Figure 22 illustrates the NFC-DEP-related part of the Deactivation Activity.

NFC Activity Specification Page 95


Poll Mode – Activities

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

Symbols in this section refer to corresponding symbols in Figure 22.

Requirements 37: Deactivation Activity – NFC-DEP

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.

9.6.5 Flow Chart and Requirements for ISO-DEP


The purpose of the ISO-DEP Device Deactivation Activity is to deactivate an NFC Forum Device
within range, communicating over ISO-DEP.
Figure 23 illustrates the ISO-DEP-related part of the Deactivation Activity.

NFC Activity Specification Page 96


Poll Mode – Activities

DD_2

DESELECT

2
Set
INT_NFCIDX_SLEEP

Figure 23: Deactivation Activity (Sheet 3, connector DD_2, ISO-DEP) – Flow Chart

Symbols in this section refer to corresponding symbols in Figure 23.

Requirements 38: Deactivation Activity – ISO-DEP

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.

9.6.6 Flow Chart and Requirements for Type 1 Tag Platform


For a Type 1 Tag Platform, there is no particular Device Deactivation Activity.

9.6.7 Flow Chart and Requirements for Type 2 Tag Platform


The purpose of the Type 2 Tag Platform Deactivation Activity is to deactivate a
Type 2 Tag Platform within range.
Figure 24 illustrates the Type 2 Tag Platform-related part of the Deactivation Activity.

NFC Activity Specification Page 97


Poll Mode – Activities

DD_3

SLP_REQ

Figure 24: Deactivation Activity (Sheet 4, connector DD_3, Type 2 Tag Platform) – Flow
Chart

Symbols in this section refer to corresponding symbols in Figure 24.

Requirements 39: Deactivation Activity – Type 2 Tag Platform

Poll Mode

9.6.7.1 Symbol 1:
The NFC Forum Device MUST send a SLP_REQ Command, as specified in
[DIGITAL].

9.6.8 Flow Chart and Requirements for Type 3 Tag Platform


For a Type 3 Tag Platform, there is no particular Device Deactivation Activity.

NFC Activity Specification Page 98


Poll Mode – Profiles

10 Poll Mode – Profiles


A Profile defines a sequence of Activities to be performed by the NFC Forum Device. This
sequence is not necessarily fixed, but can develop based on the outcome of the Resolution
Processes.
A Profile definition consists of:
• The Configuration Parameters values of the Activities used in the Profile
• The Resolution Process of the Profile
A Resolution Process consists of an algorithm that is controlled by the adjacent upper layer and
determines the next Activity to call, depending on the outcome of the previous Activity. For each
possible Activity to call next, the Resolution Process provides the necessary input Parameters.
The adjacent upper layer has the freedom to execute profiles sequentially in any order and it may
also freely switch between Profiles in Poll Mode and Listen Mode.

yes no
Poll Mode?

Profile LISTEN MODE


Resolution process

yes
Continue?

no

Figure 25: Sequential execution of profiles

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.

NFC Activity Specification Page 99


Poll Mode – Profiles

10.1 Greedy Collection Information


For some decisions in the resolution processes, information contained in the Greedy Collection
must be evaluated. Table 26 describes what information in the Greedy Collection must be used
for a specific decision.

Table 26: Greedy Collection Information Required for Resolution Processes

Decision Greedy Collection More


Information
Is NFC-A device capable Determined by b6 and b7 of the SEL_RES of [DIGITAL]
of NFC-DEP? the device, which is contained in Section 4.8.2
GRE_SEL_RES[].
Is NFC-F device capable Determined by Byte 1 and Byte 2 of NFCID2 [DIGITAL]
of NFC-DEP? field in SENSF_RES. SENSF_RES of the Section 6.6.2
device, which is contained in
GRE_POLL_F[] (after Technology
Detection) or GRE_SENSF_RES[] (after
Collision Resolution).
Does device support Determined by b1–b5 of SENS_RES of the [DIGITAL]
Type 1 Tag Platform? device, which is contained in Section 4.6.3
GRE_POLL_A[].
Does device support Determined by b6 and b7 of the SEL_RES of [DIGITAL]
Type 2 Tag Platform? the device, which is contained in Section 4.8.2
GRE_SEL_RES[].

Does device support Determined by Byte 1 and Byte 2 of NFCID2 [DIGITAL]


Type 3 Tag Platform? field in SENSF_RES. SENSF_RES of the Section 6.6.2
device, which is contained in
GRE_POLL_F[] (after Technology
Detection) or GRE_SENSF_RES[] (after
Collision Resolution).
Does NFC-A device Determined by b6 and b7 of SEL_RES of the [DIGITAL]
support ISO-DEP? device, which is contained in Section 4.8.2
GRE_SEL_RES[].

Does NFC-B device Determined by b1 of Protocol_Type field of [DIGITAL]


support ISO-DEP? SENSB_RES, which is contained in Section 5.6.2
GRE_POLL_B[] (after Technology
Detection) or GRE_SENSB_RES[] (after
Collision Resolution).

NFC Activity Specification Page 100


Poll Mode – Profiles

10.2 P2P Poll Profile


The P2P Poll Profile is developed to establish a communication with another NFC Forum device
using the NFC-DEP protocol. To enable a high data throughput for LLCP, the Profile uses the
highest bit rate supported by the NFC Forum Device in Listen Mode for NFC-DEP. The Profile
ends without establishing a communication if multiple NFC-DEP capable devices are found.

10.2.1 Configuration Parameters


For this Profile, the Technology Detection uses a speed of 424kbit/s for NFC-F.
The Configuration Parameters for the P2P Poll Profile are listed in Table 27:

Table 27: P2P Poll Profile Configuration Parameters

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

10.2.2 Resolution Process


The resolution process of the P2P Poll Profile is defined by Figure 26.

1
Start at 424 and stay at this bit rate

NFC Activity Specification Page 101


Poll Mode – Profiles

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 := get next INT_INDEX := device index


NFCIDX INT_PROTOCOL := 000b

Current NFCIDX
Device Activation
no
indicates NFC-DEP
capability?

yes Data Exchange


Sequence of commands
NFCDEPDevices + 1 according to NFC-DEP
Remember NFCIDX

Device Deactivation
no
NFCDEPDevices > 1?

yes

Figure 26: P2P Poll Profile Resolution Process

NFC Activity Specification Page 102


Poll Mode – Profiles

10.3 NDEF Poll Profile


The purpose of the NDEF Poll Profile is to access the NDEF data on a tag. The Profile first
searches for an NDEF-capable tag and, if there is exactly one, it establishes a communication
with it. Depending on the tag type, detecting NDEF on a tag may require that a data exchange
Activity is performed with the device and READ Commands are issued according to the
corresponding Type Tag Platform Operations specification. The Profile ends without establishing
a communication if multiple NDEF-capable tags are detected.

10.3.1 Configuration Parameters


The Configuration Parameters for the NDEF Poll Profile are listed in Table 28:

Table 28: NDEF Poll Profile Configuration Parameters

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

10.3.2 Resolution Process


The resolution process of the NDEF Poll Profile is defined by Figure 27 and Figure 28.

NFC Activity Specification Page 103


Poll Mode – Profiles

NDEF

Technology
Detection

no no no
FOUND_A := 1b? FOUND_B := 1b? FOUND_F := 1b?

yes yes yes

INT_TECH_SEL := 00b INT_TECH_SEL := 01b INT_TECH_SEL := 10b

Collision_Resolution Collision_Resolution

Next NFCIDX no Next NFCIDX no


available? available?

yes yes

current index := index of next current NFCIDX := get next


NFCIDX NFCIDX

Type 1 Platform no 14443-4 protocol no Type 2 Platform no no 14443-4 protocol


supported supported? supported? supported?

yes yes yes yes


INT_INDEX := current index INT_INDEX := current index INT_INDEX := current index INT_INDEX := current index INT_INDEX := 1
INT_PROTOCOL := 010b INT_PROTOCOL := 001b INT_PROTOCOL := 011b INT_PROTOCOL := 001b INT_PROTOCOL := 100b

Device Activation Device Activation Device Activation Device Activation

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

Device Deactivation1 Device Deactivation1

no no NDEF device(s) no
NDEF detected? NDEF detected?
detected?

yes yes yes

Remember NDEF device Remember NDEF device Remember NDEF device(s)

no More than one no More than one More than one no


NDEF device? NDEF device? NDEF device?

yes yes yes

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.

Figure 27: NDEF Poll Profile Resolution Process – Sheet 1

NFC Activity Specification Page 104


Poll Mode – Profiles

current index := index of found


NDEF device

NDEF device is no NDEF device is No (NDEF device is Type F)


Type A? Type B?

yes yes

INT_TECH_SEL := 00b INT_TECH_SEL := 01b INT_TECH_SEL := 10b

Type 1 Platform no 14443-4 protocol no (Type 2 platform supported)


supported supported?

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

Device Activation Device Activation Device Activation Device Activation

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]

Device Deactivation Device Deactivation Device Deactivation Device Deactivation

Figure 28: NDEF Poll Profile Resolution Process – Sheet 2

NFC Activity Specification Page 105


Poll Mode – Profiles

10.4 P2PNDEF Poll Profile


The P2PNDEF Profile searches for NDEF tags and NFC-DEP-capable devices. If exactly one
device is identified, the Profile starts a communication session with this device. If the identified
device is an NDEF-capable tag, the communication session allows the device to access NDEF on
the tag. If the identified device is an NFC Forum Device, the communication session establishes
an NFC-DEP communication between the devices. The Profile ends without establishing a
communication if multiple NFC Forum devices or NFC Forum tags are detected.

10.4.1 Configuration Parameters


The Configuration Parameters for the P2PNDEF Poll Profile are listed in Table 29:

Table 29: P2PNDEF Poll Profile Configuration Parameters

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

10.4.2 Resolution Process


The resolution process has been split into parts by using subroutines to improve readability.
Figure 29 shows the main flow of the resolution process. The “FOUND_[A|B|F] processing”
subroutines (as shown in Figure 30, Figure 31, and Figure 32) detect the number of NDEF-
enabled tags and NFC-DEP targets for the corresponding technology. The “Device
communication” subroutine, as shown in Figure 33, handles the data exchange if a single
communication partner has been identified.

NFC Activity Specification Page 106


Poll Mode – Profiles

P2PNDEF

Technology
Detection

no no no One device no
FOUND_A = 1b? FOUND_B = 1b? FOUND_F = 1b?
found?

yes yes yes yes

FOUND_A FOUND_B FOUND_F Device


processing processing processing communication

More than one no More than one no More than one no


Device found? Device found? Device found?

yes yes yes

Figure 29: NDEFP2P Poll Profile Resolution Process – Main Flow

NFC Activity Specification Page 107


Poll Mode – Profiles

FOUND_A
processing

INT_TECH_SEL := 00b

Collision_Resolution

Next NFCIDX no
available?

yes

Current index := index of next


NFCIDX

Type 1 Platform no 14443-4 protocol no Type 2 Platform no


NFC-DEP supported?
no
supported supported? supported?

yes yes yes yes


INT_INDEX := current index INT_INDEX := current index INT_INDEX := current index
INT_PROTOCOL := 010b INT_PROTOCOL := 001b INT_PROTOCOL := 011b

Device Activation Device Activation Device Activation

Data Exchange Data Exchange Data Exchange


Detect NDEF according to Detect NDEF according to Detect NDEF according to
[T1T OP]. [T4T OP]. [T2T OP].

Device Deactivation1

no
NDEF detected?

yes

Remember device Remember device

no More than one yes


Device found?

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.

Figure 30: NDEFP2P Poll Profile Resolution Process – FOUND_A Processing

NFC Activity Specification Page 108


Poll Mode – Profiles

FOUND_B
processing

INT_TECH_SEL := 01b

Collision_Resolution

Next NFCIDX no
available?

yes

Current index := index of next


NFCIDX

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

no More than one


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.

Figure 31: NDEFP2P Poll Profile Resolution Process – FOUND_B Processing

NFC Activity Specification Page 109


Poll Mode – Profiles

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

Figure 32: NDEFP2P Poll Profile Resolution Process – FOUND_F Processing

NFC Activity Specification Page 110


Poll Mode – Profiles

Device
communication

current index :=
index of found device

Device is no Device is No (device is Type F)


Type A? Type B?

yes yes

INT_TECH_SEL := 00b INT_TECH_SEL := 01b INT_TECH_SEL := 10b

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

Device Activation Device Activation

Data Exchange Data Exchange Data Exchange


Sequence of commands in Sequence of commands in Sequence of commands in
accordance to accordance to accordance to
[T4T OP] [T3T OP] NFC-DEP

Device Deactivation Device Deactivation

Figure 33: NDEFP2P Poll Profile Resolution Process – Device Communication

NFC Activity Specification Page 111


Poll Mode – Profiles

NFC-A
communication

yes

Type 1 Platform no 14443-4 protocol no Type 2 Platform no (NFC-DEP supported)


supported supported? supported?

yes yes 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

Device Activation Device Activation Device Activation Device Activation

Data Exchange Data Exchange Data Exchange Data Exchange


Sequence of commands in Sequence of commands in Sequence of commands in Sequence of commands in
accordance to accordance to accordance to accordance to
[T1T OP] [T4T OP] [T2T OP] NFC-DEP

Device Deactivation Device Deactivation Device Deactivation Device Deactivation

Figure 34: NDEFP2P Poll Profile Resolution Process – NFC-A Communication

NFC Activity Specification Page 112


Listen Mode – State Diagram (Informative)

A. Listen Mode – State Diagram (Informative)


Figure 35 shows a graphical representation of an NFC Forum Device in Listen Mode.

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

SENSB_REQ (AFI, N>),


ALLB_REQ (AFI, N>)
SENSB_REQ (AFI, N1),
ALLB_REQ (AFI, N1),
SLOT_MARKER
SENSB_REQ (nAFI),
ALLB_REQ (nAFI) SENSB_REQ (AFI, N1),
READY_B_ ALLB_REQ (AFI, N1)
REQU OTHER
OTHER CARD
EMULATOR
SENSB_REQ (nAFI),
ALLB_REQ (nAFI) SENSB_REQ (AFI, N>), 3
CUP
ALLB_REQ (AFI, N>) CUP

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

READY_A' * SDD_REQ CL2 READY_A' SDD_REQ CL2

SEL_REQ CL2 SEL_REQ CL2


SEL_REQ CL2
SEL_REQ CL2
SENSF_REQ

READY_A" * SDD_REQ CL3 READY_A" SDD_REQ CL3


OTHER
SLP_REQ
OTHER
SEL_REQ CL3
SEL_REQ CL3 PSL_REQ (F)

ACTIVE_A * ACTIVE_A SLEEP_AF


OTHER
ATR_REQ
ATR_REQ
SLP_REQ

RATS ATR_ DSL_REQ

RATS
READY_A
DEP_REQ,
DESELECT RLS_REQ PSL_REQ (A), DSL_REQ
OTHER ALL_REQ
OTHER
CARD
EMULATOR TARGET_A
4A OTHER

Figure 35: Listen Mode – State Diagram (Informative)

NFC Activity Specification Page 113


Values

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.

Table 30: Poll Mode and Listen Mode Parameter Values

Parameter Poll Mode Value Listen Mode Value Units


Min Nominal Max Min Nominal Max
tFIELD_OFF 5.1 5.0 ms
PTGTA 0.5 ms
PTGTB 3.8 ms
PTGTF 0.5 ms
GTA 5.1 See [DIGITAL]. ms
GTB 5.1 See [DIGITAL]. ms
GTBF 15.3 See GTF in [DIGITAL]. ms
GTFB 20.4 See GTF in [DIGITAL]. ms

NFC Activity Specification Page 114


Revision History

C. Revision History
The following table outlines the revision history of NFC Activity Specification.

Table 31: Revision History

Document Revision and Status Change Notice Supersedes


Name Release Date
NFC Activity Version 1.0, Technical
Specification November 2010 Specification

NFC Activity Specification Page 115

You might also like