Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-340 — Near Field Communication Interface and Protocol 1 (NFCIP-1) (June 2024)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

communication ecma ecmainternational field interface near nfcip protocol

ecma, standard, ecma international, specification, ecma-340, ecma 340, 340, near, field, communication, interface, and, protocol, nfcip-1

ECMA-340 4th Edition / June 2024

Near Field Communication Interface and Protocol 1 (NFCIP-1)

Reference number ECMA-123:2009

Contents

Page

Scope ...................................................................................................................................................... 1

Normative references ............................................................................................................................ 1

Terms and definitions ........................................................................................................................... 2

Symbols and abbreviated terms .......................................................................................................... 3

5 5.1 5.2

Conventions and notations .................................................................................................................. 5 Representation of numbers .................................................................................................................. 5 Names ..................................................................................................................................................... 5

Conformance ......................................................................................................................................... 5

General ................................................................................................................................................... 5

8 8.1 8.2 8.3 8.4

RF field.................................................................................................................................................... 6 Values ..................................................................................................................................................... 6 Passive communication mode ............................................................................................................. 6 Active communication mode................................................................................................................ 6 External RF field detection ................................................................................................................... 6

9 9.1 9.2 9.3 9.3.1 9.3.2 9.3.3 9.4 9.4.1 9.4.2

RF signal interface ................................................................................................................................ 6 General ................................................................................................................................................... 6 Bit duration ............................................................................................................................................ 7 Active communication mode................................................................................................................ 7 General ................................................................................................................................................... 7 Requirements for fc/128 ........................................................................................................................ 7 Requirements for fc/64 and fc/32 .......................................................................................................... 8 Passive communication mode ............................................................................................................. 9 Requirements for fc/128 ........................................................................................................................ 9 Requirements for fc/64 and fc/32 .......................................................................................................... 9

General Protocol flow ......................................................................................................................... 10

11 11.1 11.2 11.2.1 11.2.2 11.2.3 11.3 11.3.1 11.3.2 11.4 11.4.1 11.4.2

Initialisation .......................................................................................................................................... 11 General ................................................................................................................................................. 11 RFCA ..................................................................................................................................................... 12 General ................................................................................................................................................. 12 Initial RFCA .......................................................................................................................................... 12 RFCA ..................................................................................................................................................... 12 Passive communication mode ........................................................................................................... 13 Initialisation and SDD for fc/128 ......................................................................................................... 13 Initialisation and SDD for fc/64 and fc/32 ........................................................................................... 14 Active communication mode.............................................................................................................. 17 Initialisation .......................................................................................................................................... 17 Active communication mode RFCA .................................................................................................. 17

12 12.1 12.2 12.3 12.4 12.5 12.6 12.6.1 12.6.2

Transport protocol .............................................................................................................................. 18 General ................................................................................................................................................. 18 Transport Data ..................................................................................................................................... 18 Passive communication mode Activation flow ................................................................................ 19 Active communication mode Activation flow ................................................................................... 19 Commands ........................................................................................................................................... 21 Activation of the protocol ................................................................................................................... 22 Attribute Request and Response Commands .................................................................................. 22 Wakeup Request and Response Commands ................................................................................... 29

12.6.3 12.7 12.7.1 12.7.2 12.7.3 12.7.4 12.7.5 12.7.6 12.8 12.8.1 12.8.2 12.8.3

Parameter Selection Request and Response Commands ............................................................. 30 Data Exchange Protocol .................................................................................................................... 33 Data Exchange Protocol Request and Response ........................................................................... 33 Response timeout extension ............................................................................................................. 38 Attention — Target present ............................................................................................................... 38 Protocol operation .............................................................................................................................. 39 Multi-Activation ................................................................................................................................... 39 More information (Chaining) .............................................................................................................. 39 Deactivation of the protocol .............................................................................................................. 40 General ................................................................................................................................................. 40 Deselect Request and Response command .................................................................................... 40 Release Request and Response commands ................................................................................... 42

Annex A (normative) CRC calculation ........................................................................................................... 45 A.1 CRC for active and passive communication mode at fc/128 .......................................................... 45 A.2 Example of CRC calculation at fc/128 ............................................................................................... 45 A.3 CRC for active and passive communication mode at fc/64 and fc/32 ............................................ 46 A.4 Example of CRC calculation at fc/64 and fc/32 ................................................................................. 46 Annex B (informative) SAK .............................................................................................................................. 47 Bibliography ..................................................................................................................................................... 49

Introduction This Standard specifies the interface and protocol for simple wireless communication between close coupled devices. These Near Field Communication (NFC) devices communicate with bit rates of 106, 212 and 424 kbit/s (fc/128, fc/64 and fc/32). This allows, but does not specify, applications in network products and consumer equipment. This 4th edition is fully aligned with the 3rd edition of ISO/IEC 18092:2023. The main changes include the adoption of near field communication (NFC) security standard for the Target, and the harmonization with the NFC Forum Digital Protocol Technical Specification[2] and Activity Technical Specification[3].

This Ecma Standard was developed by Technical Committee 51 and was adopted by the General Assembly of June 2024.

iii

COPYRIGHT NOTICE © 2024 Ecma International This document may be copied, published and distributed to others, and certain derivative works of it may be prepared, copied, published, and distributed, in whole or in part, provided that the above copyright notice and this Copyright License and Disclaimer are included on all such copies and derivative works. The only derivative works that are permissible under this Copyright License and Disclaimer are: (i)

works which incorporate all or portion of this document for the purpose of providing commentary or explanation (such as an annotated version of the document),

(ii) works which incorporate all or portion of this document for the purpose of incorporating features that provide accessibility, (iii) translations of this document into languages other than English and into different formats and (iv) works by making use of this specification in standard conformant products by implementing (e.g. by copy and paste wholly or partly) the functionality therein. However, the content of this document itself may not be modified in any way, including by removing the copyright notice or references to Ecma International, except as required to translate it into languages other than English or into a different format. The official version of an Ecma International document is the English language version on the Ecma International website. In the event of discrepancies between a translated version and the official version, the official version shall govern. The limited permissions granted above are perpetual and will not be revoked by Ecma International or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and ECMA INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Near Field Communication Interface and Protocol 1 (NFCIP-1)

Scope

This document defines: −

communication modes for Near Field Communication Interface and Protocol 1 (NFCIP-1) using inductive coupled devices operating at the centre frequency of 13,56 MHz for interconnection of computer peripherals;

−

both the active and the passive communication modes of NFCIP-1 to realize a communication network using Near Field Communication (NFC) devices for networked products and for consumer equipment;

−

a transport protocol including protocol activation and data exchange methods.

This document specifies: −

modulation schemes;

−

codings;

−

bit rates;

−

frame format of the radio frequency (RF) interface;

−

initialisation schemes and conditions required for data collision control during initialisation.

Information interchange between systems is based on agreement between the interchange parties upon the interchange codes and the data structure.

Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ISO/IEC 13157-1, Information technology — Telecommunications and information exchange between systems — NFC Security — Part 1: NFC-SEC NFCIP-1 security services and protocol ISO/IEC 14443-2:2020, Cards and security devices for personal identification — Contactless proximity objects — Part 2: Radio frequency power and signal interface ISO/IEC 14443-3:2018, Cards and security devices for personal identification — Contactless proximity objects — Part 3: Initialization and anticollision ITU-T V.41:1988, Code-independent error-control system

Terms and definitions

For the purposes of this document, the terms and definitions given in ISO/IEC 14443-2 and ISO/IEC 14443-3, and the following apply. ISO and IEC maintain terminology databases for use in standardization at the following addresses: — ISO Online browsing platform: available at https://www.iso.org/obp — IEC Electropedia: available at https://www.electropedia.org/ 3.1 active communication mode mode in which both the Initiator (3.5) and the Target (3.16) use their own radio frequency (RF) field to enable the communication 3.2 collision transmission by two or more Targets (3.16) or Initiators (3.5) during the same time period (3.17), such that the Initiator or the Target is unable to distinguish from which Target the data originated 3.3 frame sequence of data bits and optional error detection bits, with frame delimiters at start and end 3.4 HThreshold threshold value to detect an external radio frequency (RF) field 3.5 Initiator entity that generates the radio frequency (RF) field and starts the Near Field Communication Interface and Protocol (NFCIP-1) communication 3.6 load modulation process of amplitude modulating a radio frequency (RF) field by varying the properties of a resonant circuit placed within the RF field 3.7 lsb first least significant bit first least significant bit first, indicating a serial data transmission system that sends lsb before all other bits 3.8 Manchester bit encoding method of bit coding whereby a logic level during a bit duration is represented by a sequence of two defined physical states of a communication medium 3.9 modulation index signal amplitude ratio of the modulation to the level of the unmodulated carrier, calculated by: [1 − b] / [1 + b] where b is the ratio between the modulated amplitude and the initial signal amplitude

