Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-391 — Memory-Spot Interface and Protocol (MSIP‑1) (December 2009)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

Open Source ↗Direct PDF ↓

ecma ecmainternational interface memory protocol

ecma, standard, ecma international, specification, ecma-391, ecma 391, 391, memory-spot, interface, and, protocol, msip

ECMA-391 1st Edition / December 2009

Memory-Spot Interface and Protocol (MSIP-1)

Reference number ECMA-123:2009

Contents

Page

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

Conformance ......................................................................................................................................... 1

Terms and definitions ........................................................................................................................... 1

4 4.1

Conventions and notations .................................................................................................................. 3 Representation of numbers .................................................................................................................. 3

Acronyms ............................................................................................................................................... 3

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

7 7.1 7.1.1 7.1.2 7.2 7.2.1 7.3 7.4

Physical Layer ....................................................................................................................................... 5 RF field.................................................................................................................................................... 5 Frequency .............................................................................................................................................. 5 Radiated Power...................................................................................................................................... 5 Passive communication mode ............................................................................................................. 6 Received Power ..................................................................................................................................... 6 Active communication mode ............................................................................................................... 6 External RF power threshold value ..................................................................................................... 6

8 8.1 8.2 8.2.1 8.2.2 8.2.3 8.2.4 8.3 8.3.1 8.3.2

RF Signal Interface ................................................................................................................................ 6 Bit duration ............................................................................................................................................ 7 Active communication mode ............................................................................................................... 7 Modulation ............................................................................................................................................. 7 Bit representation and coding ............................................................................................................. 8 Byte encoding ........................................................................................................................................ 9 Data Whitening ...................................................................................................................................... 9 Passive communication mode ............................................................................................................. 9 Initiator to Target ................................................................................................................................... 9 Target to Initiator ................................................................................................................................. 11

9 9.1 9.2 9.2.1 9.2.2

Data Transaction and Frame Formats ............................................................................................... 12 Transaction between Initiator and Target(s)..................................................................................... 12 Frame format ........................................................................................................................................ 13 Start of Frame (SOF) ........................................................................................................................... 14 Transport Data Fields.......................................................................................................................... 15

10 10.1 10.2

General Protocol flow ......................................................................................................................... 16 Protocol flow for Passive communication mode ............................................................................. 16 Protocol flow for Active communication mode ................................................................................ 19

11 11.1 11.2 11.2.1 11.2.2 11.3 11.4 11.5

Initialization and Anti-collision .......................................................................................................... 21 General ................................................................................................................................................. 21 RF Collision Avoidance ...................................................................................................................... 21 Initial RF Collision Avoidance ............................................................................................................ 21 Response RF Collision Avoidance .................................................................................................... 22 Initialisation and device detection ..................................................................................................... 22 Single Device Detection (SDD) ........................................................................................................... 26 Multiple device detection and isolation ............................................................................................ 27

12 12.1 12.2

Protocols .............................................................................................................................................. 28 Reading the PROTOCOL value: Initiator command ......................................................................... 28 Reading the PROTOCOL value: Target response ............................................................................ 29

13 13.1

MSIP-1 Transport Protocol ................................................................................................................. 29 Transport Data ..................................................................................................................................... 29

13.1.1 13.1.2 13.2 13.3 13.3.1 13.3.2 13.3.3 13.4 13.4.1 13.4.2 13.4.3 13.4.4 13.4.5 13.4.6 13.5 13.5.1 13.5.2

Initiator to Target frame ......................................................................................................................29 Target to Initiator frame ......................................................................................................................30 Commands ...........................................................................................................................................30 Activation of the protocol ...................................................................................................................31 Attribute Request and Response Commands ..................................................................................31 Wakeup Request and Response Commands ...................................................................................37 Parameter Selection Request and Response Commands ..............................................................39 Data Exchange Protocol .....................................................................................................................42 Data Exchange Protocol Request and Response ............................................................................42 Response timeout extension ..............................................................................................................46 Attention – Target present ..................................................................................................................46 Protocol operation ...............................................................................................................................46 Multi Activation ....................................................................................................................................47 More information (Chaining)...............................................................................................................47 Deactivation of the protocol ...............................................................................................................48 Deselect Request and Response command .....................................................................................48 Release Request and Response commands ....................................................................................49

14 Direct Addressing Protocol ................................................................................................................51 14.1 Read (CMD3=0x00) ..............................................................................................................................51 14.1.1 Initiator command ................................................................................................................................51 14.1.2 Target response ...................................................................................................................................51 14.2 Write (CMD3=0x01) ..............................................................................................................................52 14.2.1 Initiator command ................................................................................................................................52 14.2.2 Target response ...................................................................................................................................52 14.3 WriteSync (CMD3=0x02)......................................................................................................................52 14.3.1 Initiator command ................................................................................................................................53 14.3.2 Target response ...................................................................................................................................54 14.4 PageErase (CMD3=0x03) .....................................................................................................................54 14.4.1 Initiator command ................................................................................................................................54 14.4.2 Target response ...................................................................................................................................54 14.5 MassErase (CMD3=0x08) ....................................................................................................................55 14.5.1 Initiator command ................................................................................................................................55 14.5.2 Target response ...................................................................................................................................55 14.6 Authenticate (CMD3=0x04) .................................................................................................................55 14.6.1 Initiator command ................................................................................................................................56 14.6.2 Target response ...................................................................................................................................56 14.7 ReportID (CMD3=0xFE) .......................................................................................................................56 14.7.1 Initiator Command ...............................................................................................................................57 14.7.2 Target Response ..................................................................................................................................57 14.8 ResetID (CMD3=0xFF) .........................................................................................................................57 14.8.1 Initiator Command ...............................................................................................................................58 14.8.2 Target Response ..................................................................................................................................58 14.9 Acknowledgement – ACK (CMD3 = 0x06) .........................................................................................59 14.10 Negative Acknowledgement – NAK (CMD3 = 0x15) .........................................................................59 14.11 Device Management ............................................................................................................................59 14.11.1 Attribute Discovery ..............................................................................................................................59 14.11.2 Parameter Selection ............................................................................................................................61 15 15.1 15.2 15.3 15.4 15.4.1 15.4.2 15.4.3 15.4.4 15.4.5 15.4.6

Target Fixed Internal Map ...................................................................................................................61 Map ........................................................................................................................................................61 Physical Device Identifier (PDID) .......................................................................................................62 Device Common Control Parameters (DCCP) ..................................................................................62 Target Common Control Parameters (TCCP) ...................................................................................63 Universal Target Header Identity (UTHID) – Location 0x00000018 .................................................63 Universal Target Header Version (VER) – Location 0x00000019 ....................................................63 User Start Page (usrStrtPg) – Location 0x0000001A .......................................................................63 Row Size (RowSz) – Location 0x0000001B .......................................................................................63 Page Size (PgSz) – Location 0x0000001C .........................................................................................63 size (Sz) – Location 0x0000001D ........................................................................................................63

15.4.7 ChkSum1– Location 0x0000001E ...................................................................................................... 64 15.4.8 PDSTRT– Location 0x00000020 ......................................................................................................... 64 15.4.9 PDDATA– Location 0x00000021 ........................................................................................................ 64 15.4.10 PDRX– Location 0x00000022 ............................................................................................................. 64 15.4.11 PDEND– Location 0x00000023 ........................................................................................................... 64 15.4.12 PDPERASE– Location 0x00000024.................................................................................................... 64 15.4.13 PDMERASE– Location 0x00000026 ................................................................................................... 64 15.4.14 MEM_DATA– Location 0x00000028 ................................................................................................... 64 15.4.15 AUTH_PAD– Location 0x00000029 .................................................................................................... 65 15.4.16 ChkSum2– Location 0x0000002B ...................................................................................................... 65 15.4.17 ID Parameter– Location 0x00000100 ................................................................................................. 65 15.4.18 PSL Parameter– Location 0x00000102 .............................................................................................. 65 15.5 Write only Memory (WOM) .................................................................................................................. 65 Annex A (normative) CRC Calculation ........................................................................................................... 67 Annex B (informative) Authentication ............................................................................................................. 69 Annex C (normative) Reference Antennas ..................................................................................................... 71 C.1 Reference Antenna #1 ......................................................................................................................... 71 C.1.1 Design Information .............................................................................................................................. 71 C.1.2 Antenna Validation .............................................................................................................................. 72 C.1.3 Use of Reference Antenna to measure radiated power and received power ................................ 73 C.2 Reference Antenna #2 ......................................................................................................................... 73 C.2.1 Design Information .............................................................................................................................. 73 C.2.2 Antenna Validation .............................................................................................................................. 76 C.2.3 Use of Reference Antenna to measure radiated power and received power ................................ 76 C.3 Reference Antenna #3 ......................................................................................................................... 76 C.3.1 Design Information .............................................................................................................................. 76 C.3.2 Antenna Validation .............................................................................................................................. 77 C.3.3 Use of Reference Antenna to measure radiated power and received power ................................ 78

iii

Introduction This Standard specifies the interface and protocol for simple wireless communication at 10 Mbps or higher between close coupled devices. The Memory Spot Interface and Protocol (MSIP-1) Standard allows, but does not specify, applications in network products and consumer equipment.

This Ecma Standard has been adopted by the General Assembly of December 2009.

DISCLAIMER This document and possible translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to Ecma International, except as needed for the purpose of developing any document or deliverable produced by Ecma International (in which case the rules applied to copyrights must be followed) or as required to translate it into languages other than English. 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.

Memory-Spot Interface and Protocol (MSIP-1)

Scope

This Ecma Standard specifies modulation schemes, codings, data rates, and frame formats of the RF interface, as well as initialization schemes and conditions required for data collision control during initialization. Furthermore, this Ecma Standard specifies a transport protocol including protocol activation and data exchange methods.

Conformance

MSIP-1 devices support both the Initiator and Target roles of operation, the Active and Passive communication modes of operation and protocols, as specified in Table 1. Table 1 — Conformant Device Matrix

Role

Active communication mode (see 7.3, 8.2)

Passive communication mode (see 7.2, 8.3)

Direct Addressing Protocol (see 14)

MSIP-1 Transport Protocol (see 13)

Initiator

Shall be supported

Target

Shall be supported

At least one protocol shall be supported and indicated by the PROTOCOL byte (s ee 14.11.1.1 )

Terms and definitions

For the purposes of this document, the following terms and definitions apply. 3.1 Active communication mode Mode in which both the Initiator and the Target use their own RF field to enable the communication 3.2 Collision Transmission by two or more Targets or Initiators during the same Time Period, 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 Initiator Generator of the RF field and starter of the MSIP-1 communication

3.5 Load modulation Process of amplitude and/or phase modulating a radio frequency field by varying the properties of a resonant circuit placed within the radio frequency field 3.6 lsb first least significant bit first, indicating a serial data transmission system that sends lsb before all other bits 3.7 LSB first Least Significant Byte first, indicating a serial data transmission system that sends LSB before all other bytes 3.8 Manchester coding 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 NOTE The order of the physical states within the sequence defines the logical state. The coding system which divides into half at the changing point in the middle point of bit self-sustaining time, and makes the direction of the changes correspond to two logic value.

3.9 msb first most significant bit indicating a serial data transmission system that sends the msb before all other bits 3.10 MSIP-1 device General term for either an Initiator or a Target communicating in the Active or the Passive communication mode 3.11 Passive communication mode When the Initiator is generating the RF field and the Target responds to an Initiator command in a load modulation scheme 3.12 RF Collision Avoidance (RFCA) Method to detect the presence of a RF field based on the carrier frequency and method to detect and resolve collisions on protocol level 3.13 Single Device Detection (SDD) An algorithm used by the Initiator to detect one out of several Targets in its RF field 3.14 Target Responds to Initiator command either using load modulation scheme (RF field generated by Initiator) or using modulation of self generated RF field 3.15 Time Period Slots used for RF Collision Avoidance

Conventions and notations

4.1

Representation of numbers

The following conventions and notations apply in this document unless otherwise stated. -

Letters and digits in parentheses represent numbers in hexadecimal notation, in addition to hexadecimal numbers that are prefixed by 0x.

The setting of bits is denoted by ZERO or ONE.

Numbers in binary notation and bit patterns are represented by a sequence 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.

|| between arguments indicates concatenation of the arguments.

Acronyms

ALL_REQ

Wake up ALL Request

Amplitude Modulation

ATR

Attribute Request and Attribute Response

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

CHAN

Channel Number Field

CMD

Command

CRC

Cyclic Redundancy Check

CRCH

Header CRC

CRCP

Payload CRC

CRCT

Target Transport Payload CRC

DEP

Data Exchange Protocol Request and Data Exchange Protocol Response

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 initiator

DSi

Data rate Send by initiator

DSL

Deselect Request and Deselect Response

DSL_REQ

Deselect Request

DSL_RES

Deselect Response

DSt

Data rate Send by Target

DUT

Device Under Test

Frequency of operating field (carrier frequency)

Optional information field for Initiator

Optional information field for Target

Identification number

lsb

least significant bit

LSB

Least Significant Byte

Multiple Information link for Data Exchange Protocol

msb

most significant bit

MSB

Most Significant Byte

NFCID3

Random ID for transport protocol activation

nfcid3n

Byte number n of the Random Identifier NFCID3

Preamble

PDID

Physical Device Identifier

PDU

protocol data unit

