X 5211：2015 (ISO/IEC 18092：2013)
（1）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目 次
ページ
序文 ··································································································································· 1
1 適用範囲························································································································· 1
2 適合性···························································································································· 2
3 引用規格························································································································· 2
4 用語及び定義··················································································································· 2
5 表記法···························································································································· 4
5.1 数の表記法 ··················································································································· 4
5.2 名称 ···························································································································· 5
6 略語······························································································································· 5
7 全般的事項······················································································································ 7
8 RFフィールド ················································································································· 7
8.1 値 ······························································································································· 7
8.2 受動通信モード ············································································································· 7
8.3 能動通信モード ············································································································· 7
8.4 外部RFフィールドしきい値 ···························································································· 7
9 RF信号インタフェース ····································································································· 8
9.1 ビット持続時間 ············································································································· 8
9.2 能動通信モード ············································································································· 8
9.3 受動通信モード ············································································································· 9
10 プロトコルの流れの概要 ································································································· 10
11 初期化 ························································································································· 11
11.1 RF衝突回避 ··············································································································· 12
11.2 受動通信モード ··········································································································· 14
11.3 能動通信モード ··········································································································· 17
12 トランスポートプロトコル ······························································································ 18
12.1 トランスポートデータ ·································································································· 18
12.2 受動通信モードの活性化手順 ························································································· 19
12.3 能動通信モードの活性化手順 ························································································· 19
12.4 命令 ·························································································································· 23
12.5 プロトコルの活性化 ····································································································· 23
12.6 データ交換プロトコル ·································································································· 31
12.7 プロトコルの非活性化 ·································································································· 37
附属書A（規定）CRC計算 ··································································································· 40
附属書B（参考）SAK ·········································································································· 42
X 5211：2015 (ISO/IEC 18092：2013)
（2）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
まえがき
この規格は，工業標準化法第14条によって準用する第12条第1項の規定に基づき，一般社団法人情報
処理学会（IPSJ）及び一般財団法人日本規格協会（JSA）から，工業標準原案を具して日本工業規格を改
正すべきとの申出があり，日本工業標準調査会の審議を経て，経済産業大臣が改正した日本工業規格であ
る。
これによって，JIS X 5211:2010は改正され，この規格に置き換えられた。
この規格は，著作権法で保護対象となっている著作物である。
この規格に従うことは，次の者の有する特許権等の使用に該当するおそれがあるので，留意する。
− 氏名：ソニー株式会社
− 住所：東京都港区港南1丁目7番1号
上記の，特許権等の権利者は，非差別的かつ合理的な条件でいかなる者に対しても当該特許権等の実施
の許諾等をする意思のあることを表明している。ただし，この規格に関連する他の特許権等の権利者に対
しては，同様の条件でその実施が許諾されることを条件としている。
この規格に従うことが，必ずしも，特許権の無償公開を意味するものではないことに注意する必要があ
る。
この規格の一部が，上記に示す以外の特許権等に抵触する可能性がある。経済産業大臣及び日本工業標
準調査会は，このような特許権等に関わる確認について，責任はもたない。
なお，ここで“特許権等”とは，特許権，出願公開後の特許出願又は実用新案権をいう。
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格
JIS
X 5211：2015
(ISO/IEC 18092：2013)
システム間の通信及び情報交換−
近距離通信用インタフェース及びプロトコル
（NFCIP-1）
Information technology-
Telecommunications and information exchange between systems-
Near Field Communication-Interface and Protocol (NFCIP-1)
序文
この規格は，2013年に第2版として発行されたISO/IEC 18092を基に，技術的内容及び構成を変更する
ことなく作成した日本工業規格である。
なお，この規格で点線の下線を施してある参考事項は，対応国際規格にはない事項である。
この規格は，近距離に置いたデバイス間での短い電文のための無線通信のためのインタフェース及びプ
ロトコルである。これらの近距離通信（Near Field Communicationを指し，以下，NFCという。）デバイス
は，106 kbit/s，212 kbit/s，424 kbit/sの伝送速度にて通信する。この近距離通信用インタフェース及びプロ
トコル（NFC Interface and Protocolを指し，以下，NFCIP-1という。）規格をネットワーク商品，消費者向
け機器などのアプリケーションに利用してよい。
1
適用範囲
この規格は，コンピュータ周辺機器の相互接続を行うために，中心周波数13.56 MHzで動作する電磁誘
導結合を利用したデバイス間での近距離通信用インタフェース及びプロトコル（NFCIP-1）で利用する通
信モードを規定する。消費者向けのネットワーク機器などに使う近距離通信デバイスを用いて通信網を実
現する近距離通信用インタフェース及びプロトコル（NFCIP-1）における能動通信モード及び受動通信モ
ードについても規定する。この規格は，変調の仕組み，符号化，伝送速度，RFインタフェースのフレーム
形式，初期化の仕組み，初期化中のデータ衝突制御に必要な条件などについて規定する。さらに，この規
格は，データ交換及びプロトコル活性化の方法を含めたトランスポートプロトコルも規定する。
システム相互間での情報交換において，最小限，交換するコード，データ構造などについて情報交換を
行う当事者間の合意を必要とする。
注記 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
ISO/IEC 18092:2013，Information technology−Telecommunications and information exchange
between systems−Near Field Communication−Interface and Protocol (NFCIP-1)（IDT）
なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1に基づき，“一致している”こ
とを示す。
2
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2
適合性
この規格の能動通信モード又は受動通信モードを実装するシステムは，この規格で規定する全ての必須
要件を満たした場合に，この規格に適合する。
なお，ISO/IEC 13157-1で規定するNFC-SECオプションを実装してもよい。
3
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの
引用規格は，その最新版（追補を含む。）を適用する。
JIS X 6322-2 識別カード−非接触（外部端子なし）ICカード−近接型−第2部：電力伝送及び信号
インタフェース
注記 対応国際規格：ISO/IEC 14443-2，Identification cards−Contactless integrated circuit cards−
Proximity cards−Part 2: Radio frequency power and signal interface（IDT）
JIS X 6322-3 識別カード−非接触（外部端子なし）ICカード−近接型−第3部：初期化及び衝突防止
注記 対応国際規格：ISO/IEC 14443-3，Identification cards−Contactless integrated circuit cards−
Proximity cards−Part 3: Initialization and anticollision（IDT）
JIS X 6322-4 識別カード−非接触（外部端子なし）ICカード−近接型−第4部：伝送プロトコル
注記 対応国際規格：ISO/IEC 14443-4，Identification cards−Contactless integrated circuit cards−
Proximity cards−Part 4: Transmission protocol（IDT）
ISO/IEC 13157-1，Information technology−Telecommunications and information exchange between systems
−NFC Security−Part 1: NFC-SEC NFCIP-1 security services and protocol
ITU-T V.41，Code-independent error-control system
4
用語及び定義
この規格で用いる主な用語及び定義は，次による。
4.1
能動通信モード（active communication mode）
イニシエータ及びターゲットがそれぞれ自ら発生したRFフィールドを用いて通信するモード。
4.2
ASK変調（ASK modulation）
伝送するデータの論理で搬送波周波数の振幅を変調すること。振幅変位キーイング変調ともいう。
注記 ASKは，Amplitude Shift Keyingの略。
4.3
2進化10進法［Binary Coded Decimal (BCD)］
4桁の2進数を使って，10進数の0〜9を表現する数値の表現法。
注記 左から右へ並ぶビット列は，10進数でそれぞれ8，4，2，1の重みがある。例えば，6という数
のBCD（Binary Coded Decimal）表記は，0110となる。
4.4
衝突（collision）
同時に二つ以上のターゲット又はイニシエータが電波を送出することによって，イニシエータ又はター
ゲットが，どの対象から発せられたものであるかを区別できなくなること。
3
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
4.5
フレーム（frame）
データビット及び任意選択でエラー検出用のビット列に，フレームの開始部及び終了部を付けたもの。
4.6
HThreshold（HThreshold）
検出する外部RFフィールドのしきい値。
4.7
イニシエータ（Initiator）
RFフィールド発生及びNFCIP-1通信開始を行うもの。
4.8
負荷変調（load modulation）
RFフィールド内の共振回路の特性を変化させることによってRFフィールドを振幅変調する処理。
4.9
最下位ビット先行（lsb first）
他の全てのビットよりも先に最下位ビット（lsb）を送り出す直列データ伝送方式。
4.10
最下位バイト先行（LSB first）
他の全てのバイトよりも先に最下位バイト（LSB）を送り出す直列データ伝送方式。
4.11
マンチェスタ符号化（Manchester coding）
各ビット区間の前半の物理的状態と，その状態とは異なる後半の物理的状態との組合せで，論理的ビッ
ト値を決める符号化方式。
4.12
変調度（modulation index）
[peak−minimum]/[peak＋minimum]で表される信号振幅比率。
Peakは無変調の信号振幅を表し，minimumは変調した最小の信号振幅を表す（JIS X 6322-2の3.4によ
る。）。
4.13
最上位ビット先行（msb first）
他の全てのビットよりも先に最上位ビット（msb）を送り出す直列データ伝送方式。
4.14
最上位バイト先行（MSB first）
他の全てのバイトよりも先に最上位バイト（MSB）を送り出す直列データ伝送方式。
4.15
NFCIP-1デバイス（NFCIP-1 device）
この規格を適用する実体（エンティティ）。
4.16
NFC識別子（NFC Identifier, NFCIDn）
受動通信モード及び能動通信モードにおいて，RF衝突回避及び単一デバイス検出処理に用いるためにラ
ンダムに発生させた数。
4
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
4.17
NFC-SEC（NFC-SEC）
ISO/IEC 13157-1で規定するNFCIP-1のためのセキュリティサービス及びプロトコル。
4.18
受動通信モード（passive communication mode）
イニシエータがRFフィールドを発生し，ターゲットがイニシエータからの命令に負荷変調で応答する
モード。
4.19
RF衝突回避（RF Collision Avoidance, RFCA）
搬送波周波数に基づくRFフィールドの存在を検知し，プロトコルレベルにて衝突を回避する方法。
4.20
SAK（SAK）
選択了解信号（A型）[JIS X 6322-3]。
注記 SAKは，JIS X 5211:2010のSEL̲RESのこと。
4.21
センス状態（sensing）
能動通信モードにあるNFCIP-1デバイスが，RFフィールドへ自分が出した要求に対する応答を期待し
て通信開始を待っている状態。
4.22
単一デバイス検出（Single Device Detection, SDD）
RFフィールドの中にある複数のターゲットの中から一つを検出するためにイニシエータが使用するア
ルゴリズム（衝突防止 [JIS X 6322-3]）。
4.23
ターゲット（Target）
負荷変調（イニシエータがRFフィールドを発生）又は自ら発生したRFフィールドの変調を用いてイニ
シエータコマンドへ応答するもの。
4.24
タイムピリオド（Time Period）
RF衝突回避のために使用する，タイムスロット数で決まる時間幅。
4.25
タイムスロット法（Time Slot Method）
ターゲットが応答するときの時間窓を用意し，二つ以上の論理チャネルを割り当てて識別できるように
する方法。
4.26
トランザクション（transaction）
初期化，データ交換及びデバイス選択解除。
5
表記法
5.1
数の表記法
この規格において，特に規定がない限り，次の表記を用いる。
5
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 16進数は，“XX”で表す。Xは数字及び英文字を表す。
− ビットの設定は，“0”又は“1”で表す。
− 2進数及びビットパターンの数字は，最上位ビットを左とし，0及び1の列とする。規定しないビット
にはXを使用することがある。
例 (XXXX) b
5.2
名称
この規格では，基礎的な要素（例えば，特定のフィールド）の名称は，頭文字が大文字である。
6
略語
この規格で使用する略語を，次に示す。
ALL̲REQ（Wake up ALL Request）
全デバイス起動要求
ATR（Attribute Request and Attribute Response）
属性要求及び属性応答
ATR̲REQ（Attribute Request）
属性要求
ATR̲RES（Attribute Response）
属性応答
BCD（Binary Coded Decimal）
2進化10進法
BRi（Receiving bit duration supported by Initiator）
イニシエータの受信ビット持続時間
BRt（Receiving bit duration supported by Target）
ターゲットの受信ビット持続時間
BSi（Sending bit duration supported by Initiator）
イニシエータの送信ビット持続時間
BSt（Sending bit duration supported by Target）
ターゲットの送信ビット持続時間
CMD（Command）
命令
CRC（Cyclic Redundancy Check）
巡回冗長検査
D（Divisor）
除数
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 Target）
ターゲットの受信データ伝送速度
DSi（Data rate Sent by Initiator）
イニシエータの送信データ伝送速度
DSL（Deselect Request and Deselect Response）
選択解除要求及び選択解除応答
DSL̲REQ（Deselect Request command）
選択解除要求命令
DSL̲RES（Deselect Response command）
選択解除応答命令
DSt（Data rate Sent by Target）
ターゲットの送信データ伝送速度
etu（elementary time unit）
1ビットに要する伝送時間の単位
fc［Frequency of operating field (carrier frequency)］
搬送波の周波数
fd（Baseband frequency of Manchester coding）
マンチェスタ符号化のベースバンド周波数
fs（Subcarrier）
副搬送波の周波数（JIS X 6322-2）
FRT（Frame Response Time）
フレーム応答時間
6
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
Gi（Optional information field for Initiator）
イニシエータの任意選択情報フィールド
Gt（Optional information field for Target）
ターゲットの任意選択情報フィールド
HLTA（HaLT command, Type A）
A型における停止命令（JIS X 6322-3）
ID（Identification number）
識別子
MI（Multiple Information link for Data Exchange Protocol） データ交換プロトコルの複数情報リンク
NAD（Node Address）
ノードアドレス
NFCID1（fc/128 UID）
識別子（fc/128 UID）
nfcid1n（Byte number n of NFCID1）
識別子NFCID1のnバイト目
NFCID2（Random ID for SDD in Passive communication mode at fc/64 and fc/32 bit rates）fc/64及びfc/32伝送速
度の受動通信モードにおけるSDDのためにランダ
ムに発生した数でできた識別子
nfcid2n（Byte number n of the Random Identifier NFCID2） 識別子NFCID2のnバイト目
NFCID3（Random ID for transport protocol activation） トランスポートプロトコル活性化のためのランダム
に発生した数でできた識別子
nfcid3n（Byte number n of the Random Identifier NFCID3） 識別子NFCID3のnバイト目
P（Odd parity bit）
奇数パリティビット
PA（Preamble）
プリアンブル
PCD（Proximity Couping Device）
近接型結合装置（JIS X 6322-2）
PDU（protocol data unit）
プロトコルデータ単位
PFB（Control information for transaction）
トランザクションのための制御情報（プロトコルフ
レーム制御バイトを表す。）
PICC（Proximity Card）
近接型ICカード（JIS X 6322-2）
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）
パラメタ選択応答
RF（Radio Frequency）
無線周波数
RFCA（RF Collision Avoidance）
RF衝突回避
RFU（Reserved for Future Use）
将来使用するため予約
RLS（Release Request and Release Response）
解放要求及び解放応答
RLS̲REQ（Release Request command）
解放要求命令
RLS̲RES（Release Response command）
解放応答命令
RWT（Response Waiting Time）
応答待ち時間
SB（Start Byte for data exchange protocol at fc/128）
fc/128におけるデータ交換プロトコル開始バイト
SDD［Single Device Detection (anti-collision)］
単一デバイス検出（衝突防止）
SEL̲CMD（Select Command byte）
選択命令バイト
SYNC（Synchronisation pattern）
同期パターン
TO（Timeout value）
タイムアウト値
7
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
UID（Unique Identifier）
固有識別子（JIS X 6322-3）
WT（Waiting Time）
待ち時間
WUP（Wakeup Request and Wakeup Response）
起動要求及び起動応答
WUP̲REQ（Wakeup Request command）
起動要求命令
WUP̲RES（Wakeup Response command）
起動応答命令
7
全般的事項
NFCIP-1のターゲット及びイニシエータは，能動通信モード及び受動通信モードの両方を実装しなけれ
ばならない。
能動通信モードでは，イニシエータ及びターゲットは，相互に通信を行うために，自らのRFフィール
ドを使用する。イニシエータは，NFCIP-1トランザクションを開始する。ターゲットは，自ら発生するRF
フィールドを変調することによって，イニシエータからの命令に応答する。
受動通信モードでは，イニシエータがRFフィールドを発生してトランザクションを開始する。ターゲ
ットは，イニシエータが発生するRFフィールドに対し，負荷変調という方法で変調をかけて応答する。
この規格は，変調，伝送速度，及びビット符号化の要求仕様を規定する。さらに，その通信は，通信開
始，通信終了，ビット表現及びバイト表現，フレーム形式及び誤り検出，単一デバイス検出，プロトコル
及びパラメタ選択，並びに，NFCIP-1デバイスのデータ交換及び選択解除の要求仕様も規定する。
トランザクションは，デバイス初期化によって開始し，デバイスの選択解除によって終了する。イニシ
エータ及びターゲットは，コマンド，応答及びデータを，半二重通信で交換する。
NFCIP-1デバイスは，fc/128，fc/64，及びfc/32の伝送速度における通信能力をもっていなければならな
い。イニシエータは，トランザクション開始時の伝送速度を維持してもよいし，通信中に
PSL̲REQ/PSL̲RESコマンドを利用して伝送速度を切り替えてもよい。
通信モード（能動又は受動）は，一つのトランザクションの途中で変えてはならない。
8
RFフィールド
8.1
値
fcは13.56 MHzとする。
Hminは1.5 A/m (rms)とする。
Hmaxは7.5 A/m (rms)とする。
HThresholdは0.187 5 A/m (rms)とする。
8.2
受動通信モード
イニシエータは，その製造業者が規定する位置（すなわち，動作空間）において，無変調の状態にて最
低Hminと最大Hmaxとの間のRFフィールドを発生しなければならない。
ターゲットは，Hmin〜Hmaxの範囲で連続的に動作しなければならない。
8.3
能動通信モード
イニシエータ及びターゲットは，その製造業者が規定する位置（すなわち，動作空間）において，無変
調の状態にて最低Hminと最大Hmaxとの間のRFフィールドを交互に発生しなければならない。
8.4
外部RFフィールドしきい値
NFCIP-1デバイスは，fcにおいて，HThresholdより強い外部RFフィールドを検出できなければならない。
8
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
9
RF信号インタフェース
9.1
ビット持続時間
一つのetuを，128/(D×fc)とし，伝送速度及び通信モードに依存する除数の値をDとする。表1参照。
表1−除数D
通信モード
伝送速度
除数 D
能動又は受動
fc/128（約106 kbit/s）
1
能動又は受動
fc/64（約212 kbit/s）
2
能動又は受動
fc/32（約424 kbit/s）
4
能動
fc/16（約848 kbit/s）
8
能動
fc/8（約1 695 kbit/s）
16
能動
fc/4（約3 390 kbit/s）
32
能動
fc/2（約6 780 kbit/s）
64
注記1 イニシエータは，通信モード（能動又は受動いずれでも）及び伝送速度（fc/128，fc/64，及び
fc/32）を選択する。
注記2 この規格は，fc/32を超える変調及びビット符号化について規定しない。
9.2
能動通信モード
ターゲット及びイニシエータは，イニシエータからターゲットへの通信，及びターゲットからイニシエ
ータへの通信の両方に適用される次の規定に従わなければならない。
9.2.1
fc/128の要求仕様
9.2.1.1
伝送速度
初期化及び単一デバイス検出における伝送速度は，fc/128でなければならない。
9.2.1.2
変調
JIS X 6322-2の8.1.2.1による。送信動作のとき，イニシエータ及びターゲットは共にPCDの値に従わな
ければならない。受信動作のとき，イニシエータ及びターゲットは共にPICCの値に従わなければならな
い。
9.2.1.3
ビット表現及び符号化
JIS X 6322-2の8.1.3の伝送速度fc/128による。
9.2.1.4
バイト送信
イニシエータ及びターゲットは，最下位ビット先行でバイトを送信しなければならない。
9.2.2
fc/64及びfc/32の要求仕様
9.2.2.1
伝送速度
初期化及び単一デバイス検出における伝送速度は，共にfc/64又はfc/32でなければならない。
9.2.2.2
変調
JIS X 6322-2の9.1.2の伝送速度fc/64及びfc/32による。送信動作時，イニシエータ及びターゲットは共
にPCDの値に従わなければならない。受信動作時，イニシエータ及びターゲットは共にPICCの値に従わ
なければならない。
注記 この変調度範囲は，JIS X 5211:2010の規定範囲よりも狭い。
JIS X 5211:2010に適合したイニシエータは，変調度14 %以上で送信している可能性があるため，ターゲ
ットは変調度8 %〜30 %を受信可能とすることが望ましい。
9
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
9.2.2.3
ビット表現及び符号化
マンチェスタ符号化を用いなければならない。波形を図1及び図2に示す。
ビット符号化形式の論理レベルは，次による。
− 論理“0”：最初の半ビットは，低振幅の搬送波で，次の半ビットは，高振幅の搬送波でなければなら
ない（無変調を適用する。）。
− 論理“1”：最初の半ビットは，高振幅の搬送波（無変調を適用する。）で，次の半ビットは，低振幅の
搬送波でなければならない。
振幅での逆極性も，許容されなければならない。同期パターン（11.2.2.2参照）から極性を検出しなけれ
ばならない。
1 etu
“0”
1 etu
“1”
図1−マンチェスタ符号化（正極性）
1 etu
“1”
1 etu
“0”
図2−マンチェスタ符号化（逆極性）
9.2.2.4
バイト送信
イニシエータ及びターゲットは，最上位ビット先行でバイトを送信しなければならない。
9.3
受動通信モード
9.3.1
fc/128におけるイニシエータからターゲットへの要求仕様
9.2.1による。
9.3.2
fc/128におけるターゲットからイニシエータへの要求仕様
9.3.2.1
伝送速度
9.2.1.1による。
9.3.2.2
変調
JIS X 6322-2の8.2.2による。
9.3.2.3
副搬送波の周波数
JIS X 6322-2の8.2.3による。
9.3.2.4
副搬送波の変調
JIS X 6322-2の8.2.4の伝送速度fc/128による。
10
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
9.3.2.5
ビット表現及び符号化
JIS X 6322-2の8.2.5.1による。
9.3.2.6
バイト送信
イニシエータ及びターゲットは，最下位ビット先行でバイトを送信しなければならない。
9.3.3
fc/64及びfc/32におけるイニシエータからターゲットへの要求仕様
9.3.3.1
伝送速度
9.2.2.1による。
9.3.3.2
変調
JIS X 6322-2の9.1.2の伝送速度fc/64及びfc/32による。送信動作時にイニシエータは，PCDの値を適用
しなければならない。
注記 変調度の許容範囲は，JIS X 5211:2010で規定する範囲よりも狭い。
9.3.3.3
ビット表現及び符号化
9.2.2.3による。
9.3.3.4
バイト送信
9.2.2.4による。
9.3.4
fc/64及びfc/32におけるターゲットからイニシエータへの要求仕様
9.3.4.1
伝送速度
9.2.2.1による。
9.3.4.2
変調
ターゲットは，JIS X 6322-2の8.2.2に規定されたPICCの負荷変調振幅値で，イニシエータのRFフィ
ールドのfcを負荷変調することによって誘導結合領域を介してイニシエータへ通信する能力をもたなけれ
ばならない。イニシエータは，JIS X 6322-2の8.2.2に規定されたPCDの受信として，負荷変調振幅信号
を受信できなければならない。
注記 ターゲット及びイニシエータの最小負荷変調振幅値は，JIS X 5211:2010から変更されている。
9.3.4.3
ビット表現及び符号化
9.2.2.3による。
9.3.4.4
バイト符号化
9.2.2.4による。
10 プロトコルの流れの概要
NFCIP-1デバイス間におけるプロトコルの流れは，一般に，次に示す一連の操作によって処理されなけ
ればならない。
− NFCIP-1デバイスの，初期状態は，特に指定しない限り，ターゲットモードで動作しRFフィールド
を発生してはならず，イニシエータからのコマンドを待たなければならない。
− NFCIP-1デバイスは，アプリケーションの要望に応じる場合には，イニシエータモードに切り替え，
能動又は受動のいずれかの通信モード，及び，伝送速度を選択してもよい。
− イニシエータは，外部RFフィールドの存在を試験しなければならず，外部RFフィールドが検出され
た場合には，自らRFフィールドを発生してはならない（8.4参照）。
− 外部RFフィールドが検出されなかった場合には，イニシエータは，ターゲットを動作させるために
自らRFフィールドを発生させなければならない。
11
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 同じ通信モード及び伝送速度においてコマンド及び応答を行う。
異なる伝送速度における能動通信モード及び受動通信モードでの初期化及び単一デバイス検出の流れの
概要を，図3に示す。
選択されたデータ伝送速度における能動通信モード又は受動通信モードでの初期化及びターゲット選択
をプロトコルの流れの概要に示す。RF衝突回避は，11.1に示す。受動通信モードは，11.2に示す。伝送速
度fc/128における初期化及び単一デバイス検出（SDD）については，11.2.1に示し，伝送速度fc/64及びfc/32
における初期化及びSDDについては，11.2.2に示す。能動通信モードについては，11.3に示す。
プロトコルの活性化は，12.5に示す。パラメタ選択は，12.5.3に示す。データ交換プロトコルは，12.6
に示す。プロトコルの非活性化は，12.7に示す。
11 初期化
この箇条は，能動通信モード及び受動通信モードにおけるターゲットの初期化及び衝突検出プロトコル
について示す。イニシエータは，少なくとも二つのターゲットが同時に，一つ以上のビット位置で値が一
致しないビットパターンを伝送するときに生じる衝突を検出しなければならない。
図3には，異なる伝送速度における能動通信モード及び受動通信モードに対する初期化及び単一デバイ
ス検出の流れの概要を含む。
12
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
開始
初期RF衝突回避
RFフィールド
検出?
アプリケーションは、受動通
信モードのイニシエータとな
って転送速度を決めて初期化
とSDDを実施する。
アプリケーションは、能動通
信モードのイニシエータとな
って転送速度を決める。
NFCID3 (ATR) による受動通信
モード活性化
NFCID3 (ATR) による能動通信
モード活性化
パラメタ選択(PSL)
データ交換
プロトコル(DEP)
非活性化(DSL, RLS)
トランザクションの
終了
プロトコル
活性化
パラメタ
選択
データ
交換
プロトコル
非活性化
はい
いいえ
図3−プロトコルの流れの概要
11.1 RF衝突回避
他の近距離通信に妨害を与えることも，現行の搬送波周波数で動作するいかなる通信基盤に対して妨害
を与えることもないように，イニシエータは，他のRFフィールドを検出している間は，自らのRFフィー
ルドを発生してはならない。
11.1.1 初期RF衝突回避
能動通信モード又は受動通信モードのいずれかのターゲットと通信を開始するために，イニシエータは，
外部RFフィールドの存在を間断なく検出しなければならない（8.4参照）。
イニシエータがTIDT＋n×TRFWの時間枠内に外部RFフィールドを検出しなかった場合には，イニシエー
13
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
タは，RFフィールドを発生して，初期RF衝突を再起動しなければならない。整数nは，乱数とする。図
4は，初期RF衝突回避のタイミングを示す。
図4−初期RF衝突回避
図4における記号及びその条件を，次に示す。
TIDT：初期遅延時間（Initial delay time，TIDT＞4 096/fc）
TRFW：RF待ち時間（RF waiting time，512/fc）
n：TRFW決定のためにランダムに発生したタイムピリオドの数（0≦n≦3）
TIRFG：RFフィールド発生から命令送信又はデータフレームまでの初期保護時間（Initial RF guard time，
TIRFG＞5 ms）
能動通信モードの場合には，イニシエータによって生成されているRFフィールドを停止しなければな
らない。受動通信モードの場合には，イニシエータによって生成されているRFフィールドを停止しては
ならない。
11.1.2 応答RF衝突回避
能動通信モードにおいて二つ以上のターゲットからの同時応答によるデータの衝突を回避するために，
ターゲットは，応答RF衝突回避を実行しなければならない。図5は，応答RF衝突回避を示す。
図5−応答RF衝突回避
図5における記号及びその条件を，次に示す。
14
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
TADT：能動遅延時間，イニシエータ及びターゲットとの間のRF非発生検出時間（Active delay time，768/fc
≦TADT≦2 559/fc）
TRFW：RF待ち時間（RF waiting time，512/fc）
n：TRFW時間に関してランダムに発生したタイムピリオド（0≦n≦3）
TARFG：RFフィールドの発生開始と命令送信との間の能動保護時間（Active guard time，TARFG＞1 024/fc）
11.2 受動通信モード
11.2.1 fc/128における初期化及び単一デバイス検出
JIS X 6322-3の箇条6，及び表2で規定されたSAKの符号化による。
表2−SAKの符号化
ビ
ッ
ト
8
ビ
ッ
ト
7
ビ
ッ
ト
6
ビ
ッ
ト
5
ビ
ッ
ト
4
ビ
ッ
ト
3
ビ
ッ
ト
2
ビ
ッ
ト
1
意味
x
x
x
x
x
1
x
x
UIDが不完全，JIS X 6322-3の表9参照
x
x
1
x
x
0
x
x
UIDが完全，JIS X 6322-3の表9参照
x
x
0
x
x
0
x
x
UIDが完全，JIS X 6322-3の表9参照
x
1
x
x
x
0
x
x
UIDが完全。ターゲットはNFCIP-1トランスポートプロトコルに
適応している。属性要求をもっている。
x
0
x
x
x
0
x
x
UIDが完全で，ターゲットはNFCIP-1トランスポートプロトコル
に未適応であり，属性要求をもっていない。
uid0は，“08”に設定しなければならない。
ビット3が(1)bの場合，イニシエータは，SAKの他のいかなるビットも無視しなければならない。ビッ
ト3が(0)bの場合，イニシエータは，ビット7を解釈して，他のビットは無視しなければならない。ビッ
ト3が(1)bに設定された場合，ターゲットは，SAKの他の全てのビットを(0)bに設定することが望ましい
（附属書B参照）。
注記1 UIDはJIS X 5211:2010のNFCID1を置換し，uid*はJIS X 5211:2010のnfcid1を置換する。
注記2 SAKのビット6が(1)bの場合，デバイスはJIS X 6322-4にて定義されたプロトコルをもって
いる。
11.2.2 fc/64及びfc/32における初期化及びSDD
11.2.2.1 通信の開始及び終了
搬送波周波数の存在によって受動通信モードの開始と解釈しなければならない。論理“0”に全て符号化
された最低48ビットのプリアンブルによって，通信の開始と解釈しなければならない。フレーム内に存在
する長さフィールドから，通信の終了を予測しなければならない。図6に通信の開始及び終了を示す。
図6−通信の開始及び終了
15
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
一つのNFCIP-1デバイスの通信が終了した後，続けて他のNFCIP-1デバイスが通信を開始する場合は，
図7に示すとおり，最低でも8×64/fcの時間を遅れてプリアンブルを送り始めなければならない。
データパケット
データパケット
プリアンブル
遅延
図7−連続するフレーム間の遅延
11.2.2.2 フレームの形式
フレームの形式は，図8に示すように，プリアンブル，同期パターン，長さ，ペイロード及びCRCから
なるものとしなければならない。
プリアンブルは，48ビット以上であって，全て論理“0”でなければならない。
同期パターンは，2バイトでなければならない。同期パターンの最初のバイトは，“B2”とし，2番目の
バイトは“4D”としなければならない。
プリアンブル
同期パターン（SYNC）
長さ
ペイロード
CRC
図8−フレームの形式
長さフィールドは，8ビットのフィールドとし，ペイロードに伝送されるバイト数に1を加えた値に設
定しなければならない。長さの範囲は，2〜255の間で設定しなければならない。他の設定は，RFUとする。
ペイロードは，1バイトが8ビットからなるnバイトのデータとしなければならない。
CRCは，A.3による。
11.2.2.3 fc/64及びfc/32における単一デバイス検出
単一デバイス検出（SDD）手順の基本は，タイムスロット法でなければならない。スロットの数は，0
より大きい整数値でなければならない。イニシエータは，ポーリング要求（Polling Requests）を発行しな
ければならない。ターゲットは，それぞれの制御可能なタイムスロットにおいて応答しなければならない。
イニシエータは，それぞれ異なるタイムスロットにおいて，ターゲットのNFCID2データ（11.2.2.4参照）
を読むことができなければならない。
イニシエータは，動作フィールド内のターゲットからNFCID2データを得た後，複数のターゲットと通
信をしてもよい。
情報交換相手相互間での取決めによって，最大16個までのタイムスロットを利用してもよい。タイムス
ロットの数は，イニシエータからのポーリング要求フレーム内のTSN値によって指示してもよい。
動作状態にあるターゲットは，イニシエータからのポーリング要求フレームを受けた後，次の規則によ
って，イニシエータに応答する。
1) ターゲットは，0〜TSNの範囲でランダムに選んだ値Rを生成しなければならない。
2) ターゲットは，タイムスロットがRになるまで待たなければならない。その後ポーリング応答フレ
ームを返し，次の要求を待たなければならない。ターゲットは，応答の衝突が減るようにポーリン
グ要求を無視してもよい。
イニシエータ及びターゲットとの間の通信は，次の手順によって開始されなければならない。
16
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
1) ターゲットは，イニシエータが生成する動作フィールドから電力を得る。
2) ターゲットは，起動してから最大2秒以内にイニシエータからのポーリング要求を受けて準備完了
状態にならなければならない。
3) ターゲットは，イニシエータが発行するポーリング要求を待たなければならない。イニシエータは，
ターゲットの都合によらずにポーリング要求を発行してもよい。
4) イニシエータがポーリング応答を受けるのに失敗した場合には，イニシエータは，ポーリング要求
を再び送ってもよい。受動通信モードのイニシエータは，単一デバイス検出（SDD）手順を実行し
ている間，RFパワーが存在する状態を維持しなければならない。
要求フレームの最後と最初のタイムスロットとの間の遅延時間Tdは，512×64/fcとする。
タイムスロット単位Tsは，256×64/fcでなければならない。
図9にタイムスロットによる単一デバイス検出（SDD）の状況例を示す。この例は，五つのターゲット
が応答している。衝突がタイムスロット1で起きているので，イニシエータは，ターゲット1及び3を除
いた2，4及び5からの応答情報を得ることができる。
イニシエータは，SDD手順を繰り返してもよい。
←
Td
→
← Ts →
← Ts →
← Ts →
← Ts →
時間 →
タイムスロット0
タイムスロット1
タイムスロット2
タイムスロット3
イニシエータ
からの要求
ターゲット4
からの応答
ターゲット1
からの応答
ターゲット5
からの応答
ターゲット2
からの応答
ターゲット3
からの応答
図9−タイムスロットによる単一デバイス検出
11.2.2.4 NFCID2の内容
NFCID2は，NFCIP-1デバイスを特定するための8バイトの数値でなければならない。NFCID2は，2バ
イトの前置き符号に続く6バイトの数値でなければならない。前置き符号は，続く6バイトの数値の特性
を定義していなければならない。
前置き符号を“01”“FE”に設定した場合，続く6バイトの数値は，乱数でなければならない。前置き
符号の他の値は，将来使用するため予約する。
11.2.2.5 ポーリング要求フレーム形式
ターゲットを見つけるために，イニシエータは，図10に示すフレームをポーリング要求として発行しな
ければならない。
プリアンブル
（最低48ビット）
SYNC
（16ビット）
長さ
（8ビット）
ペイロード
CRC
（16 ビット）
“00”
“FF”
“FF”
“00”
TSN
図10−ポーリング要求のフレーム形式
プリアンブルは，全て論理“0”で48 ビット以上でなければならない。
同期パターン（SYNC）は，2 バイトでなければならない。最初のバイトは，“B2”とし，2番目のバイ
トは“4D”とする。
17
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
長さフィールドは，“06”に設定しなければならない。
ペイロードの最初のバイトは，“00”に設定しなければならない。
ペイロードの2番目及び3番目のバイトは，“FF”に設定しなければならない。他の値は，将来使用す
るため予約する。
ペイロードの4番目は，“00”に設定しなければならない。他の値は，将来使用するため予約する。
TSN は，“00”，“01”，“03”，“07”，又は“0F”でなければならない。他の値は，将来使用するため予約
する。
CRCは，A.3によって計算しなければならない。
図9は，TSNが“03”の例を示している。TSNを“00”に設定した場合には，タイムスロット0だけが
使われなければならない。
11.2.2.6 ポーリング応答フレームの形式
ターゲットは，ポーリング要求に対し，図11に示すフレームをポーリング応答として返さなければなら
ない。
プリアンブル
（最低48ビット）
SYNC
（16ビット）
長さ
（8ビット）
ペイロード
CRC
（16 ビット）
“01”
NFCID2
Pad
図11−ポーリング応答のフレーム形式
プリアンブルは，全て論理“0”で48 ビット以上でなければならない。
同期パターン（SYNC）は，2 バイトでなければならない。最初のバイトは，“B2”とし，2番目のバイ
トは“4D”とする。
長さフィールドは，“12”に設定しなければならない。
ペイロードの開始バイトは，“01”に設定しなければならない。ペイロードには，8バイトのNFCID2及
び8バイトのPadを含まなければならない。Padは，情報交換に当たっては無視しなければならない。
CRCは，A.3によって計算しなければならない。
11.3 能動通信モード
11.3.1 fc/128，fc/64及びfc/32での初期化
能動通信モードにおいて，アプリケーションは，イニシエータになり，また，fc/128，fc/64又はfc/32を
選んでもよい。
11.3.2 能動通信モードでのRF衝突回避
図12によってRF衝突回避を実行しなければならない。
− イニシエータは，初期RF衝突回避を実施しなければならない。
− 選択した伝送速度の能動通信モードにおいて，イニシエータが最初に発行する命令は，ATR̲REQと
する。
− イニシエータは，RFフィールドを消滅させなければならない。
− ターゲットは，応答RF衝突回避を実施する。
− ターゲットは，受信したATR̲REQと同じ伝送速度でATR̲RESを返し，RFフィールドを断つ。
− イニシエータは，応答RF衝突回避をn＝0で行う。
− イニシエータは，パラメタ交換のためにPSL̲REQを，又はデータ交換プロトコルを開始するために
DEP̲REQを発行する。
18
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図12−能動通信モードの初期化手順
11.3.2.1 能動通信モードでの衝突回避
フィールドにターゲットが二つ以上存在する場合には，最少のn（タイムピリオド）をもつターゲット
が応答し，他のターゲットは，応答しない。二つ以上のターゲットが同じタイムスロットで応答している
場合には，イニシエータは，衝突を検出し12.5.1.1に示すATR̲REQを再送する。
最初のターゲット応答がイニシエータによって検出された後，イニシエータ及びターゲットは，次の通
信のためにn（タイムピリオド）を0とし利用する。
12 トランスポートプロトコル
トランスポートプロトコルは，次の三つの部分からなる。
− 属性の要求及びパラメタ選択を含むプロトコルの活性化
− データ交換のプロトコル
− 選択解除及び解放を含むプロトコルの非活性化
12.1 トランスポートデータ
ユーザデータは，フレーム形式でトランスポートデータによって伝送しなければならない。図13は，そ
れぞれのフレーム形式でのトランスポートデータフィールドの位置を規定する。
fc/128のフレーム形式の構造は，JIS X 6322-3の6.2.3.2に規定する。開始バイトSBは，“F0”に設定し
なければならない。LENには，伝送データの長さに1を加えた値を設定しなければならない。LENは，3
〜255の範囲でなければならない。E1は，A.1に示すとおりの，fc/128のフレーム形式に対応するCRCと
する。LENをこの値以外に設定することは，この規格では禁止する。
11.2.2.2は，プリアンブル（PA）及び同期パターン（SYNC）を含めてfc/64及びfc/32に対するフレーム
形式の構造を規定する。
LENには，伝送データの長さに1を加えた値を設定しなければならない。LENの値は，3〜255の範囲
としなければならない。E2は，A.3に示すとおりのfc/64及びfc/32のフレーム形式のCRCとする。LEN
をこれ以外の値に設定することは，この規格では禁止する。
19
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
伝送データフィールドは，12.4に規定する必須の命令バイトCMD1及びCMD2，並びにデータバイトバ
イト1〜バイトnからなる。バイト1〜バイトnの内容は，命令バイトCMD2に依存しており，ある種の
情報を含んでもよい。その場合は必須となるが，データバイトは，任意選択とする。
←
トランスポートデータフィールド
→
fc/128の場合の
フレーム形式
SB
LEN
CMD1 CMD2 バイト1 バイト2 バイト3
…
…
バイト
n
E1
←
トランスポートデータフィールド
→
fc/64及びfc/32
の場合のフレ
ーム形式
PA SYNC
LEN
CMD1 CMD2 バイト1 バイト2 バイト3
…
…
バイト
n
E2
図13−転送データフレーム形式
12.2 受動通信モードの活性化手順
次の活性化手順を適用しなければならない。
1) イニシエータは，11.1.1で規定するとおりに初期のRF衝突回避手順を実行しなければならない。
2) イニシエータは，11.2で規定するとおりの選択された伝送速度で，受動通信モードのための初期化
及びSDDを実行しなければならない。
3) NFCIP-1プロトコルの提供は，12.5.1.1で規定するとおりに，属性要求に従って異なる伝送速度で検
査されなければならない。
4) ATR̲REQが提供されてない場合には，ターゲットは，初期化及び単一デバイス検出（SDD）を行
ってもよい。
5) ATR̲REQは，属性要求の受信が利用可能になった後，次の命令としてイニシエータによって送信
してもよい。
6) ターゲットは，ATR̲REQに応答してATR̲RESを送信しなければならない。ターゲットは，選択の
後ATR̲REQを直接に受信した場合には，ATR̲REQの応答だけをしなければならない。
7) ターゲットがATR̲REQのあらゆる変更可能なパラメタを扱える場合には，変更可能なパラメタに
対するATR̲REQを受信した後，次の命令としてPSL̲REQがイニシエータによって使われてもよ
い。
8) ターゲットは，PSL̲REQに応答してPSL̲RESを送信しなければならない。
9) ターゲットは，ATR̲RESの変更可能なパラメタを扱えない場合には，パラメタ選択を補完する必要
はない。
10) 透過的なデータは，データ交換トランスポートプロトコルを使って送信しなければならない。
受動通信モードにおけるターゲットに対するイニシエータ活性化手順を，図14に示す。
12.3 能動通信モードの活性化手順
能動通信モードのプロトコルには，次の活性化手順を適用しなければならない。
1) イニシエータは，11.1.1に規定するとおりに初期のRF衝突回避手順を実行しなければならない。
2) イニシエータは，能動通信モードへ切り替えて，伝送速度を選択しなければならない。
3) イニシエータは，ATR̲REQを送信しなければならない。
4) ターゲットは，ATR̲REQに応答してATR̲RESを送信しなければならない。応答が成功した後で，
デバイスが選択される。
20
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5) イニシエータがデータの衝突を検出する場合には，ATR̲REQを再送しなければならない。
6) ターゲットがATR̲RESの変更可能パラメタを扱う場合には，その変更可能パラメタに対して
ATR̲RESを受信した後，PSL̲REQが，次の命令としてイニシエータに使われてもよい。
7) ターゲットは，PSL̲REQに応答してPSL̲RESを送信しなければならない。
8) ターゲットがATR̲RESの変更可能パラメタを扱わない場合には，パラメタ選択を補完する必要は
ない。
能動通信モードにおけるターゲットに対するイニシエータ活性化手順を，図15に示す。
21
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
開始
初期RFCA
属性要求？
DSL̲RESを受信する。
PSL̲REQを送信する。
PSL̲REQを受信する。
パラメタを変更する。
初
期
化
及
び
衝
突
回
避
プ
ロ
ト
コ
ル
活
性
化
及
び
パ
ラ
メ
タ
選
択
はい
いいえ
受動通信モードになる。
初期化及び
SDDループ
ATR̲REQを送信する。
ATR̲REQを受信する。
パラメタ変更か?
データ交換
プロトコル(DEP)
独自プロトコル
はい
いいえ
DSL̲RESを送信する。
RSL̲RESを受信する。
RSL̲RESを送信する。
図14−受動通信モードでの活性化プロトコル
22
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
開始
初期RFCA
DSL̲RESを受信する。
PSL̲REQを送信する。
PSL̲REQを受信する。
パラメタを変更する。
初
期
化
及
び
衝
突
回
避
プ
ロ
ト
コ
ル
活
性
化
及
び
パ
ラ
メ
タ
選
択
能動通信モードになる。
ATR̲REQを送信する。
ATR̲REQを受信する。
パラメタ変更か?
データ交換
プロトコル(DEP)
はい
いいえ
DSL̲RESを送信する。
RSL̲RESを受信する。
RSL̲RESを送信する。
WUP̲REQを送信する。
WUP̲REQを受信する。
図15−能動通信モードにおける活性化プロトコル
23
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
12.4 命令
命令バイトは，表3に規定されるCMD1及びCMD2から構成される。
表3−NFCIP-1プロトコル命令セット
簡易表記
命令バイト
定義
CMD1
CMD2
ATR̲REQ
“D4”
“00”
属性要求（Attribute Request）
（イニシエータが発行する。）
ATR̲RES
“D5”
“01”
属性応答（Attribute Response）
（ターゲットが発行する。）
WUP̲REQ
“D4”
“02”
起動要求（Wakeup Request）
（能動通信モードの場合にだけイニシエータが発行する。）
WUP̲RES
“D5”
“03”
起動応答（Wakeup Response）
（能動通信モードの場合にだけターゲットが発行する。）
PSL̲REQ
“D4”
“04”
パラメタ選択要求（Parameter Selection Request）
（イニシエータが発行する。）
PSL̲RES
“D5”
“05”
パラメタ選択応答（Parameter Selection Response）
（ターゲットが発行する。）
DEP̲REQ
“D4”
“06”
データ交換プロトコル要求（Data Exchange Protocol Request）
（イニシエータが発行する。）
DEP̲RES
“D5”
“07”
データ交換プロトコル応答（Data Exchange Protocol Response）
（ターゲットが発行する。）
DSL̲REQ
“D4”
“08”
選択解除要求（Deselect Request）
（イニシエータが発行する。）
DSL̲RES
“D5”
“09”
選択解除応答（Deselect Response）
（ターゲットが発行する。）
RLS̲REQ
“D4”
“0A”
解放要求（Release Request）
（イニシエータが発行する。）
RLS̲RES
“D5”
“0B”
解放応答（Release Response）
（ターゲットが発行する。）
12.5 プロトコルの活性化
12.5.1 属性要求及び属性応答命令
12.5.1.1 属性要求（ATR̲REQ）
12.5.1.1は，属性要求（ATR̲REQ）の全てのパラメタを定義する。この命令の構造を図16に示す。イニ
シエータは，選択したターゲットへATR̲REQを送らなければならない。
CMD1
CMD2
バイト 1
…
バイト 10 バイト 11 バイト 12 バイト 13 バイト 14 バイト 15
…
バイト n
“D4” “00” nfcid3i1
… nfcid3i10
DIDi
BSi
BRi
PPi
[Gi(1)]
... [Gi(n-14)]
図16−ATR̲REQの構造
12.5.1.1.1 ATR̲REQの各バイトの定義
CMD1：“D4”に設定しなければならない。
CMD2 (ATR̲REQ)：ATR̲REQバイトは，イニシエータが発行する属性要求命令を意味する。このバイ
トの値は“00”でなければならない。
バイト1〜バイト10 (NFCID3i)：10個のnfcid3iバイトは，イニシエータの乱数識別子NFCID3iを定義
する。NFCID3は，アプリケーションによってダイナミックに生成されたIDであり，一つの通信中は固定
24
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
されている。fc/64及びfc/32の受動通信モードにおいては，NFCID3iをNFCID2tで置き換える。
バイト11 (DIDi)：DIDバイトは，二つ以上のターゲットをもつ多重データ転送プロトコル活性化に対し
て使われる。DIDiの範囲は，1〜14の間で定義される。DIDiがデータ転送プロトコルで使われない場合に
は，このバイトは，値“0”に設定する。この規格では他の値を禁止する。
バイト12 (BSi)：イニシエータデバイスは，BSiバイトの中で，サポートする送信伝送速度（D）を規定
しなければならない。図17に示すようにビット符号化する。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
“0”
“0”
DSi
DSi
DSi
DSi
図17−BSiバイトの符号化
− ビット8〜ビット5：“0”に設定し，他の全ての値は，将来使用するため予約（RFU）とする。
− ビット4：D＝64の能力をもつときDSi＝“1”に設定する。
− ビット3：D＝32の能力をもつときDSi＝“1”に設定する。
− ビット2：D＝16の能力をもつときDSi＝“1”に設定する。
− ビット1：D＝8の能力をもつときDSi＝“1”に設定する。
バイト13 (BRi)：イニシエータデバイスは，BRiバイトの中で，サポートする表1に示す受信伝送速度
を規定しなければならない。図18に示すようにビット符号化する。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
“0”
“0”
DRi
DRi
DRi
DRi
図18−BRiバイトの符号化
− ビット8〜ビット5：“0”に設定し，他の全ての値は，将来使用するため予約（RFU）とする。
− ビット4：D＝64の能力をもつときDRi＝“1”に設定する。
− ビット3：D＝32の能力をもつときDRi＝“1”に設定する。
− ビット2：D＝16の能力をもつときDRi＝“1”に設定する。
− ビット1：D＝8の能力をもつときDRi＝“1”に設定する。
バイト14 (PPi)：PPiバイトは，イニシエータデバイスによって使われるオプションのパラメタを決める。
ビット符号化を図19に示す。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
SECi
RFU
LRi
LRi
RFU
RFU
Gi
NAD
図19−PPiバイトの符号化
− ビット8：SECi。“1”に設定したときNFC-SECの能力をもち，“0”に設定したときNFC-SECの能力
をもたない。
− ビット7：RFU。イニシエータは“0”に設定しなければならない。ターゲットはこのビットを無視し
なければならない。
− ビット6及びビット5：LRi (Length Reduction Value)。表4参照。
25
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表4−LRiの定義
LRi
定義
b “00”
バイト1から64だけが転送データとして有効
b “01”
バイト1から128だけが転送データとして有効
b “10”
バイト1から192だけが転送データとして有効
b “11”
バイト1から252だけが転送データとして有効
− ビット4及びビット3：RFU。イニシエータは，“0”に設定しなければならない。ターゲットはこの
ビットを無視しなければならない。
− ビット2：汎用バイトの利用が可能なとき“1”に設定する。
− ビット0：イニシエータがノードアドレス（NAD）を使うとき“1”に設定する。
バイト15〜バイトn [Gi(1)〜Gi(n-14)]：汎用バイトは，任意選択とし，汎用情報を指定する。ATR̲REQ
命令の最大長から必須バイト数を差し引くと，汎用バイトの最大バイト数になる。
12.5.1.2 属性応答（ATR̲RES）
ATR̲RESは，ATR̲REQに対する応答であり，選択されたNFCIP-1ターゲットデバイスだけが送信しな
ければならない。この命令の構造を図20に示す。
CMD1
CMD2
バイト 1
…
バイト 10 バイト 11 バイト 12 バイト 13 バイト 14 バイト 15 バイト 16
…
バイト n
“D5” “01” nfcid3t1
… nfcid3t10
DIDt
BSt
BRt
TO
PPt
[Gt(1)]
… [Gt(n-14)]
図20−ATR̲RESの構造
12.5.1.2.1 ATR̲RESの各バイトの定義
CMD1：“D5”に設定しなければならない。
CMD2 (ATR̲RES)：ATR̲RESバイトは，イニシエータが発行したATR̲REQに対するターゲットの属
性応答命令を意味する。このバイトの値は，“01”に設定しなければならない。
バイト1〜バイト10 (NFCID3t)：10個のnfcid3tバイトは，ターゲットの乱数識別子NFCID3tを定義す
る。NFCID3は，アプリケーションによって生成されたIDとする。NFCID3の内容は，NFCID1又は NFCID2
の内容と同じでもよい。
バイト11 (DIDt)：DIDtバイトは，二つ以上のターゲットをもつ多重データ伝送プロトコル活性化に使
われる。DIDtは，DIDiと同じ値をもつ。全ての他の値は，この規格では禁じられている。DIDtの用途に
ついては12.5.1.1.1を参照。
バイト12 (BSt)：BStバイトは，ターゲットデバイスが対応可能な伝送速度を示す。図21に示すように
ビット符号化する。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
“0”
“0”
DSt
DSt
DSt
DSt
図21−BStバイトの符号化
− ビット 8〜ビット 5：“0”に設定する。
− ビット 4：D＝64の能力をもつときDSt＝“1”に設定する。
− ビット 3：D＝32の能力をもつときDSt＝“1”に設定する。
− ビット 2：D＝16の能力をもつときDSt＝“1”に設定する。
− ビット 1：D＝8の能力をもつときDSt＝“1”に設定する。
26
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
バイト13 (BRt)：BRtバイトは，ターゲットデバイスが対応可能な伝送速度を示す。図22に示すように
ビット符号化する。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
“0”
“0”
DRt
DRt
DRt
DRt
図22−BRtバイトの符号化
− ビット 8〜ビット 5：“0”に設定する。
− ビット 4：D＝64の能力をもつときDRt＝“1”に設定する。
− ビット 3：D＝32の能力をもつときDRt＝“1”に設定する。
− ビット 2：D＝16の能力をもつときDRt＝“1”に設定する。
− ビット 1：D＝8の能力をもつときDRt＝“1”に設定する。
バイト14 (TO)：TOバイトは，データ伝送プロトコルに対するターゲットNFCIP-1デバイスのタイムア
ウトを示す。タイムアウトの計算は，イニシエータによって送信された最後のビットで始まり，ターゲッ
トによって最初に送信されたビットで終了する。タイムアウトは，図23で与える。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
“0”
“0”
WT
WT
WT
WT
図23−TOバイトの符号化
− ビット 8〜ビット 5：“0”に設定する。
− ビット 4〜ビット 1：待ち時間（WT）。
応答待ち時間［Response Waiting Time (RWT)］は，次の式によって計算する。
RWT＝(256×16/fc)×2WT
ここで，WTの値は，0〜14の範囲とし，15は，RFUとする。WTのデフォルト値は，14とする。
WT＝0の場合，RWT＝RWTMIN (302 µs)
WT＝14の場合，RWT＝RWTMAX (4 949 ms)
バイト15 (PPt)：PPtバイトは，図4に示すターゲットデバイスによって使われる任意選択パラメタを規
定する。図24に示すようにビットを符号化する。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
LRt
LRt
“0”
“0”
Gt
NAD
図24−PPtバイトの符号化
− ビット8及びビット7：“0”に設定する。
− ビット6及びビット5：表5に規定するLRt。
表5−LRtの定義
LRt
定義
b “00”
バイト1から64だけが伝送データとして有効
b “01”
バイト1から128だけが伝送データとして有効
b “10”
バイト1から192だけが伝送データとして有効
b “11”
バイト1から252だけが伝送データとして有効
27
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− ビット 4及びビット 3：“0”に設定する。
− ビット 2：汎用バイトを利用するとき“1”に設定する。
− ビット 1：ターゲットがノードアドレス（NAD）を使うとき“1”に設定する。
バイト16〜バイトn [Gt(1)〜Gt(n-14)]：Gtバイトは，任意選択とし，汎用情報を含む。ATR̲RES命令
の長さから必須バイト長を差し引くと，汎用情報のバイト数となる。
12.5.1.3 ATR̲REQ及びATR̲RESの取扱方法
12.5.1.3.1 イニシエータ規定
イニシエータがATR̲REQ命令を送信し有効なATR̲RES命令を受信するとき，イニシエータは，動作
を継続する。
他の場合，イニシエータは，12.7で規定する非活性化手順を使う前にATR̲REQ命令を再送する。
非活性化手順を失敗した場合には，fc/128での受動通信モードだけHLTA命令を使用してもよい。HLTA
命令は，JIS X 6322-3の6.4.3で規定されている。
12.5.1.3.2 ターゲット規定
ターゲットが最後の命令（受動通信モードでだけ有効）を選択した場合，次による。
a) 有効なATR̲REQ命令を受け取ると，ターゲットは，次の動作を行わなければならない。
− 受信したATR̲REQ命令に対するATR̲RES命令を送信する。
− 引き続いて，ATR̲REQ命令を受信できないようにする。
b) fc/128での受動通信モードだけ，HLTA命令（12.5.1.3.1参照）を除く他の有効な又は無効なフレーム
を受信すると，ターゲットは，次の動作を行わなければならない。
− ブロックを無視する。
− 受信モードにとどまる。
12.5.1.4 タイムアウトTOの取扱方法
はじめに選択されたモードによって，通信は能動又は受動として定義される。タイムアウトの取扱いは
能動通信モードか受動通信モードかによって異なる。
12.5.1.4.1 能動通信モードにおける取扱方法
能動通信モードでの通信フローは，搬送波周波数を切り替えて取り扱われる。
イニシエータ：イニシエータは，ターゲットデバイスからの応答がATR̲REQ命令の中のTOバイトを
使って計算されたRWTを超えるターゲットを無視し，動作を継続しなければならない。
ターゲット：ターゲットは，共通通信を許したTO値を使用し，定義されたRWTを延長するタイムアウ
ト拡張を含む管理PDUを使用しなければならない（12.6.1.1.1参照）。
12.5.1.4.2 受動通信モードにおける取扱方法
受動通信モードでの通信は，通信フローによってだけ取り扱われる。搬送波周波数は，切り替わらない。
イニシエータ：イニシエータは，はじめに誤り処理を行い，応答がなければ指定されたタイムアウトを
超えるターゲットデバイスを無視し，動作を続行しなければならない。
ターゲット：ターゲットは，共通通信を許したTO値を使用し，定義されたRWTを延長するタイムアウ
ト拡張を含む管理PDUを使用しなければならない（12.6.1.1.1参照）。
12.5.1.5 DIDの取扱方法
12.5.1.5.1 能動通信モード及び受動通信モードにおけるDIDの取扱方法
イニシエータは，値が“0”に等しいDIDを含むATR̲REQ命令を送信した場合，次による。
a) 値が“0”に等しいDIDを含むATR̲RES命令を受信した場合。
28
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− DIDを含まないPDUをターゲットに送る。
− 当該ターゲットが選択解除されていない間は，任意の他のターゲットを活性化しない。
b) 値が“0”でないDIDを含むATR̲RES命令を受信した場合。
− エラー処理を継続する。
イニシエータは，値が“0”でないDIDを含むATR̲REQ命令を送信した場合，次による。
a) 同じ値のDIDを含むATR̲RES命令を受信した場合。
− DIDを含むPDUをターゲットに送る。
− 任意の他のターゲットに対してDIDを使用しない。
− 任意の他のターゲットに対してDID＝0を使用しない。
b) 任意の他の値のDIDを含むATR̲RES命令を受信した場合。
− エラー処理を継続する。
12.5.2 起動要求及び起動応答命令
起動要求及び起動応答命令は，能動通信モードのためにだけ規定する。
12.5.2.1 起動要求（WUP̲REQ）
図25は，属性WUP̲REQについてのパラメタバイトを含む起動要求を定義する。イニシエータは，能
動通信モードにいるときだけWUP̲REQをターゲットへ送信する。WUP̲REQは，DSL命令によって非活
性化された明確なターゲットデバイスをNFCID3によって再活性化するのに適用される。
CMD1
CMD2
バイト 1
…
バイト 10
バイト 11
“D4”
“02”
nfcid3t1
…
nfcid3t10
DID
図25−WUP̲REQの構造
12.5.2.1.1 WUP̲REQの各バイトの定義
CMD1：“D4”に設定しなければならない。
CMD2 (WUP̲REQ)：WUP̲REQバイトは，イニシエータが発行する起動要求命令を意味する。このバ
イトの値は“02”でなければならない。
バイト1〜バイト10 (NFCID3t)：10個のnfcid3tバイトはターゲットの乱数識別子として定義される。
WUP̲REQ命令に対し，イニシエータは，ターゲットを起動するために既知のNFCID3t乱数識別子を送る。
バイト 11 (DID)：DIDバイトは，二つ以上のターゲットをもつ多重データ伝送プロトコルの活性化に使
われる。DIDの範囲は，1〜14の間で定義される。DIDがデータ伝送プロトコルの間で使われない場合に
は，このバイトは，値0が設定される。この規格では他の値を禁止する。最後のDSL命令の前に使われる
ときには，イニシエータは，ターゲットに対して異なる値を割り当ててもよい。
12.5.2.2 起動応答（WUP̲RES）
図26は，WUP̲RESの属性に対する起動応答の構成を規定する。WUP̲RESは，WUP̲REQへの応答で，
選択されたNFCIP-1ターゲットデバイスによって送信しなければならない。
CMD1
CMD2
バイト 1
“D5”
“03”
DID
図26−WUP̲RESの構造
12.5.2.2.1 WUP̲RESの各バイトの定義
CMD1：“D5”に設定しなければならない。
29
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
CMD2 (WUP̲RES)：WUP̲RESバイトは，イニシエータが発行したWUP̲REQに対するターゲットの
起動応答命令を意味する。このバイトの値は，“03”でなければならない。
バイト 1 (DID)：DIDバイトは，二つ以上のターゲットをもつ多重データ交換プロトコルの活性化に使
われなければならない。DIDtは，DIDiと同じ値にしなければならない。全ての他の値は，この規格では
禁止とする。
12.5.2.3 WUP̲REQ及びWUP̲RESの取扱方法
12.5.2.3.1 イニシエータ規定
イニシエータがWUP̲REQを送信し，有効なWUP̲RESを受信すると，イニシエータは，動作を継続す
る。
他の場合には，イニシエータは，12.7で規定する非活性化手順を使う前にWUP̲REQを再送する。
受動通信モードでfc/128の非活性化手順を失敗した場合には，HLTA命令を使ってもよい（JIS X 6322-3
の6.4.3参照）。
12.5.2.3.2 ターゲット規定
ターゲットが最後の命令（能動通信モードに対してだけ）によって再選択された場合，次による。
a) そのNFCID3をもつWUP̲REQを受信すると，ターゲットはWUP̲RESを送り，続くWUP̲REQを受
信できないように，無効にしなければならない。
b) fc/128での受動通信モードのためのHLTA命令を除いて，他の有効な又は無効なフレームを受信する
と，ターゲットはブロックを無視し，受信モードにとどまる。
12.5.3 パラメタ選択要求及び応答命令
12.5.3.1 パラメタ選択要求（PSL̲REQ）
イニシエータは図27に示すPSL̲REQ命令を使い，引き続く伝送プロトコルのパラメタを切り替える。
CMD1
CMD2
バイト 1
バイト 2
バイト 3
“D4”
“04”
DID
BRS
FSL
図27−PSL̲REQの構造
12.5.3.1.1 PSL̲REQの各バイトの定義
CMD1：“D4”に設定しなければならない。
CMD2 (PSL̲REQ)：PSL̲REQバイトは，イニシエータが発行するパラメタ選択要求命令を意味する。
このバイトの値は“04”でなければならない。
バイト 1 (DID)：DIDは，ATR又はWUPの間で定義されるDIDと同様でなければならない。
バイト 2 (BRS)：BRSバイトは，図28に示すようにイニシエータ及びターゲットデバイスに対する選
択された伝送速度を指示しなければならない。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
DSi
DSi
DSi
DRi
DRi
DRi
図28−BRSバイトの符号化
− ビット 8及びビット 7：“0”に設定しなければならない。
− ビット 6〜ビット 4：表6に規定するイニシエータからターゲットへのビット持続時間
− ビット 3〜ビット 1：表6に規定するターゲットからイニシエータへのビット持続時間
30
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表6−DRi及びDSiの符号化
DRi及びDSi
約数D
b “000”
1
b “001”
2
b “010”
4
b “011”
8
b “100”
16
b “101”
32
b “110”
64
b “111”
RFU
バイト 3 (FSL)：FSLバイトは，図29のようにフレーム長の最大値を定義する。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
“0”
“0”
“0”
“0”
LR
LR
図29−FSLバイトの符号化
− ビット 8〜ビット 3：全て“0”に設定しなければならない。
− ビット 2及びビット 1：表7に規定するLR。
表7−LRの定義
LR
定義
b “00”
バイト1からバイト64だけが伝送データとして有効
b “01”
バイト1からバイト128だけが伝送データとして有効
b “10”
バイト1からバイト192だけが伝送データとして有効
b “11”
バイト1からバイト252だけが伝送データとして有効
12.5.3.2 パラメタ選択応答（PSL̲RES）
PSL̲RESのフレーム構造は，図30のように規定しなければならない。
CMD1
CMD2
バイト 1
“D5”
“05”
DID
図30−PSL̲RESの構造
12.5.3.2.1 PSL̲RESの各バイトの定義
CMD1：“D5”に設定しなければならない。
CMD2 (PSL̲RES)：PSL̲RESバイトは，イニシエータが発行したPSL̲REQに対するターゲットのパラ
メタ選択応答命令を意味する。このバイトの値は，“05”でなければならない。
バイト 1 (DID)：DIDは，ATR又はWUPの間で定義されたDIDと同じでなければならない。
12.5.3.3 PSL̲REQ及びPSL̲RESの取扱方法
12.5.3.3.1 イニシエータ規定
イニシエータは，ターゲットへPSL̲REQを送信することによって，プロトコルのパラメタを変えても
よい。有効なPSL̲RESを受信すると，イニシエータは，次による。
− 12.1で規定するフォーマットへフレームを変えなければならない。
− 動作を続行しなければならない。
31
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
他の場合は，イニシエータは，12.7で規定する非活性化手順を使う前にPSL̲REQを再送しなければな
らない。
fc/128の受動通信モードで非活性化手順を失敗した場合には，HLTA命令を使ってもよい（12.5.1.3.2参
照）。
12.5.3.3.2 ターゲット規定
ターゲットがATR̲REQを受信し，ATR̲RESを送信した場合，次による。
a) 有効なPSL̲REQを受信すると，ターゲットは，次による。
− PSL̲RESを送信しなければならない。
− PSL̲REQ受入れ動作を停止しなければならない（受信したPSL̲REQへの応答停止）。
− 12.5.3に規定する値へパラメタを変えなければならない。
− 受信モードにとどまらなければならない。
b) 無効なフレームを受信すると，ターゲットは，次による。
− ブロックを無視しなければならない。
− PSL̲REQ受入れ動作を停止しなければならない（受信したPSL̲REQへの応答停止）。
− 現在のフレームにとどまらなければならない。
− 受信モードにとどまらなければならない。
c) PSL̲REQを除いた有効なフレームを受信すると，ターゲットは，次による。
− PSL̲REQ受入れ動作を停止しなければならない（受信したPSL̲REQへの応答停止）。
− 現在のフレームにとどまらなければならない。
− 動作を継続しなければならない。
12.6 データ交換プロトコル
12.6.1 データ交換プロトコル要求及び応答
12.6.1.1 DEP̲REQ及びDEP̲RESの各バイトの定義
プロトコルは，誤り処理をもつブロック指向データ伝送を採用する半二重プロトコルでなければならな
い。一つのフレームに収まらないデータに対しては，連鎖を定義する。プロトコルフレームのフォーマッ
トは，図31によらなければならない。
伝送データフィールド
CMD1
CMD2
バイト 1
バイト 2
バイト 3
バイト 4
バイト 5
…
バイト n
データ交換プロトコルヘッダ
CMD1
CMD2
PFB
[DID]
[NAD]
伝送データバイト
データバ
イト 1
データバ
イト 2
…
データバ
イト n
図31−プロトコルフレームの定義
情報交換において，伝送データフィールドのペイロードの内容は，情報交換する相互間の合意を必要と
する。
12.6.1.1.1 データ交換プロトコルヘッダの定義
CMD1：CMD2がDEP̲REQのとき，CMD1は“D4”に設定しなければならない。CMD2がDEP̲RES
のとき，CMD1は“D5”に設定しなければならない。
32
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
CMD2（DEP̲REQの場合）：DEP̲REQバイトは，イニシエータが発行するデータ交換プロトコル要求
命令を意味する。このバイトの値は，“06”に設定しなければならない。
CMD2（DEP̲RESの場合）：DEP̲RESバイトは，イニシエータが発行したDEP̲REQに対するターゲッ
トのデータ交換プロトコル応答命令を意味する。このバイトの値は，“07”に設定しなければならない。
バイト 1 (PFB)：PFBバイトは，データ伝送及び誤り回復を制御するためのビットを含まなければなら
ない。PFBバイトは，伝送制御を要求する情報を伝えるために使われる。データ交換プロトコルは，これ
の基本的なPDUの型を定義する。
− アプリケーションレイヤに対する情報を伝える情報PDU。
− 肯定又は否定の確認応答を伝えるACK/NACK PDU。ACK/NACK PDUは，データフィールドを含まな
い。確認応答は，最後に受け取ったブロックに関係する。
− ISO/IEC 13157-1におけるNFC-SECを任意選択で利用する保護PDU。
− イニシエータ及びターゲットとの間の制御情報を交換する管理PDU。二つの管理PDUが定義される。
− タイムアウト応答拡張は，1バイト長のデータフィールドを含む。
− アテンションは，データフィールドを含まない。
表8は，PFBの符号化を規定する。
表8−PFBビット8〜6の符号化
ビット 8
ビット 7
ビット 6
PFB
0
0
0
情報PDU
0
0
1
保護PDU
0
1
0
ACK/NACK PDU
1
0
0
管理PDU
その他の設定は，RFU
図32は，情報PDUの構造を規定する。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
“0”
MI
NAD
DID
PNI
PNI
図32−情報PDU
− ビット 8〜ビット 6：全て“0”に設定しなければならない。
− ビット 5：情報PDUの連鎖（MI）を活性化するとき“1”に設定する。
− ビット 4：NADが利用可能なとき“1”に設定する。
− ビット 3：DIDが利用可能なとき“1”に設定する。
− ビット 2及びビット 1：PNIのパケット番号情報。
パケット番号情報（PNI）は，0で始まり，イニシエータからターゲット及びその逆に送信されるパケッ
ト数を数える。これらのバイトは，プロトコルの扱いにおいて誤り検出に使われる。
図33は，ACK/NACK PDUの構造を定義する。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“1”
“0”
ACK/NACK
NAD
DID
PNI
PNI
図33−ACK/NACK PDU
− ビット 8：“0”に設定しなければならない。
33
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− ビット 7：“1”に設定しなければならない。
− ビット 6：“0”に設定しなければならない。
− ビット 5：NACKを示すとき“1”に設定し，ACKを示すとき“0”とする。
− ビット 4：NADが利用可能なとき“1”に設定する。
− ビット 3：DIDが利用可能なとき“1”に設定する。
− ビット 2及びビット1：PNIパケット番号情報。
図34は，管理PDU（アテンション−ターゲットあり，タイムアウト拡張）を定義する。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“1”
“0”
“0”
アテンション／
タイムアウト
NAD
DID
“0”
“0”
図34−管理PDU
− ビット 8：“1”に設定しなければならない。
− ビット 7及びビット 6：“0”に設定しなければならない。
− ビット 5：“0”はアテンション，“1”はタイムアウト拡張を示す。
− ビット 4：NADが有効の場合には，“1”に設定する。
− ビット 3：DIDが有効の場合には，“1”に設定する。
− ビット 2及びビット1：“0”に設定しなければならない。
バイト 2 (DID)：DIDバイトは，プロトコルの活性化の間で定義されるものと同じでなければならない。
バイト 3 (NAD)：NADバイトは，イニシエータ及びターゲットの双方で異なる論理的な結合を確立し
たり，扱ったりするために予約されている。ビット8〜ビット5は，イニシエータの論理アドレスを符号
化し，ビット4〜ビット1は，ターゲットの論理アドレスを符号化する。次の定義は，NADの使用法に適
用されなければならない。
− NADは，データ交換プロトコルに対してだけ使用されなければならない。
− イニシエータがNADを使用するとき，ターゲットもNADを使用しなければならない。
− MIビットがセットされている場合には，NADは，最初のフレームにおいてだけ伝送されなければな
らない。
− イニシエータは，二つの異なるターゲットをアドレスするためにNADを使用してはならない。
バイト4〜バイトn（ユーザデータバイト）：データフィールドは，伝送されたデータを含み，任意選択
とする。データフィールドが存在するときは，アプリケーションデータ又はステータス情報が格納されて
いる。データフィールドの長さは，（伝送データフレーム形式）の長さフィールド（LEN）に格納されてい
る値よりも1少ない値から（トランスポートデータフィールドの）データ交換プロトコルヘッダの必須及
び任意選択バイト数を減じた値になる。
12.6.1.2 PDU番号の取扱方法
12.6.1.2.1 イニシエータ規定
イニシエータのPNIは，それぞれのターゲットに対して全て“0”に初期化されなければならない。
等しいPNIをもつ情報又は確認応答PDUを受信すると，イニシエータは，新しいフレームを送る前に，
そのターゲットに対する現在のPNIを1加算しなければならない。
34
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
12.6.1.2.2 ターゲット規定
ターゲットのPNIは，全て“0”に初期化されなければならない。
等しいPNIをもつ情報又は確認応答PDUを受信すると，ターゲットは，このPNIに応答し，その後に
PNIを1加算しなければならない。
12.6.1.3 ブロックの取扱方法
12.6.1.3.1 一般規定
最初のPDUは，イニシエータによって送信しなければならない。
連鎖ビットをもつデータのPDUを受信した場合には，ACK PDUによって確認応答しなければならない。
管理PDUは，対でだけ使われる。管理要求に対しては，常に管理応答されなければならない。
12.6.1.3.2 イニシエータ規定
無効なPDUを受信すると（DSL又はRLSの場合を除き）NACK PDUを送信しなければならない。
タイムアウトが起こると，（NACKが事前に送信されている場合を除き）アテンション命令を送信しな
ければならない。
タイムアウトが起きNACKが事前に送信されている場合には，NACKを再送信しなければならない。
ACK PDUを受信し，そのPDU数がイニシエータの現在のPNIに等しいならば，連鎖を続けなければな
らない。
DSL̲REQに対する有効なDSL̲RESが返却されなかった場合には，DSL̲REQを再送信してもよいし，
そうでなければそのターゲットからの命令を無視する。
12.6.1.3.3 ターゲット規定
ターゲットは情報PDUの代わりに管理PDU（応答タイムアウト拡張要求）を送信することができる。
連鎖を含まないデータのPDUを受信した場合には，データのPDUによって，確認応答しなければなら
ない。
NACK PDUを受信し，PNIが前に送信したPDUのPNIに等しいならば，前のブロックは再送されなけ
ればならない。
正しくないPDUを受信した場合には，ターゲットは，無応答とし，同じ状態にとどまらなければならな
い。
管理PDU（アテンション命令）を受信した場合には，ターゲットは，管理PDU（アテンション応答）を
送信する。
12.6.2 タイムアウト応答拡張
タイムアウト応答拡張は，ターゲットによってだけ使われる。イニシエータから受け取ったブロックを
処理するのに，ターゲットがRWTに定義されている時間より多くの時間を必要とする場合には，図35で
示す応答タイムアウト拡張要求を使った管理PDUを使う。応答のタイムアウト拡張要求は，1バイト長の
データフィールドを含む。そのバイトの定義は，図35に示される。
ビット 8
ビット 7
ビット 6
ビット 5
ビット 4
ビット 3
ビット 2
ビット 1
“0”
“0”
RTOX
RTOX
RTOX
RTOX
RTOX
RTOX
図35−応答タイムアウト拡張バイト
− ビット 8及びビット 7：“0”に設定しなければならない。
− ビット 6〜ビット 1：RTOX 値。
RTOXに対して値0及び60〜63は，RFUとする。他の全ての値に対しては，RWTINT（拡張された応答
35
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
待ち時間）が，次の式によって計算されなければならない。
RWTINT＝RWT×RTOX
RWTINTは，イニシエータがターゲットに対してそのRTOX応答を返信した後に，始まる。RWTINTが
RWTMAXを超えた場合には，RWTMAXが使われなければならない。RWTINTは，次のフレームをイニシエー
タによって受信するまで有効とする。
12.6.3 アテンション−ターゲットの存在
ターゲットがまだ受動通信モードの状態にあることを保証するため，又は複数活性化の間にターゲット
ロスを検出できるために，イニシエータは，ターゲットにアテンション命令を送信しなければならない。
この命令は，現在のターゲットの状態を変えてはならない。
ターゲットは，有効なアテンション要求に対して同じ情報フィールドを含むアテンション命令で，イニ
シエータに対して応答しなければならない。
ターゲットが正しくないPDUを受信した場合には，応答せず，同じ状態にとどまらなければならない。
12.6.4 プロトコル操作方法
活性化の後，イニシエータだけが送信する権利をもっているので，ターゲットは，ブロックを待たなけ
ればならない。ブロックを送った後，イニシエータは，受信モードに切り替えなければならない。そして
送信モードに戻る前にブロックを待たなければならない。
ターゲットは，受信ブロックに応答する場合にだけ，ブロックを送信してもよい。応答の後，ターゲッ
トは，受信モードに戻らなければならない。
イニシエータは，現在の要求及び応答の対が完了するか又はフレーム待機時間を応答なしで経過するま
では，新しい要求及び応答の対を開始してはならない。
12.6.5 複数活性化
複数活性化機能によって，イニシエータは複数のターゲットを同時に活性化状態に保つことができる。
これによって，イニシエータは，あるターゲットの非活性化の時間及び別のターゲットの活性化の時間を
要することなく，複数のターゲットを切り替えることができる。
複数活性化の例を表9に示す。イニシエータは，それぞれの活性化されたターゲットに対し異なるパケ
ット番号情報（PNI）を取り扱う必要がある。
36
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表9−複数活性化
イニシエータの動作
ターゲット1の状態 ターゲット2の状態 ターゲット3の状態
能動モードを選択する。
DID = 1でターゲット1を活性化する。
(1)選択済み
センス
センス
DID = 1による通信
(1)選択済み
センス
センス
…
DID = 2でターゲット2を活性化する。
(1)選択済み
(2)選択済み
センス
DID = 1及び2による通信
(1)選択済み
(2)選択済み
センス
…
DID = 3でターゲット3を活性化する。
(1)選択済み
(2)選択済み
(3)選択済み
DID = 1，2及び3による通信
(1)選択済み
(2)選択済み
(3)選択済み
…
DID = 1による選択解除を行う。
スリープ
(2)選択済み
(3)選択済み
DID = 2及び3による通信
スリープ
(2)選択済み
(3)選択済み
…
DID = 2による選択解除を行う。
スリープ
スリープ
(3)選択済み
DID = 3による通信
スリープ
スリープ
(3)選択済み
…
DID = 3で選択解除を行う。
スリープ
スリープ
スリープ
…
12.6.6 長大データの転送（連鎖）
連鎖の機能によって，イニシエータ又はターゲットは，一つのブロックに入らない情報を複数のブロッ
クに分割して転送できる。それぞれのブロックは，最大フレームサイズ（LENMAX）以下の長さでなければ
ならない。
プロトコルフレームのPFBバイトの連鎖ビットによってフレームの連鎖を制御する。連鎖ビットをもつ
それぞれのフレームは，ACK PDUによって応答されなければならない。
連鎖の機能を，16バイト長の文字列を三つのブロックに分けて転送する例を用いて図36に示す。
37
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
0123456
789ABC
DEF
回答
PFB
(10)
0123456
EDC
PFB
(11)
789ABC
EDC
PFB
(02)
DEF
EDC
PFB
(40)
EDC
PFB
(41)
EDC
S(ACK)
S(ACK)
PFB
(02)
回答
EDC
0123456
789ABC
DEF
回答
0
1
受信
送信
受信
送信
図36−長大データ（連鎖）
12.7 プロトコルの非活性化
データ交換プロトコルを使ったデータの交換の後，イニシエータは，データ交換プロトコルを非活性化
してもよい。選択解除の後イニシエータ及びターゲットは，はじめに選ばれた状態にとどまらなければな
らないが，イニシエータは，再活性化に定義された伝送速度の一つを選んでもよい。
受動モード及び能動モードにおける，それぞれのターゲットの再活性化はJIS X 6322-3の6.4.1及び
12.5.2を参照する。
選択解除が成功した後，ターゲットは，続くATR̲REQ命令に応答してはならない。
RLS̲REQ命令は，ターゲットを電源投入済みの状態へ切り替えなければならない（12.7.2.1参照）。こ
の状態では，ターゲットは全ての初期通信方式に応答しなければならず，また，ATR̲REQにも応答しな
ければならない。
12.7.1 選択解除要求命令及び選択解除応答命令
12.7.1.1 選択解除要求命令（DSL̲REQ）
図37は，選択解除要求命令DSL̲REQを定義する。DSL̲REQは，イニシエータからターゲットへ送信
する。
CMD1
CMD2
バイト 1
“D4”
“08”
[DID]
図37−DSL̲REQの構造
12.7.1.1.1 DSL̲REQバイトの定義
CMD1：“D4”に設定しなければならない。
CMD2 (DSL̲REQ)：DSL̲REQバイトは，イニシエータからターゲットの選択解除要求命令を意味する。
38
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
このバイトの値は，“08”でなければならない。
バイト 1 (DID)：DIDは，ATR命令又はWUP命令の間で定義されるものと同じでなければならない。
12.7.1.2 選択解除応答命令（DSL̲RES）
図38は，選択解除応答命令DSL̲RESを定義する。DSL̲RESはDSL̲REQに応答し，ターゲットから
イニシエータへ送られる。
CMD1
CMD2
バイト 1
“D5”
“09”
[DID]
図38−DSL̲RESの構造
12.7.1.2.1 DSL̲RESバイトの定義
CMD1：“D5”に設定しなければならない。
CMD2 (DSL̲RES)：DSL̲RESバイトは，ターゲットの選択解除応答命令を意味する。このバイトの値
は，“09”でなければならない。
バイト 1 (DID)：DIDは，DSL̲REQでの値と同じでなければならない。
12.7.1.3 DSL̲REQ及びDSL̲RESの取扱方法
12.7.1.3.1 イニシエータ規定
イニシエータがDSL̲REQを送り，有効なDSL̲RESを受け取れば，ターゲットは完全に停止している。
ターゲットへ割り当てられたDIDは，解放される。
12.7.1.3.2 ターゲット規定
ターゲットがDSL̲REQを受信し，そのDSL̲RESを送信すると，ターゲットは，次による。
− はじめに選ばれたモードにとどまらなければならない。
− 11.2で定義の受動通信モード及び11.3で定義の能動通信モードで規定したデフォルトの伝送速度を受
信できなければならない。
− fc/128の受動通信モードで有効なALL̲REQを受信するまで，又は能動通信モードでWUP̲REQを受
信するまで，受信モードにとどまらなければならない。
12.7.2 解放要求命令及び解放応答命令
12.7.2.1 解放要求命令（RLS̲REQ）
図39は，解放要求命令RLS̲REQを定義する。RLS̲REQは，イニシエータからターゲットへ送信する。
CMD1
CMD2
バイト 1
“D4”
“0A”
[DID]
図39−RLS̲REQの構造
12.7.2.1.1 RLS̲REQバイトの定義
CMD1：“D4”に設定しなければならない。
CMD2 (RLS̲REQ)：RLS̲REQバイトは，イニシエータからターゲットを解放する命令を意味する。こ
のバイトの値は，“0A”でなければならない。
バイト1 (DID)：DIDは，ATR又はWUP命令で定義されたものと同じでなければならない。
12.7.2.2 解放応答命令（RLS̲RES）
図40は，解放応答命令RLS̲RESを定義する。RLS̲RESは，RLS̲REQに対する応答で，ターゲットか
らイニシエータへ送られる。
39
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
CMD1
CMD2
バイト 1
“D5”
“0B”
[DID]
図40−RLS̲RESの構造
12.7.2.2.1 RLS̲RESバイトの定義
CMD1：“D5”に設定しなければならない。
CMD2 (RLS̲RES)：RLS̲RESバイトは，ターゲットの解放応答命令を意味する。このバイトの値は“0B”
でなければならない。
バイト1 (DID)：DIDは，RLS̲REQ命令で定義されたものと同じでなければならない。
12.7.2.3 RLS̲REQ及びRLS̲RESの取扱方法
12.7.2.3.1 イニシエータ規定
イニシエータがRLS̲REQを送り，有効なRLS̲RESを受け取れば，ターゲットは，完全に解放されてい
る。イニシエータは，初期状態へ戻ってもよい。
12.7.2.3.2 ターゲット規定
ターゲットは，RLS̲REQを受信し，そのRLS̲RESを送信すると，初期状態へ戻らなければならない。
40
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書A
（規定）
CRC計算
A.1 fc/128における能動及び受動通信モードのCRC
フレームCRCは，パリティビット，S，E及びCRC自身を除くフレームに含まれる全データビットから
なるk個のデータビットの関数でなければならない。データは，バイト符号化されるので，ビットkの数
は，8の倍数にしなければならない。誤り検出のために，そのバイトの後及びEの前，標準フレーム中で
二つのCRCバイトが送信されなければならない。CRCは，次の式で計算しなければならない。初期値は
“6363”とし，レジスタの内容を計算後に反転してはならない。
1
)
(
5
12
16
＋
＋
＋
x
x
x
x
G
=
fc/128における能動及び受動通信モードのCRC計算の例を，A.2に示す。
A.2 fc/128におけるCRC計算例
この例は，説明を目的としており，物理的層に存在するビットパターンを示している。fc/128のデータ
伝送速度を選択した場合の符号化の受動通信モードの実装の確認も兼ねている。
符号化及び復号のプロセスは，適切な帰還ゲートで構成される16段巡回シフトレジスタによって実現し
てもよい。ITU-T勧告（ITU-T V.41，Code-independent error-control system）の附属書I，図I-1/V.41及び図
I-2/V.41によれば，レジスタのフリップフロップは，“FF1”〜“FF16”と付番されなければならない。“FF1”
は，データがシフトインする最も下位のフリップフロップでなければならない。“FF16”は，データがシ
フトアウトする最も上位のフリップフロップでなければならない。表A.1は，レジスタの初期値を示す。
表A.1−値“6363”による16段シフトレジスタの初期値
FF1
FF2
FF3
FF4
FF5
FF6
FF7
FF8
FF9 FF10 FF11 FF12 FF13 FF14 FF15 FF16
0
1
1
0
0
0
1
1
0
1
1
0
0
0
1
1
したがって，“FF1”がmsbに，“FF16”がlsbに該当する。
標準フレームによって伝送されるビットパターンの例を，次に示す。
例1：（図A.1参照）
データの伝送，先頭バイト＝“00”，次のバイト＝“00”，CRC付加。
計算されたCRCの値＝“1EA0”（表A.2参照）
転送される先頭のビット
S
0000 0000
1
0000 0000
1
0000 0101
1
0111 1000
1 E
“00”
P
“00”
P
“A0”
P
“1E”
P
図A.1−CRC符号化の例1
41
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表A.2−値“1EA0”による16段シフトレジスタの内容
FF1
FF2
FF3
FF4
FF5
FF6
FF7
FF8
FF9 FF10 FF11 FF12 FF13 FF14 FF15 FF16
0
0
0
1
1
1
1
0
1
0
1
0
0
0
0
0
例2：（図A.2参照）
データブロックの転送，先頭バイト＝“12”，次のバイト＝“34”，CRC付加。
計算されたCRC値＝“CF26”（表A.3参照）
転送される先頭のビット
S
0100 1000
1
0010 1100
0
0110 0100
0
1111 0011
1 E
“12”
P
“34”
P
“26”
P
“CF”
P
図A.2−CRC符号化の例2
表A.3−値“CF26”による16段シフトレジスタの内容
FF1
FF2
FF3
FF4
FF5
FF6
FF7
FF8
FF9 FF10 FF11 FF12 FF13 FF14 FF15 FF16
1
1
0
0
1
1
1
1
0
0
1
0
0
1
1
0
A.3 fc/64及びfc/32における能動通信モード及び受動通信モードのCRC
CRCは，CCITT CRC-16に従って計算しなければならない。その計算対象の範囲は，長さフィールド及
びペイロードフィールドが含まれる。計算式G(x)は，次による。
1
)
(
5
12
16
＋
＋
＋
x
x
x
x
G
=
初期値は，0でなければならない。fc/64及びfc/32における能動及び受動通信モードのCRC計算例をA.4
に示す。
A.4 fc/64及びfc/32におけるCRC計算例
例えば，フレームが“00” “00” “00” “00” “00” “00” “B2” “4D” “03” “AB” “CD”
“90” “35”のとき，SYNCが“B2” “4D”，長さが“03”，ユーザデータが“AB” “CD”で，CRC
は“90” “35”となる。
42
X 5211：2015 (ISO/IEC 18092：2013)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書B
（参考）
SAK
図B.1は，JIS X 6322規格群及びJIS X 5211で使用するSAK設定値の組合せを図示する。
図B.1−SAK値の組合せ
JIS X 6322規格群 A型
開始
REQAを送信
ATQAを受信
カスケードレベル1
を選択
ビットフレーム衝突
回避ループを実行
カスケードレベルを
増やす。
SAK
b3＝“0”及びb6＝“1”
b3＝“1”
UIDが
不完全
UIDが完全，106 kbit/sを選択し，JIS X
6322-4に適応したNFCIP-1ターゲット
JIS X 6322-4のA型に定義された
命令及びプロトコルを処理
SAK
b3＝“0”及びb6＝“0”
b7＝“1”
JIS X 6322規格群とJIS X 5211で定義されて
いない命令及びプロトコル
JIS X 5211 トランスポートプロトコル
b7＝“0”
UIDが完全，106 kbit/sを選択
し，JIS X 5211のトランスポ
ートプロトコルに未適応な
NFCIP-1ターゲット