3.10 msb first most significant bit first serial data transmission system that sends the msb before all other bits 3.11 NFCIP-1 device entity supporting the active communication mode (3.1) and the passive communication mode (3.13) 3.12 NFC identifier NFCIDn (n = 1, 2 or 3) number used by the Single Device Detection (3.15) sequence for both the Active communication mode (3.1) and the Passive communication mode (3.13) 3.13 passive communication mode mode when the Initiator (3.5) is generating the radio frequency (RF) field and the Target (3.16) responds to an Initiator command in a load modulation scheme 3.14 RF Collision Avoidance RFCA method to detect the presence of a radio frequency (RF) field based on the carrier frequency 3.15 Single Device Detection SDD algorithm used by the Initiator (3.5) to detect one out of several Targets (3.16) in its radio frequency (RF) field 3.16 Target entity that responds to Initiator (3.5) command either using load modulation scheme (radio frequency (RF) field generated by Initiator) or using modulation of self-generated RF field 3.17 time period number of slots used for RF Collision Avoidance (3.14) 3.18 time slot method of preparing a time window when a Target (3.16) answers, and assigning and identifying two or more logic channels

Symbols and abbreviated terms

The abbreviated terms in ISO/IEC 14443-2 and ISO/IEC 14443-3, and the following apply. ATR

Attribute

ATR_REQ

Attribute Request

ATR_RES

Attribute Response

BRi

receiving bit duration supported by Initiator

BRt

receiving bit duration supported by Target

BSi

sending bit duration supported by Initiator

BSt

sending bit duration supported by Target

CMD

command

CRC

cyclic redundancy check

divisor

DEP

Data Exchange Protocol

DEP_REQ

Data Exchange Protocol Request

DEP_RES

Data Exchange Protocol Response

DIDi

Initiator Device ID

DIDt

Target Device ID

DRi

Data rate Received by Initiator

DRt

Data rate Received by Target

DSi

Data rate Sent by Initiator

DSL

Deselect

DSL_REQ

Deselect Request

DSL_RES

Deselect Response

DSt

Data rate Send by Target

etu

elementary time unit

frequency of operating field (carrier frequency)

G(x)

generator polynomial for CRC generation

optional information field for Initiator

optional information field for Target

HLTA

HaLT command, Type A

Hmax

maximum field strength of the Initiator antenna field

Hmin

minimum field strength of the Initiator antenna field

HThreshold

threshold value to detect an external radio frequency (RF) field

identification number

LENMAX

maximum frame size

LRi

length reduction of Initiator

LRt

length reduction of Target

lsb

least significant bit

lsb first

least significant bit first

Multiple Information link for Data Exchange Protocol

msb

most significant bit

NAD

Node Address

NFCID1

UID for SDD in Passive communication mode at fc/128

NFCID2

ID for SDD in Passive communication mode at fc/64 and fc/32

NFCID3

random ID for transport protocol activation

NFC-SEC

NFCIP-1 Security Services and Protocol (specified in ISO/IEC 13157-1)

preamble

PCD

Proximity Coupling Device

pdu

protocol data unit

PFB

control information for transaction

PICC

proximity card or object

PNI

Packet Number Information

PPi

Protocol Parameters used by Initiator

PPt

Protocol Parameters used by Target

PSL

Parameter Selection

PSL_REQ

Parameter Selection Request

PSL_RES

Parameter Selection Response

Radio Frequency

RFCA

RF Collision Avoidance

RFU

Reserved for Future Use

RLS

Release

RLS_REQ

Release Request

RLS_RES

Release Response

tRW

Response Waiting Time

SAK

Select AcKnowledge

Start Byte for data exchange protocol at fc/128

SDD

Single Device Detection (anticollision)

SYNC

synchronisation pattern

Time Out

UID

Unique Identifier

Waiting Time

WUP

Wakeup

WUPA

Wake UP command, Type A

WUP_REQ

Wakeup Request

WUP_RES

Wakeup Response

Conventions and notations

5.1

Representation of numbers

The following conventions and notations apply in this document unless otherwise stated: −

Letters and digits in single quotation marks represent numbers in hexadecimal notation.

−

The setting of bits is denoted by ZERO or ONE.

−

Numbers in binary notation and bit patterns are represented by strings of digits 0 and 1 shown with the most significant bit to the left. Within such strings, X may be used to indicate that the setting of a bit is not specified within the string, e.g. (XXXX)b.

5.2

Names

The names of basic elements, e.g. specific fields, are written with a capital initial letter.

Conformance

A system implementing the active and the passive communication mode shall be in conformance with this document if it meets all the mandatory requirements specified herein.

General

NFCIP-1 Targets and Initiators shall implement both the active and the passive communication modes. In the active communication mode, both the Initiator and the Target use their own RF field to communicate. The Initiator starts the NFCIP-1 transaction, which consists of initialisation, protocol activation, data exchange and optional device deactivation. The Target responds to an Initiator command in the active communication mode by modulating its own RF field. In the passive communication mode, the Initiator generates the RF field and starts the transaction. The Target responds to an Initiator command in the passive communication mode by modulating the Initiators’ RF field, which is referred to as load modulation.

This document specifies requirements for modulation, bit rates and bit coding. In addition, it specifies requirements for the start of communication, the end of communication, the bit and byte representation, the framing and error detection, the single device detection (SDD), the protocol activation and parameter selection and the data exchange and deactivation of NFCIP-1 devices. Initiators and Targets exchange commands, responses and data in alternating or half duplex communication. NFCIP-1 devices are capable to start transactions at bit rates of fc/128, fc/64 and fc/32. Initiators select one of those bit rates to start a transaction and they may change the bit rate using the parameter selection during a transaction. The mode (active or passive) shall not be changed during a transaction.

RF field

8.1

Values

fc is 13,56 MHz. Hmin is 1,5 A/m (rms). Hmax is 7,5 A/m (rms). HThreshold is 0,187 5 A/m (rms).

8.2

Passive communication mode

The Initiator shall generate field strength of at least Hmin and not exceeding Hmin at manufacturer specified positions (i.e. operating volume) under un-modulated conditions. The Target shall operate continuously between Hmin and Hmax.

8.3

Active communication mode

An Initiator and a Target shall alternately generate an RF field of at least Hmin and not exceeding Hmax at manufacturer specified positions (i.e. operating volume) under un-modulated conditions.

8.4

External RF field detection

NFCIP-1 devices shall detect external RF fields at fc with field strength higher than HThreshold.

RF signal interface

9.1

General

This clause specifies bit duration and RF signal interface requirements for active and passive communication modes. NOTE and [3].

Active and passive communication modes have also been adopted by NFC Forum, as shown in Reference [2]

9.2

Bit duration

One etu equals 128/(D × fc), where the values of the divisor D depend on the bit rate and communication mode, see Table 1. Table 1 — Divisor D Communication mode

bit rate

Divisor D

Active or Passive

fc/128 (~106 kbit/s)

Active or Passive

fc/64 (~212 kbit/s)

Active or Passive

fc/32 (~424 kbit/s)

Active

fc/16 (~848 kbit/s)

Active

fc/8 (~1 695 kbit/s)

Active

fc/4 (~3 390 kbit/s)

Active

fc/2 (~6 780 kbit/s)

NOTE 1 The Initiator selects the communication mode (either Active or Passive) and bit rate (fc/128, fc/64 or fc/32 specified by the following clauses). NOTE 2

9.3 9.3.1

This document does not specify the modulation and the bit coding beyond the bit rate of fc/32.

Active communication mode General

Targets and Initiators shall conform with the following specifications for both communication directions, i.e. Initiator to Target and Target to Initiator. 9.3.2 9.3.2.1

Requirements for fc/128 Bit rate

The bit rate for the transmission during initialisation and SDD shall be fc/128. 9.3.2.2

Modulation

The modulation shall be in accordance with ISO/IEC 14443-2:2020, 8.1.2 for a bit rate of fc/128. During transmission, both the Initiator and the Target shall conform to PCD values. During reception, both the Initiator and the Target shall conform to PICC values. 9.3.2.3

Bit representation and coding

The bit representation and coding shall be in accordance with ISO/IEC 14443-2:2020, 8.1.3 for a bit rate of fc/128. 9.3.2.4

Byte transmission

Initiators and targets shall transmit bytes with the lsb first.

9.3.3 9.3.3.1

Requirements for fc/64 and fc/32 Bit rates

The bit rates for the transmission during initialisation and SDD shall respectively be fc/64 or fc/32. 9.3.3.2

Modulation

The modulation shall be in accordance with ISO/IEC 14443-2:2020, 9.1.2 for the bit rate of fc/64 and fc/32. During transmission, both the Initiator and the Target shall apply the PCD values. During reception, both the Initiator and the Target shall apply the PICC values. The Target should accept a modulation index range from 8 % to 30 % to operate with Initiators using a modulation index higher than 14 % for backward compatibility. 9.3.3.3

Bit representation and coding

Manchester bit encoding shall be employed as illustrated in Figure 1 and Figure 2. Bit coding format is Manchester with logic levels defined as: −

Logic “ZERO”: The first half of the bit duration is carrier low field amplitude, and the second half of the bit duration shall be carrier high field amplitude (no modulation applied).

−

Logic “ONE”: The first half of the bit duration is carrier high field amplitude (no modulation applied), and the second half of the bit duration shall be carrier low field amplitude.