PFB

Control information for transaction

PNI

Packet Number Information

PPi

Protocol Parameters used by Initiator

PPt

Protocol Parameters used by Target

PSL

Parameter Selection Request and Parameter Selection Response

PSL_REQ

Parameter Selection Request

PSL_RES

Parameter Selection Response

Radio Frequency

RFCA

RF Collision Avoidance

RFU

Reserved for Future Use

RLS

Release Request and Release Response

RLS_REQ

Release Request

RLS_RES

Release Response

RWT

Response Waiting Time

SOCK

Socket ID Field

SOF

Start of Frame

SYNC

Synchronisation pattern

Timeout value

WUP

Wakeup Request and Wakeup Response

WUP_REQ

Wakeup Request

WUP_RES

Wakeup Response

Waiting Time

General

This Standard defines both the Active and the Passive communication modes as follows: In the Active communication mode, both the Initiator and the Target use their own RF field to enable communication. The Initiator starts the MSIP-1 communication. The Target responds to an Initiator command in the Active communication mode using self-generated modulation of a self-generated RF field. In the Passive communication mode, the Initiator generates the RF field and starts the communication. The Target responds to an Initiator command in the Passive communication mode using a load modulation scheme. The communication over the RF interface in the Active and the Passive communication mode includes modulation schemes, data rate and bit coding. In addition it includes the start of communication, the end of communication, the bit and byte representation, the framing and error detection, collision avoidance, the protocol and parameter selection and the data exchange and deactivation of the MSIP-1 devices. A communication between Initiator and Target is started by device initialisation and terminated by device deactivation. All MSIP-1 devices have a communication capability of 10 Mbps. The communication mode (Active or Passive) is not to be changed between activation and deactivation of the Target.

Physical Layer

7.1

RF field

7.1.1

Frequency

The carrier frequency of the RF field (fc) shall be 2 442 MHz ± 1 MHz. 7.1.2

Radiated Power

An MSIP-1 Device belongs to at least one of the Device Classes specified in Table 2. An Initiator's radiated power shall be measured using a standard antenna configuration as specified in Annex C. For each Device Class the Initiator's radiated power shall conform to the values given in Table 2 at the measurement ranges given in Table 2. Table 2 — Device Classes – Radiated Power

NOTE 1

Device Class

Distance between measurement Antenna and DUT (mm)

Power (P mid ) measured at reference antenna (dBm)

NOTE

5,0 ± 0,1

7,5 ± 0,75

10,0 ± 0,5

13,5 ± 0,75

100,0 ± 0,5

7,5 ± 0,75

Two MSIP-1 Devices will interoperate if they belong to the same device class.

Device Classes have been chosen to support range of possible device implementations designed for different applications. These Device Classes may typically support maximum operating ranges operating ranges and antenna sizes as listed in Table 3.

Table 3 — Device Classes – typical operating distance and antenna area

7.2

Device Class

Typical Maximum Operating Distance (mm)

Typical Antenna Area (mm 2 )

100

1000

Passive communication mode

An Initiator shall radiate power to energise the Target as specified in 7.1.2. 7.2.1

Received Power

A Target shall operate continuously when radiated from a reference antenna configuration as specified in Annex C with an applied power level and operating distance as specified in Table 4. Table 4 — Device Classes – Received Power

7.3

Device Class

Distance between reference antenna and DUT (mm)

Power applied at reference antenna (dBm)

1,0 ± 0,1

18,5 ± 0,1

10,0 ± 0,5

18,5 ± 0,1

100,0 ± 0,5

18,5 ± 0,1

Active communication mode

An Initiator and a Target shall alternately radiate power of a level as specified in 7.1.2. When receiving data, the Initiator and Target shall operate at a received power level as specified in 7.2.1.

7.4

External RF power threshold value

MSIP-1 devices shall detect external RF power levels at 2 442 MHz with a value higher than PThreshold, as specified in Table 5, while performing external RF power detection. Table 5 — PThreshold

Device Class

Distance between reference antenna and DUT (mm)

Power P Threshold applied at reference antenna (dBm)

1,0 ± 0,1

10,0 ± 0,5

1,0 ± 0,1

100,0 ± 0,5

1,0 ± 0,1

RF Signal Interface

This Clause specifies the signal interface for a data rate of 10 Mbps.

8.1

Bit duration

For Active communication mode the bit duration, Tbit, (see Figure 1) shall be 100 ns ± 1 ns for communication both from the Initiator to the Target and from the Target to the Initiator. For Passive communication mode the bit duration Tbit, shall be 100 ns ± 1 ns for communication from the Initiator to Target and shall be 100 ns ± 15 ns for communication from Target to the Initiator.

8.2

Active communication mode

The specification both from the Initiator to the Target and from the Target to the Initiator shall be identical. 8.2.1 8.2.1.1

Modulation Amplitude Modulation

Data transmission between the Initiator and the Target shall use Amplitude Modulation compliant with the limits shown in Figure 1 and Table 6. NOTE

A compliant signal does not enter the hatched area in Figure 1.

Table 6 — AM parameters P max

P mid +1,6 dB ± 0,4 dB

P mid

Power level specified in Table 2.

P min

P mid – 2 dB ± 0,6 dB

T transition

<50 ns

Figure 1 — AM power and time limits The filtering applied to the bit stream used for Amplitude Modulation shall be such that when combined with the Spectrum Spreading Modulation (see NOTE below) the necessary national or international regulations for spectral emissions are met.

The profile of a transmission shall be as follows, with reference to Figure 2: A. The power is smoothly ramped to the mean level, to eliminate the spectral growth caused by a sudden switch-on. Period A shall be less than 5 µs. B. The power shall be maintained at the mean level for at least 20 µs to allow the Target to power up and initialize itself. C. Data shall be transmitted. D. The power is smoothly ramped down to zero. Period D shall be less than 5 µs.

Figure 2 — Active communication mode transmission profile NOTE In addition to the amplitude modulation used for data transmission, there may also be modulation of the carrier frequency in order to reduce its power spectral density. This is applied throughout regions B and C in Figure 2 and can be done in any manner that complies with the necessary national and international regulations for spectral emissions. For example, for most countries within the Committee on European Postal Regulations (CEPT) there shall be a peak power density of 10 mW/MHz and a maximum average transmitted power of 100 mW (both values measured as e.i.r.p.). 1

8.2.2

Bit representation and coding

Logic “ZERO”: Shall be represented by a low carrier amplitude for one bit duration. Logic “ONE”: Shall be represented by a high carrier amplitude for one bit duration.

1 ERC Recommendation 70-03 (Tromsø 1997 and subsequent amendments), Version 9, February 2007, Annex 3.

8.2.3 .2.3

Byte encoding

The byte encoding shall be most significant bit (msb) first. 8.2.4

Data Whitening

Data whitening shall be performed on the MSIP-1 Transport Data Fields only. The whitening word is generated using a 7 bit LFSR with the polynomial f(D) = D7 + D5 +1 and subsequenty EXORed with the MSIP-1 Transport Data Fields data. Before each transmission, the shift register is initialised with logical ONES. After initialisation, the MSIP-1 Transport Data Field is scrambled. The first bit of the “Data in” sequence is the msb of the MSIP-1 Transport Data Fields. The received data is de-scrambled using the same whitening word. Data out

Data in

Figure 3 — Data whitening LFSR for Initiator and Target

8.3

Passive communication mode

8.3.1

Initiator to Target

8.3.1.1

Modulation

Transmission between the Initiator and the Target uses Amplitude Modulation identical to that described in Amplitude Modulation, 8.2.1.1, but with a different transmission profile. The profile of a transmission shall be as follows, with reference to Figure 4: A. The power is smoothly ramped to the mean level, to eliminate the spectral growth caused by a sudden switch-on. Period A shall be less than 5 µs. B. The power shall be maintained at the mean level for at least 20 µs to allow the Target to power up and initialize itself. C. Data is transmitted. D. The power is maintained at the mean level while the Target responds. E. The power is smoothly ramped down to zero. Period E shall be less than 5 µs.

Figure 4 — Passive communication mode transmission profile NOTE In addition to the amplitude modulation used for data transmission, there may also be modulation of the carrier in order to reduce its power spectral density. This is applied throughout regions B and C and D in Figure 4 and can be done in any manner that complies with the necessary national and international regulations for spectral emissions. For example, for most countries within the Committee on European Postal Regulations (CEPT) there shall be a peak power density of 10 mW/MHz and a maximum average transmitted power of 100 mW (both values measured as e.i.r.p.). 2

8.3.1.2

Bit representation and coding

Manchester bit encoding shall be employed. For each input bit the Manchester coder produces an output word of two symbols, according to either Table 7 or Table 8 below; the use of either is acceptable. The duration of each output symbol is the same as the bit duration specified in 0. Since two symbols are derived from one input data bit, the input data bit duration is twice as long as that specified in 0. Polarity of the encoded data may be detected in the Target from the SYNC field. Figure 5 below shows an example of the Manchester encoding of a short input data stream.

2 ERC Recommendation 70-03 (Tromsø 1997 and subsequent amendments), Version 9, February 2007, Annex 3.

Figure 5 — Example - Manchester encoding Table 7 — Manchester Encoding – Obverse Obverse Coding Input bit

Output symbols

Table 8 — Manchester Encoding - Reverse Reverse Coding Input bit

8.3.1.3

Output symbols

Byte encoding

The byte encoding shall be most significant bit (msb) first. 8.3.2

Target to Initiator

8.3.2.1

Modulation

The power reflected by the Target for at least one of the modulation states, shall be greater than 5% of the power received by the Target. The magnitude of the vector difference of the load modulation states, shall be greater than 4% and less than 15% of the mean magnitude of the reflected signal, the mean magnitude being the average magnitude of the load modulation signal of the two modulation states. Figure 6 illustrates the requirements described above.

m a b

a = power reflection coefficient of passive target when sending data = ZERO b = power reflection coefficient of passive target when sending data = ONE |a| or |b| > 0,05 m = magnitude of vector difference of reflected states such that: 0,04 x (|a|+|b|)/2 < m < 0,15 x (|a|+|b|)/2

Figure 6 — Passive Target Load Modulation

8.3.2.2

Bit representation and coding

Logic ZERO is represented by one of the two load modulation states, logic ONE is represented by the other load modulation state. The logic sense shall be determined by the use of the SYNC field in the Target Frame. 8.3.2.3

Byte encoding

The byte encoding shall be most significant bit (msb) first. 8.3.2.4

Data Whitening

Data whitening shall be performed on the MSIP-1 Transport Data Fields only. The scrambling method as used for Active communication mode transmissions shall be used as defined in 8.2.4.

Data Transaction and Frame Formats

9.1

Transaction between Initiator and Target(s)

A transaction shall consist of the transmission of an Initiator frame and the reception of a Target Frame.

Initiator frame Target frame

Initiator

Delay

Target

Figure 7 — Successful transaction For the Direct Addressing Protocol (see Clause 14) the Target shall respond to an Initiator Frame not before 4 µs and no later than 50 µs after the completion of the final bit of the Initiator Frame, unless the Direct Addressing Protocol command explicitly permits a longer delay. If the Initiator does not receive a response from the Target it shall timeout after 50 µs. It may then retry the command. For the MSIP-1 Transport Protocol (see Clause 11) the Target shall respond to an Initiator Frame not before 4 µs and no later than 10 ms after the completion of the final bit of the Initiator Frame. NOTE In MSIP-1 Transport Protocol, the delay for a response from the Target may be adjusted by the Timeout byte in an Attribute Response (see 13.3.1.2) from the Target. If the Target detects a corrupted frame before the end of the transmission by the Initiator as in Figure 8, it may immediately send a response incorporating a negative acknowledgment.

Initiator Frame Target Frame

Initiator Target Negative acknowledgement Figure 8 — Unsuccessful transaction

9.2

Frame format

Initiator Frames shall conform to the format shown in Figure 9.

Size (bits)

Start of Frame (SOF)

Initiator Transport Data Fields

≥ 80 bits

≥ 136 bits

Figure 9 — Initiator Frame format

Target Frames shall conform to the format shown in Figure 10.

Size (bits)

Start of Frame (SOF)

Target Transport Data Fields

≥ 80 bits

≥ 40 Figure 10 — Target Frame format

9.2.1

Start of Frame (SOF)

9.2.1.1 9.2.1.1.1

Passive communication mode Initiator

The SOF is specified in Figure 11 and shall be encoded as specified in 8.3.1.3. SOF PREAMBLE

SYNC

PRE0

PRE1

≥ 40 bits

24 bits

16 bits

0x00

0x555551

0x1616

Figure 11 — Initiator SOF, Passive communication mode

9.2.1.1.2

Target

In Passive communication mode the Target SOF is specified in Figure 12 and shall be encoded as specified in 8.3.2.3. SOF PRE2

SYNC

≥ 64 bits

16 bits

0101…0101

0x1616

Figure 12 — Target SOF, Passive communication mode

9.2.1.2

Active communication mode

In Active communication mode the SOF shall be the same for both Initiator and Target Frames and shall be identical to the SOF for Passive communication mode Target frames as specified in 9.2.1.1.2.

9.2.2

Transport Data Fields

9.2.2.1

Initiator Transport Data Fields

The Initiator Transport Data Fields comprises a HEADER and may contain a PAYLOAD, each protected by its own 32 bit CRC. The Initiator Transport Data Fields shall be used in both Active and Passive communication modes. The PAYLOAD data contained in PLD may contain data directly addressed by the HEADER (see Clause 14), or it may contain an MSIP-1 Transport data field (see MSIP-1 Transport Protocol, Clause 13). The type of PAYLOAD information is indicated in the HEADER. Clauses 13 and 14 specify in detail how PLD is structured and its length specified. When no PLD is present there shall not be a CRCP.

Initiator Transport Data Fields HEADER

PAYLOAD

Initiator HEADER Data Fields

CRCH

PLD

CRCP

104 bits

32 bit

≥0

32 bit

Figure 13 — Initiator Transport Data Fields

9.2.2.1.1

Initiator HEADER Data Fields

This HEADER is used for all Initiator Transport Data Fields, as specified in Figure 14. CHAN: The header frame shall begin with a 4 bit (CHAN) field that specifies which channel this frame is applied to. The target shall only process frames with CHAN value matching their own channel ID or frames with CHAN value equal to 0xFF (broadcast channel). SOC: The 12 bit SOC field specifies which socket this frame is applied to; it immediately follows the CHAN field. The targets shall only process frames with SOC value matching their own channel ID except for CMD3 values 0xFF (ResetID) and 0xFE (ReportID). CMD3: The CMD3 field specifies which operation the target is requested to perform. This 8 bit field shall consist of a number between 0x00 to 0x08 and 0xFE and 0xFF. All other values are reserved for future use. CMD3_EX: The command extension field (CMD3_EX) shall be 48 bits. This field provides additional information on the CMD3 field. The significance of each bit within this field is CMD3 dependent. When the CMD3_EX field is used for direct memory access applications it may be further sub-divided into two fields – ADDR and LEN, to allow direct addressing of up to 64kbyte blocks of a 32 bit address space. Initiator HEADER Data Fields CHAN 4 bit

SOC 12 bit

CMD3 8 bit

CMD3_EX ADDR

LEN

32 bit

16 bit

Figure 14 — Initiator Header

9.2.2.1.2

CRCH

The CRCH field is a 32 bit CRC value of the fields CHAN, SOC, CMD3, and CMD3_EX concatenated together. 9.2.2.1.3

PLD

The PLD field is of variable length, and may be zero length. 9.2.2.1.4

CRCP

If PLD is one or more bytes long, then it shall be protected by a 32 bit CRC – CRCP – calculated over the length of PLD. 9.2.2.2

Target Transport Data Fields

The Target Transport Data Fields comprises an initial response byte – CMD3 – followed by a variable length payload – PLDT. CMD3 and PLDT concatenated together are then protected by a 32 bit CRC – CRCT. The Target Transport Data Fields shall be used in both Active and Passive communication modes. Figure 15 specifies the Target Transport Data Fields structure: Target Transport Data Fields CMD3

PLDT

CRCT

8 bits

≥0

32 bits

Figure 15 — Target Transport Data Fields CMD3: Target’s response code. Allowed response codes are defined in Clause 14. PLDT: Target’s Payload. The size of this field is dependent on the requested operation and may be zero. CRCT: CRC of CMD3 and PLDT field only; this field shall consist of 32 bits. If the PLDT field is absent, CRCT shall be computed on the CMD3 field only.

10 General Protocol flow Any MSIP-1 device shall initially be a Target. The MSIP-1 device may choose to operate in either Active or Passive communication mode. 10.1 describes the overall protocol flow when Passive communication mode is selected, and 10.2 describes the overall protocol flow for Active communication mode.

10.1 Protocol flow for Passive communication mode Figure 16 describes the overall protocol flow when the Passive communication mode is selected by the Initiator.

There are five phases to the protocol: 1. Initialisation and Single Device Detection (see Clause 11) a. The Initiator shall perform the initial RF Collision Avoidance (RFCA) sequence as defined in 11.2.1. b. The Initiator shall switch to Passive communication mode. c.

The Initiator shall perform the Initialisation and SDD (see 11.3, 11.4, 11.5).

2. Determine Protocol Support (see Clause 12) a. The Initiator shall read the PROTOCOL value from the Target (see 12.1). b. The Target shall respond with its PROTOCOL value (see 12.2). c.

If the Target supports the MSIP-1 transport protocol, the Initiator proceeds to activate the MSIP-1 Protocol.

3. Protocol Activation and Parameter Selection (see 13.3) a. The Target may fall back to the Initialisation and SDD if no ATR_REQ is supported. b. The ATR_REQ may be sent by the Initiator as a next command after receiving the Attribute Request. c.

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.

d. 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. e. The Target shall send a PSL_RES as answer to the PSL_REQ. f.

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

4. Data Exchange (see 13.4) a. The transparent data shall be sent using the data exchange transport protocol. 5. Deactivation of the protocol (see 13.5) a. The Initiator may send either a DSL_REQ to deselect the Target or send a RLS_REQ to return the Target to its power-on reset condition as exists at the start of initialisation and device detection. b. The Target shall respond to a DSL_REQ with a DSL_RES, or respond to a RLS_REQ with a RLS_RES.

Start

Initial RFCA

Switch to Passive Mode

Initialisation and SDD Loop

Initialisation and Single Device Detection (Clause 11)

Read PROTOCOL value from Target

Direct Addressing Protocol

MSIP-1 Transport Protocol supported? no

Determine protocol support (Clause 12)

Receive RLS_RES

yes

Direct Addressing

Send RLS_REQ

(Clause 14) Send ATR_REQ Protocol Activation and Parameter Selection Receive ATR_REQ

(Clause 13.3)

Receive DSL_RES

yes Parameter Change? no

Send DSL_REQ

Send PSL_REQ

Protocol De-Activation (Clause 13.5)

Receive PSL_REQ

Change Parameter

Data Exchange Protocol (Clause 13.4) Data Exchange Protocol

Figure 16 — Protocol in Passive communication mode

10.2 Protocol flow for Active communication mode Figure 17 describes the overall protocol flow when the Active communication mode is selected by the Initiator. There are five phases to the protocol: 1. Initialisation (see Clause 11) a. The Initiator shall perform the initial RF Collision Avoidance sequence as defined in 11.2.1. b. The Initiator shall switch to the Active communication mode. c.

The Initiator shall perform the Initialisation and SDD (see 11.3, 11.4, 11.5).

2. Determine Protocol Support (see Clause 12) a. The Initiator shall read the PROTOCOL value from the Target (see 12.1). b. The Target shall respond with its PROTOCOL value (see 12.2). c.

If the Target supports the MSIP-1 transport protocol, the Initiator proceeds to activate the MSIP-1 Protocol.

3. Protocol Activation and Parameter Selection (see 13.3) a. The Initiator shall send the ATR_REQ. If the Initiator supports the NFC-SEC extension to MSIP-1, it shall indicate that in the ATR_REQ. b. The Target shall send its ATR_RES in response to the ATR_REQ. After a successful response the device is selected. If the Target supports the NFC-SEC extension to MSIP-1, it shall indicate that in the ATR_RES. c.

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.

d. The Target shall send a PSL_RES in response to the PSL_REQ. e. A Target does not need to complement the parameter selection, if it does not support any changeable parameters in the ATR_RES. 4. Data Exchange (see 13.4) a. The transparent data shall be sent using the data exchange transport protocol. 5. Deactivation of the protocol (see 13.5) a. The Initiator may send either a DSL_REQ to deselect the Target or send a RLS_REQ to return the Target to its power-on reset condition as exists at the start of initialisation and device detection. b. The Target shall respond to a DSL_REQ with a DSL_RES, or respond to a RLS_REQ with a RLS_RES.

Figure 17 — Protocol in Active communication mode

11 Initialization and Anti-collision 11.1 General The anti-collision / initialisation sequence is used to isolate Targets of interest by the Initiator in the event where more than one Target is present within the RF field of the Initiator. In the event that only one Target is present, the protocol is designed to quickly identify this condition so as to enable normal data transfer at the earliest possible moment.

11.2 RF Collision Avoidance In order not to disturb any other MSIP-1 communication and any current infrastructure running on the carrier frequency, an Initiator for MSIP-1 communication shall not generate its own RF field as long as another RF field is detected. 11.2.1 Initial RF Collision Avoidance 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 7.4. If the Initiator detects no RF field within the timeframe TIDT + n × TRFW the Initiator shall switch on its RF field. Figure 18 illustrates the initial RF Collision Avoidance during initialisation. Send Request

RF On T RFW

Start

T IRFG

T IDT n x T RFW

Figure 18 — Initial RF Collision Avoidance TIDT:

Initial delay time.

TRFW: RF waiting time. n:

TIDT > 100 µs 24 µs

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 > 25 µs The RF field, which is generated by the Initiator, shall be switched off in the Active communication mode after the Send Request message has been sent. The RF field, which is generated by the Initiator, shall not be switched off in the Passive communication mode.

The Initiator shall use Initial RF Collision Avoidance only for protocol activation. Subsequently it shall respect TADT as defined in 11.2.2 for switching on the RF field. 11.2.2 Response RF Collision Avoidance After the initial RF Collision Avoidance as described in 11.2.1, a response RF collision avoidance during activation shall be performed in the Active communication mode to avoid collision of data by simultaneous responding of more than one Target. If the Target detects no RF field within the time frame TADT + (n x TRFW) the Target shall switch on the RF field. The Target shall use Response RF Collision Avoidance only for protocol activation. Subsequently it shall respect TADT for switching on the RF field. Figure 19 illustrates the response RF Collision Avoidance sequence during initialisation. Send Response

RF On T RFW

Start

T ARFG

T ADT n x T RFW

Figure 19 — Response RF Collision Avoidance sequence during activation TADT: Active delay time, sense time between RF off Initiator/Target and Target/Initiator (50 µs≤ TADT ≤ 200 µs) TRFW: RF waiting time. (24 µs) n:

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 > 25 µs)

11.3 Initialisation and device detection Figure 20 and Figure 21 illustrate the procedures that are specified in 11.3, 11.4 and 11.5.

Figure 20 — Initiator Flowchart

START

Reset CHAN and SOCK

Wait for standard frame command from initiator

CHAN = own ID ?

Y N

Command = ResetID ?

N N N CHAN = 0xF? Command = ReportID

CHAN= own ID?

Command = Read?

Y Extract N from standard frame Y

Generate number from 1 to N and assign to Channel ID

Send Status Register bytes 0x0 and 0x1 to initiator

N Target address = Own address?

Send requested data at requested address of requested length to initiator

Command = Write?

Write data at requested address of requested length to memory/ register

Generate number from 0 to 4096 and assign to Socket ID

Figure 21 — Target flowchart The TargetID is the concatenation of the ChannelID and SocketID. The Target shall reset its TargetID to 0x0000 upon detection of a power-on reset or upon receipt of a ResetID command on the reset channel (CHAN=0x0). A Target operating in Passive communication mode shall perform a power-on reset when the RF field transmitted by the Initiator has been absent for greater than TADT. Command and channel data for initialisation and device detection is encoded in the fields of the HEADER as shown in Figure 23. The ChannelID is encoded in the CHAN field, and the SocketID is encoded in the SOCK field.

The Target shall only process frames with Channel ID and Socket ID matching their own with the following exceptions: •

The Target shall process the ‘ResetID’ command if it is issued on the Broadcast Channel (CHAN=0xF) or on a channel matching its ChannelID. The Target shall not match the SocketID.

•

The Target shall process the ‘ReportID’ command if it is issued on a channel matching its channelID. The Target shall not match the SocketID.

The device detection scheme shall be the channel selection method. The number of channels shall be given by an integer value N, between 1 and 13 inclusive, which is determined by the Initiator. If the ‘ResetID’ command (Figure 23) is issued on the Broadcast Channel, all Targets on all channels shall select a random ChannelID between 1 and N and a SocketID between 0 and 4095. If the ‘ResetID’ (Figure 24) is issued on a particular channel (y), only Targets operating on channel (y) shall select a random ChannelID between 1 and N and a SocketID between 0 through 4095. Targets operating on all other channels (i.e not y) shall retain their ChannelID and SocketID. Channel 15 (broadcast)

All Targets shall respond to a ResetID command issued on this channel. Targets shall not use this channel when selecting a random ChannelID in response to a ResetID command. The initiator may assign any Target to this channel.

Channel 14 (park)

Channel 13 Channel 12 Channel 11 Targets shall select a channel from 1 to N, where N is ≤ 13, in response to a ResetID command.

Channel 3 Channel 2 Channel 1 Channel 0 (reset)

All Targets shall default to this channel upon power-on reset.

Figure 22 — MSIP-1 communication channels

SOF Preamble

HEADER SYNC

See Initiator standard frame format

CHAN

SOCK

CMD3

CMD3_EX ADDR

LEN

CRCH

4 bits

8 bits

4 bits

8 bits

32 bits

16 bits

32 bits

0xF

0xFF

0x00000100

0x02

CRC

Figure 23 — Initiator to Target broadcast ‘ResetID’ frame

SOF Preamble

HEADER SYNC

CHAN

SOCK

CMD3

CMD3_EX ADDR

LEN

CRCH

4 bits

8 bits

4 bits

8 bits

32 bits

16 bits

32 bits

0x0

0xFF

0x00000100

0x02

CRC

See Initiator standard frame format

Figure 24 — Example: Initiator to Target ‘ResetID’ frame for channel 0 NOTE