Reverse polarity in amplitude shall be permitted. Polarity shall be detected from the SYNC.

Figure 1 — Manchester bit encoding (obverse amplitude)

Figure 2 — Manchester bit encoding (reverse amplitude) 9.3.3.4

Byte transmission

Initiators and Targets shall transmit bytes with the msb first.

9.4

Passive communication mode

9.4.1

Requirements for fc/128

9.4.1.1

Initiator to Target requirements

See 9.3.2. 9.4.1.2

Target to Initiator requirements

9.4.1.2.1

Bit rate

See 9.3.2.1. 9.4.1.2.2

Modulation

The modulation shall be in accordance with ISO/IEC 14443-2:2020, 8.2.2. 9.4.1.2.3

Subcarrier Frequency

The subcarrier frequency shall be in accordance with ISO/IEC 14443-2:2020, 8.2.3 for a bit rate of fc/128. 9.4.1.2.4

Subcarrier modulation

The subcarrier modulation shall be in accordance with ISO/IEC 14443-2:2020, 8.2.4 for a bit rate of fc/128. 9.4.1.2.5

Bit representation and coding

The bit representation and coding shall be in accordance with ISO/IEC 14443-2:2020, 8.2.6 for a bit rate of fc/128. 9.4.1.2.6

Byte transmission

Initiators and Targets shall transmit bytes with the lsb first. 9.4.2

Requirements for fc/64 and fc/32

9.4.2.1 9.4.2.1.1

Initiator to Target requirements Bit rate

See 9.3.3.1. 9.4.2.1.2

Modulation

The modulation shall be in accordance with ISO/IEC 14443-2:2020, 9.1.2 for the bit rate of fc/64 and fc/32. During transmission, the Initiator shall apply the PCD values. 9.4.2.1.3

Bit representation and coding

See 9.3.3.3. 9.4.2.1.4

Byte transmission

See 9.3.3.4.

9.4.2.2 9.4.2.2.1

Target to Initiator requirements Bit rate

See 9.3.3.1. 9.4.2.2.2

Modulation

The Target shall be capable of communication to the Initiator via an inductive coupling area by using load modulation applied at fc of the Initiator’s RF field with the PICC load modulation amplitude value specified in ISO/IEC 14443-2:2020, 8.2.2. The Initiator shall be able to receive a signal with load modulation amplitude as specified for the PCD reception in ISO/IEC 14443-2:2020, 8.2.5. 9.4.2.2.3

Bit representation and coding

See 9.3.3.3. 9.4.2.2.4

Byte transmission

See 9.3.3.4.

General Protocol flow

The General Protocol flow between NFCIP-1 devices shall be conducted through the following consecutive operations: −

Any NFCIP-1 device shall be in Target mode initially and not generate an RF field and shall wait for a command from an Initiator.

−

The NFCIP-1 device may switch to Initiator mode and select either active or passive communication mode and bit rate.

−

Initiators shall test for external RF field presence and shall not activate their RF field if an external RF field is detected. See 8.4.

−

If an external RF field is not detected, the Initiator shall activate its own RF field for the activation of Target.

−

Exchange commands and responses in the same communication mode and the bit rate.

Figure 3 shows the general initialisation and SDD flow for the active and the passive communication mode at different bit rates. The General Protocol flow describes the flow to initialise and select the Targets either in the Passive communication mode or in the active communication mode using one of the bit rates. RFCA is described in 11.2. The passive communication mode is described in 11.3. The initialisation and SDD for the bit rate of fc/128 is described in 11.3.1, initialisation and SDD for bit rates of fc/64 and fc/32 is described in 11.3.2. The active communication mode is described in 11.3. The Activation of the Protocol is described in 12.5. The Parameter Selection is described in 12.6.3. The Data Exchange Protocol is described in 12.6. The Deactivation is described in 12.7.

Initialisation

11.1

General

This clause describes the initialisation and collision detection protocol for Targets in the active and the passive communication mode. The Initiator shall detect a collision that occurs when at least two Targets simultaneously transmit bit patterns with one or more bit positions where they transmit complementary values. Figure 3 shows the general initialisation and SDD flow for the active and the passive communication mode at different bit rates.

Figure 3 — General initialisation and SDD flow

11.2 11.2.1

RFCA General

In order not to disturb any other NFC communication and any current infrastructure running on the carrier frequency, an Initiator for NFC communication shall not generate its own RF field as long as another RF field is detected. 11.2.2

Initial RFCA

To start communication with the Target device either in the active or the passive communication mode an Initiator shall sense continuously for the presence of an external RF field. See 8.4. If the Initiator detects no RF field within the timeframe tIDT + n × tRFW then the Initiator shall switch its RF field on, otherwise it shall restart Initial RFCA. The integer value of n shall be randomly generated. Figure 4 specifies the timing of the initial RFCA during initialisation.

Key tIDT

initial delay time

tIDT > 4 096 / fc

tRFW

RF waiting time

512 / fc

randomly generated number of time periods for tRFW 0≤n≤3

tIRFG

initial guard-time between switching on RF field and start to send command or data frame tIRFG > 5 ms

Figure 4 — Initial RFCA The RF field, which is generated by the Initiator, shall be switched off in the active communication mode. The RF field, which is generated by the Initiator, shall not be switched off in the passive communication mode. 11.2.3

RFCA

To avoid collision by simultaneous responding of more than one Target in the active communication mode during activation, Targets shall perform response RFCA as specified in Figure 5.

Key tADT

active delay time, sense time between RF off Initiator/Target and Target/Initiator (768/fc ≤ tADT ≤ 2 559/fc)

tRFW

RF waiting time. (512/fc)

randomly generated number of time periods for tRFW (0 ≤ n ≤ 3)

tARFG

active guard time between switching on RF field and start to send command (tARFG > 1 024/fc)

Figure 5 — Response RFCA sequence during activation

11.3

Passive communication mode

11.3.1

Initialisation and SDD for fc/128

Initialisation and SDD for fc/128 shall conform to ISO/IEC 14443-3:2018, Clause 6 with the coding of SAK as specified in Table 2. Table 2 — Coding of SAK bit 8

bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

Meaning

UID not complete, see ISO/IEC 14443-3:2018, Table 9.

UID complete, see ISO/IEC 14443-3:2018, Table 9.

UID complete, Target compliant with the transport protocol specified in Clause 12. Attribute Request is supported.

UID complete, Target not compliant with the transport protocol specified in Clause 12. Attribute Request is not supported.

The uid0 shall be set to ‘08’. If bit 3 is (1)b the Initiator shall ignore any other bit of SAK. If bit 3 is (0)b the Initiator shall interpret bit 7 and ignore the other bits. When bit 3 is set to (1)b then the Target should set all other bits of SAK to (0)b. See Annex B for combination of SAK use in the ISO/IEC 14443 series and this document. NOTE

If bit 6 is (1)b in SAK then device supports protocol as defined in ISO/IEC 14443-4.

11.3.2

Initialisation and SDD for fc/64 and fc/32

11.3.2.1

Start and end of communication

The start of the Passive communication shall be signalled by the presence of the carrier frequency. The communication shall start with the preamble sequence of at least 48 bits of Manchester encoded ZERO. The end of communication shall be forecasted from the Length field of the frame. After one NFCIP-1 device has finished communication, the other shall delay for a period of at least 8 × 64/fc before starting transmission by sending the preamble sequence as shown in Figure 6.

Figure 6 — Delay between consecutive frames 11.3.2.2

Frame format

The frame format shall consist of Preamble, SYNC, Length, Payload, and CRC, see Figure 7. The Preamble shall be 48 bits minimum all logical ZEROs. The SYNC shall be 2 bytes. The 1st byte of the SYNC shall be ‘B2’ and the 2nd byte shall be ‘4D’.

Figure 7 — Frame format The Length shall be an 8-bit field and it shall be set to the number of bytes to be transmitted in Payload plus 1. The range of the Length shall be 1 to 255, and other settings are RFU. NOTE 1

The minimum value for the Length was 2 in the last edition of this document.

NOTE 2

The range of the Length is harmonized with the NFC Forum Digital Protocol Technical Specification [2].

The Payload shall consist of n 8-bit-bytes of data where n is indicated by the number of data bytes. The CRC shall be calculated according to A.3. 11.3.2.3

SDD for fc/64 and fc/32

The basic technique of the SDD procedure shall be the time slot method. The number of the slot shall be the integer value beyond zero. The Initiator shall send Polling Requests. The Target shall respond in a time slot randomly chosen from the range specified by the Initiator. The Initiator shall be able to read NFCID2 data (see 11.3.2.4) of Target(s) in different time slots. After obtaining NFCID2 data from Target(s) in the operating field, the Initiator may communicate with multiple Targets.

Up to 16 time slots may be supported by agreement between the interchange parties. The number of time slot may be indicated by the value TSN in the Polling Request Frame from the Initiator. A Target, which is already powered up, responds to the Initiator according to the following rules after receiving the Polling Request Frame from the Initiator. −

The Target shall generate a random number R in the range 0 to TSN.

−