x denotes any arbitrary values.

Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode. •

CHAN: Channel number this frame is applied to. Valid values are 0 through 15. Channel 15 shall be the Broadcast Channel. All Targets shall respond to a ‘ResetID’ frame if this is issued on a channel matching its ChannelID or on a Broadcast Channel.

•

SOCK: The Initiator shall use the lowest 4 bits of the SOCK field to specify the number of channels (N) available for this session. The value shall range from 1 through 13, all other values shall be invalid. The Target shall ignore the 8 most significant bits.

•

CMD3: This value shall be 0xFF (ResetID opcode).

•

ADDR: This value shall be 0x00000100.

•

LEN: This value shall be 0x02.

•

CRCH: CRC of fields CHAN, SOCK, CMD3, ADDR, and LEN concatenated together.

The Targets shall respond to the ‘ResetID’ frame with the frame specified in Figure 25. Preamble

SYNC

See Initiator standard frame format

CMD3

CHAN

SOCK

CRCT

8 bits

4 bits

12 bits

32 bits

0xFE

CRC

Figure 25 — ResetID response frame format Preamble is PRE2 for both Active and Passive communication mode response •

CMD3: This value shall be 0xFE (8 bits).

•

CHAN: This value, C, shall be the Target’s ChannelID.

•

SOCK: This value, S, shall be the Target’s SocketID.

•

CRCT: CRC of fields CMD3, CHAN, and SOCK concatenated together.

11.4 Single Device Detection (SDD) If the Response Frame to a ResetID issued on the Broadcast Channel is decoded with no CRC errors, then only one Target exists within the operating volume; in this situation the enumeration process is completed and the Initiator can now uniquely address the Target using the CHAN and SOCK values returned by the Target.

11.5 Multiple device detection and isolation If a reply is received from the Target in response to a ‘ResetID’ command or ReportID command issued on the Broadcast Channel and is decoded with CRC errors, then a collision is deemed to have occurred. The Initiator shall proceed with the next phase of the anticollison sequence to enumerate and isolate the Targets. The Initiator shall send a ‘ReportID’ frame (Figure 26) on the channels it wishes to enumerate. Only Targets with ChannelID matching the CHAN field of the ‘ReportID’ frame shall respond to the frame. SOF Preamble

HEADER SYNC

CHAN

See Initiator standard frame format

SOCK

CMD 3

CMD_EX

CRCH

ADDR

LEN

4 bits

12 bits

8 bits

32 bits

16 bits

32 bits

0xFE

00000100

0x02

CRC

Figure 26 — Initiator to Target broadcast ‘ReportID’ frame NOTE

x denotes any arbitrary values.

Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode •

CHAN: C = Channel number this frame is applied to. Valid values are 0 though 14. The Target shall respond to ‘ReportID’ frame if the CHAN field matches it own ChannelID field.

•

SOCK: This field shall be 12 bit. The Target shall ignore this field.

•

CMD3: This value shall be 0xFE (Report ID opcode).

•

ADDR: This value shall be 0x00000100.

•

LEN: This value shall be 0x02.

•

CRCH: CRC of fields CHAN, SOCK, CMD3, ADDR, LEN; this field shall be 32 bits.

The Target shall reply with the ‘ReportID’ response frame (Figure 27). Preamble

SYNC

See Target standard frame format

CMD3

CHAN

SOCK

CRCT

8 bits

4 bits

12 bits

32 bits

0xFE

CRC

Figure 27 — ReportID response frame format Preamble is PRE2 for both Active and Passive Mode Response. •

CMD3: This value shall be 0xFE.

•

CHAN: This value, C, shall be the Target’s ChannelID.

•

SOCK: This value, S, shall be the Target’s SocketID.

•

CRCT: CRC of fields CMD3, CHAN, and SOCK concatenated together.

If a reply is received from the Target in response to a ‘ReportID’ frame issued on a particular channel (x) and decoded with no CRC error, only one Target is deemed to exist on that channel (x), otherwise the procedure specified in 12.5 shall be reapplied. The Initiator may reassign the Target to another channel, including the Park Channel, by issuing a ChangeID frame as described in Figure 28. Within the ChangeID frame it may also change the SocketID. SOF Preamble

HEADER

PAYLOAD

SYNC

CHAN

SOC

CMD3

CMD_EX

CRCH

NEWCHAN

NEWSOCK

CRCP

16 bit

4 bit

12 bit

8 bit

48 bit

32 bit

4 bit

12 bit

32 bit

CRC

See Initiator standard frame format

0x01

ADDR

LEN

32 bit

16 bit

0x00000100

0x02

Figure 28 — Initiator to Target ’ChangeID’ frame format Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode •

CHAN: C = Channel number received from the Target in the Target’s ReportID frame.

•

SOCK: S = Socket number received from the Target in the Target’s ReportID frame.

•

CRCH: CRC of CHAN,SOC,CMD3,ADDR,LEN fields.

•

NEWCHAN: New CHAN, NC, assigned to Target by Initiator.

•

NEWSOCK: New SOCK, NS, assigned to Target by Initiator.

•

CRCP: CRC of Concatenation of NEWCHAN and NEWSOCK fields.

The Initiator may repeat the multiple Targets detection and isolation sequence, (this time on channels with collision) until all Targets have been isolated.

12 Protocols This specification defines two protocols: 1. MSIP-1 Transport Protocol This is a Transport Protocol closely related to the NFCIP-1 Transport Protocol. 2. Direct Addressing Protocol: Using this protocol, data and message fields in a Target may be accessed directly by an Initiator by specifying an address and length using fields in the HEADER. This protocol is most suitable for accessing Passive Targets where processing resources are limited. The Initiator shall determine the Target’s support for these protocols by using the following command and response:

12.1 Reading the PROTOCOL value: Initiator command An Initiator Frame as defined in Clause 9 shall be sent with the following Transport Data Field values: •

CHAN: determined by Initiator during Initialization (see Clause 11)

•

SOC: determined by Initiator during Initialization (see Clause 11)

•

CMD3: 0x00

•

ADDR: 0x00000010

•

LEN: 0x0001

•

CRCH: CRC of concatenation of CHAN, SOC, CMD3, ADDR, LEN fields.

12.2 Reading the PROTOCOL value: Target response A Target shall respond to the command defined in 12.1 with the following values in its Target Transport Data Fields: •

CMD3: 0x00

•

PLDT: PROTOCOL byte as defined in 14.11.1.1

•

CRCT: CRC of the concatenation of the CMD3 and PLDT fields.

13 MSIP-1 Transport Protocol The MSIP-1 Transport Protocol is derived from the NFCIP-1 Transport Protocol and supports all of NFCIP-1’s Transport Protocol features.

13.1 Transport Data 13.1.1 Initiator to Target frame Figure 29 specifies the overall packet structure of an MSIP-1 Transport Protocol transmission from Initiator to Target. The Initiator Transport Data Fields with format is specified in 9.2.2.1 shall be used, with the following values: •

CHAN: determined by Initiator during Initialization (see Clause 11)

•

SOC: determined by Initiator during Initialization (see Clause 11)

•

CMD3: 0x07

•

ADDR: RFU

•

LEN1, LEN2: Bytes LEN1 and LEN2 shall indicate the length of PLDI. LEN1 is the MSB of the 16 bit length, LEN2, is the LSB. PLDI shall be a maximum of 65535 bytes

•

CRCH: is the 32 bit CRC computed over (CHAN || SOC || CMD3 || ADDR || LEN)

•

PLDI: Shall contain the MSIP-1 Transport Data as defined in 13.3, 13.4 and 13.5

•

CRCP is the 32 bit CRC computed over the PLDI.

SOF Preamble

Initiator Transport Data Fields SYNC

HEADER CHAN

SOC

CMD3

ADDR

PAYLOAD LEN1

LEN2

CRCH

CRCP

PLDI MSIP-1 Transport Data CMD0

CMD1

Byte0

Byte1

Byte2

…..

Byten

Figure 29 — MSIP-1 Frame Format – Initiator to Target

13.1.2 Target to Initiator frame The Target Transport Data Fields as specified in Figure 30 and whose format is described in 9.2.2.2 shall be used with the following values: •

CMD3: 0x07

•

PLDT: Shall contain the MSIP-1 Transport Data packet as defined in 13.3, 13.4 and 13.5 pre-pended by two bytes - LEN1 and LEN2. Bytes LEN1 and LEN2 shall contain the 16-bit length of the MSIP-1 Transport data, including the CMD0 and CMD1 bytes. LEN1 is the MSB of the 16 bit length, LEN2, is the LSB.

•

CRCT: is the 32 bit CRC computed over (CMD3 || PLDT) SOF PRE2

SYNC

Target Transport Data Fields CMD3

PLDT

CRCT

MSIP-1 Transport Data LEN1

LEN2

CMD0

CMD1

Byte0

Byte1

Byte2

……

Byte n

Figure 30 — Frame Format - Target to Initiator

13.2 Commands The Command Bytes shall consist of 2 bytes. The first shall be CMD0 and the second shall be CMD1. The Commands are defined Table 9.

Table 9 — MSIP-1 Protocol Command Set Mnemonic

Command

Definition

CMD0

CMD1

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 mode only)

WUP_RES

(D5)

(03)

Wakeup Response (sent by Target in Active 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)

13.3 Activation of the protocol 13.3.1 Attribute Request and Response Commands 13.3.1.1

Attribute Request (ATR_REQ)

The Initiator shall send the ATR_REQ to the selected Target: CMD0

CMD1

Byte 0

…

Byte 9

Byte 10

Byte 11

Byte 12

Byte 13

Byte 14

...

Byte n

(D4)

(00)

nfcid3i0

…

nfcid3i9

DIDi

BSi

BRi

PPi

[Gi[0]]

...

[Gi[n]]

Figure 31 — Structure of the ATR_REQ

13.3.1.1.1 Definition of the ATR_REQ bytes CMD0: Shall be set to (D4). CMD1: 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 0 to Byte 9: 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.

Byte 10: DIDi The DIDi 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 are prohibited. Byte 11: BSi Bits 3 to 0 of the BSi byte shall indicate the send bit rates that the Initiator supports: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

DSi

Figure 32 — BSi byte -

bit 7 to bit 4: shall be set to ZERO, all other values are RFU

bit 3: DSi = 160 Mbps supported, shall be set to ZERO, RFU

bit 2: DSi = 80 Mbps supported, shall be set to ZERO, RFU

bit 1: DSi = 40 Mbps supported, shall be set to ZERO, RFU

bit 0: DSi = 20 Mbps supported, shall be set to ZERO, RFU 10 Mbps shall be supported – see Clause 8.

Byte 12: BRi Bits 3 to 0 of the BRi byte shall indicate the receive bit rates that the Initiator supports: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

DRi

Figure 33 — BRi byte -

bit 7 to bit 4: shall be set to ZERO, all other values are RFU

bit 3: DRi = 160 Mbps supported, shall be set to ZERO, RFU

bit 2: DRi = 80 Mbps supported, shall be set to ZERO, RFU

bit 1: DRi = 40 Mbps supported, shall be set to ZERO, RFU

bit 0: DRi = 20 Mbps supported, shall be set to ZERO, RFU 10 Mbps shall be supported – see Clause 8.

Byte13: PPi The PPi byte specifies optional parameters used by Initiator: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

SECi

RFU

LRi

RFU

NAD

Figure 34 — PPi byte -

bit 7: SECi. The Initiator shall set SECi to ONE if the Initiator supports the NFC-SEC extension; ZERO Indicates no support

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

bit 5 and bit 4: Length Reduction value: Table 10 — Definition of LRi LENMAX

LRi 00

Only Byte 0 to Byte 255 is valid in the Transport Data

Only Byte 0 to Byte 1023 is valid in the Transport Data

Only Byte 0 to Byte 4095 is valid in the Transport Data

Only Byte 0 to Byte 65535 is valid in the Transport Data

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

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

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

Byte 14 to Byte n: Gi[0] to Gi[n] The General bytes G[0] to Gi[n] 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. 13.3.1.2

Attribute Response (ATR_RES)

The selected MSIP-1 Target device shall send the ATR_RES within 10 ms after receiving the ATR_REQ: CMD0

CMD1

Byte 0

…

Byte 9

Byte 10

Byte 11

Byte 12

Byte 13

Byte 14

Byte 15

…

Byte n

(D5)

(01)

nfcid3t0

…

nfcid3t9

DIDt

BSt

BRt

PPt

Gt[0]

…

Gt[n]

Figure 35 — Structure of the ATR_RES

13.3.1.2.1 Definition of the ATR_RES bytes CMD0: Shall be set to (D5).

CMD1: 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 0 to Byte 9: NFCID3t The 10 nfcid3t bytes define the random identifier NCID3t of the Target. NFCID3 should be an ID generated by the application. Byte 10: DIDt The DIDt 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 are prohibited. For usage of DIDt, see 13.3.1.1.1. Byte 11: BSt Bit 3 to 0 of BSt indicate the supported transmit bit rate of the Target device: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

BSt

Figure 36 — BSt byte -

bit 7 to bit 4: Shall be set to ZERO

bit 3: BSt = 160 Mbps supported, shall be set to ZERO, RFU

bit 2: BSt = 80 Mbps supported, shall be set to ZERO, RFU