The Target shall wait until the time slot is matched to R, then send the Polling Response Frame and wait for the next Request. The Target may ignore a Polling Request to reduce instances of collision of Responses.

The communication between the Initiator and the Target shall be initiated as follows: −

The Target gets power from the operating field generated by the Initiator.

−

The Target shall become ready for receiving a Polling Request from the Initiator in maximum 2 sec from power up.

−

The Target shall wait for a Polling Request sent from the Initiator. The Initiator may send a Polling Request without waiting for the Target to become ready.

−

If the Initiator fails to receive Polling Response, then the Initiator may send Polling Request again. The Initiator of the Passive communication mode shall keep RF power on while executing the SDD procedure.

The delay td between the end of the Request Frame and the first time slot shall be 512 × 64/fc. The time slot unit ts shall be 256 × 64/fc. Figure 8 illustrates an example situation of the SDD by time slot. In this example, 5 Targets are responding. The Initiator may be able to get the Response information of the Target 2, 4, and 5 excluding 1 and 3. Because a collision has occurred at the time slot 1. The Initiator may repeat the SDD procedure.

Figure 8 — SDD by time slot 11.3.2.4

NFCID2 contents

NFCID2 shall be an 8-byte number for identifying NFCIP-1 devices. The 2-byte prefix code shall be followed by a 6-byte number in the NFCID2. The prefix code shall define the characteristics for the 6‑byte number. The prefix code and 6-byte number shall be used as specified in Table 3.

Table 3 — NFCID2 contents Prefix code

6-byte number

Meaning

‘01’ ‘FE’

Random number, dynamically generated by the Target

Indicates Target is compliant with the transport protocol specified in Clause 12 and Attribute Request is supported.

‘02’ ‘FE’

Fixed number, non-unique

Indicates Target is not compliant with the transport protocol specified in Clause 12 and Attribute Request is not supported.

Other values

n/a

NOTE

11.3.2.5

RFU

The prefix code of ‘02’ ‘FE’ is harmonized with the NFC Forum Digital Protocol Technical Specification [2].

Polling Request Frame format

To find Targets, an Initiator shall send a Polling Request frame, see Figure 9.

Figure 9 — Polling Request Frame format The Preamble, SYNC, Length and CRC shall be in accordance with 11.3.2.2. The Length shall be set to ‘06’, which is calculated as specified in 11.3.2.2. The 1st byte of the Payload shall be set to ‘00’. The 2nd byte and the 3rd of Payload shall be set to ‘FF’ and other settings are RFU. The 4th byte of Payload shall be set to ‘00’, and other settings are RFU. The TSN shall be ‘00’, ‘01’, ‘03’, ‘07’, or ‘0F’. Any other settings are RFU. Figure 8 illustrates an example where the TSN is ‘03’. If the TSN is set to ‘00’ then only the time slot 0 shall be used. 11.3.2.6

Polling Response Frame format

Target shall send the following frame as the Polling Response toward the Polling Request, see Figure 10.

Figure 10 — Polling Response Frame format The Preamble, SYNC, Length and CRC shall be in accordance with 11.3.2.2. The Length field shall be set ‘12’, which is calculated as specified in 11.3.2.2. The start byte of the Payload shall be set to ‘01’. The Payload shall contain 8-byte of NFCID2 and 8‑byte of Pad. The Pad shall be ignored for data interchange.

11.4 11.4.1

Active communication mode Initialisation

The application switches to Initiator for the active communication mode and may select a bit rate; fc/128, fc/64 or fc/32. 11.4.2

Active communication mode RFCA

The RFCA shall be executed according to the timing chart in Figure 11. −

The Initiator shall perform the initial RFCA.

−

The first command sent by the Initiator shall be an ATR_REQ in the active communication mode at a selected bit rate.

−

The Initiator shall switch off the RF field and respect tRF_OFF after any command is sent in active communication mode.

−

The Target performs the response RFCA.

−

The Target sends the ATR_RES as a response to the ATR_REQ in the same bit rate as it has received the ATR_REQ and switch of the RF field respecting tRF_OFF after any command is sent in active communication mode.

−

The Initiator performs the response RFCA with n = 0.

−

The Initiator sends the PSL_REQ in order to change parameter or sends the DEP_REQ to start the data exchange protocol.

Figure 11 — Initialisation flow for active communication mode tRF_OFF is the time between the start of the rising edge of the last modulation and the start of falling edge when the device turns off the RF field and should be in the range of −

350/fc < tRF_OFF ≤ 2 559/fc for a bit rate of fc/128, and

−

215/fc < tRF_OFF ≤ 2 559/fc for a bit rate of fc/64 or fc/32.

In case where two Targets or more are in the field, the one with the lowest n will answer first and the other will not answer. In case of two or more Targets answering in exactly the same time period, the Initiator will detect a collision and it will re-send the ATR_REQ, which is described in 12.6.1.1. After the first valid Target response is detected by the Initiator, the Initiator shall use n = 0 for further communication. After the Target has received a request other than ATR_REQ, the Target shall use n = 0 for further communication.

Transport protocol

12.1

General

The transport protocol is handled in three parts: −

activation of the protocol, which includes the Request for Attributes and the Parameter Selection;

−

the data exchange protocol;

−

the deactivation of the protocol including the Deselect and the Release.

12.2

Transport Data

User data shall be transported in the Transport Data field in the Frame format. Figure 12 specifies the position of the Transport Data field in each Frame format. The structure for the Frame format for fc/128 shall conform to ISO/IEC 14443-3:2018, 6.2.3.2. The start byte SB shall be set to ‘F0’. The LEN byte shall be set to the length of the Transport Data field plus 1. The range of the LEN shall be in the range of 3 to 255. The E1 is the CRC for the Frame format of fc/128 as described in A.1. Other settings of LEN shall not be used. Subclause 11.3.2.2 specifies the frame format for fc/64 and fc/32 including the Preamble PA and the Synchronous pattern bytes SYNC. The LEN byte shall be set to the length of the Transport Data field plus 1. The value of LEN shall be in the range of 3 to 255. The E2 is the CRC for the Frame format of fc/64 and fc/32 as described in A.3. Other settings of LEN shall not be used. The Transport data field contains the mandatory command bytes CMD1 and CMD2 as described in 12.4 and the data bytes Byte 1 to Byte n. The content of Byte 1 to Byte n depends on the command byte CMD2 and may contain information. In that case they are mandatory. Data bytes are optional.

Figure 12 — Transport Data Frame format

12.3

Passive communication mode Activation flow

The following activation sequence shall be applied: a) The Initiator shall perform the initial RFCA sequence as defined in 11.2.2. b) The Initiator shall perform the Initialisation and SDD for the Passive communication mode at a selected bit rate as defined in 11.2. c) The support of the NFCIP-1 protocol shall be checked at the different bit rates according to the result of the SDD. d) The Target may fall back to the Initialisation and SDD if no ATR_REQ is supported. e) The ATR_REQ may be sent by the Initiator as a next command if the Target indicates that the Attribute Request is supported. f)

The Target shall send its ATR_RES as answer to the ATR_REQ. The Target shall only answer to the ATR_REQ if the ATR_REQ is received directly after selection.

g) If the Target supports any changeable parameter in the ATR_REQ, a PSL_REQ may be used by the Initiator as the next command after receiving the ATR_REQ to change parameters. h) The Target shall send a PSL_RES as answer to the PSL_REQ. i)

A Target does not need to complement the Parameter Selection, if it does not support any changeable parameters in the ATR_RES.

The transparent data shall be sent using the data exchange transport protocol.

The Initiator activation sequence for a Target in the Passive communication mode is shown in Figure 13.

12.4

Active communication mode Activation flow

The following activation sequence for the protocol in the active communication mode shall be applied: a) The Initiator shall perform the initial RFCA sequence as defined in 11.2.2. b) The Initiator shall switch to the active communication mode and select the bit rate. c) The Initiator shall send the ATR_REQ. d) The Target shall send its ATR_RES in response to the ATR_REQ. After a successful response the device is selected. e) If the Initiator detects a collision of data the ATR_REQ shall be re-sent. f)

It the Target supports any changeable parameter in the ATR_RES, a PSL_REQ may be used by the Initiator as the next command after receiving the ATR_RES to change parameters.

g) The Target shall send a PSL_RES in response to the PSL_REQ. h) A Target does not need to complement the Parameter Selection, if it does not support any changeable parameters in the ATR_RES. The Initiator activation sequence for a Target in the active communication mode is shown in Figure 14.

Figure 13 — Activation Protocol in Passive communication mode

Figure 14 — Activation Protocol in Active communication mode

12.5

Commands

The Command bytes consist of CMD1 and CMD2 as specified in Table 4.

Table 4 — NFCIP-1 Protocol Command Set Mnemonic

Command bytes

Definition

CMD1

CMD2

ATR_REQ

‘D4’

‘00’

Attribute Request (sent by Initiator)

ATR_RES

‘D5’

‘01’

Attribute Response (sent by Target)

WUP_REQ

‘D4’

‘02’

Wakeup Request (sent by Initiator in active communication mode only)

WUP_RES

‘D5’

‘03’

Wakeup Response (sent by Target in active communication mode only)

PSL_REQ

‘D4’

‘04’

Parameter Selection Request (sent by Initiator)

PSL_RES

‘D5’

‘05’

Parameter Selection Response (sent by Target)

DEP_REQ

‘D4’

‘06’

Data Exchange Protocol Request (sent by Initiator)

DEP_RES

‘D5’

‘07’

Data Exchange Protocol Response (sent by Target)

DSL_REQ

‘D4’

‘08’

Deselect Request (sent by Initiator)

DSL_RES

‘D5’

‘09’

Deselect Response (sent by Target)

RLS_REQ

‘D4’

‘0A’

Release Request (sent by Initiator)

RLS_RES

‘D5’

‘0B’

Release Response (sent by Target)

12.6

Activation of the protocol

12.6.1

Attribute Request and Response Commands

12.6.1.1

Attribute Request (ATR_REQ)

This clause defines the Attribute Request ATR_REQ with all its parameter bytes, see Figure 15. The Initiator shall send the ATR_REQ to the selected Target.

Figure 15 — Structure of the ATR_REQ 12.6.1.1.1

Definition of the ATR_REQ bytes

CMD 1: Shall be set to ‘D4’. CMD 2: ATR_REQ The ATR_REQ byte shall specify the Attribute Request for the Initiator. The value of ATR_REQ shall be set to ‘00’. Byte 1 to Byte 10: NFCID3i The 10 nfcid3i bytes define the random identifier NFCID3i of the Initiator. NFCID3 shall be an ID dynamically generated by the application and be fixed during one communication. For Passive communication mode fc/64 and fc/32, the NFCID3i shall be replaced by NFCID2t.

Byte 11: DIDi The DID byte shall be used for multiple data transport protocol activation with more than one Target. The range of the DIDi shall be defined between 1 and 14. The value ZERO shall be used if no DIDi is used during the data transport protocol. All other values shall not be used. Byte 12: BSi The Initiator device shall specify its supported send-bit rates (D) in the BSi byte, see Figure 16.

Figure 16 — Coding of the BSi byte The coding of bits is as follows: −

bit 8 to bit 5: shall be set to ZERO, all other values are RFU;

−

bit 4: if DSi4 = ONE then D = 64 is supported;

−

bit 3: if DSi3 = ONE then D = 32 is supported;

−

bit 2: if DSi2 = ONE then D = 16 is supported;

−

bit 1: if DSi1 = ONE then D = 8 is supported.

Byte 13: BRi The Initiator device shall specify its supported bit rates (see Table 1) in the BRi byte, see Figure 17. The coding of bits is as follows:

Figure 17 — Coding of the BRi byte −

bit 8 to bit 5: shall be set to ZERO, all other values are RFU;

−

bit 4: if DRi4 = ONE then D = 64 is supported;

−

bit 3: if DRi3 = ONE then D = 32 is supported;

−

bit 2: if DRi2 = ONE then D = 16 is supported;

−

bit 1: if DRi1 = ONE then D = 8 is supported.

Byte14: PPi The PPi byte specifies optional parameters used by Initiator device, see Figure 18. The coding of bits shall be as follows:

Figure 18 — Coding of the PPi byte −

bit 8: SECi. If set to ONE the Initiator supports NFC-SEC; ZERO indicates no support.

−

bit 7: RFU. The Initiator shall set it to ZERO. The Target shall ignore it.

−

bit 6 and bit 5: LRi. Length Reduction value, see Table 5. Table 5 — Definition of LRi LRi

LENMAX

Only Byte 1 to Byte 64 is valid in the Transport Data

Only Byte 1 to Byte 128 is valid in the Transport Data

Only Byte 1 to Byte 192 is valid in the Transport Data

Only Byte 1 to Byte 252 is valid in the Transport Data

−

bit 4 and bit 3: RFU. The Initiator shall set it to ZERO. The Target shall ignore it.

−

bit 2: If bit is set to ONE then it indicates General bytes are available.

−

bit 1: If bit is set to ONE then it indicates the Initiator uses NAD.

Byte 15 to Byte n: Gi[1] to Gi[n] The general bytes shall be optional and designate general information. The maximum length of the ATR_REQ subtracted by the mandatory bytes give the maximum number of general bytes. 12.6.1.2

Attribute Response (ATR_RES)

The ATR_RES, see Figure 19 shall be the response to the ATR_REQ and shall be sent by the selected NFCIP1 Target device.

Figure 19 — Structures of the ATR_RES 12.6.1.2.1

Definition of the ATR_RES bytes

CMD 1: Shall be set to ‘D5’. CMD 2: ATR_RES The ATR_RES byte shall specify the Target’s Response to the ATR_REQ send by the Initiator. The value of CMD1 for ATR_RES shall be set to ‘01’.

Byte 1 to Byte 10: NFCID3t The 10 nfcid3t bytes define the random identifier NCID3t of the Target. NFCID3 should be an ID generated by the application. The content of NFCID3 may be the same as UID or NFCID2. Byte 11: DIDt The DID byte shall be used for multiple data transport protocol activation with more than one Target. The DIDt shall have the same value as the DIDi. All other values shall not be used. For usage of DIDt, see 12.7.5. Byte 12: BSt The BSt byte shall specify the supported bit rates of the Target device, see Figure 20. The coding of bits is defined as follows:

Figure 20 — Coding of the BSt byte −

bit 8 to bit 5: Shall be set to ZERO.

−

bit 4: if DSt4 = ONE then D = 64 is supported.

−

bit 3: if DSt3 = ONE then D = 32 is supported.

−

bit 2: if DSt2 = ONE then D = 16 is supported.

−

bit 1: if DSt1 = ONE then D = 8 is supported.

Byte 13: BRt The BRt byte shall specify the supported receive bit rates of the Target device, see Figure 21. The coding of bits is defined as follows:

Figure 21 — Coding of the BRt byte −

bit 8 to bit 5: Shall be set to ZERO.

−

bit 4: if DRt4 = ONE then D = 64 is supported.

−

bit 3: if DRt3 = ONE then D = 32 is supported.

−

bit 2: if DRt2 = ONE then D = 16 is supported.

−

bit 1: if DRt1 = ONE then D = 8 is supported.

Byte 14: TO The TO byte shall specify the timeout value of the Target NFCIP-1 device for the data transport protocol, see Figure 22. The timeout calculation for fc/128 shall start with the start of the rising edge of the last modulation sent by the Initiator and stop with the start of the modulation edge of the first modulation sent by the Target. The timeout calculation for fc/64 and fc/32 shall start with the end of the last bit of a frame sent by the Initiator and stop with the start of the first bit of the Length field in a frame sent by the Target. NOTE

The definition of timeout calculation is harmonized with the NFC-DEP Protocol defined by NFC Forum.

The timeout is specified as follows:

Figure 22 — Coding of the TO byte −

bit 8 to bit 5: Shall be set to all ZEROs.

−

bit 4 to bit 1: WT: Waiting Time.

The Response Waiting Time (tRW) shall be calculated by the following formula: tRW = (256 × 16 / fc) × 2WT where the value of WT

shall be range from 0 to 14;

the value of 15

is RFU;

The default value of WT shall be 14; for WT = 0

tRW = tRW,MIN (302 µs);

for WT = 14

tRW = tRW,MAX (4 949 ms).

Byte 15: PPt The PPt byte specifies optional parameters used by Target device, see Figure 23. The coding of bits shall be as follows:

Figure 23 — Coding of the PPt byte

−

bit 8: SECt. If set to ONE, the Target supports NFC-SEC; ZERO indicates no support.

−

bit 7: Shall be set to ZERO.

−

bit 6 and bit 5: LRt. Length Reduction value, see Table 6. Table 6 — Definition of LRt LRt

LENMAX

Only Byte 1 to Byte 64 is valid in the Transport Data

Only Byte 1 to Byte 128 is valid in the Transport Data

Only Byte 1 to Byte 192 is valid in the Transport Data

Only Byte 1 to Byte 252 is valid in the Transport Data

−

bit 4 and bit 3: Shall be set to ZERO.

−

bit 2: If bit is set to ONE then it indicates General bytes available.

−

bit 1: If bit is set to ONE then it indicates the Target uses NAD.

Byte 15 to Byte n: Gt[1] to Gt[n] The Gt bytes shall be optional and designate general information. The maximum length of the ATR_RES subtracted by the mandatory bytes gives the maximum number of general bytes. 12.6.1.3 12.6.1.3.1

Handling of ATR_REQ and ATR_RES Initiator rules

When the Initiator has sent the ATR_REQ and receives a valid ATR_RES the Initiator shall continue with operation. In any other case the Initiator shall retransmit the ATR_REQ before using the deactivation sequence as defined in 12.7. In case of failure of the deactivation sequence it may use the HLTA command only for Passive communication mode at fc/128. The HLTA command is specified in ISO/IEC 14443-3:2018, 6.4.3. 12.6.1.3.2

Target rules

When the Target has been selected by the last command (for passive communication mode only) and a)

Receives a valid ATR_REQ, the Target ⎯ shall send its ATR_RES, and ⎯ shall disable to receive a subsequent ATR_REQ.