bit 1: BSt = 40 Mbps supported, shall be set to ZERO, RFU

bit 0: BSt = 20 Mbps supported, shall be set to ZERO, RFU 10 Mbps shall be supported – see Clause 8.

Byte 12: BRt Bit 3 to 0 of BRt shall indicate the supported receive bit rates of the Target device: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

BRt

Figure 37 — Coding of the BRt byte -

bit 7 to bit 4: Shall be set to ZERO

bit 3: BRt = 160 Mbps supported, shall be set to ZERO, RFU

bit 2: BRt = 80 Mbps supported, shall be set to ZERO, RFU

bit 1: BRt = 40 Mbps supported, shall be set to ZERO, RFU

bit 0: BRt = 20 Mbps supported, shall be set to ZERO, RFU 10 Mbps shall be supported – see Clause 8.

Byte 13: TO The TO byte shall specify the timeout value of the Target MSIP-1 device for the data transport protocol. The timeout calculation shall start with the last bit sent by the Initiator and stop with the first bit sent by the Target. The timeout is specified as follows: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

Figure 38 — TO byte -

bit 7 to bit 4: Shall be set to all ZEROs.

bit 3 to bit 0: WT: Waiting Time.

The Response Waiting Time (RWT) shall be calculated by the following formula: RWT = 302 × 2WT µs Where the value of WT shall be the range from 0 to 14 and the value of 15 is RFU. For WT = 0, RWT = RWTMIN (302 µs) For WT = 14, RWT = RWTMAX (4949 ms) Byte 14: PPt The PPt byte specifies optional parameters used by Target device: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

SECt

RFU

LRt

RFU

NAD

Figure 39 — PPt byte -

bit 7: SECt. The Target shall set SECt to ONE if the Target supports the NFC-SEC extension; ZERO Indicates no support.

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

bit 5 and bit 4: Length Reduction value: Table 11 — Definition of LRt LRt

LENMAX

Only Byte 0 to Byte 255 is valid in the Transport Data

Only Byte 0 to Byte 1023 is valid in the Transport Data

Only Byte 0 to Byte 4095 is valid in the Transport Data

Only Byte 0 to Byte 65535 is valid in the Transport Data

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

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

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

Byte 14 to Byte n: Gt[0] to Gt[n] Gt[0] to Gt[n] 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. 13.3.1.3

Handling of ATR_REQ and ATR_RES

13.3.1.3.1 Initiator rules After reception of a valid ATR_RES, the Initiator may check if the Target supports MSIP-1 extensions. In case such extensions match the Initiators capabilities it may chose to use MSIP-1 extensions. In any other case the Initiator may retransmit the ATR_ REQ before it uses the deactivation sequence as defined in 13.5. 13.3.1.3.2 Target rules When the Target: a) Receives a valid ATR_REQ, the Target -

shall send its ATR_RES,

shall ignore subsequent ATR_REQs if any other valid command has been received.

b) Receives any other valid or invalid frame the Target -

shall ignore the block and

shall remain in receive mode.

13.3.1.4

Handling of timeout TO

The handling of the timeout is different for active and passive communication mode. 13.3.1.4.1 Handling in active mode In active communication mode the protocol together with the Initiator switching the carrier on and off, handle the timeout behaviour. Initiator: The Initiator shall ignore a Target that exceeded RWT calculated using TO byte in ATR_RES from a Target device and continue operation. Target: The Target shall specify a TO value suitable for common communication and may specify a timeout extension to the RWT in a supervisory PDU, see 13.4.1.1.1. 13.3.1.4.2 Handling of timeout in passive mode In passive communication mode only the protocol handles timeout behaviour. Initiator: The Initiator shall first use error handling and if no response is received, it shall ignore Targets that exceeded the specified timeout and it shall continue communication. Target: The Target shall specify a TO value suitable for common communication and may specify a timeout extension to the RWT in a supervisory PDU, see 13.4.1.1.1.

13.3.1.5

Handling of DID

13.3.1.5.1 Handling of DID in active and in passive mode. When the Initiator has sent a ATR_REQ containing a DID equal to ZERO and a) received an ATR_ RES containing DID equal to ZERO -

shall send PDU’s containing no DID to the Target and

shall not activate any other Target while this Target is not deactivated.

b) received an ATR_RES containing DID not equal to ZERO -

shall continue with error handling.

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

shall send PDU’s containing the DID to the Target and

shall not use the DID for any other Targets and

shall not use DID=0 for any other Targets.

b) received an ATR_RES containing any other DID -

shall continue with error handling.

13.3.2 Wakeup Request and Response Commands The Wakeup Request and Response commands are only defined for the Active communication mode. 13.3.2.1

Wakeup Request (WUP_REQ)

This Clause defines 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. CMD0

CMD1

Byte 0

…

Byte 9

Byte 10

(D4)

(02)

nfcid3t0

…

nfcid3t9

DID

Figure 40 — Structure of the WUP_REQ

13.3.2.1.1 Definition of the WUP_REQ bytes CMD0: Shall be set to (D4). CMD1: 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 0 to Byte 9: 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 10: DID The DID byte shall be used for multiple data transport protocol activation with more than one Target. 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 are prohibited by this Standard. The Initiator may assign a different value to the Target, as used before the last DSL command. 13.3.2.2

Wakeup Response (WUP_RES)

This Clause defines 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 MSIP-1 Target device. CMD0 (D5)

CMD1 (03)

Byte 0 DID

Figure 41 — Structure of the WUP_RES

13.3.2.2.1 Definition of the WUP_RES bytes CMD0: Shall be set to (D5). CMD1: WUP_RES The WUP_RES byte shall specify the response to the WUP_REQ. The value of WUP_RES shall be (03). Byte 0: 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 are prohibited by this Standard. 13.3.2.3

Handling of WUP_REQ and WUP_RES

13.3.2.3.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 at least once before it shall use the deactivation sequence as defined in 14.7. 13.3.2.3.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 ignore any subsequent WUP_REQ.

b) receives any other valid or invalid frame, the Target -

shall ignore the block and

shall remain in receive mode.

13.3.3 Parameter Selection Request and Response Commands 13.3.3.1

Parameter Selection Request (PSL_REQ)

The Initiator may switch parameters for the subsequent transport protocol using the PSL_REQ command. CMD0

CMD1

Byte 0

Byte 1

Byte 2

(D4)

(04)

DID

BRS

FSL

Figure 42 — Structure of the PSL_REQ

13.3.3.1.1 Definition of the PSL_REQ bytes CMD0: Shall be set to (D4). CMD1: 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 0: DID The DID shall be similar to the DID defined during ATR or WUP. Byte 1: BRS The BRS byte shall specify the selected bit rates for Initiator and Target device. bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

DSI

DRI

Figure 43 — Coding of the BRS byte -

bit 7 and bit 6: Shall be set to ZERO.

bit 5 to bit 3: Bit duration of Initiator to Target.

bit 2 to bit 0: Bit duration of Target to Initiator.

Table 12 — Coding of DRI and DSI DRI and DSI

Bit Rate

000

20 Mbps

001

40 Mbps

010

80 Mbps

011

160 Mbps

100

RFU

101

RFU

110

RFU

111

RFU

Byte 2: FSL The FSL byte defines the maximum value for the Frame Length. bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

Figure 44 — Coding of FSL bytes -

bit 7 to bit 2: Shall be set to all ZERO.

bit 1 and bit 0: Length Reduction value. Table 13 — Definition of LR LENMAX

13.3.3.2

Only Byte 0 to Byte 255 is valid in the Transport Data

Only Byte 0 to Byte 1023 is valid in the Transport Data

Only Byte 0 to Byte 4095 is valid in the Transport Data

Only Byte 0 to Byte 65535 is valid in the Transport Data

Parameter Selection Response (PSL_RES)

The definition of the frame structure of PSL_RES shall be as follows. CMD0

CMD1

Byte 0

(D5)

(05)

DID

Figure 45 — Structure of PSL_RES The target shall send the PSL_RES within 1000 ms. 13.3.3.2.1 Definition of the PSL_RES bytes CMD0: Shall be set to (D5).

CMD1: 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 0: DID The DID shall be the same as the DID defined during ATR or WUP. 13.3.3.3

Handling of PSL_REQ and PSL_RES

13.3.3.3.1 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 13.1 and

shall continue with operation.

In any other case the Initiator may retransmit the PSL_REQ before it shall use the deactivation sequence as defined in 13.5. 13.3.3.3.2 Target rules When the Target has received a 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 13.3.3 and

shall remain in receive mode.

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

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

13.4 Data Exchange Protocol 13.4.1 Data Exchange Protocol Request and Response 13.4.1.1

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

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 Format of the protocol frame shall be as follows: Transport Data field CMD0

CMD1

Byte 0

Byte 1

Byte 2

DID

NAD

Byte 3

Byte 4

…

Byte n

…

Data byte n

Data Exchange Protocol Header CMD0

CMD1

PFB

Transport data bytes Data byte 0

Data byte 1

Figure 46 — Definition of the protocol frames In information interchange, the content of the payload of the Transport Data Field requires agreement between the interchanging parties. 13.4.1.1.1 Definition of the Data Exchange Protocol Header bytes CMD0: If the CMD1 is DEP_REQ then the CMD0 shall be set to (D4). If the CMD1 is DEP_RES then the CMD0 shall be set to (D5). CMD1: 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). CMD1: 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 0: 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 three fundamental types of PDU’s: -

Information PDU’s to convey information for the application layer.

NFC-SEC PDUs to convey protected information for the application layer.

Acknowledge PDU’s to convey positive or negative acknowledgements. An Acknowledge PDU never contains a data field. The acknowledgement relates to the last received block.

Supervisory PDU’s to exchange control information between the Initiator and the Target. Two types of supervisory PDU’s are defined. -

Timeout extensions containing a 1 byte long data field.

Attention containing no data field.

The coding of PFB depends on its type and is defined in the following definitions. Table 14 — Coding of the PFB bits 7 to 5 bit 7

bit 6

bit 5

PFB

Information PDU

NFC-SEC PDU

Acknowledge PDU

Supervisory PDU

Other settings are RFU

Definition of the Information PDU: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

NAD

DID

PNI

Figure 47 — Coding of the information PDU -

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

bit 4: If bit set to ONE then it indicates Multiple Information chaining activated.

bit 3: If bit set to ONE then it indicates NAD available.

bit 2: If bit set to ONE then it indicates DID available.

bit 1 and bit 0: PNI packet number information.

The Packet Number Information (PNI) counts the number of packet send by the Initiator to the Target and vice versa starting by 0. These bytes are used for error detection during the protocol handling. Definition of the NFC-SEC PDU: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

ONE

NAD

DID

PNI

Figure 48 — Coding of the NFC-SEC PDU -

bit 7 to bit 6: Shall be set to all ZEROs. The Target shall ignore it.

Bit 5: Shall be set to ONE.

bit 4: If bit set to ONE then it indicates Multiple Information chaining activated.

bit 3: If bit set to ONE then it indicates NAD available.

bit 2: If bit set to ONE then it indicates DID available.

bit 1 and bit 0: 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 at 0. These bytes are used for error detection during the protocol handling. Definition of Acknowledge PDU: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

ONE

ZERO

Acknowledge

NAD

DID

PNI

Figure 49 — Coding of the Acknowledge PDU -

bit 7: Shall be set to ZERO.

bit 6: Shall be set to ONE.

bit 5: Shall be set to ZERO.

bit 4: If bit set to ONE then it indicates NACK, otherwise ACK.

bit 3: If bit set to ONE then it indicates NAD available.

bit 2: If bit set to ONE then it indicates DID available.

bit 1 and b0: PNI packet number. Definition of the Supervisory PDU (Attention-Target Present, Timeout extensions): bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ONE

ZERO

Attention/ Timeout

NAD

DID

ZERO

Figure 50 — Coding of the supervisory PDU -

bit 7: Shall be set to ONE.

bit 6 and bit 5: shall be set to ZERO.

bit 4: If ATTENTION then set to ZERO. If TIME–OUT_EXTENTION then set to ONE.

bit 3: If bit set to ONE then it indicates NAD available.

bit 2: If bit set to ONE then it indicates DID available.

bit 1 and b0: Shall be set to ZERO.

Byte 1: DID The DID byte shall be the same as defined during activation of the protocol. Byte 2: NAD The NAD byte is reserved to build up and address different logical connections on both the Initiator and the Target device. Bit 7 to bit 4 code the logical address of the Initiator, bits 3 to 0 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 3 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. 13.4.1.2

Handling of Pdu number information

13.4.1.2.1 Initiator rules The PNI of the Initiator shall be initialized for each Target with all ZEROs. When an Information, NFC-SEC or Acknowledge PDU with an equal PNI is received, the Initiator shall increment the current PNI for that Target before optionally sending a new frame. 13.4.1.2.2 Target rules The PNI of the Target shall be initialized with all ZEROs. When an information, NFC-SEC or Acknowledge PDU with an equal PNI was received the Target shall send its response with this PNI and shall increment the PNI afterwards. 13.4.1.3

Handling of Blocks