Receives any other valid or invalid frame, except a HLTA command (see 12.6.1.3.1) only for Passive communication mode at fc/128, the Target ⎯ ignores the block, and ⎯ remains in receive mode.

12.6.1.4 12.6.1.4.1

Handling of timeout (TO) General

Defined by the initially chosen mode, the communication is either active or passive. The handling of the timeout is different for active and passive communication modes. 12.6.1.4.2

Handling in active communication mode

In active communication mode the communication flow is handled by switching the carrier frequency. Initiator: The Initiator shall ignore a Target that exceeded tRW calculated using TO byte in ATR_REQ from a Target device and continue operation. Target: The Target shall use a TO value that allows common communication and shall use a Supervisory pdu indicating Timeout extension to extend the defined tRW. See 12.7.1.1.1. 12.6.1.4.3

Handling of timeout in passive communication mode

In passive communication mode the communication is only handled by communication flow. The carrier frequency is not switched. Initiator: The Initiator shall first use error handling and if no response is received ignores a Target device, that has exceeded the specified timeout and continue communication. Target: The Target shall use a TO value that allows common communication and shall use a Supervisory pdu indicating Timeout extension to extend the defined tRW. See 12.7.1.1.1. 12.6.1.5 12.6.1.5.1

Handling of DID Handling of DID in active and in passive communication mode

When the Initiator has sent an ATR_REQ containing a DID equal to ZERO and a)

received an ATR_ RES containing DID equal to ZERO, the Initiator ⎯ shall send pdus containing no DID to the Target, and ⎯ shall not activate any other Target while this Target is not deactivated.

received an ATR_RES containing DID not equal to ZERO, the Initiator ⎯ shall continue with error handling.

When the Initiator has sent an ATR_REQ containing a DID not equal to ZERO and a)

received an ATR_RES containing the same DID, the Initiator ⎯ shall send pdus containing the DID to the Target, ⎯ shall not use the DID for any other Targets, and ⎯ shall not use DID=0 for any other Targets.

received an ATR_RES containing any other DID, the Initiator ⎯ shall continue with error handling.

12.6.2

Wakeup Request and Response Commands

12.6.2.1 −

General

The Wakeup Request and Response commands are only defined for the active communication mode.

12.6.2.2 12.6.2.2.1

Wakeup Request (WUP_REQ) General

Figure 24 specifies the Wakeup Request for Attributes WUP_REQ with its parameter bytes. The Initiator sends the WUP_REQ to the Target only in the active communication mode. It shall be applied to reactivate a distinct Target device by its NFCID3, which was deactivated by the DSL command.

Figure 24 — Structure of the WUP_REQ 12.6.2.2.2

Definition of the WUP_REQ bytes

CMD 1: Shall be set to ‘D4’. CMD 2: WUP_REQ The WUP_REQ byte shall specify the command Wake Up for the Initiator device. The value of WUP_REQ shall be ‘02’. Byte 1 to Byte 10: NFCID3t The 10 nfcid3t bytes shall be defined as the random identifier of the Target. For the WUP_REQ command the Initiator shall send the known NFCID3t random identifier to wake up the Target. Byte 11: DID The DID byte shall be used for multiple data transport protocol activation with more than one Targets. The range of the DID shall be defined between 1 and 14. The value 0 shall be used, if no DID is used during the data transport protocol. All other values shall not be used. The Initiator may assign a different value to the Target, as used before the last DSL command. 12.6.2.3 12.6.2.3.1

Wakeup Response (WUP_RES) General

Figure 25 specifies the structure of the Wakeup Response for attributes WUP_RES. The WUP_RES shall be the response to the WUP_REQ and shall be sent by the selected NFCIP-1 Target device.

Figure 25 — Structure of the WUP_RES

12.6.2.3.2

Definition of the WUP_RES bytes

CMD 1: Shall be set to ‘D5’. CMD 2: WUP_RES The WUP_RES byte shall specify the response to the WUP_REQ. The value of WUP_RES shall be (03). Byte 1: DID The DID byte shall be used for multiple data exchange protocol activation with more than one Targets. The DIDt shall have the same value as the DIDi. All other values shall not be used. 12.6.2.4

Handling of WUP_REQ and WUP_RES

12.6.2.4.1

Initiator rules

When the Initiator has sent a WUP_REQ and receives a valid WUP_RES the Initiator shall continue with operation. In any other case the Initiator shall retransmit the WUP_REQ before using the deactivation sequence as defined in 12.7. In case of failure of the deactivation sequence in Passive communication mode at fc/128, it may use the HLTA command (see ISO/IEC 14443-3:2018, 6.4.3). 12.6.2.4.2

Target rules

When the Target has been de-selected by the last command (for the active communication mode only) and a)

receives a WUP_REQ with its NFCID3, the Target ⎯ shall send its WUP_RES, and ⎯ shall disable in order to not receive a subsequent WUP_REQ.

receives any other valid or invalid frame, except a HLTA command only for passive communication mode at fc/128, the Target ⎯ ignores the block, and ⎯ remains in receive mode.

12.6.3

Parameter Selection Request and Response Commands

12.6.3.1 12.6.3.1.1

Parameter Selection Request (PSL_REQ) General

The Initiator may switch parameters for the subsequent transport protocol using the PSL_REQ command, see Figure 26.

Figure 26 — Structure of the PSL_REQ 12.6.3.1.2

Definition of the PSL_REQ bytes

CMD 1: Shall be set to ‘D4’. CMD 2: PSL_REQ The PSL_REQ byte shall specify the command Parameter Selection for the Initiator device. The value of PSL_REQ shall be ‘04’. Byte 1: DID The DID shall be similar to the DID defined during ATR or WUP. Byte 2: BRS The BRS byte (see Figure 27) shall specify the selected bit rates for Initiator and Target device.

Figure 27 — Coding of the BRS byte — bit 8 and bit 7: Shall be set to ZERO. — bit 6 to bit 4: Bit duration of Initiator to Target, see Table 7. — bit 3 to bit 1: Bit duration of Target to Initiator, see Table 7. Table 7 — Coding of DRI and DSI DRI and DSI

Divisor D

000

001

010

011

100

101

110

111

RFU

Byte 3: FSL The FSL byte defines the maximum value for the Frame Length, see Figure 28.

Figure 28 — Coding of FSL bytes — bit 8 to bit 3: Shall be set to all ZERO. — bit 2 and bit 1: Length Reduction (LR) value, see Table 8. Table 8 — Definition of LR LR

12.6.3.2

LENMAX

Only Byte 1 to Byte 64 is valid in the Transport Data

Only Byte 1 to Byte 128 is valid in the Transport Data

Only Byte 1 to Byte 192 is valid in the Transport Data

Only Byte 1 to Byte 252 is valid in the Transport Data

Parameter Selection Response (PSL_RES)

12.6.3.2.1

General

Figure 29 specifies the frame Structure of PSL_RES.

Figure 29 — Structure of PSL_RES 12.6.3.2.2

Definition of the PSL_RES bytes

CMD1: Shall be set to ‘D5’. CMD2: PSL_RES The PSL_RES byte shall specify the command Parameter Selection response for the Target device. The value of PSL_RES shall be ‘05’. Byte 1: DID The DID shall be the same as the DID defined during ATR or WUP. 12.6.3.3 12.6.3.3.1

Handling of PSL_REQ and PSL_RES Initiator rules

The Initiator may change protocol parameters by sending the PSL_REQ to the Target. After reception of a valid PSL_RES, the Initiator — shall change the framing to the format which is defined in 12.2, and

— shall continue with operation. In any other case the Initiator may retransmit the PSL_REQ before using the deactivation sequence as defined in 12.7. In case of failure of deactivation sequence in Passive communication mode at fc/128, it may use the HLTA command (see 12.6.1.3.1). 12.6.3.3.2

Target rules

When the Target has received an ATR_REQ, sent its ATR_RES and a)

receives a valid PSL_REQ, the Target ⎯ shall send its PSL_RES, ⎯ shall disable the PSL_REQ (stop responding to received PSL_REQ), ⎯ shall change all parameters to the defined values, which are specified in 12.6.3, and ⎯ shall remain in receive mode.

receives an invalid frame, the Target ⎯ shall ignore the block, ⎯ shall disable the PSL_REQ (stop responding to received PSL_REQ), ⎯ shall remain with the current framing, and ⎯ shall remain in receive mode.

receives a valid frame, except a PSL_REQ, the Target ⎯ shall disable the PSL_REQ (stop responding to received PSL_REQ), ⎯ shall remain with the current framing, and ⎯ shall continue operation.

12.7

Data Exchange Protocol

12.7.1

Data Exchange Protocol Request and Response

12.7.1.1 12.7.1.1.1

Data Exchange Protocol Request (DEP_REQ) and Response (DEP_RES) General

The protocol shall be half-duplex protocol supporting block-oriented data transmission with error handling. For data which does not fit in one frame, a chaining mechanism is defined. The format of the protocol frame as specified in Figure 30 shall be used.

Figure 30 — Definition of the protocol frames In information interchange, the content of the payload of the Transport Data Field requires agreement between the interchanging parties. 12.7.1.1.2

Definition of the Data Exchange Protocol Header bytes

CMD 1: If the CMD2 is DEP_REQ then the CMD1 shall be set to ‘D4’. If the CMD2 is DEP_RES then the CMD1 shall be set to ‘D5’. CMD 2: DEP_REQ The DEP_REQ bytes specify the command for the data exchange protocol for the Initiator device. The value of the DEP_REQ shall be ‘06’. CMD 2: DEP_RES The DEP_RES bytes specify the command for data exchange for the Target device. The value of the DEP_RES shall be ‘07’. Byte 1: PFB The PFB byte shall contain bits to control the data transmission and error recovery. The PFB byte is used to convey the information required controlling the transmission. The data exchange protocol defines these fundamental types of pdus: — Information pdus to convey information for the application layer. — ACK/NACK pdus to convey positive or negative acknowledgements. An ACK / NACK pdu never contains a data field. The acknowledgement relates to the last received block. — Protected pdus to convey data which shall be in accordance with ISO/IEC 13157-1. — Supervisory pdus to exchange control information between the Initiator and the Target. Two types of supervisory pdus are defined: ⎯ timeout extension containing a 1-byte data field; ⎯ attention containing no data field. Table 9 specifies the coding of PFB.

Table 9 — Coding of the PFB bits 8 to 6 bit 8

bit 7

bit 6

PFB

Information pdu

Protected pdu

ACK/NACK pdu

Supervisory pdu

Other settings are RFU

Figure 31 specifies the structure of the Information pdu:

Figure 31 — Information pdu — bit 8 to bit 6: Shall be set to all ZEROs. — bit 5: If bit set to ONE then it indicates Multiple Information (MI) chaining activated. — bit 4: If bit set to ONE then it indicates NAD available. — bit 3: If bit set to ONE then it indicates DID available. — bit 2 and bit 1: PNI packet number information. The Packet Number Information (PNI) counts the number of packets sent by the Initiator to the Target and vice versa starting by 0. These bytes are used for error detection during the protocol handling. Figure 32 specifies the structure of the ACK/NACK pdu.

Figure 32 — ACK/NACK pdu — bit 8: Shall be set to ZERO. — bit 7: Shall be set to ONE. — bit 6: Shall be set to ZERO. — bit 5: If bit set to ONE then it indicates NACK, otherwise ACK. — bit 4: If bit set to ONE then it indicates NAD available. — bit 3: If bit set to ONE then it indicates DID available. — bit 2 and bit 1: PNI packet number

Figure 33 specifies the Supervisory pdu (Attention-Target Present, Timeout extension).

Figure 33 — Supervisory pdu — bit 8: Shall be set to ONE. — bit 7 and bit 6: shall be set to ZERO. — bit 5: If bit set to ZERO then it indicates Attention (see 12.7.3), otherwise Timeout extension (see 12.7.2). — bit 4: If bit set to ONE then it indicates NAD available. — bit 3: If bit set to ONE then it indicates DID available. — bit 2 and bit 1: Shall be set to ZERO. Figure 34 specifies the Protected pdu.

Figure 34 — Protected pdu — bit 8 and bit 7: RFU. The Initiator shall set it to ZERO. The Target shall ignore it. — bit 6: shall be set to ONE. — bit 5: If bit set to ONE then it indicates Multiple Information (MI) chaining activated. — bit 4: If bit set to ONE then it indicates NAD available. — bit 3: If bit set to ONE then it indicates DID available. — bit 2 and bit 1: PNI packet number information. The PNI counts the number of packets sent by the Initiator to the Target and vice versa starting by 0. These bytes are used for error detection during the protocol handling. Byte 2: DID The DID byte shall be the same as defined during activation of the protocol. Byte 3: NAD The NAD byte is reserved to build up and address different logical connections on both the Initiator and the Target device. Bit 8 to bit 5 code the logical address of the Initiator, bits 4 to 1 code the logical address of the Target. The following definitions shall apply for the usage of the NAD: — The NAD shall only be used for the data exchange protocol.

— When the Initiator uses an NAD, the Target shall also use an NAD. — If MI bit is set, the NAD shall only be transmitted in the first frame. — The Initiator shall never use the NAD to address two different Targets. Byte 4 to Byte n: User data bytes The data field shall contain the transported data and is optional. When present, it conveys either application data or status information. The length of the data field is calculated by subtracting the mandatory and optional send bytes of the data exchange transport header from the length byte and additionally subtracting one. 12.7.1.2 12.7.1.2.1

Handling of pdu number information Initiator rules

The PNI of the Initiator shall be initialized for each Target with all ZEROs. When an Information, Protected or ACK/NACK pdu with an equal PNI is received, the Initiator shall increment the current PNI for that Target before optionally sending a new frame. 12.7.1.2.2

Target rules

The PNI of the Target shall be initialized with all ZEROs. When an Information, Protected or ACK/NACK pdu with an equal PNI was received the Target shall send its response with this PNI and shall increment the PNI afterwards. 12.7.1.3

Handling of Blocks

12.7.1.3.1

General rules

The first pdu shall be sent by the Initiator. When an Information or Protected pdu indicating more information is received the pdu shall be acknowledged by an ACK pdu. Supervisory pdus are only used in pairs. A Supervisory Request shall always be followed by a Supervisory Response. 12.7.1.3.2

Initiator rules

When an invalid pdu was received a NACK pdu shall be sent (except in the case of DSL or RLS). When a timeout occurs, a Supervisory pdu indicating Attention (Attention Request) shall be sent (except a NACK pdu has been sent before). When a timeout occurs and a NACK pdu has been sent before, the NACK pdu shall be retransmitted. When an ACK pdu is received, if its pdu number is equal to the current PNI of the Initiator, the chaining shall be continued. If the DSL_REQ is not answered by a valid DSL_RES the DSL_REQ may be retransmitted or the Target command ignored.

12.7.1.3.3

Target rules

The Target is allowed to send a Supervisory pdu indicating Response timeout extension (Timeout extension Request) instead of an Information pdu. When an Information or Protected pdu not containing chaining is received it shall be acknowledged by an Information or Protected pdu. When a NACK pdu is received, if the PNI is equal to the PNI of the previous sent pdu, the previous block shall be re-transmitted. When an erroneous pdu is received the Target shall not answer but stay in the same State. When an Attention Request is received, the Target shall respond by sending a Supervisory pdu indicating Attention (Attention Response). 12.7.2

Response timeout extension

The response timeout extension shall only be used by the Target. When a Target needs more time to process the received block from the Initiator than defined in tRW, it shall use a Timeout extension. A Timeout extension Request contains a 1-byte data field (Response timeout extension byte). The definition of the byte is shown in Figure 35.

Figure 35 — Response timeout extension byte — bit 8 and bit 7: Shall be set to ZERO. — bit 6 to bit 1: RTOX value. For RTOX the values 0 and 60 to 63 are RFU. For all other values, the intermediate tRW,INT shall be calculated by the following formula: tRW,INT = tRW × RTOX The tRW,INT starts after the Initiator has sent its Supervisory pdu indicating Timeout extension (Timeout extension Response) to the Target. In case tRW,INT exceeds tRW,MAX, tRW,MAX shall be used. The tRW,INT is valid until the next frame has been received by the Initiator. 12.7.3

Attention — Target present

The Initiator shall send the Attention Request to the Target to ensure the Target is still in field for passive communication mode or to be able to detect a Target loss during multi-activation. This command shall not change the current State of the Target. The Target shall respond to a valid Attention Request by sending an Attention Response containing the identical data field to the Initiator. If the Target receives an incorrect pdu it shall not respond and shall stay in the same State.

12.7.4

Protocol operation

After the activation sequence the Target shall wait for a block as only the Initiator has the right to send. After sending a block, the Initiator shall switch to receive mode and wait for a block before switching back to transmit mode. The Target may transmit blocks only in response to received blocks. After responding, the Target shall return to the receive mode. The Initiator shall not initiate a new pair of Request/Response until the current pair of Request/Response has been completed or if the frame waiting time is exceeded without response. 12.7.5

Multi-Activation

The Multi-Activation feature allows the Initiator to hold several Targets active simultaneously. It allows switching directly between several Targets without needing additional time for deactivation of a Target and activation of another Target. For an example of Multi-Activation see Table 10. The Initiator needs to handle a separate package number information for each activated Target. Table 10 — Multi-Activation Initiator action

Status Target 1

Status Target 2

Status Target 3

Choose active communication mode Activate Target 1 with DID=1

Selected (1)

Sense

Any communication with DID=1

Selected (1)

Sense

Activate Target 2 with DID=2

Selected (1)

Selected (2)

Sense

Any communication with DID=1,2

Selected (1)

Selected (2)

Sense

Activate Target 3 with DID=3

Selected (1)

Selected (2)

Selected (3)

Any communication with DID=1,2,3

Selected (1)

Selected (2)

Selected (3)

Deactivation Sequence with DID=1

Sleep

Selected (2)

Selected (3)

Any communication with DID=2,3

Sleep