13.4.1.3.1 General rules The first PDU shall be sent by the Initiator. When an Information or NFC-SEC PDU indicating more information is received the PDU shall be acknowledged by an Acknowledge PDU (ACK). Supervisory PDUs are only used in pairs. A Supervisory Request shall always be followed by a Supervisory Response. 13.4.1.3.2 Initiator rules When an invalid PDU is received an Acknowledge PDU (NACK) shall be sent (except in the case of DSL or RLS). When a timeout occurs, an attention command shall be sent (except a NACK has been sent before). When a timeout occurs and a NACK has been sent before, the NACK shall be retransmitted. When an Acknowledge 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.

13.4.1.3.3 Target rules The Target is allowed to send a Supervisory PDU (RTO) instead of an Information PDU. When a, information or NFC-SEC PDU not containing chaining is received it shall be acknowledged by an information or NFC-SEC PDU. When an Acknowledge PDU (NACK) 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 same State. When a Supervisory PDU coding an attention command is received, the Target shall respond sending a supervisory attention PDU response. 13.4.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 RWT, it shall use a supervisory PDU using response timeout extension request. A response timeout extension request contains 1 byte long data field. The definition of the byte is shown in Figure 51. Bit 7

Bit 6

bit 5

Bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

RTOX

Figure 51 — Coding of Response timeout extension byte -

bit 7 and bit 6: Shall be set to ZERO.

bit 5 to bit 0: RTOX value.

For RTOX the values 0 and 60 to 63 are RFU. For all other values the intermediate RWTINT shall be calculated by the following formula: RWTINT = RWT × RTOX The RWTINT starts after the Initiator has sent its RTOX response to the Target. In case RWTINT exceeds RWTMAX, RWTMAX shall be used. The RWTINT is valid until the next frame has been received by the Initiator. 13.4.3 Attention – Target present The Initiator shall send the attention command to the Target to ensure the Target is still in field for passive 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 sending an attention command 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. 13.4.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. 13.4.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 15. The Initiator needs to handle a separate package number information for each activated Target. Table 15 — Multi Activation Initiator Action

Status Target 1

Status Target 2

Status Target 3

Choose active 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 …

13.4.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 52 using a 16 bytes long string transmitted in three blocks.

Send

0123456

PFB (10)

789A BC

PFB (11)

0123456 EDC

PFB (40)

Receive

DEF

Answer

789A BC EDC

PFB (41)

EDC

789A BC

DEF

EDC

PFB (02)

Answer

EDC

S(ACK) 1

S(ACK) 0

0123456

PFB (02)

DEF

Answer

Receive

Send

Figure 52 — More Information (Chaining)

13.5 Deactivation of the protocol When the protocol is activated (see 14.5), 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. After successful deactivation the Target shall not respond to subsequent ATR_REQ commands. The RLS_REQ command shall switch the Target back to its power-on reset condition as exists at the start of initialisation and device detection. See 11.3. In this state, the Target shall answer to all initial communication schemes. 13.5.1 Deselect Request and Response command 13.5.1.1

Deselect request (DSL_REQ)

This Clause defines the deselect command DSL_REQ. The DSL_REQ is sent from Initiator to the Target. CMD0

CMD1

Byte 0

(D4)

(08)

DID

Figure 53 — Structure of the DSL_REQ 13.5.1.1.1 Definition of DSL_REQ bytes CMD0: Shall be set to (D4).

CMD1: DSL_REQ The DSL_REQ byte specifies the command deselect for the Initiator device. The value of DSL_REQ shall be (08). Byte 0: DID The DID shall be the same as defined during ATR or WUP commands. 13.5.1.2

Deselect response (DSL_RES)

This Clause defines 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. CMD0

CMD1

Byte 0

(D5)

(09)

DID

Figure 54 — Structure of the DSL_RES

13.5.1.2.1 Definition of Deselect Response bytes CMD0: Shall be set to (D5). CMD1: DSL_RES The DSL_RES byte specifies the command deselect response for the Target device. The value of DSL_RES shall be (09). Byte 0: DID The DID shall be the same as in DSL_REQ. 13.5.1.3

Handling of DSL_REQ and DSL_RES

13.5.1.3.1 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. 13.5.1.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 remain in receive mode until a valid ALL_REQ is received in Passive communication mode or a WUP_REQ is received in active communication mode.

13.5.2 Release Request and Response commands 13.5.2.1

Release Request (RLS_REQ)

This Clause defines the release command RLS_REQ. The RLS_REQ is sent from the Initiator to the Target.

CMD0

CMD1

Byte 0

(D4)

(0A)

DID

Figure 55 — Structure of RLS_REQ

13.5.2.1.1 Definition of RLS_REQ bytes CMD0: Shall be set to (D4). CMD1: 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 0: DID The DID shall be the same as defined in ATR or WUP commands. 13.5.2.2

Release response RLS_RES

This Clause defines the answer to release command the release response command RLS_RES. The RLS_RES is the response to the RLS_REQ sent from the Target to the Initiator. CMD0

CMD1

Byte 0

(D5)

(0B)

DID

Figure 56 — Structure of RLS_RES

13.5.2.2.1 Definition of RLS_RES bytes CMD0: Shall be set to (D5). CMD1: 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 0: DID The DID shall be the same as defined in RLS_REQ command. 13.5.2.3

Handling of RLS_REQ and RLS_RES

13.5.2.3.1 Initiator rules When the Initiator has sent a RLS_REQ and received a valid RLS_RES, the Target has been successfully released. The Initiator may return to its initial state. 13.5.2.3.2 Target rules When the Target has received a RLS_REQ and sent its RLS_RES, the Target shall return to its initial state.

14 Direct Addressing Protocol In Direct Addressing Protocol, an Initiator may write and read data directly to memory in a Target device. CMD_EX in the HEADER is used to specify the starting address of a transaction, and number of bytes to be transferred. CMD3 in the HEADER is used to specify the type of transaction being undertaken. For Targets, if Direct Addressing Protocol is supported, then the Read command shall be supported; all other commands are optional. Initiators shall support all commands specified in 14. The Direct Addressing Protocol capabilities of a Target shall be encoded as described in 14.11.

14.1 Read (CMD3=0x00) Purpose: Read one or more bytes from target starting from location ‘Addr’. 14.1.1 Initiator command SOF Preamble

Value

HEADER SYNC

CHAN

SOC

CMD3

CMD_EX

CRCH

16 bit

4 bit

12 bit

8 bit

48 bit

32 bit

See initiator standard frame format

0x00

ADDR

LEN

32 bit

16 bit

Addr

N bytes

CRC

Figure 57 — Initiator to target ‘Read’ frame format Preamble is PRE0, PRE1 for Passive communication mode command, PRE2 for Active communication mode •

CMD3: This value shall be 0x00.

•

ADDR: Target’s start address from which data is to be read from.

•

LEN: Length N of data to be read in byte units (8 bits).

•

CRCH: CRC of CHAN, SOC, CMD3, ADDR and LEN fields concatenated together.

14.1.2 Target response Preamble

Value

SYNC

CMD3

PLDT

CRCT

16 bit

8 bit

(N x 8 bit)

32 bit

0x00

Data

CRC

See target standard frame format

Figure 58 — Read from target response frame format •

CMD3: Response field. This value shall be 0x00.

•

PLDT: Payload. This field contains the requested data of length N, with LSB first.

•

CRCT: CRC of CMD3 and PLDT fields.

14.2 Write (CMD3=0x01) Purpose: Write one or more bytes to target starting from location ‘addr’. Support for this command in a Target is indicated by the MEM_DATA parameter as described in 15.4.14. 14.2.1 Initiator command SOF Preamble

Value

HEADER

PAYLOAD

SYNC

CHAN

SOC

CMD3

CMD_EX

CRCH

PLD

CRCP

16 bit

4 bit

12 bit

8 bit

48 bit

32 bit

(N x 8 bit)

32 bit

CRC

Data

CRC

See initiator standard frame format

0x01

ADDR

LEN

32 bit

16 bit

Addr

N bytes

Figure 59 — Initiator to target ’Write’ frame format Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode •

CMD3: This value shall be 0x01.

•

ADDR: Target’s start address Addr, to which data is to be written.

•

LEN: Length (N) of data to write in bytes units (8 bits).

•

CRCH: CRC of CHAN,SOC,CMD3,ADDR,LEN fields.

•

PLD: Data to write of length (N) bytes, with LSB first.

•

CRCP: CRC of PLD field.

14.2.2 Target response The Target shall respond with an Acknowledgement frame (ACK) if the data is successfully written to memory. See 14.9. The Target shall respond with a Negative Acknowledgement frame (NACK) if the data is not successfully written to memory. See 14.10.

14.3 WriteSync (CMD3=0x02) Purpose: Write one or more bytes to target starting from location ‘addr’, using SyncFlash algorithm. Support for this command in a Target is indicated by the MEM_DATA parameter as described in 15.4.14.

14.3.1 Initiator command SOF Preamble

Value

HEADER SYNC

CHAN

SOC

CMD3

16 bit

4 bit

12 bit

8 bit

See initiator standard frame format

0x02

PAYLOAD CMD_EX

ADDR

LEN

32 bit

16 bit

Addr

CRCH

PLD1

CRC1

PAD

PLD2

CRC2

PAD

PLDn

CRCn

PAD

32 bit

8 bit

32 bit

P bit

8 bit

32 bit

P bit

8 bit

32 bit

P bit

Datan

CRCn

…… CRC

Data

CRC

Data1

CRC1

bytes

Figure 60 — Initiator to target ’WriteSync’ frame format Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode •

CMD3: This value shall be 0x02.

•

ADDR: Target’s start address, Addr, to which data is to be written.

•

LEN: Length (N) of data to write in bytes units (8 bits).

•

CRCH: CRC of CHAN, SOC, CMD3, ADDR, and LEN fields concatenated together.

•

PLD1: 1st (LSB) data byte of payload.

•

CRC1: CRC of 1st data byte.

•

PLD2: 2nd data byte of payload.

•

CRC2: CRC of 2nd data byte.

•

PLDn: nth data byte of payload.

•

CRCn: CRC of nth data byte.

•

PAD: Padding. The size of this field shall be determined by the following formula: Size, P = (STRT*PDSTRT + PDDATA + CROSS*PDRX + END*PDEND.) x 8 bits. o

PDSTRT, PDDATA, PDRX, PDEND shall be obtained from the Target Common Control Parameters (TCCP), see 15.4.

STRT: This shall be 1 for the 1st byte and shall be 0 for subsequent bytes.

CROSS: This shall be 1 if the address crosses a row boundary and shall be 0 otherwise. This field shall be set to 0 if the physical memory architecture is not of row configuration type. The value of CROSS is determined by the following formula: CROSS = 1 if Address written = (N x RowSz)+1 (N is an integer) else CROSS =0 The Row Size shall be obtained from the Row Size parameter (see 15.4.4).

END: This shall be 1 for the last byte and shall be 0 for all other bytes.

The value of the PAD data is not defined, and is at the implementer’s discretion. 14.3.2 Target response The Target shall respond with an Acknowledgement frame (ACK) if the data is successfully written to memory. See 14.9. The Target shall respond with a Negative Acknowledgement frame (NACK) if the data is not successfully written to memory. See 14.10.

14.4 PageErase (CMD3=0x03) Purpose: Initialise one page of target’s memory. Support for this command in a Target is indicated by the MEM_DATA parameter as described in 15.4.14. This operation only applies to target with Flash/EEPROM based memory. This operation shall have no effect on “RAM type” memory, use ‘Write’ operation to overwrite contents for “RAM type” memory. The initialised value may be logical ‘1’ or logical ‘0’ and is dependent on the target memory technology. 14.4.1 Initiator command SOF Preamble

Value

HEADER SYNC

CHAN

SOC

CMD3

16 bit

4 bit

12 bit

8 bit

See initiator standard frame format

0x03

PAYLOAD CMD_EX

ADDR

32 bit

16 bit

Addr

0x0032

CRCH

PAD

32 bit

PDPERASE x 8 bit

CRC

Figure 61 — Initiator to target ’PageErase’ frame format Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode •

CMD3: This value shall be 0x03.

•

ADDR: Target’s page to erase. The target shall erase the entire page that contains this address. For example, if the target page size is 256 bytes, erasing address 0x102H and 0x14FH shall mean the same thing: i.e. the target shall erase page 1.

•

ID: This value shall be 0x0032.

•

CRCH: CRC of CHAN, SOC, CMD3, ADDR, and LEN fields concatenated together.

•

PAD: End-of-frame padding. This shall be PDPERASE x 8 bits (see 15.4.12). The target shall ignore the contents of this field. The value of the PAD data is not defined, and is at the implementer’s discretion.

14.4.2 Target response The Target shall respond with an Acknowledgement frame (ACK) if the data is successfully written to memory. See 14.9. The Target shall respond with a Negative Acknowledgement frame (NACK) if the data is not successfully written to memory. See 14.10.

14.5 MassErase (CMD3=0x08) Purpose: Initialise entire target’s memory. Support for this command in a Target is indicated by the MEM_DATA parameter as described in 15.4.14. This operation only applies to targets with Flash/EEPROM based memory. This operation shall have no effect on “RAM type” memory, use ‘Write’ operation to overwrite contents for “RAM type” memory. The initialised value may be logical ‘1’ or logical ‘0’ and is dependent on the target memory technology. 14.5.1 Initiator command SOF Preamble

HEADER

PAYLOAD

SYNC

CHAN

SOC

CMD3

CMD_EX

CRCH

PAD

16 bit

4 bit

12 bit

8 bit

MASSERASEID

32 bit

PDMERASE x 8 bit