Selected (2)

Selected (3)

Deactivation Sequence with DID=2

Sleep

Selected (3)

Any communication with DID=3

Sleep

Selected (3)

Sleep

…

… Deactivation Sequence with DID=3 …

12.7.6

More information (Chaining)

The chaining feature allows the Initiator or Target to transmit information that does not fit in a single block, by dividing the information into several blocks. Each of those blocks shall have a length less than or equal to the maximum frame size (LENMAX). The chaining bit in the PFB of a protocol frame controls the chaining of frames. Each frame with the chaining bit set shall be acknowledged by an ACK pdu.

The chaining feature is shown in Figure 36 using a 16-byte long string transmitted in three blocks.

12.8

Deactivation of the protocol

12.8.1

General

After exchange of data by using the data exchange protocol, the Initiator may apply a deactivation of the data exchange protocol. After successful deactivation Initiator and Target shall stay in the initially chosen mode, but the Initiator may choose one of the defined bit rates for reactivation. See ISO/IEC 14443-3:2018, 6.4.1 and 12.6.2 for reactivation of Targets in passive communication mode and active communication mode, respectively. After successful deactivation the Target shall not respond to subsequent ATR_REQ commands. The RLS_REQ command shall switch the Target back to POWER ON State. See 12.8.3.1. In this State, the Target shall answer to all initial communication schemes and shall also answer to an ATR_REQ command.

Figure 36 — More Information (Chaining) 12.8.2

Deselect Request and Response command

12.8.2.1 12.8.2.1.1

Deselect request (DSL_REQ) General

Figure 37 specifies the deselect command DSL_REQ. The DSL_REQ is sent from Initiator to the Target.

Figure 37 — Structure of the DSL_REQ 12.8.2.1.2

Definition of DSL_REQ bytes

CMD 1: Shall be set to ‘D4’. CMD 2: DSL_REQ The DSL_REQ byte specifies the command deselect for the Initiator device. The value of DSL_REQ shall be ‘08’. Byte 1: DID The DID shall be the same as defined during ATR or WUP commands. 12.8.2.2

Deselect response (DSL_RES)

12.8.2.2.1

General

Figure 38 specifies the Deselect Response command DSL_RES. The DSL_RES is the response to the DSL_REQ and is sent from the Target to the Initiator.

Figure 38 — Structure of the DSL_RES 12.8.2.2.2

Definition of Deselect Response bytes

CMD 1: Shall be set to ‘D5’. CMD 2: DSL_RES The DSL_RES byte specifies the command deselect response for the Target device. The value of DSL_RES shall be ‘09’. Byte 1: DID The DID shall be the same as in DSL_REQ. 12.8.2.3 12.8.2.3.1

Handling of DSL_REQ and DSL_RES Initiator rules

When the Initiator has sent a DSL_REQ and received a valid DLS_RES, the Target has been successfully halted. The DID assigned to the Target has been released.

12.8.2.3.2

Target rules

When the Target has received a DSL_REQ and sent its DSL_RES, the Target — shall stay in initially chosen mode, — shall enable to receive the default bit rates defined in 11.3 for the Passive communication mode and in 11.4 for the active communication mode, and — shall remain in receive mode (either active or passive) at the bit rate used for DSL_REQ/DSL_RES exchange until a valid WUPA at fc/128 or valid Polling Request at fc/64 or fc/32 (the Target shall not change NFCID2 when entering or leaving halted state) is received in passive communication mode or a valid WUP_REQ is received in active communication mode. 12.8.3

Release Request and Response commands

12.8.3.1

Release Request (RLS_REQ)

12.8.3.1.1

General

Figure 39 specifies the release command RLS_REQ. The RLS_REQ is sent from the Initiator to the Target.

Figure 39 — Structure of RLS_REQ 12.8.3.1.2

Definition of RLS_REQ bytes

CMD 1: Shall be set to ‘D4’. CMD 2: RLS_REQ The RLS_REQ bytes specify the command release for the Initiator device. The value of the RLS_REQ bytes shall be ‘0A’. Byte 1:DID The DID shall be the same as defined in ATR or WUP commands. 12.8.3.2 12.8.3.2.1

Release response RLS_RES General

The RLS_RES is the response to the RLS_REQ sent from the Target to the Initiator, see Figure 40.

Figure 40 — Structure of RLS_RES

12.8.3.2.2

Definition of RLS_RES bytes

CMD 1: Shall be set to ‘D5’. CMD 2: RLS_RES The RLS_RES bytes specify the command release for the Target device. The value of the RLS_RES bytes shall be ‘0B’. Byte 1:DID The DID shall be the same as defined in RLS_REQ command. 12.8.3.3 12.8.3.3.1

Handling of RLS_REQ and RLS_RES Initiator rules

When the Initiator has sent an RLS_REQ and received a valid RLS_RES, the Target has been successfully released. The Initiator may return to initial State. 12.8.3.3.2

Target rules

When the Target has received an RLS_REQ and sent its RLS_RES, the Target shall return to initial State.

Annex A (normative) CRC calculation

A.1 CRC for active and passive communication mode at fc/128 The frame CRC shall be a function of k data bits, which consist of all the data bits in the frame, excluding parity bits, S and E, and the CRC itself. Since data is encoded in bytes, the number of bits k shall be a multiple of 8. For error checking, the two CRC bytes shall be sent in the Standard Frame, after the bytes and before the E. The CRC shall be calculated by the following polynomial. The pre-set value shall be (6363) and the register content shall not be inverted after calculation. G(x) = x16 + x12 +x5 + 1 For an example of the CRC calculation for the active and the passive communication mode at fc/128 see A.2.

A.2 Example of CRC calculation at fc/128 This example is provided for explanatory purposes and indicates the bit patterns that will exist in the physical layer. It is included for the purpose of checking the Passive communication mode implementation at fc/128 encoding. The process of encoding and decoding may be conveniently carried out by a 16-stage cyclic shift register with appropriate feedback gates. The flip-flops of the register shall be numbered from FF1 to FF16 as specified in ITU-T V.41:1988, Annex I, Figures I-1/V.41 and I-2/V.41. FF1 shall be the leftmost flip-flop where data is shifted in. FF16 shall be the rightmost flip-flop where data is shifted out. Table A.1 defines the initial content of the register. Table A.1 — Initial content of 16-stage shift register according to value (6363) FF1

FF2

FF3

FF4

FF5

FF6

FF7

FF8

FF9

FF10

FF11

FF12

FF13

FF14

FF15

FF16

Consequently, FF1 corresponds to the msb and FF16 to the lsb. Examples of bit patterns that will be transmitted via Standard Frames. EXAMPLE 1 Transmission of data, first byte = ‘00’, second byte = ‘00’, CRC appended, see Figure A.1. Calculated CRC = (1EA0), see Table A.2. First bit transmitted

Figure A.1 — Example 1 for CRC encoding Table A.2 — Content of 16-stage shift register according to value (1EA0) FF1

FF2

FF3

FF4

FF5

FF6

FF7

FF8

FF9

FF1 0

FF1 1

FF1 2

FF1 3

FF1 4

FF1 5

FF1 6

EXAMPLE 2

Transmission of data block, first byte = ‘12’, second byte = ‘34’, CRC appended, see Figure A.2.

Calculated CRC = ‘CF26’, see Table A.3. First bit transmitted

Figure A.2 — Example 2 for CRC encoding Table A.3 — Content of 16-stage shift register according to value (CF26) FF1

FF2

FF3

FF4

FF5

FF6

FF7

FF8

FF9

FF1 0

FF1 1

FF1 2

FF1 3

FF1 4

FF1 5

FF1 6

A.3 CRC for active and passive communication mode at fc/64 and fc/32 The CRC shall be calculated by the CCITT CRC-16, the scope of which shall include the Length field and the Payload field. Calculation in a G(x) shall be defined by: G(x) = x16 + x12 +x5 + 1 Pre-set value shall be 0. For an example of the CRC calculation for the active and the passive communication mode at fc/64 and fc/32 see A.4.

A.4 Example of CRC calculation at fc/64 and fc/32 The sample Frame is as follows: ‘00’ ‘00’ ‘00’ ‘00’ ‘00’ ‘00’ ‘B2’ ‘4D’ ‘03’ ‘AB’ ‘CD’ ‘90’ ‘35’ ‘B2’ ‘4D’ is SYNC. ‘03’ is the length. ‘AB’ ‘CD’ is the user data. ‘90’ ‘35’ is the corresponding CRC.

Annex B (informative) SAK

Figure B.1 illustrates the combination of SAK use in ISO/IEC 14443-3 and this document.

Figure B.1 — Combination of SAK

Bibliography (if any)

[1]

ISO/IEC 14443-4, Cards and security devices for personal identification — Contactless proximity objects — Part 4: Transmission protocol

[2]

NFC Forum, Digital Protocol Technical Specification, v2.3, available at “https://nfc-forum.org

[3]

NFC Forum, Activity Technical Specification, v2.2, available at “https://nfc-forum.org

ECMA-340 — Near Field Communication Interface and Protocol 1 (NFCIP-1) (June 2024)

Related documents