CRC

48 bit Value

See initiator standard frame format

0x08

0x0000025F0032

Figure 62 — Initiator to target ’MassErase’ frame format Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode •

CMD3: This field shall be of value 0x08H.

•

MASSERASEID: 0x0000025F0032.

•

CRCH: CRC of CHAN, SOC, CMD3, and CMD_EX fields concatenated together.

•

PAD: End of frame padding. This shall be PDMERASE x 8 bits (see 15.4.13). The target shall ignore the contents of this field. The value of the PAD data is not defined, and is at the implementer’s discretion.

14.5.2 Target response The Target shall respond with an Acknowledgement frame (ACK) if the data is successfully written to memory. See 14.9. The Target shall respond with a Negative Acknowledgement frame (NACK) if the data is not successfully written to memory. See 14.10.

14.6 Authenticate (CMD3=0x04) Purpose: Authenticate target’s (k) key, where (k) is 0 to 15. Support for this command in a Target is indicated by the MEM_DATA parameter as described in 15.4.14. The target shall respond with a 180 bit SHA-1 message digest of the augmented challenge and secret key (k).

14.6.1 Initiator command SOF Preamble

Value

HEADER

PAYLOAD

SYNC

CHAN

SOC

CMD3

CMD_EX

CRCH

CHA

16 bit

4 bit

12 bit

8 bit

48 bit

32 bit

216 bit

CRC

See initiator standard frame format

0x04

AID0

KEY

REV

AID1

23 bit

4 bit

5 bit

16 bit

0x1

0x0

0x20

PAD

Figure 63 — Initiator to Target broadcast ‘Authenticate’ frame Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode NOTE

# denotes operational dependent values.

•

CMD3: This value shall be 0x04.

•

AID0: Authentication ID0. This field shall be 23 bit. The value shall be 0x1.

•

KEY: Authentication Key. This field indicates which key to authenticate and shall be 4 bits.

•

REV: This field is reserved and shall be 0x0.

•

AID1: Authentication ID1. This field shall be 16 bit. The value shall be 0x20.

•

CRCH: CRC of CHAN, SOC, CMD3, and CMD_EX fields concatenated together.

•

CHA: Challenge. This field shall be 216 bit. The target shall use this field as a challenge key.

•

PAD: End of frame padding. This field shall be 8 x AUTH_PAD (see 0) bits long. The target shall ignore the contents of this field. The value of the PAD data is not defined, and is at the implementer’s discretion.

14.6.2 Target response Preamble

Value

SYNC

CMD3

DIGST

16 bit

8 bit

(180 bit)

0x05

Data

See target standard frame format

Figure 64 — Authenticate response frame format •

CMD3: Response field. This value shall be 0x05.

•

DIGST: 180 bit SHA1 message digest of augmented challenge and secret key (k).

14.7 ReportID (CMD3=0xFE) Purpose: Retrieve target’s ChannelID and SocketID value on channel (c). This frame is usually used for target enumeration and isolation.

14.7.1 Initiator Command SOF Preamble

Value

HEADER SYNC

CHAN

SOCK

CMD3

CMD_EX

CRCH

16 bits

4 bits

12 bit

8 bits

48 bit

32 bit

See initiator standard frame format

chan

0xFE

ADDR

LEN

32 bit

16 bit

0x00000100

0x2

CRC

Figure 65 — Initiator to Target broadcast ‘ReportID’ frame Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode •

CHAN: Channel number, chan, this frame is applied to. Valid values are 0 through 14. The target shall respond to a ‘ReportID’ frame if this field matches it own ChannelID field.

•

SOCK: This field shall be 12 bit. The target shall ignore this field. The value of the SOCK data is not defined, and is at the implementer’s discretion.

•

CMD3: This value shall be 0xFE (Report ID opcode).

•

ADDR: This value shall be 0x00000100. (ID parameter location).

•

LEN: This value shall be 0x02.

•

CRCH: CRC of fields CHAN, SOCK, CMD3, ADDR, and LEN concatenated together.

14.7.2 Target Response SYNC

CMD3

CHAN

SOCK

CRCT

16 bits

8 bits

4 bits

12 bits

32 bits

See target standard frame format

0xFE

chan

sock

CRC

Preamble

Value

Figure 66 — ReportID response frame format •

CMD3: This value shall be 0xFE.

•

CHAN: This value shall be the target’s ChannelID equal to the ID parameter.

•

SOCK: This value shall be the target’s SocketID equal to the ID parameter.

•

CRCT: CRC of fields CMD3, CHAN, and SOCK concatenated together.

14.8 ResetID (CMD3=0xFF) Purpose: Reset target’s ChannelID and SocketID value on channel (c). This frame is usually used for target enumeration and isolation.

14.8.1 Initiator Command SOF Preamble

HEADER SYNC

CHAN

SOCK

CMD3

CMD_EX

CRCH

16 bits

4 bits

12 bit

8 bits

48 bit

32 bit

8 bit

Value

See initiator standard frame format

chan

4 bit

0xFF

ADDR

LEN

32 bit

16 bit

0x00000100

0x0

CRC

Figure 67 — Initiator to Target ‘ResetID’ frame NOTE 1

Preamble is PRE0, PRE1 for Passive communication mode, PRE2 for Active communication mode

NOTE 2

x denotes any arbitrary values.

•

CHAN: Channel number this frame is applied to. Valid values are 0 though 15. Channel 15 shall be the broadcast channel. All targets shall respond to a ‘ResetID’ frame if (c) matches its ChannelID or if (c) is 0xFF (broadcast channel).

•

SOCK: The initiator shall specify the number of channels (N) available for this session. The value shall range from 1 through 13, all other values shall be invalid. The target shall ignore the 8 most significant bits.

•

CMD3: This value shall be 0xFFH (ResetID opcode).

•

ADDR: This value shall be 0x00000100H.

•

LEN: This value shall be 0x00H to indicate that no payload data is to follow.

•

CRCH: CRC of fields CHAN, SOCK, CMD3, ADDR, and LEN concatenated together.

14.8.2 Target Response Preamble

Value

SYNC

CMD3

CHAN

SOCK

CRCT

16 bits

8 bits

4 bits

12 bits

32 bits

See target standard frame format

0xFE

chan

sock

CRC

Figure 68 — ResetID response frame format NOTE

# denotes operational dependent values.

•

CMD3: This value shall be 0xFE (8 bits)

•

CHAN: This value shall be the target’s ChannelID equal to the ID parameter.

•

SOCK: This value shall be the target’s SocketID equal to the ID parameter.

•

CRCT: CRC of fields CMD3, CHAN, and SOCK fields concatenated together.

14.9 Acknowledgement – ACK (CMD3 = 0x06) Preamble

Value

SYNC

CMD3

CRCT

8 bit

32 bit

0x06

0xA26909D1

See target standard frame format

Figure 69 — ACK response frame format

14.10 Negative Acknowledgement – NAK (CMD3 = 0x15)

Preamble

Value

SYNC

CMD3

CRCT

8 bit

32 bit

0x15

0xE33bF478

See target standard frame format

Figure 70 — NACK response frame format

14.11 Device Management Attributes of a device shall be discovered by reading defined parameters to retrieve the version # of the MSIP-1 specification being supported, the send and receive data rates of the device, and the maximum frame lengths supported. 14.11.1

Attribute Discovery

14.11.1.1 Protocol This parameter indicates the supported protocols of the device. The PROTOCOL byte shall be encoded as below: Bit 0 = 1 if Direct Addressing Protocol is supported when operating as a Target. Bit 1 = 1 if MSIP-1 Protocol is supported when operating as a Target. 14.11.1.2 VER_PHY This parameter indicates the version number of the specification supported by this device. For version 1 of the specification the encoding of VER_PHY is as follows: Bit 7 0

Bit 6 0

Bit 5 0

Bit 4 0

Bit 3 0

Bit 2 0

Bit 1 0

Bit 0 1

Figure 71 — Coding of the VER_PHY byte

14.11.1.3 BSt, BRt This parameter indicates the data rates supported by the device when operating as a Target. The coding of bits is as follows: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

BSt

BRt

Figure 72 — Coding of the BSt, BRt byte -

bit 7: BSt = 160 Mbps sending supported, shall be set to ZERO, RFU

bit 6: BSt = 80 Mbps sending supported, shall be set to ZERO, RFU

bit 5: BSt = 40 Mbps sending supported, shall be set to ZERO, RFU

bit 4: BSt = 20 Mbps sending supported, shall be set to ZERO, RFU

bit 3: BRt = 160 Mbps receiving supported, shall be set to ZERO, RFU

bit 2: BRt = 80 Mbps receiving supported, shall be set to ZERO, RFU

bit 1: BRt = 40 Mbps receiving supported, shall be set to ZERO, RFU

bit 0: BRt = 20 Mbps receiving supported, shall be set to ZERO, RFU

If the device does not support Direct Addressing Protocol functionality then the BSt, BRt byte is set to 0x00. 14.11.1.4 LRt This parameter indicates the maximum frame lengths supported by the device when operating as a Target. The coding of bits shall be as follows: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

ZERO

LRt

Figure 73 — Coding of the LRt byte -

bit 7, 6, 5, 4, 3 and 2: Shall be set to ZERO.

bit 1 and bit 0: Length Reduction value when acting as a Target. LRt

LENMAX

Only Byte 0 to Byte 255 is valid in the PAYLOAD

Only Byte 0 to Byte 1023 is valid in the PAYLOAD

Only Byte 0 to Byte 4095 is valid in the PAYLOAD

Only Byte 0 to Byte 65535 is valid in the PAYLOAD

Figure 74 — LRt coding for LENMAX

14.11.2

Parameter Selection

The PSL parameter (15.4.18) is used to instruct the Direct Addressing Protocol device to use selected data rates for sending and receiving data. Setting this parameter using the WRITE command (see 14.2) is used to execute this parameter selection. 14.11.2.1 Data Rate The PSL parameter is encoded as follows: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

RFU

BRt

RFU

BSt

Figure 75 — Coding of the PSL Parameter -

bit 1 and bit 0: Target Sending Data Rate: BSt

Data Rate

10 Mbps

20 Mbps

40 Mbps

80 Mbps

Figure 76 — BSt Data Rate coding -

bit 4 and bit 3: Target Receiving Data Rate: BRt

Data Rate

10 Mbps

20 Mbps

40 Mbps

80 Mbps

Figure 77 — BRt Data Rate coding -

bit 2: Shall be set to ZERO

bit 7, 6, 5: Shall be set to ZERO.

15 Target Fixed Internal Map 15.1 Map The addresses in the map below shall identify references to parameter data that describes the capabilities and configuration of the device. Implementation is not required in the form of this map.

Offset 7 Address

Offset 6

Offset 5

Offset 4

Offset 3

Offset 2

Offset 1

(MSB)

Offset 0 (LSB)

R/W Memory

0xFFFFFFFF 0x00000400

Secret Key 15 (240 bits)

0x000003FD

Write only Memory (WOM)

0x000003E0

Secret Key 1 (240 bits)

0x0000023D 0x00000220

Secret key 0 (240 bits)

0x0000021D 0x00000200 0x00000107

Reserved

PSL Parameter

ID Parameter

0x00000100 0x00000037

Reserved

ChkSum2 (Check sum)

AUTH_PAD

MEM_DATA

0x00000030 (mass erase padding)

PDPERASE

PDEND

PDRX

PDDATA

(page erase padding)

(last byte padding)

(Row crossing padding)

(Data byte padding)

(1st byte padding)

VER_MEM

UTHID

0x00000027

ChkSum1

PgSz

RowSz

UsrStrtPg

0x0000001F

(Check sum)

(Memory Size)

(Page Size)

(Row size)

(Start of (version) user’s page)

0x0000001F

ChkSum0

Reserved

0x00000018

(Check sum)

LRi, LRt

BSt, BRt

BSi, BRi

Max frame length

Target Data Rates

Initiator Data (version) Rates

VER_PHY

PDSTRT

TCCP

PDMERASE

0x00000028

( Tag Format ID) PROTOCOL Direct Addressing and/or MSIP1

DCCP

0x0000002F

PDID

0x00000017 0x00000008

Reserved

0x00000007 0x00000000

Figure 78 — Address Map

15.2 Physical Device Identifier (PDID) This field consists of 128 bits. The PDID shall be supported in devices supporting Direct Addressing protocol. The PDID may be read by performing a Read command (14.1) with ADDR = 0x0000008 and LEN = 8.

15.3 Device Common Control Parameters (DCCP) The Device Common Control Parameters allow for efficient checking of the basic characteristics of the device. See 14.11.1. The DCCP shall be supported in devices supporting Direct Addressing protocol.

15.4 Target Common Control Parameters (TCCP) The Target Common Control Parameters allow for quick host checking and control of the target’s on a per target basis. The bits in the TCCP are mixed Read/Write and read only. All reserved for future use bits (RFU) shall be read-only and return a value of 0. All writeable bits are set to 0 after power-up or reset. Access to the TCCP is possible at any time. The TCCP shall be supported in devices supporting the Direct Addressing protocol. Each parameter may be read by performing a Read command (14.1) with the Read command's ADDR field equal to the Location value indicated in each of the following clauses and with the Read command's LEN field equal to the byte length of the parameter being read. 15.4.1 Universal Target Header Identity (UTHID) – Location 0x00000018 This is a 1-byte field that identifies this memory system as conforming to the MSIP-1 UTH format. This field shall be populated with the value 0x46H. 15.4.2 Universal Target Header Version (VER) – Location 0x00000019 This is a 1-byte field that indicates the version of UTH. Its value shall be 0x01 (version 1.0). 15.4.3 User Start Page (usrStrtPg) – Location 0x0000001A This is a 1-byte field that specifies the page number of the first usable page in the target’s memory. 15.4.4 Row Size (RowSz) – Location 0x0000001B This is a 1-byte field that specifies the length of the row used in the memory. The Row Length = 2RowSz 15.4.5 Page Size (PgSz) – Location 0x0000001C This is a 1-byte field that specifies the page size of the memory technology. This value is expressed as a binary multiple using the following formula: Absolute size of page (bytes) = 2PgSz For example: A 256 bytes page size memory technology would have a value of 0x8H as the pageSize. A 2048 bytes page size memory technology would have a value of 0xBH as the pageSize. If pageSize = 0 then this means that the absolute size of the page is a single byte, indicating that RAM-type memory is used. 15.4.6 size (Sz) – Location 0x0000001D This is a 1-byte field that specifies the total size of the device. This value is expressed as binary multiples using the following formula Absolute memory size (bytes) =2Sz For example: A 32,768 bytes memory size shall have a value of 0xFH as the size. A 524,288 bytes memory size shall have a value of 0x13H as the size.

15.4.7 ChkSum1– Location 0x0000001E This is a one’s complement value of, UsrStartPage, PageSize, Size. This checksum ensures these fields are not corrupted. An example of how this value is computed is as follows: If Offset 14,15,16,17 is given 0xF5H,0xF4H,0xF3H,0xF2H

0x0AH,0x0BH,0x0CH,0x0DH,

Offset

18,19,20,21

shall

15.4.8 PDSTRT– Location 0x00000020 See 14.3.1. 15.4.9 PDDATA– Location 0x00000021 See 14.3.1. 15.4.10

PDRX– Location 0x00000022

See 14.3.1. 15.4.11

PDEND– Location 0x00000023

See 14.3.1. 15.4.12

PDPERASE– Location 0x00000024

See 14.4.1. 15.4.13

PDMERASE– Location 0x00000026

See 14.5.1. 15.4.14

MEM_DATA– Location 0x00000028

The supported capabilities of the memory starting at the address given in usrStrtPage and addressable using the Direct Addressing protocol is given by the MEM_DATA parameter: The MEM_DATA parameter is encoded as follows: bit 7

bit 6

bit 5

bit 4

bit 3

bit 2

bit 1

bit 0

RFU

Wr1

Wr0

Figure 79 — Coding of the MEM_DATA Parameter -

bit 4: Authentication supported, if bit is set to ONE

bit 3: Mass Erase supported, if bit is set to ONE

bit 2: Page Erase supported, if bit is set to ONE

bit 1 and bit 0: Write Capability:

Wr1,0

Meaning

Write is NOT supported

Only Write CMD3=0x01 supported

Only WriteSync CMD3=0x02 supported

Write CMD3=0x01 and WriteSync CMD3=0x02 supported

Figure 80 — Write Capability

15.4.15

AUTH_PAD– Location 0x00000029

16 bit value that defines the number of padding bytes used during the Authenticate command. 15.4.16

ChkSum2– Location 0x0000002B

This is a one’s complement value of, PDSTRT, PDDATA, PDRX, PDEND, PDPERASE, MEM_DATA, AUTH_PAD. This checksum ensures these fields are not corrupted. 15.4.17

ID Parameter– Location 0x00000100

See 11.3. 15.4.18

PSL Parameter– Location 0x00000102

See 0.

15.5 Write only Memory (WOM) This set of key values shall be supported if the device supports Authentication as defined in 14.6.

Annex A (normative) CRC Calculation

The CRCH, CRCP and CRCT fields are used to detect errors in the HEADER, PLD and PLDT fields respectively. The CRCT field is used to detect errors in the Target frame. CRCH, CRCP and CRCT shall be 32 bit. The CRC shall be calculated by the following polynomial. G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 The initial state of the LFSR shall be loaded with logical ‘1’. Data is shifted in and out as indicated. The resulting CRC value shall be attached to the respective field (ie CRCH, CRCP, CRCT). The most significant byte shall be transmitted first. The most significant bit of each byte shall be transmitted first. At the receiving side (initiator and target) the incoming CRC bits are clocked into the register. After the LSB bit is clocked, the 32 bit LFSR register should contain all ‘1’s. The 32 bit CRC shall be calculated on all data bits up to, but not including, the first CRC bit.

Figure A.1 — The LFSR circuit generating the CRC for Initiator and Target

Annex B (informative) Authentication

The entity authentication specified herein uses a challenge-response scheme in which an Initiator’s knowledge of a secret key is checked through a 2-move protocol using symmetric secret keys. The latter imples that a correct Initiator/Target pair shared the same secret key.

Initiator

Target

Key 15

Challenge (CK) + K

Key 14

Challenge (CK)

Key 1 Key 0 Secure Memory bank

Message (MSG)

Secret (S(K))

D (CK,S(K))

SHA Processor

D’ (CK,S(K))

Check: D’ =D

Figure B.1 — Challenge-response for symmetric key systems In the challenge-response scheme, the initiator challenges the target to authenticate a random input (the Challenge key), denoted by CK, with a 4 bit authentication key (K). K shall be a value between 0 and 15 and shall be used as a pointer to retrieve the secret key S(K) from the Target’s secure memory bank. A 480 bit string Message (MSG) consisting of the interleaving bytes Challenge (CK) and Secret S(k)) shall be formed see Figure B.2 for the input message (MSG) to the SHA processor.

Challenge (CK) 8 bit

8 bit

C[n] MSB

C[n-1]

C[1]

C[0] (LSB)

Message (MSG) 16 bit

16 bit

C[n]S[n] MSB

C[n-1]S(K)[n-1]

16 bit

C[1]S(K)[1]

C[0]S(K)[0] (LSB)

Secret S(K) 8 bit

8 bit

S(K)[n] MSB

S(K)[n-1]

S(K)[1]

S(K)[0] (LSB)

Figure B.2 — SHA processor input message formation The 480-bit string Message (MSG) shall be digested by the target’s authenticator using a SHA-1 (FIPS PUB 180-1) compliant algorithm, producing a 160 bit Digest (D). SHA-1 algorithm is well documented and is freely available. The Digest (D) will be sent back to the intiator. An alternate Digest (D’) may be calculated in the initiator using prior knowledge of the secret S(K) using the same technique. Alternatively the alternate Digest (D’) may be calculated using another target. The later method is preffered. The targets with matching D=D’ implies that they share the same secret.

Annex C (normative) Reference Antennas

This Annex specifies the design and validation of three reference antennas that shall be used to determine the radiated power and received power as specified in this Standard. The designs specified herein include information sufficient to build the reference antennas. This comprises dimensional information with their required tolerances, and specifications for materials used in their construction. All dimensions are in mm. Equivalent parts or materials may be substituted for manufacturer-specific items specified in the designs in this Annex. This Annex also specifies a procedure to measure the reference antennas to ensure their correct operation.

C.1 Reference Antenna #1 C.1.1 Design Information Figure C.1 illustrates the PCB layout of the Reference Antenna #1 and specifies the PCB material and the circuit components used.

U.FL‐R‐SMT(01) Receptacle Coaxial SMD. Manufacturer: Hirose Electric Company., Ltd

Matching Capacitor: ACCU‐P 0,6 pF Thin‐film chip capacitor. Part #: 06035J0R6PBT. Manufacturer: AVX Corporation.

10 Plated‐thru vias, 0,4 mm diameter

PCB material: FR4, relative permittivity = 4,6 ± 0,2 at 2,4 GHz; 0,5 mm thick, with 17,5 µm copper traces.

Matching Capacitor: Hole in centre of ACCU‐P 2,2 pF Thin‐film antenna loop – 2,4 chip capacitor. mm diameter Part #: 06035J2R2PBT. Manufacturer: AVX Corporation.

Figure C.1 — Reference Antenna #1 – Layout Precise layout information for the antenna PCB is specified by the gerber artwork files that can be found at: http://www.ecma-international.org/publications/standards/Ecma-391.htm.

C.1.2 Antenna Validation C.1.2.1

Antenna input return loss

The antenna input return loss as measured by a network analyser or similar instrument, when measured in a system having a characteristic impedance of 50 ohms, shall be greater than 6 dB at 2 442 MHz. C.1.2.2

Antenna transmission loss

Two Reference Antennas #1 shall be used in this test. Both antennas shall have passed the test specified in C.1.2.1.

The two antennas shall be placed 180 degrees rotated relative to each other and spaced 5 mm ± 0.1 mm apart, and with their radiating patterns facing each other, and with the centres of the radiating loops on the same axis. Figure C.2 illustrates this arrangement. To measurement instrument

Reference antenna#1

5,0mm ± 0,1mm

Antenna loop centre‐line

To signal source

Figure C.2 — Antenna arrangement The transmission loss between the two antennas shall be 10,5 dB ± 1 dB at 2 442 MHz.

C.1.3 Use of Reference Antenna to measure radiated power and received power Where use of the reference antenna is specified in this Standard, then the average of measurements in dB using both the antennas validated in C.1.2 shall be used to determine the actual performance obtained.

C.2 Reference Antenna #2 C.2.1 Design Information Figure C.3, C.4 and C.5 specify the design of Reference Antenna #2. Printed Circuit Board Material: Rogers Corporation RO4003C. Thickness 0,032”, 35 µm copper cladding.

Tolerance for Antenna radiating pattern dimensions: ± 0,02 mm. Tolerance for Board Outline dimensions: ± 0,25 mm.

24,0

Gap between tracks = 0,48 mm

Track width = 0,22 mm

24,0

Printed Circuit Board outline

Antenna radiating copper trace, symmetrical about PCB centre‐line

Gap between pads = 0,45 mm

Centre line

A B 2 pads, 1,00 mm square. Each pad has 0,3 mm diameter plate‐thru via in its centre.

Dimension A = 3,00 mm Dimension B = 12,01 mm Dimension C = 10,87 to 11,37 mm. Dimension D = 1,23 mm

Dimension C may be adjusted within the range 10,87 to 11,37mm to ensure that the antenna return loss meets the specification as given in C.2.2.1.

Figure C.3 — Reference Antenna #2 – Radiating pattern dimensions

24,0 Printed Circuit Board outline

U.FL‐R‐SMT(01) Receptacle Coaxial SMD, Manufacturer: Hirose Electric Company,, Ltd

24,0

Copper trace for mounting connector and matching capacitor, See detailed diagram for pattern dimensions,

Matching Capacitor: ACCU‐P 1,0 pF Thin‐film chip capacitor, Part #: 06035J1R0PBT, Manufacturer: AVX Corporation,

Figure C.4 — Reference Antenna #2 - Component-side layout

4,06 0,525 1,25

1,05

+ 1,45 3,11

0,45 1,96 0,77

0,91

1,00

1,90

4,00

0,23 0,45 1,25 1,05

2,20

Figure C.5 — Reference Antenna #2 – Detailed component-side pattern dimensions

C.2.2 Antenna Validation C.2.2.1

Antenna input return loss

Antenna transmission loss

Two Reference Antennas #2 shall be used in this test. Both antennas shall have passed the test specified in C.2.2.1. The two antennas shall be placed in the same orientation and spaced 10 mm ± 0.2 mm apart, and with their radiating patterns facing each other, and with the centre of the antenna's folded loops on the same axis. The transmission loss between the two antennas shall be 4,5 dB ± 1 dB at 2 442 MHz.

C.2.3 Use of Reference Antenna to measure radiated power and received power Where use of the reference antenna is specified in this Standard, then the average of measurements in dB using both the antennas validated in C.2.2 shall be used to determine the actual performance obtained.

C.3 Reference Antenna #3 C.3.1 Design Information Figure C.6 specifies the construction of the Reference Antenna#3.

57,5 Printed Circuit Board and Ground Plane outline

31,99

Antenna radiating pattern outline 19,60

1,80 1,80 44,60

SMA connector fitted here

65,0

1,80 9,36 19,60

Printed Circuit Board Material: Rogers Corporation RO4003C, Thickness 0,032” 35 µm copper cladding,

10,00

All dimensions in mm, Tolerance for Antenna radiating pattern outline: +/‐ 0,05 mm Tolerance for Board and Ground Plane Outline: +/‐ 0,1 mm

10,20

Figure C.6 — Design Information for Reference Antenna #3

C.3.2 Antenna Validation C.3.2.1

Antenna input return loss

Antenna transmission loss

Two Reference Antennas #3 shall be used in this test. Both antennas shall have passed the test specified in C.3.2.1. The two antennas shall be placed in the same orientation and spaced 100 mm ± 1 mm apart, and with their radiating patterns facing each other. The transmission loss between the two antennas shall be 11,0 dB ± 0,5 dB at 2 442 MHz.

C.3.3 Use of Reference Antenna to measure radiated power and received power Where use of the reference antenna is specified in this Standard, then the average of measurements in dB using both the antennas validated in C.3.2 shall be used to determine the actual performance obtained.

ECMA-391 — Memory-Spot Interface and Protocol (MSIP‑1) (December 2009)

Related documents