---
title: "\"ГОСТ Р ИСО/МЭК 18092-2015. Национальный стандарт Российской Федерации. Информационные технологии. Телекоммуникации и обмен информацией между системами. Коммуникация в ближнем поле. Интерфейс и протокол (NFCIP-1)\""
number: "ГОСТ Р ИСО/МЭК 18092-2015"
issuer: "Федеральное агентство по техническому регулированию и метрологии"
status: действует
canonical: "https://bukva.ai/docs/gost-r-isomek-18092-2015"
---

## "ГОСТ Р ИСО/МЭК 18092-2015. Национальный стандарт Российской Федерации. Информационные технологии. Телекоммуникации и обмен информацией между системами. Коммуникация в ближнем поле. Интерфейс и протокол (NFCIP-1)"

# "ГОСТ Р ИСО/МЭК 18092-2015. Национальный стандарт Российской Федерации. Информационные технологии. Телекоммуникации и обмен информацией между системами. Коммуникация в ближнем поле. Интерфейс и протокол (NFCIP-1)"

(утв. и введен в действие Приказом Росстандарта от 31.08.2015 N 1227-ст)

> [!IMPORTANT]
> Документ [введен](#p100009) в действие с 1 ноября 2016 года.


<a id="p100001"></a>Утвержден и введен в действие
Приказом Федерального агентства
по техническому регулированию
и метрологии
от 31 августа 2015 г. N 1227-ст

<a id="p100002"></a>**НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ**

<a id="p100003"></a>**ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ**

<a id="p100004"></a>**ТЕЛЕКОММУНИКАЦИИ И ОБМЕН ИНФОРМАЦИЕЙ МЕЖДУ СИСТЕМАМИ.**
**КОММУНИКАЦИЯ В БЛИЖНЕМ ПОЛЕ. ИНТЕРФЕЙС И ПРОТОКОЛ (NFCIP-1)**

<a id="p100005"></a>Information technology. Telecommunications and information
exchange between systems. Field Communication. Interface
and Protocol (NFCIP-1)

<a id="p100006"></a>**ISO/IEC 18092:2013**
Information technology - Telecommunications and information
exchange between systems - Field Communication - Interface
and Protocol (NFCIP-1)
**(IDT)**

<a id="p100007"></a>**ГОСТ Р ИСО/МЭК 18092-2015**

<a id="p100008"></a>ОКС 35.100.10

<a id="p100009"></a>Дата введения
1 ноября 2016 года


### <a id="p100010"></a>Предисловие


<a id="p100011"></a>1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием Государственный научно-исследовательский и конструкторско-технологический институт "ТЕСТ" (ФГУП ГосНИИ "ТЕСТ"), Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в [пункте 4](#p100014)
<a id="p100012"></a>2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"
<a id="p100013"></a>3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 31 августа 2015 г. N 1227-ст
<a id="p100014"></a>4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 18092:2013 "Информационные технологии. Телекоммуникации и обмен информацией между системами. Коммуникация в ближнем поле. Интерфейс и протокол (NFCIP-1)" [ISO/IEC 18092:2013 "Information technology - Telecommunications and information exchange between systems - Field Communication - Interface and Protocol (NFCIP-1)"].
<a id="p100015"></a>При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном [приложении ДА](#p101560)
<a id="p100016"></a>**5 ВВЕДЕН ВПЕРВЫЕ**

<a id="p100017"></a>Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)


### 1. <a id="p100018"></a>Область применения


<a id="p100019"></a>Настоящий стандарт определяет режимы индуктивной связи устройств, работающих на центральной частоте 13,56 МГц, для подключения компьютерной периферии посредством интерфейса и протокола коммуникации в ближнем поле (NFCIP-1). А также настоящий стандарт определяет для интерфейса и протокола коммуникации в ближнем поле (NFCIP-1) как активный, так и пассивный режимы связи для реализации коммуникационной сети для сетевой и бытовой техники на основе устройств с возможностью коммуникации в ближнем поле. В частности, настоящий стандарт определяет схемы модуляции, кодирования, скорости передачи и радиочастотную структуру интерфейса устройств NFC, а также схемы инициализации и условия, необходимые для контроля за конфликтными ситуациями во время инициализации. Кроме того, настоящий стандарт определяет протокол передачи, включая протокол активации и способ обмена данными.
<a id="p100020"></a>Обмен информацией между системами требует совпадения у обменивающихся сторон, как минимум, кодов обмена и структуры данных.


### 2. <a id="p100021"></a>Соответствие


<a id="p100022"></a>Система, реализующая активный и пассивный режимы связи, будет соответствовать требованиям настоящего стандарта, если она отвечает всем обязательным требованиям, указанным в настоящем стандарте.
<a id="p100023"></a>Возможно также реализовать опцию NFC-SEC, как указано в стандарте ИСО/МЭК 13157-1.


### 3. <a id="p100024"></a>Нормативные ссылки


<a id="p100025"></a>В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
<a id="p100026"></a>МСЭ-Т V.41:1988 Кодонезависимая система защиты данных от ошибок (ITU-T V.41:1988 Code-independent error-control system)
<a id="p100027"></a>ИСО/МЭК 13157-1:2010 Информационные технологии. Телекоммуникации и обмен информацией между системами. Безопасность NFC. Часть 1. Службы и протокол безопасности NFC-SEC NFCIP-1 (ISO/IEC 13157-1:2010 Information technology - Telecommunications and information exchange between systems - NFC Security - Part 1: NFC-SEC NFCIP-1 security services and protocol)
<a id="p100028"></a>ИСО/МЭК 14443-2:2010 Карточки идентификационные. Бесконтактные карточки на интегральных схемах. Бесконтактные карточки. Часть 2. Мощность высокочастотного сигнала и сигнальный интерфейс (ISO/IEC 14443-2:2010 Identification cards - Contactless integrated circuit cards - Proximity cards - Part 2: Radio frequency power and signal interface)
<a id="p100029"></a>ИСО/МЭК 14443-3:2011 Карточки идентификационные. Бесконтактные карточки на интегральных схемах. Карточки с индуктивной связью через малый зазор. Часть 3. Инициализация и антиконфликтность (ISO/IEC 14443-3:2011 Identification cards - Contactless integrated circuit cards - Proximity cards - Part 3: Initialization and anticollision)
<a id="p100030"></a>ИСО/МЭК 14443-4:2008 Идентификационные карточки. Бесконтактные карточки на интегральных схемах. Карточки с индуктивной связью через малый зазор. Часть 4. Протокол передачи (ISO/IEC 14443-4:2008 Identification cards - Contactless integrated circuit cards - Proximity cards - Part 4: Transmission protocol)


### 4. <a id="p100031"></a>Термины и определения


<a id="p100032"></a>В настоящем стандарте использованы следующие термины с соответствующими определениями.
<a id="p100033"></a>4.1 активный режим связи (active communication mode): Режим, в котором как Инициатор, так и Цель используют собственное радиочастотное поле для осуществления связи.
<a id="p100034"></a>4.2 АМн-модуляция (ASK modulation): Амплитудная манипуляция, при которой амплитуда несущей частоты модулируется по логике передаваемых данных.
<a id="p100035"></a>4.3 Двоично-десятичный код BCD (Binary Coded Decimal): Система для представления каждого десятичного числа от 0 до 9 в виде четырехразрядного двоичного кода.
<a id="p100036"></a>*Примечание* - Двоичные разряды (биты), слева направо, равняются 8, 4, 2 и 1, соответственно, в десятичных числах. Так, например, число 6 в BCD будет выглядеть как 0110.

<a id="p100037"></a>4.4 конфликт (collision): Передача информации одновременно от двух или более Целей или Инициаторов, в результате чего принимающий такую информацию Инициатор или Цель не в состоянии распознать, от которого именно источника эти данные поступили.
<a id="p100038"></a>4.5 кадр (frame): Последовательность битов данных и дополнительные биты обнаружения ошибок с разделителями в начале и в конце кадра.
<a id="p100039"></a>4.6 HПороговое (HThreshold): Пороговое значение напряженности поля для обнаружения внешнего излучения радиочастотного поля.
<a id="p100040"></a>4.7 Инициатор (Initiator): Генерирует радиочастотное поле и начинает связь по NFCIP-1.
<a id="p100041"></a>4.8 нагрузочная модуляция (load modulation): Процесс амплитудной модуляции радиочастотного поля за счет изменения свойств резонансного контура, помещенного внутрь радиочастотного поля.
<a id="p100042"></a>4.9 младшим битом вперед (lsb first, least significant bit first): Структура посимвольной передачи данных, где lsb передается прежде, чем все другие биты.
<a id="p100043"></a>4.10 младшим байтом вперед (LSB first, Least Significant Byte first): Структура посимвольной передачи данных, где LSB передается прежде, чем все другие байты.
<a id="p100044"></a>4.11 Манчестерское кодирование (Manchester coding): Метод двоичного кодирования, при котором логический уровень на протяжении длительности бита представлен последовательностью двух определенных физических состояний коммуникационной среды.
<a id="p100045"></a>4.12 коэффициент модуляции (modulation index): Отношение разности между максимальным и минимальным значениями амплитуд модулированного сигнала к сумме этих значений, выраженное в процентах.
<a id="p100046"></a>4.13 старшим битом вперед (msb first, most significant bit first): Структура посимвольной передачи данных, где msb передается прежде, чем все другие биты.
<a id="p100047"></a>4.14 старшим байтом вперед (MSB first, Most Significant Byte first): Структура посимвольной передачи данных, где MSB передается прежде, чем все другие байты.

#### <a id="p100048"></a>4.15 NFCIP-1-устройство (NFCIP-1 device): Объект настоящего стандарта.

<a id="p100049"></a>4.16 NFC-идентификатор (NFC Identifier, NFCIDn): Число, сгенерированное случайным образом, которое используется Избежанием радиочастотных конфликтов и Обнаружением единственного устройства как для активного, так и для пассивного режимов связи.
<a id="p100050"></a>4.17 NFC-SEC: Службы и протокол безопасности NFCIP-1 в соответствии со стандартом ИСО/МЭК 13157-1.
<a id="p100051"></a>4.18 пассивный режим связи (passive communication mode): Когда Инициатор генерирует радиочастотное поле, а Цель отвечает на команду Инициатора по схеме нагрузочной модуляции.
<a id="p100052"></a>4.19 Избежание радиочастотных конфликтов (RF Collision Avoidance, RFCA): Способ обнаружить наличие радиочастотного поля на основе несущей частоты, а также метод обнаружения и устранения конфликтов на уровне протокола.
<a id="p100053"></a>4.20 SAK (Select Acknowledge): Подтверждение выбора в соответствии со стандартом ИСО/МЭК 14443-3.
<a id="p100054"></a>*Примечание* - Термин SAK заменяет термин SEL_RES из ИСО/МЭК 18092:2004.

<a id="p100055"></a>4.21 зондирование (sensing): NFCIP-1-устройство в активном режиме связи ожидает ответ на запрос, отправленный им в радиочастотном поле для обнаружения начала коммуникации и приема данного запроса.
<a id="p100056"></a>4.22 Обнаружение единственного устройства (Single Device Detection, SDD): Алгоритм, используемый Инициатором для того, чтобы обнаружить одну из нескольких Целей в радиочастотном поле (антиконфликтность по ИСО/МЭК 14443-3).
<a id="p100057"></a>4.23 Цель (Target): Отвечает на команду Инициатора либо по схеме нагрузочной модуляции (радиочастотное поле сгенерировано Инициатором), либо с помощью модуляции собственного сгенерированного радиочастотного поля.
<a id="p100058"></a>4.24 Временной период (Time Period): Определяет количество слотов (интервалов времени), используемых для Избежания радиочастотных конфликтов.
<a id="p100059"></a>4.25 Временной интервал (Time Slot): Метод подготовки временного окна, когда Цель отвечает, а также назначения и идентификации двух или более логических каналов.
<a id="p100060"></a>4.26 транзакция (transaction): Инициализация, обмен данными и деселекция устройства.


### 5. <a id="p100061"></a>Соглашения и обозначения


<a id="p100062"></a>В настоящем стандарте применены следующие соглашения и обозначения, если не указано иное.

#### <a id="p100063"></a>5.1 Представления чисел

<a id="p100064"></a>Буквы и цифры в одинарных кавычках представляют собой числа в шестнадцатеричной системе счисления.
<a id="p100065"></a>Установка битов обозначается НУЛЕМ или ЕДИНИЦЕЙ.
<a id="p100066"></a>Числа в двоичной системе счисления и битовые комбинации представлены строками, состоящими из цифр 0 и 1, со старшим битом слева. Внутри таких строк может использоваться знак X с целью указать, что установка бита не указана внутри строки. Например, (XXXX)b.

#### <a id="p100067"></a>5.2 Названия

<a id="p100068"></a>Названия базовых элементов, например конкретных областей, пишутся с прописной начальной буквы.


### 6. <a id="p100069"></a>Сокращения


<a id="p100070"></a>В настоящем стандарте применены следующие сокращения.
<a id="p100071"></a>ALL_REQ - Wake up ALL Request (Запрос на побудку ВСЕХ);
<a id="p100072"></a>ATR - Attribute Request and Attribute Response (Запрос на атрибут и реакция на атрибут);
<a id="p100073"></a>ATR_REQ - Attribute Request (Запрос на атрибут);
<a id="p100074"></a>ATR_RES - Attribute Response (Реакция на атрибут);
<a id="p100075"></a>BCD - Binary Code Decimal (Двоично-десятичный код);
<a id="p100076"></a>BRi - Receiving bit duration supported by Initiator (Прием длительности бита, поддерживаемой Инициатором);
<a id="p100077"></a>BRt - Receiving bit duration supported by Target (Прием длительности бита, поддерживаемой Целью);
<a id="p100078"></a>BSi - Sending bit duration supported by Initiator (Передача длительности бита, поддерживаемой Инициатором);
<a id="p100079"></a>BSt - Sending bit duration supported by Target (Передача длительности бита, поддерживаемой Целью);
<a id="p100080"></a>CMD - Command (Команда);
<a id="p100081"></a>CRC - Cyclic Redundancy Check (Циклический избыточный код);
<a id="p100082"></a>D - Divisor (Делитель);
<a id="p100083"></a>DEP - Data Exchange Protocol Request and Data Exchange Protocol Response (Запрос на протокол обмена данными и ответ на протокол обмена данными);
<a id="p100084"></a>DEP_REQ - Data Exchange Protocol Request (Запрос на протокол обмена данными);
<a id="p100085"></a>DEP_RES - Data Exchange Protocol Response (Ответ на протокол обмена данными);
<a id="p100086"></a>DIDi - Initiator Device ID (Идентификатор устройства Инициатора);
<a id="p100087"></a>DIDt - Target Device ID (Идентификатор Целевого устройства);
<a id="p100088"></a>DRi - Data rate Received by Initiator (Скорость передачи данных, полученных Инициатором);
<a id="p100089"></a>DRt - Data rate Received by Target (Скорость передачи данных, полученных Целью);
<a id="p100090"></a>DSi - Data rate Send by Initiator (Скорость передачи данных, отправленных Инициатором);
<a id="p100091"></a>DSL - Deselect Request and Deselect Response (Запрос на деселекцию и ответ на деселекцию);
<a id="p100092"></a>DSL_REQ - Deselect Request (Запрос на деселекцию);
<a id="p100093"></a>DSL_RES - Deselect Response (Ответ на деселекцию);
<a id="p100094"></a>DSt - Data rate Send by Target (Скорость передачи данных, отправленных Целью);
<a id="p100095"></a>etu - elementary time unit (Элементарная единица времени);
<a id="p100096"></a>fc - Frequency of operating field (carrier frequency) [Частота рабочего поля (несущая частота)];
<a id="p100097"></a>fd - Baseband frequency of Manchester coding (Групповая частота Манчестерского кодирования);
<a id="p100098"></a>fs - Subcarrier (Поднесущая частота по ИСО/МЭК 14443-2);
<a id="p100099"></a>FRT - Frame Response Time (Время отклика кадра);
<a id="p100100"></a>Gi - Optional information field for Initiator (Необязательное информационное поле для Инициатора);
<a id="p100101"></a>Gt - Optional information field for Target (Необязательное информационное поле для Цели);
<a id="p100102"></a>HLTA - HaLT command, Type A (Команда HaLT, Тип A по ИСО/МЭК 14443-3);
<a id="p100103"></a>ID - Identification number (Идентификационный номер);
<a id="p100104"></a>lsb - least significant bit (Младший бит);
<a id="p100105"></a>LSB - Least Significant Byte (Младший байт);
<a id="p100106"></a>MI - Multiple Information link for Data Exchange Protocol (Линк Многокомпонентная информация для протокола обмена данными);
<a id="p100107"></a>msb - most significant bit (Старший бит);
<a id="p100108"></a>MSB - Most Significant Byte (Старший байт);
<a id="p100109"></a>NAD - Node Address (Адрес узла);
<a id="p100110"></a>NFCID1 - fc/128 UID;
<a id="p100111"></a>nfcid1n - Byte number n of NFCID1 (Байт номер n NFCID1);
<a id="p100112"></a>NFCID2 - Random ID for SDD in Passive communication mode at fc/64 and fc/32 bit rates (Произвольный идентификатор для SDD в пассивном режиме связи на скоростях передачи данных fc/64 и fc/32);
<a id="p100113"></a>nf<sub>cid2</sub>n - Byte number n of the Random Identifier NFCID2 (Байт номер n произвольного идентификатора NFCID2);
<a id="p100114"></a>NFCID3 - Random ID for transport protocol activation (Произвольный идентификатор для активации транспортного протокола);
<a id="p100115"></a>nfcid3n - Byte number n of the Random Identifier NFCID3 (Байт номер n произвольного идентификатора NFCID3);
<a id="p100116"></a>P - Odd parity bit (Бит проверки на нечетность);
<a id="p100117"></a>PA - Preamble (Преамбула);
<a id="p100118"></a>PCD - Proximity Coupling Device (Устройство связи через малый зазор по ИСО/МЭК 14443-2);
<a id="p100119"></a>pdu - protocol data unit (Блок данных протокола);
<a id="p100120"></a>PFB - Control information for transaction (Управляющая информация для транзакции);
<a id="p100121"></a>PICC - Proximity Card (Proximity Integrated Circuit Card) or object (Бесконтактная карта или объект по ИСО/МЭК 14443-2);
<a id="p100122"></a>PNI - Packet Number Information (Информация о номере пакета);
<a id="p100123"></a>PPi - Protocol Parameters used by Initiator (Параметры протокола, используемые Инициатором);
<a id="p100124"></a>PPt - Protocol Parameters used by Target (Параметры протокола, используемые Целью);
<a id="p100125"></a>PSL - Parameter Selection Request and Parameter Selection Response (Запрос о выборе параметров и ответ о выборе параметров);
<a id="p100126"></a>PSL_REQ - Parameter Selection Request (Запрос о выборе параметров);
<a id="p100127"></a>PSL_RES - Parameter Selection Response (Ответ о выборе параметров);
<a id="p100128"></a>RF - Radio Frequency (Радиочастота);
<a id="p100129"></a>RFCA - RF Collision Avoidance (Избежание радиочастотных конфликтов);
<a id="p100130"></a>RFU - Reserved for Future Use (Зарезервировано для использования в будущем);
<a id="p100131"></a>RLS - Release Request and Release Response (Запрос на освобождение и ответ на освобождение);
<a id="p100132"></a>RLS_REQ - Release Request (Запрос на освобождение);
<a id="p100133"></a>RLS_RES - Release Response (Ответ на освобождение);
<a id="p100134"></a>RWT - Response Waiting Time (Время ожидания ответа);
<a id="p100135"></a>SB - Start byte for data exchange protocol at fc/128 (Стартовый байт данных для протокола обмена данными на fc/128);
<a id="p100136"></a>SDD - Single Device Detection (anti-collision) [Обнаружение единственного устройства (антиконфликтность)];
<a id="p100137"></a>SEL_CMD - Select Command byte (Байт команды избирания);
<a id="p100138"></a>SYNC - Synchronisation pattern (Синхрогруппа);
<a id="p100139"></a>TO - Timeout value (Значение тайм-аута);
<a id="p100140"></a>UID - Unique Identifier (Уникальный идентификатор по ИСО/МЭК 14443-3);
<a id="p100141"></a>WT - Waiting Time (Время ожидания);
<a id="p100142"></a>WUP - Wakeup Request and Wakeup Response (Запрос на побудку и реакция на побудку);
<a id="p100143"></a>WUP_REQ - Wakeup Request (Запрос на побудку);
<a id="p100144"></a>WUP_RES - Wakeup Response (Реакция на побудку).


### 7. <a id="p100145"></a>Общие положения


<a id="p100146"></a>Цели и Инициаторы NFCIP-1 могут реализовывать как активный, так и пассивный режимы связи.
<a id="p100147"></a>В активном режиме связи как Инициатором, так и Целью используется собственное радиочастотное поле для коммуникации. Инициатор начинает NFCIP-1-транзакцию. Цель в активном режиме связи отвечает на команду Инициатора посредством модуляции собственного радиочастотного поля.
<a id="p100148"></a>В пассивном режиме связи Инициатор генерирует радиочастотное поле и начинает транзакцию. Цель в пассивном режиме связи отвечает на команду Инициатора посредством модуляции радиочастотного поля Инициатора, что называется нагрузочной модуляцией.
<a id="p100149"></a>Настоящий стандарт устанавливает требования для модуляции, скорости передачи данных и двоичного кодирования. Кроме того, он устанавливает требования для начала коммуникации, окончания коммуникации, представления бита и байта, обнаружения кадровой синхронизации и ошибок, обнаружения единственного устройства, выбора протокола и параметров, обмена данными и деселекции устройства с интерфейсом и протоколом коммуникации в ближнем поле (NFCIP-1).
<a id="p100150"></a>Транзакции начинаются с инициализации устройства и заканчиваются деселекцией устройства. Инициаторы и Цели обмениваются командами, ответами и данными посредством поочередной или полудуплексной двусторонней связи.
<a id="p100151"></a>NFCIP-1-устройства способны начинать транзакции на скорости передачи данных fc/128, fc/64 и fc/32. Инициаторы выбирают одну из этих скоростей для начала транзакции и затем могут изменить ее при помощи команд PSL_REQ/PSL_RES в течение транзакции.
<a id="p100152"></a>Режим (активный или пассивный) не подлежит изменению в течение одной транзакции.


### 8. <a id="p100153"></a>Радиочастотное поле



#### <a id="p100154"></a>8.1 Значения величин

<a id="p100155"></a>fc = 13,56 МГц.
<a id="p100156"></a>Hmin = 1,5 А/м (ср. квадр).
<a id="p100157"></a>Hmax = 7,5 А/м (ср. квадр).
<a id="p100158"></a>HПороговое = 0,1875 А/м (ср. квадр).

#### <a id="p100159"></a>8.2 Пассивный режим связи

<a id="p100160"></a>Инициатор в местах, указанных изготовителем, должен генерировать напряженность поля, равную, по крайней мере, Hmin и не превышающую Hmax (т.е. рабочий объем) в режиме без модуляции.
<a id="p100161"></a>Цель должна работать непрерывно в пределах между Hmin и Hmax.

#### <a id="p100162"></a>8.3 Активный режим связи

<a id="p100163"></a>Инициатор и Цель в местах, указанных изготовителем, должны поочередно генерировать радиочастотное поле, равное, по крайней мере, Hmin и не превышающее Hmax (т.е. рабочий объем) в режиме без модуляции.

#### <a id="p100164"></a>8.4 Обнаружение внешнего излучения радиочастотного поля

<a id="p100165"></a>NFCIP-1-устройства должны уметь обнаруживать внешнее излучение радиочастотного поля на частоте fc с напряженностью поля выше, чем HПороговое.


### 9. <a id="p100166"></a>Интерфейс радиочастотного сигнала



#### <a id="p100167"></a>9.1 Длительность бита

<a id="p100168"></a>Один etu равен 128/(D x fc), где значение делителя D зависит от скорости передачи данных и режима связи, см. таблицу 1.

<a id="p100169"></a>Таблица 1

<a id="p100170"></a>Делитель D


| <a id="p100171"></a>Режим связи | <a id="p100172"></a>Скорость передачи | <a id="p100173"></a>Делитель D |
| --- | --- | --- |
| <a id="p100174"></a>Активный или пассивный | <a id="p100175"></a>fc/128 (~106 кбит/с) | <a id="p100176"></a>1 |
| <a id="p100177"></a>Активный или пассивный | <a id="p100178"></a>fc/64 (~212 кбит/с) | <a id="p100179"></a>2 |
| <a id="p100180"></a>Активный или пассивный | <a id="p100181"></a>fc/32 (~424 кбит/с) | <a id="p100182"></a>4 |
| <a id="p100183"></a>Активный | <a id="p100184"></a>fc/16 (~848 кбит/с) | <a id="p100185"></a>8 |
| <a id="p100186"></a>Активный | <a id="p100187"></a>fc/8 (~1695 кбит/с) | <a id="p100188"></a>16 |
| <a id="p100189"></a>Активный | <a id="p100190"></a>fc/4 (~3390 кбит/с) | <a id="p100191"></a>32 |
| <a id="p100192"></a>Активный | <a id="p100193"></a>fc/2 (~6780 кбит/с) | <a id="p100194"></a>64 |


<a id="p100195"></a>Примечания
<a id="p100196"></a>1 Инициатор выбирает режим связи (активный или пассивный) и скорость передачи данных (fc/128, fc/64 или fc/32, определены далее).
<a id="p100197"></a>2 Модуляция и двоичное кодирование на скорости передачи данных за пределами fc/32 выходит за рамки настоящего стандарта.


#### <a id="p100198"></a>9.2 Активный режим связи

<a id="p100199"></a>Цели и Инициаторы должны соответствовать следующим требованиям для обоих направлений связи (Инициатор - Цель и Цель - Инициатор).

##### <a id="p100200"></a>9.2.1 Требования для fc/128


###### <a id="p100201"></a>9.2.1.1 Скорость передачи

<a id="p100202"></a>Скорость передачи при инициализации и обнаружении единственного устройства должна быть fc/128.

###### <a id="p100203"></a>9.2.1.2 Модуляция

<a id="p100204"></a>*См.* 8.1.2.1 ИСО/МЭК 14443-2. В течение передачи как Инициатор, так и Цель должны соответствовать PCD-значениям. В течение приема как Инициатор, так и Цель должны соответствовать PICC-значениям.

###### <a id="p100205"></a>9.2.1.3 Двоичное представление и кодирование

<a id="p100206"></a>*См.* 8.1.3 ИСО/МЭК 14443-2 для скорости передачи fc/128.

###### <a id="p100207"></a>9.2.1.4 Передача байтов

<a id="p100208"></a>Инициаторы и цели должны передавать байты младшим битом вперед.

##### <a id="p100209"></a>9.2.2 Требования для fc/64 и fc/32


###### <a id="p100210"></a>9.2.2.1 Скорости передачи

<a id="p100211"></a>Скорости передачи при инициализации и обнаружении единственного устройства должны быть соответственно fc/64 или fc/32.

###### <a id="p100212"></a>9.2.2.2 Модуляция

<a id="p100213"></a>*См.* 9.1.2 ИСО/МЭК 14443-2 для скоростей передачи fc/64 и fc/32. В течение передачи как Инициатор, так и Цель должны соответствовать PCD-значениям. В течение приема как Инициатор, так и Цель должны соответствовать PICC-значениям.
<a id="p100214"></a>*Примечание* - Диапазон коэффициента модуляции более строгий, чем в ИСО/МЭК 18092:2004.

<a id="p100215"></a>Цель должна принимать коэффициент модуляции в диапазоне от 8 до 30% для работы с Инициаторами, совместимыми с ИСО/МЭК 18092:2004, использующими коэффициент модуляции выше 14%.

###### <a id="p100216"></a>9.2.2.3 Двоичное представление и кодирование

<a id="p100217"></a>Манчестерское двоичное кодирование должно применяться, как показано на рисунках 1 и 2.

<a id="p100218"></a> ![9. Интерфейс радиочастотного сигнала](https://i.bukva.ai/s8td7dH1/img_0.png) 

<a id="p100219"></a>Рисунок 1 - Манчестерское двоичное кодирование
(прямая амплитуда)



<a id="p100220"></a> ![9. Интерфейс радиочастотного сигнала](https://i.bukva.ai/s8td7dH1/img_1.png) 

<a id="p100221"></a>Рисунок 2 - Манчестерское двоичное кодирование
(обратная амплитуда)

<a id="p100222"></a>Форматом двоичного кодирования является Манчестер с логическими уровнями, определенными как:
- <a id="p100223"></a>логический элемент "НУЛЬ": первая половина длительности бита является амплитудой несущей с полем низкой напряженности, вторая половина длительности бита должна быть амплитудой несущей с полем высокой напряженности (без применения модуляции);
- <a id="p100224"></a>логический элемент "ЕДИНИЦА": первая половина длительности бита является амплитудой несущей с полем высокой напряженности (без применения модуляции), вторая половина длительности бита должна быть амплитудой несущей с полем низкой напряженности.
<a id="p100225"></a>Обратная полярность амплитуды должна быть разрешена. Полярность должна быть определена из SYNC.

###### <a id="p100226"></a>9.2.2.4 Передача байтов

<a id="p100227"></a>Инициаторы и Цели должны передавать байты старшим битом вперед.

#### <a id="p100228"></a>9.3 Пассивный режим связи


##### <a id="p100229"></a>9.3.1 Режим Инициатор - Цель. Требования для fc/128

<a id="p100230"></a>См. [9.2.1](#p100200).

##### <a id="p100231"></a>9.3.2 Режим Цель - Инициатор. Требования для fc/128


###### <a id="p100232"></a>9.3.2.1 Скорость передачи

<a id="p100233"></a>См. [9.2.1.1](#p100201).

###### <a id="p100234"></a>9.3.2.2 Модуляция

<a id="p100235"></a>*См.* 8.2.2 ИСО/МЭК 14443-2.

###### <a id="p100236"></a>9.3.2.3 Частота поднесущей

<a id="p100237"></a>*См.* 8.2.3 ИСО/МЭК 14443-2.

###### <a id="p100238"></a>9.3.2.4 Модуляция поднесущей

<a id="p100239"></a>*См.* 8.2.4 ИСО/МЭК 14443-2 для скорости передачи fc/128.

###### <a id="p100240"></a>9.3.2.5 Двоичное представление и кодирование

<a id="p100241"></a>*См.* 8.2.5.1 ИСО/МЭК 14443-2.

###### <a id="p100242"></a>9.3.2.6 Передача байтов

<a id="p100243"></a>Инициаторы и Цели должны передавать байты младшим битом вперед.

##### <a id="p100244"></a>9.3.3 Режим Инициатор - Цель. Требования для fc/64 и fc/32


###### <a id="p100245"></a>9.3.3.1 Скорость передачи

<a id="p100246"></a>См. [9.2.2.1](#p100210).

###### <a id="p100247"></a>9.3.3.2 Модуляция

<a id="p100248"></a>*См.* 9.1.2 ИСО/МЭК 14443-2 для скорости передачи fc/64 и fc/32. В течение передачи Инициатор должен соответствовать PCD-значениям.
<a id="p100249"></a>*Примечание* - Диапазон коэффициента модуляции более строгий, чем в ИСО/МЭК 18092:2004.


###### <a id="p100250"></a>9.3.3.3 Двоичное представление и кодирование

<a id="p100251"></a>См. [9.2.2.3](#p100216).

###### <a id="p100252"></a>9.3.3.4 Передача байтов

<a id="p100253"></a>См. [9.2.2.4](#p100226).

##### <a id="p100254"></a>9.3.4 Режим Цель - Инициатор. Требования для fc/64 и fc/32


###### <a id="p100255"></a>9.3.4.1 Скорость передачи

<a id="p100256"></a>См. [9.2.2.1](#p100210).

###### <a id="p100257"></a>9.3.4.2 Модуляция

<a id="p100258"></a>Цель должна быть способна коммуницировать с Инициатором посредством области индуктивной связи с помощью нагрузочной модуляции, применяемой к fc радиочастотного поля Инициатора со значением амплитуды PICC-нагрузочной модуляции, указанным в 8.2.2 ИСО/МЭК 14443-2. Инициатор должен быть способен получать сигнал с амплитудой нагрузочной модуляции, как указано для PCD-приема в ИСО/МЭК 14443-2, 8.2.2.
<a id="p100259"></a>*Примечание* - Минимальная величина амплитуды нагрузочной модуляции для Цели и Инициатора была изменена по сравнению с ИСО/МЭК 18092:2004.


###### <a id="p100260"></a>9.3.4.3 Двоичное представление и кодирование

<a id="p100261"></a>См. [9.2.2.3](#p100216).

###### <a id="p100262"></a>9.3.4.4 Передача байтов

<a id="p100263"></a>См. [9.2.2.4](#p100226).


### 10. <a id="p100264"></a>Общий ход выполнения протокола


<a id="p100265"></a>Общий ход выполнения протокола между NFCIP-1-устройствами должен осуществляется посредством следующих последовательных операций:
- <a id="p100266"></a>Любое NFCIP-1-устройство в исходном положении должно находиться в режиме Цели, не генерировать радиочастотное поле и ждать команды от Инициатора.
- <a id="p100267"></a>Оно может переключиться в режим Инициатора и выбрать либо активный, либо пассивный режим связи, а также скорость передачи данных.
- <a id="p100268"></a>Инициаторы должны провести проверку на наличие внешнего излучения радиочастотного поля и не должны активировать свое собственное радиочастотное поле в том случае, если внешнее излучение радиочастотного поля обнаружено. См. [8.4](#p100164).
- <a id="p100269"></a>В случае, если внешнее излучение радиочастотного поля не обнаружено, Инициатор должен активировать свое собственное радиочастотное поле для приведения в действие Цели.
- <a id="p100270"></a>Обмен командами и ответами в том же режиме связи и на той же скорости передачи данных.
<a id="p100271"></a>На [рисунке 3](#p100278) показан общий ход выполнения инициализации и обнаружения единственного устройства для активного и пассивного режимов связи на различных скоростях передачи данных.
<a id="p100272"></a>Общий ход выполнения протокола описывает ход выполнения инициализации и выбора Целей либо в пассивном режиме связи, либо в активном режиме связи на одной из возможных скоростей передачи данных. Избежание радиочастотных конфликтов описано в [11.1](#p100279). Пассивный режим связи описан в [11.2](#p100293). Инициализация и SDD на скорости fc/128 описаны в [11.2.1](#p100294), инициализация и SDD на скоростях fc/64 и fc/32 описаны в [11.2.2](#p100357). Активный режим связи описан в [11.3](#p100437).
<a id="p100273"></a>Активация протокола описана в [12.5](#p100553). Выбор параметров описан в [12.5.3](#p100914). Протокол обмена данными описан в [12.6](#p101047). Деактивация описана в [12.7](#p101310).


### 11. <a id="p100274"></a>Инициализация


<a id="p100275"></a>Этот раздел описывает протокол инициализации и обнаружения радиочастотных конфликтов для Целей в активном и пассивном режиме связи. Инициатор должен уметь обнаруживать радиочастотный конфликт, который возникает, когда по крайней мере две Цели одновременно передают битовые комбинации с одной или более позициями битов, в которых они передают дополнительные значения.
<a id="p100276"></a>На рисунке 3 показан общий ход выполнения инициализации и обнаружения единственного устройства для активного и пассивного режимов связи на различных скоростях передачи данных.

<a id="p100277"></a> ![11. Инициализация](https://i.bukva.ai/s8td7dH1/img_2.png) 

<a id="p100278"></a>Рисунок 3 - Общий ход инициализации и обнаружения
единственного устройства


#### <a id="p100279"></a>11.1 Избежание радиочастотных конфликтов

<a id="p100280"></a>Чтобы не нарушать любую другую NFC-коммуникацию, а также работу любого оборудования на частоте несущей, Инициатор NFC-связи не должен генерировать свое собственное радиочастотное поле до тех пор, пока присутствует другое радиочастотное поле.

##### <a id="p100281"></a>11.1.1 Первоначальное избежание радиочастотных конфликтов

<a id="p100282"></a>Для того чтобы начать коммуникацию с Целевым устройством в активном или пассивном режиме связи, Инициатор должен непрерывно контролировать присутствие внешнего излучения радиочастотного поля. См. [8.4](#p100164).
<a id="p100283"></a>Если Инициатор не обнаруживает радиочастотного поля в пределах временных рамок TIDT + n x TRFW, то он должен включить свое собственное радиочастотное поле либо заново запустить Первоначальное избежание радиочастотных конфликтов. Целочисленное значение n должно быть сгенерировано случайным образом. Рисунок 4 определяет временные рамки Первоначального избежания радиочастотных конфликтов при инициализации.

<a id="p100284"></a> ![11. Инициализация](https://i.bukva.ai/s8td7dH1/img_3.png) 

<a id="p100285"></a>TIDT - время начальной задержки (TIDT > 4096/fc);
TRFW - время ожидания радиочастоты (512/fc); n - случайным
образом сгенерированное число периодов времени для TRFW
(0 <= n <= 3); TIRFG - начальное контрольное время между
включением радиочастотного поля и началом посылки команды
или кадра данных (TIRFG > 5 мс)

<a id="p100286"></a>Рисунок 4 - Первоначальное избежание радиочастотных
конфликтов

<a id="p100287"></a>Радиочастотное поле, сгенерированное Инициатором, должно быть выключено в активном режиме связи. Радиочастотное поле, сгенерированное Инициатором, не должно быть выключено в пассивном режиме связи.

##### <a id="p100288"></a>11.1.2 Избежание радиочастотных конфликтов при ответе

<a id="p100289"></a>Чтобы избежать конфликтов одновременного ответа более чем одной Цели в активном режиме связи при активации, Цели должны выполнять процедуру избежания радиочастотных конфликтов при ответе, как указано на рисунке 5.

<a id="p100290"></a> ![11. Инициализация](https://i.bukva.ai/s8td7dH1/img_4.png) 

<a id="p100291"></a>TADT - время активной задержки, время зондирования
между отключенной радиочастотой Инициатор/Цель
и Цель/Инициатор (768/fc <= TADT <= 2 559/fc); TRFW - время
ожидания радиочастоты (512/fc); n - случайным образом
сгенерированное число периодов времени для TRFW
(0 <= n <= 3); TARFG - активное контрольное время между
включением радиочастотного поля и началом посылки команды
(TARFG > 1024/fc)

<a id="p100292"></a>Рисунок 5 - Последовательность избежания радиочастотных
конфликтов при ответе в процессе активации


#### <a id="p100293"></a>11.2 Пассивный режим связи


##### <a id="p100294"></a>11.2.1 Инициализация и Обнаружение единственного устройства на fc/128

<a id="p100295"></a>*См.* ИСО/МЭК 14443-3, раздел 6 с кодированием SAK, как указано в таблице 2.

<a id="p100296"></a>Таблица 2

<a id="p100297"></a>Кодирование SAK


| <a id="p100298"></a>Бит 8 | <a id="p100299"></a>Бит 7 | <a id="p100300"></a>Бит 6 | <a id="p100301"></a>Бит 5 | <a id="p100302"></a>Бит 4 | <a id="p100303"></a>Бит 3 | <a id="p100304"></a>Бит 2 | <a id="p100305"></a>Бит 1 | <a id="p100306"></a>Значение |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100307"></a>x | <a id="p100308"></a>x | <a id="p100309"></a>x | <a id="p100310"></a>x | <a id="p100311"></a>x | <a id="p100312"></a>1 | <a id="p100313"></a>x | <a id="p100314"></a>x | <a id="p100315"></a>UID неполный, см. табл. 9 ИСО/МЭК 14443-3 |
| <a id="p100316"></a>x | <a id="p100317"></a>x | <a id="p100318"></a>1 | <a id="p100319"></a>x | <a id="p100320"></a>x | <a id="p100321"></a>0 | <a id="p100322"></a>x | <a id="p100323"></a>x | <a id="p100324"></a>UID полный, см. табл. 9 ИСО/МЭК 14443-3 |
| <a id="p100325"></a>x | <a id="p100326"></a>x | <a id="p100327"></a>0 | <a id="p100328"></a>x | <a id="p100329"></a>x | <a id="p100330"></a>0 | <a id="p100331"></a>x | <a id="p100332"></a>x | <a id="p100333"></a>UID полный, см. табл. 9 ИСО/МЭК 14443-3 |
| <a id="p100334"></a>x | <a id="p100335"></a>1 | <a id="p100336"></a>x | <a id="p100337"></a>x | <a id="p100338"></a>x | <a id="p100339"></a>0 | <a id="p100340"></a>x | <a id="p100341"></a>x | <a id="p100342"></a>UID полный, Цель совместима с транспортным протоколом NFCIP-1. Запрос на атрибуты поддерживается |
| <a id="p100343"></a>x | <a id="p100344"></a>0 | <a id="p100345"></a>x | <a id="p100346"></a>x | <a id="p100347"></a>x | <a id="p100348"></a>0 | <a id="p100349"></a>x | <a id="p100350"></a>x | <a id="p100351"></a>UID полный, Цель не поддерживает транспортный протокол NFCIP-1, запрос на атрибуты не поддерживается |


<a id="p100352"></a>Параметру uid0 должно быть присвоено значение '08'.
<a id="p100353"></a>Если бит 3 представлен (1)b, Инициатор должен проигнорировать любой другой бит SAK. Если бит 3 представлен (0)b, Инициатор должен интерпретировать бит 7 и проигнорировать другие биты. Если биту 3 присвоено значение (1)b, Цель должна присвоить всем остальным битам SAK значение (0)b.
<a id="p100354"></a>Примечания
<a id="p100355"></a>1 UID заменяет NFCID1 из ИСО/МЭК 18092:2004, а uid* заменяет nfcid1 из ИСО/МЭК 18092:2004.
<a id="p100356"></a>2 Если бит 6 в SAK представлен (1)b, то устройство поддерживает протокол, как определено в ИСО/МЭК 14443-4.


##### <a id="p100357"></a>11.2.2 Инициализация и обнаружение единственного устройства на fc/64 и fc/32


###### <a id="p100358"></a>11.2.2.1 Начало и конец коммуникации

<a id="p100359"></a>Сигналом к началу пассивной коммуникации должно служить наличие несущей частоты. Коммуникация должна начинаться с последовательности-преамбулы, состоящей из по крайней мере 48 битов НУЛЕЙ Манчестерского кодирования. Конец коммуникации должен быть спрогнозирован, исходя из поля кадра Длина. Рисунок 6 иллюстрирует начало и конец коммуникации.

<a id="p100360"></a> ![11. Инициализация](https://i.bukva.ai/s8td7dH1/img_5.png) 

<a id="p100361"></a>Рисунок 6 - Начало и конец коммуникации

<a id="p100362"></a>После того как одно NFCIP-1-устройство закончило коммуникацию, другое должно задержаться на время не менее 8 x 64/fc, прежде чем начать передачу, за счет отправки последовательности-преамбулы, как показано на рисунке 7.

<a id="p100363"></a> ![11. Инициализация](https://i.bukva.ai/s8td7dH1/img_6.png) 

<a id="p100364"></a>Рисунок 7 - Задержка между последовательными кадрами


###### <a id="p100365"></a>11.2.2.2 Формат кадра

<a id="p100366"></a>Формат кадра должен состоять из Преамбулы, Синхрогруппы, Длины, Полезной нагрузки и CRC, см. рисунок 8.


| <a id="p100367"></a>Преамбула | <a id="p100368"></a>SYNC | <a id="p100369"></a>Длина | <a id="p100370"></a>Полезная нагрузка | <a id="p100371"></a>CRC |
| --- | --- | --- | --- | --- |


<a id="p100372"></a>Рисунок 8 - Формат кадра

<a id="p100373"></a>Преамбула должна состоять минимум из 48 битов логических элементов НУЛЬ.
<a id="p100374"></a>Синхрогруппа должна состоять из 2 байтов. 1-й байт в Синхрогруппе должен быть 'B2', 2-й байт должен быть '4D'.
<a id="p100375"></a>Длина должна быть 8-битным полем, а его значение должно быть установлено в соответствии с количеством байт, передаваемых в Полезной нагрузке, плюс 1. Диапазон Длины должен быть в пределах от 2 до 255, остальные параметры являются RFU.
<a id="p100376"></a>Полезная нагрузка должна состоять из n 8-бит-байтовых данных, где n означает количество байтов данных.
<a id="p100377"></a>CRC должен быть рассчитан согласно [A.3](#p101546).

###### <a id="p100378"></a>11.2.2.3 Обнаружение единственного устройства на fc/64 и fc/32

<a id="p100379"></a>Основным методом SDD-процедуры должен быть метод временных интервалов. Номер интервала должен быть целочисленным значением за исключением нуля. Инициатор должен отправлять запросы на опрос. Цель должна отвечать в случайном порядке в каждый временной интервал. Инициатор должен уметь читать NFCID2-данные (см. [11.2.2.4](#p100396)) Цели(ей) в различных временных интервалах.
<a id="p100380"></a>После получения NFCID2-данных от Цели(ей) в рабочее поле Инициатор может коммуницировать с несколькими Целями.
<a id="p100381"></a>При согласии между обменивающимися сторонами могут поддерживаться до 16 временных интервалов. Номер временного интервала может быть указан значением TSN в кадре запроса на опрос от Инициатора.
<a id="p100382"></a>Цель, которая уже запитана, отвечает Инициатору после получения от Инициатора кадра запроса на опрос, согласно следующим правилам:
1. <a id="p100383"></a>Цель должна сгенерировать случайное число R в диапазоне от 0 до TSN.
2. <a id="p100384"></a>Цель должна дождаться временного интервала, который соответствует R, и затем отправить кадр ответа при опросе и ждать следующего запроса. Цель может игнорировать запрос на опрос для того, чтобы сократить число конфликтов при ответе.
<a id="p100385"></a>Коммуникация между Инициатором и Целью должна проводиться следующим образом:
1. <a id="p100386"></a>Цель получает питание от рабочего поля, сгенерированного Инициатором.
2. <a id="p100387"></a>Цель должна быть готова к получению запроса на опрос от Инициатора максимум через 2 секунды с момента получения питания.
3. <a id="p100388"></a>Цель должна ждать запроса на опрос, отправленного Инициатором. Инициатор может отправить запрос на опрос, не дожидаясь готовности Цели.
4. <a id="p100389"></a>Если Инициатору не удается получить ответа при опросе, то Инициатор может отправить запрос на опрос еще раз. Инициатор пассивного режима связи должен сохранять радиочастотное питание, пока осуществляется SDD-процедура.
<a id="p100390"></a>Задержка Td между окончанием кадра запроса и первым временным интервалом должна быть 512 x 64/fc.
<a id="p100391"></a>Блок временного интервала Ts должен быть 256 x 64/fc.
<a id="p100392"></a>Рисунок 9 иллюстрирует примерную ситуацию процедуры SDD по временным интервалам. В данном примере отвечают пять Целей. Инициатор может получить ответную информацию от Целей 2, 4 и 5, но не от Целей 1 и 3. Причина в конфликте, произошедшем во временном интервале 1.

<a id="p100393"></a> ![11. Инициализация](https://i.bukva.ai/s8td7dH1/img_7.png) 

<a id="p100394"></a>Рисунок 9 - Обнаружение единственного устройства
по временным интервалам

<a id="p100395"></a>Инициатор может повторять SDD-процедуру.

###### <a id="p100396"></a>11.2.2.4 Содержание NFCID2

<a id="p100397"></a>Идентификатор NFCID2 должен быть 8-байтовым числом, служащим для идентификации NFCIP-1-устройств. 2-байтовый код префикса должен сопровождаться 6-байтовым числом в NFCID2. Код префикса должен определять характеристики для 6-байтового числа.
<a id="p100398"></a>6-байтовое число должно быть сгенерировано случайным образом, когда код префикса '01' 'FE'. Другие параметры для кода префикса являются RFU.

###### <a id="p100399"></a>11.2.2.5 Формат кадра запроса на опрос

<a id="p100400"></a>Для обнаружения Цели Инициатор должен отправить кадр запроса на опрос, см. рисунок 10.


<table>
<colgroup><col width="18%"><col width="13%"><col width="13%"><col width="9%"><col width="9%"><col width="9%"><col width="9%"><col width="9%"><col width="13%"></colgroup>
<tr><td rowspan="2"><a id="p100401"></a>Преамбула<br>(48 бит мин.)</td><td rowspan="2"><a id="p100402"></a>SYNC<br>(16 бит)</td><td rowspan="2"><a id="p100403"></a>Длина<br>(8 бит)</td><td colspan="5"><a id="p100404"></a>Полная нагрузка</td><td rowspan="2"><a id="p100405"></a>CRC<br>(16 бит)</td></tr>
<tr><td><a id="p100406"></a>'00'</td><td><a id="p100407"></a>'FF'</td><td><a id="p100408"></a>'FF'</td><td><a id="p100409"></a>'00'</td><td><a id="p100410"></a>TSN</td></tr>
</table>


<a id="p100411"></a>Рисунок 10 - Формат кадра запроса на опрос

<a id="p100412"></a>Преамбула должна состоять минимум из 48 битов логических элементов НУЛЬ.
<a id="p100413"></a>Синхрогруппа (SYNC) должна состоять из 2 байтов. 1-й байт в Синхрогруппе должен быть 'B2', 2-й байт должен быть '4D'.
<a id="p100414"></a>Поле Длина должно быть установлено как '06'.
<a id="p100415"></a>1-й байт полезной нагрузки должен быть установлен в '00'.
<a id="p100416"></a>2-й и 3-й байты полезной нагрузки должны быть установлены в 'FF', другие параметры являются RFU.
<a id="p100417"></a>4-й байт полезной нагрузки должен быть установлен в '00', другие параметры являются RFU.
<a id="p100418"></a>TSN должен быть '00', '01', '03', '07' или '0F'. Любые другие параметры являются RFU.
<a id="p100419"></a>CRC должен быть рассчитан согласно [A.3](#p101546).
<a id="p100420"></a>[Рисунок 9](#p100394) иллюстрирует пример, где TSN равен '03'. Если TSN установлен как '00', то только временной интервал 0 должен быть использован.

###### <a id="p100421"></a>11.2.2.6 Формат кадра ответа при опросе

<a id="p100422"></a>Цель должна отправить следующий кадр как ответ при опросе на запрос на опрос, см. рисунок 11.


<table>
<colgroup><col width="20%"><col width="15%"><col width="15%"><col width="10%"><col width="15%"><col width="10%"><col width="15%"></colgroup>
<tr><td rowspan="2"><a id="p100423"></a>Преамбула<br>(48 бит мин.)</td><td rowspan="2"><a id="p100424"></a>SYNC<br>(16 бит)</td><td rowspan="2"><a id="p100425"></a>Длина<br>(8 бит)</td><td colspan="3"><a id="p100426"></a>Полная нагрузка</td><td rowspan="2"><a id="p100427"></a>CRC<br>(16 бит)</td></tr>
<tr><td><a id="p100428"></a>'01'</td><td><a id="p100429"></a>NFCID2</td><td><a id="p100430"></a>Pad</td></tr>
</table>


<a id="p100431"></a>Рисунок 11 - Формат кадра ответа при опросе

<a id="p100432"></a>Преамбула должна состоять минимум из 48 битов логических элементов НУЛЬ.
<a id="p100433"></a>Синхрогруппа (SYNC) должна состоять из 2 байтов. 1-й байт Синхрогруппы должен быть 'B2', 2-й байт должен быть '4D'.
<a id="p100434"></a>Поле Длина должно быть установлено как '12'.
<a id="p100435"></a>Стартовый байт полезной нагрузки должен быть установлен как '01'. Полезная нагрузка должна состоять из 8 байтов NFCID2 и 8 байтов Pad. Значение Pad должно быть проигнорировано для обмена данными.
<a id="p100436"></a>CRC должен быть рассчитан согласно [A.3](#p101546).

#### <a id="p100437"></a>11.3 Активный режим связи


##### <a id="p100438"></a>11.3.1 Инициализация на fc/128, fc/64 и fc/32

<a id="p100439"></a>Приложение переходит в режим Инициатора для активного режима связи и может выбрать скорость передачи данных fc/128, fc/64 или fc/32.

##### <a id="p100440"></a>11.3.2 Избежание радиочастотных конфликтов в активном режиме связи

<a id="p100441"></a>Избежание радиочастотных конфликтов должно быть выполнено в соответствии с временной диаграммой на рисунке 12.

<a id="p100442"></a> ![11. Инициализация](https://i.bukva.ai/s8td7dH1/img_8.png) 

<a id="p100443"></a>Рисунок 12 - Ход выполнения инициализации в активном
режиме связи

- <a id="p100444"></a>Инициатор должен осуществить Первоначальное избежание радиочастотных конфликтов.
- <a id="p100445"></a>Первой командой, отправляемой Инициатором, является ATR_REQ в активном режиме связи на выбранной скорости передачи.
- <a id="p100446"></a>Инициатор должен выключить радиочастотное поле.
- <a id="p100447"></a>Цель осуществляет Избежание радиочастотных конфликтов при ответе.
- <a id="p100448"></a>Цель посылает ATR_RES в ответ на ATR_REQ на той же скорости передачи, на которой она получила ATR_REQ, и выключает радиочастотное поле.
- <a id="p100449"></a>Инициатор осуществляет Избежание радиочастотных конфликтов при ответе с n = 0.
- <a id="p100450"></a>Инициатор посылает PSL_REQ для того, чтобы изменить параметр, или посылает DEP_REQ, чтобы начать протокол обмена данными.

###### <a id="p100451"></a>11.3.2.1 Избежание конфликтов в активном режиме связи

<a id="p100452"></a>В случае, когда в поле находятся две или более Целей, то Цель с наименьшим n будет отвечать первой, а другая Цель отвечать не будет.
<a id="p100453"></a>В случае, когда две или более Целей отвечают в один и тот же временной период, Инициатор обнаружит конфликт и повторно отправит ATR_REQ, описанный в [12.5.1.1](#p100555).
<a id="p100454"></a>После того как ответ от первой Цели обнаружен Инициатором, Инициатор и Цель должны использовать n = 0 для дальнейшей коммуникации.


### 12. <a id="p100455"></a>Транспортный протокол


<a id="p100456"></a>С транспортным протоколом работают в трех частях:
- <a id="p100457"></a>Активация протокола, которая включает в себя запрос на атрибуты и выбор параметров.
- <a id="p100458"></a>Протокол обмена данными.
- <a id="p100459"></a>Деактивация протокола, включающая деселекцию и освобождение.

#### <a id="p100460"></a>12.1 Передача данных

<a id="p100461"></a>Данные пользователя должны передаваться в поле Передача данных в формате кадра. Рисунок 13 указывает положение поля Передача данных в разных форматах кадра.

<a id="p100462"></a> ![12. Транспортный протокол](https://i.bukva.ai/s8td7dH1/img_9.png) 

<a id="p100463"></a>Рисунок 13 - Формат кадра передачи данных

<a id="p100464"></a>Структура формата кадра для fc/128 определяется в ИСО/МЭК 14443-3, 6.2.3.2. Стартовый байт SB должен быть установлен в значение 'F0'. LEN-байт должен быть равен длине поля Передача данных плюс 1. Диапазон LEN должен быть в пределах от 3 до 255. E1 является CRC для формата кадра fc/128, как описано в [разделе A.1](#p101392). Другие параметры LEN запрещены настоящим стандартом.
<a id="p100465"></a>[Подпункт 11.2.2.2](#p100365) настоящего стандарта определяет формат кадра для fc/64 и fc/32, в том числе Преамбулу PA и Синхрогруппу SYNC.
<a id="p100466"></a>LEN-байт должен быть равен длине поля Передача данных плюс 1. Значение LEN должно быть в пределах от 3 до 255. E2 является CRC для формата кадра fc/64 и fc/32, как описано в [разделе A.3](#p101546). Другие параметры LEN запрещены настоящим стандартом.
<a id="p100467"></a>Поле Передача данных содержит байты обязательных команд CMD1 и CMD2, как описано в [подразделе 12.4](#p100496), и байты данных: Байт 1 - Байт n. Содержимое с Байта 1 по Байт n зависит от байта команды CMD2 и может содержать информацию. В таком случае они являются обязательными. Байты данных являются необязательными.

#### <a id="p100468"></a>12.2 Ход выполнения активации пассивного режима связи

<a id="p100469"></a>Для активации должна быть применена следующая последовательность:
1. <a id="p100470"></a>Инициатор должен осуществить последовательность Первоначального избежания радиочастотных конфликтов в соответствии с [11.1.1](#p100281).
2. <a id="p100471"></a>Инициатор должен осуществить инициализацию и SDD для пассивного режима связи на выбранной скорости передачи, как определено в [11.2](#p100293).
3. <a id="p100472"></a>Должна быть проверена поддержка протокола NFCIP-1 на различных скоростях передачи в соответствии с запросом на атрибут, как описано в [12.5.1.1](#p100555).
4. <a id="p100473"></a>Цель может вернуться к инициализации и SDD, если ни один ATR_REQ не поддерживается.
5. <a id="p100474"></a>ATR_REQ может быть отправлен Инициатором в качестве следующей команды после получения подтверждения о доступности запроса на атрибут.
6. <a id="p100475"></a>Цель должна отправить свой ATR_RES в ответ на ATR_REQ. Цель должна отвечать на ATR_REQ только в том случае, если ATR_REQ получен непосредственно после выбора.
7. <a id="p100476"></a>Если Цель поддерживает какой-либо изменяемый параметр в ATR_REQ, PSL_REQ может быть использован Инициатором в качестве следующей команды после получения ATR_REQ для изменения параметров.
8. <a id="p100477"></a>Цель должна отправить PSL_RES в ответ на PSL_REQ.
9. <a id="p100478"></a>Цели не нужно дополнять Выбор параметров при отсутствии у нее поддержки каких-либо изменяемых параметров в ATR_RES.
10. <a id="p100479"></a>Прозрачные данные должны быть отправлены с использованием транспортного протокола обмена данными.
<a id="p100480"></a>Последовательность активации от Инициатора к Цели в пассивном режиме связи показана на рисунке 14.

<a id="p100481"></a> ![12. Транспортный протокол](https://i.bukva.ai/s8td7dH1/img_10.png) 

<a id="p100482"></a>Рисунок 14 - Протокол активации в пассивном режиме связи


#### <a id="p100483"></a>12.3 Ход выполнения активации активного режима связи

<a id="p100484"></a>Следующая последовательность активации для протокола в активном режиме связи должна быть применена:
1. <a id="p100485"></a>Инициатор должен осуществить последовательность Первоначального избежания радиочастотных конфликтов в соответствии с [11.1.1](#p100281).
2. <a id="p100486"></a>Инициатор должен переключиться в активный режим связи и выбрать скорость передачи.
3. <a id="p100487"></a>Инициатор должен отправить ATR_REQ.
4. <a id="p100488"></a>Цель должна отправить свой ATR_RES в ответ на ATR_REQ. После успешного ответа устройство выбирается.
5. <a id="p100489"></a>Если Инициатор обнаруживает конфликт данных, ATR_REQ должен быть отправлен повторно.
6. <a id="p100490"></a>Если Цель поддерживает какой-либо изменяемый параметр в ATR_REQ, PSL_REQ может быть использован Инициатором в качестве следующей команды после получения ATR_REQ для изменения параметров.
7. <a id="p100491"></a>Цель должна отправить PSL_RES в ответ на PSL_REQ.
8. <a id="p100492"></a>Цели не нужно дополнять Выбор параметров при отсутствии у нее поддержки каких-либо изменяемых параметров в ATR_RES.
<a id="p100493"></a>Последовательность активации от Инициатора к Цели в активном режиме связи показана на рисунке 15.

<a id="p100494"></a> ![12. Транспортный протокол](https://i.bukva.ai/s8td7dH1/img_11.png) 

<a id="p100495"></a>Рисунок 15 - Протокол активации в активном режиме связи


#### <a id="p100496"></a>12.4 Команды

<a id="p100497"></a>Байты команд состоят из CMD1 и CMD2, как указано в таблице 3.

<a id="p100498"></a>Таблица 3

<a id="p100499"></a>Набор команд протокола NFCIP-1


<table>
<colgroup><col width="15%"><col width="9%"><col width="9%"><col width="66%"></colgroup>
<tr><td rowspan="2"><a id="p100500"></a>Мнемоника</td><td colspan="2"><a id="p100501"></a>Байты команд</td><td rowspan="2"><a id="p100502"></a>Определение</td></tr>
<tr><td><a id="p100503"></a>CMD1</td><td><a id="p100504"></a>CMD2</td></tr>
<tr><td><a id="p100505"></a>ATR_REQ</td><td><a id="p100506"></a>'D4'</td><td><a id="p100507"></a>'00'</td><td><a id="p100508"></a>Запрос на атрибут (отправленный Инициатором)</td></tr>
<tr><td><a id="p100509"></a>ATR_RES</td><td><a id="p100510"></a>'D5'</td><td><a id="p100511"></a>'01'</td><td><a id="p100512"></a>Реакция на атрибут (отправленная Целью)</td></tr>
<tr><td><a id="p100513"></a>WUP_REQ</td><td><a id="p100514"></a>'D4'</td><td><a id="p100515"></a>'02'</td><td><a id="p100516"></a>Запрос на побудку (отправленный Инициатором только в активном режиме)</td></tr>
<tr><td><a id="p100517"></a>WUP_RES</td><td><a id="p100518"></a>'D5'</td><td><a id="p100519"></a>'03'</td><td><a id="p100520"></a>Реакция на побудку (отправленная Целью только в активном режиме)</td></tr>
<tr><td><a id="p100521"></a>PSL_REQ</td><td><a id="p100522"></a>'D4'</td><td><a id="p100523"></a>'04'</td><td><a id="p100524"></a>Запрос о выборе параметров (отправленный Инициатором)</td></tr>
<tr><td><a id="p100525"></a>PSL_RES</td><td><a id="p100526"></a>'D5'</td><td><a id="p100527"></a>'05'</td><td><a id="p100528"></a>Ответ о выборе параметров (отправленный Целью)</td></tr>
<tr><td><a id="p100529"></a>DEP_REQ</td><td><a id="p100530"></a>'D4'</td><td><a id="p100531"></a>'06'</td><td><a id="p100532"></a>Запрос на протокол обмена данными (отправленный Инициатором)</td></tr>
<tr><td><a id="p100533"></a>DEP_RES</td><td><a id="p100534"></a>'D5'</td><td><a id="p100535"></a>'07'</td><td><a id="p100536"></a>Ответ на протокол обмена данными (отправленный Целью)</td></tr>
<tr><td><a id="p100537"></a>DSL_REQ</td><td><a id="p100538"></a>'D4'</td><td><a id="p100539"></a>'08'</td><td><a id="p100540"></a>Запрос на деселекцию (отправленный Инициатором)</td></tr>
<tr><td><a id="p100541"></a>DSL_RES</td><td><a id="p100542"></a>'D5'</td><td><a id="p100543"></a>'09'</td><td><a id="p100544"></a>Ответ на деселекцию (отправленный Целью)</td></tr>
<tr><td><a id="p100545"></a>RLS_REQ</td><td><a id="p100546"></a>'D4'</td><td><a id="p100547"></a>'0A'</td><td><a id="p100548"></a>Запрос на освобождение (отправленный Инициатором)</td></tr>
<tr><td><a id="p100549"></a>RLS_RES</td><td><a id="p100550"></a>'D5'</td><td><a id="p100551"></a>'0B'</td><td><a id="p100552"></a>Ответ на освобождение (отправленный Целью)</td></tr>
</table>



#### <a id="p100553"></a>12.5 Активация протокола


##### <a id="p100554"></a>12.5.1 Команды Запрос на атрибут и Реакция на атрибут


###### <a id="p100555"></a>12.5.1.1 Запрос на атрибут (ATR_REQ)

<a id="p100556"></a>Данный подпункт определяет запрос на атрибут ATR_REQ со всеми его байтами параметров, см. рисунок 16. Инициатор должен отправить ATR_REQ выбранной Цели.


| <a id="p100557"></a>CMD 1 | <a id="p100558"></a>CMD 2 | <a id="p100559"></a>Байт 1 | <a id="p100560"></a>... | <a id="p100561"></a>Байт 10 | <a id="p100562"></a>Байт 11 | <a id="p100563"></a>Байт 12 | <a id="p100564"></a>Байт 13 | <a id="p100565"></a>Байт 14 | <a id="p100566"></a>Байт 15 |  | <a id="p100567"></a>Байт n |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100568"></a>'D4' | <a id="p100569"></a>'00' | <a id="p100570"></a>nfcid3i1 |  | <a id="p100571"></a>nfcid3i10 | <a id="p100572"></a>DIDi | <a id="p100573"></a>BSi | <a id="p100574"></a>BRi | <a id="p100575"></a>PPi | <a id="p100576"></a>[Gi[1]] |  | <a id="p100577"></a>[Gi[n]] |


<a id="p100578"></a>Рисунок 16 - Структура ATR_REQ


###### <a id="p100579"></a>12.5.1.1.1 Определение байтов ATR_REQ

<a id="p100580"></a>CMD 1: Должен быть установлен в значение 'D4'.
<a id="p100581"></a>**CMD 2: ATR_REQ**
<a id="p100582"></a>Байт ATR_REQ должен определять запрос на атрибут для Инициатора. Значение ATR_REQ должно быть установлено как '00'.
<a id="p100583"></a>Байт 1 - Байт 10: NFCID3i
<a id="p100584"></a>10 байтов nfcid3i определяют случайный идентификатор Инициатора NFCID3i. NFCID3 должен быть идентификатором, динамически генерируемым приложением, и должен быть постоянным в течение одной коммуникации. Для пассивного режима связи fc/64 и fc/32 NFCID3i должен быть заменен на NFCID2t.
<a id="p100585"></a>Байт 11: DIDi
<a id="p100586"></a>Байт DID должен быть использован для активации транспортного протокола многокомпонентных данных (multiple data) с более чем одной Целью. Диапазон DIDi должен быть определен между 1 и 14. Значение НУЛЬ должно использоваться, если DIDi не используется в течение протокола передачи данных. Все другие значения запрещены настоящим стандартом.
<a id="p100587"></a>Байт 12: BSi
<a id="p100588"></a>Устройство Инициатор должно указать поддерживаемые им скорости отправляемых данных (D) в байте BSi, см. рисунок 17.


| <a id="p100589"></a>бит 8 | <a id="p100590"></a>бит 7 | <a id="p100591"></a>бит 6 | <a id="p100592"></a>бит 5 | <a id="p100593"></a>бит 4 | <a id="p100594"></a>бит 3 | <a id="p100595"></a>бит 2 | <a id="p100596"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100597"></a>НУЛЬ | <a id="p100598"></a>НУЛЬ | <a id="p100599"></a>НУЛЬ | <a id="p100600"></a>НУЛЬ | <a id="p100601"></a>DSi | <a id="p100602"></a>DSi | <a id="p100603"></a>DSi | <a id="p100604"></a>DSi |


<a id="p100605"></a>Рисунок 17 - Кодирование байта BSi

<a id="p100606"></a>Кодирования битов следующее:
- <a id="p100607"></a>бит 8 - бит 5: должен быть установлен в значение НУЛЬ, все остальные значения являются RFU;
- <a id="p100608"></a>бит 4: если DSi = ЕДИНИЦЕ, то поддерживается D = 64;
- <a id="p100609"></a>бит 3: если DSi = ЕДИНИЦЕ, то поддерживается D = 32;
- <a id="p100610"></a>бит 2: если DSi = ЕДИНИЦЕ, то поддерживается D = 16;
- <a id="p100611"></a>бит 1: если DSi = ЕДИНИЦЕ, то поддерживается D = 8.
<a id="p100612"></a>Байт 13: BRi
<a id="p100613"></a>Устройство Инициатор должно указать поддерживаемые им скорости передачи данных (см. [таблицу 1](#p100170)) в байте BRi, см. рисунок 18.


| <a id="p100614"></a>бит 8 | <a id="p100615"></a>бит 7 | <a id="p100616"></a>бит 6 | <a id="p100617"></a>бит 5 | <a id="p100618"></a>бит 4 | <a id="p100619"></a>бит 3 | <a id="p100620"></a>бит 2 | <a id="p100621"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100622"></a>НУЛЬ | <a id="p100623"></a>НУЛЬ | <a id="p100624"></a>НУЛЬ | <a id="p100625"></a>НУЛЬ | <a id="p100626"></a>DRi | <a id="p100627"></a>DRi | <a id="p100628"></a>DRi | <a id="p100629"></a>DRi |


<a id="p100630"></a>Рисунок 18 - Кодирование байта BRi

<a id="p100631"></a>Кодирования битов следующее:
- <a id="p100632"></a>бит 8 - бит 5: должен быть установлен в значение НУЛЬ, все остальные значения являются RFU;
- <a id="p100633"></a>бит 4: если DRi = ЕДИНИЦЕ, то поддерживается D = 64;
- <a id="p100634"></a>бит 3: если DRi = ЕДИНИЦЕ, то поддерживается D = 32;
- <a id="p100635"></a>бит 2: если DRi = ЕДИНИЦЕ, то поддерживается D = 16;
- <a id="p100636"></a>бит 1: если DRi = ЕДИНИЦЕ, то поддерживается D = 8.
<a id="p100637"></a>Байт 14: PPi
<a id="p100638"></a>Байт PPi определяет дополнительные параметры, используемые устройством Инициатором, см. рисунок 19.


| <a id="p100639"></a>бит 8 | <a id="p100640"></a>бит 7 | <a id="p100641"></a>бит 6 | <a id="p100642"></a>бит 5 | <a id="p100643"></a>бит 4 | <a id="p100644"></a>бит 3 | <a id="p100645"></a>бит 2 | <a id="p100646"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100647"></a>SECi | <a id="p100648"></a>RFU | <a id="p100649"></a>LRi | <a id="p100650"></a>LRi | <a id="p100651"></a>RFU | <a id="p100652"></a>RFU | <a id="p100653"></a>Gi | <a id="p100654"></a>NAD |


<a id="p100655"></a>Рисунок 19 - Кодирование байта PPi

<a id="p100656"></a>Кодирование битов должно быть следующим:
- <a id="p100657"></a>бит 8: SECi. Если установлен в значение ЕДИНИЦА, Инициатор поддерживает NFC-SEC; НУЛЬ означает отсутствие поддержки;
- <a id="p100658"></a>бит 7: RFU. Инициатор должен установить его в значение НУЛЬ. Цель должна игнорировать его;
- <a id="p100659"></a>бит 6 и бит 5: Значение Сокращение длины LR (Length Reduction), см. таблицу 4.

<a id="p100660"></a>Таблица 4

<a id="p100661"></a>Определение LRi


| <a id="p100662"></a>LRi | <a id="p100663"></a>LEN<sub>MAX</sub> |
| --- | --- |
| <a id="p100664"></a>00 | <a id="p100665"></a>В передаче данных действительны только Байты с 1 по 64 |
| <a id="p100666"></a>01 | <a id="p100667"></a>В передаче данных действительны только Байты с 1 по 128 |
| <a id="p100668"></a>10 | <a id="p100669"></a>В передаче данных действительны только Байты с 1 по 192 |
| <a id="p100670"></a>11 | <a id="p100671"></a>В передаче данных действительны только Байты с 1 по 252 |


- <a id="p100672"></a>бит 4 и бит 3: RFU. Инициатор должен установить его в значение НУЛЬ. Цель должна игнорировать его;
- <a id="p100673"></a>бит 2: Если установлен в значение ЕДИНИЦА, то доступны Общие байты;
- <a id="p100674"></a>бит 1: Если установлен в значение ЕДИНИЦА, значит, Инициатор использует NAD.
<a id="p100675"></a>Байт 15 - Байт n: Gi[1] - Gi[n]
<a id="p100676"></a>Общие байты должны быть необязательными и должны обозначать общую информацию. Максимальная длина ATR_REQ за вычетом обязательных байтов дает максимальное число общих байтов.

###### <a id="p100677"></a>12.5.1.2 Реакция на атрибут (ATR_RES)

<a id="p100678"></a>ATR_RES, см. рисунок 20, должна быть реакцией на ATR_REQ и должна быть отправлена выбранным Целевым устройством NFCIP-1.


| <a id="p100679"></a>CMD 1 | <a id="p100680"></a>CMD 2 | <a id="p100681"></a>Байт 1 |  | <a id="p100682"></a>Байт 10 | <a id="p100683"></a>Байт 11 | <a id="p100684"></a>Байт 12 | <a id="p100685"></a>Байт 13 | <a id="p100686"></a>Байт 14 | <a id="p100687"></a>Байт 15 | <a id="p100688"></a>Байт 16 |  | <a id="p100689"></a>Байт n |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100690"></a>'D5' | <a id="p100691"></a>'01' | <a id="p100692"></a>nfcid3t1 |  | <a id="p100693"></a>nfcid3t10 | <a id="p100694"></a>DIDt | <a id="p100695"></a>BSt | <a id="p100696"></a>BRt | <a id="p100697"></a>TO | <a id="p100698"></a>PPt | <a id="p100699"></a>[Gi[1]] |  | <a id="p100700"></a>[Gt[n]] |


<a id="p100701"></a>Рисунок 20 - Структура ATR_RES


###### <a id="p100702"></a>12.5.1.2.1 Определение байтов ATR_RES

<a id="p100703"></a>CMD 1: Должен быть установлен в значение 'D5'.
<a id="p100704"></a>**CMD 2: ATR_RES**
<a id="p100705"></a>Байт ATR_RES должен определять ответ Цели на ATR_REQ, отправленный Инициатором. Значение CMD1 для ATR_RES должно быть установлено как '01'.
<a id="p100706"></a>Байт 1 - Байт 10: NFC<sub>ID3</sub>t
<a id="p100707"></a>10 байтов nfcid3t определяют произвольный идентификатор Цели NCID3t. NFCID3 должен быть идентификатором, генерируемым приложением. Содержание NFCID3 может быть такими же, как NFCID1 или NFCID2.
<a id="p100708"></a>Байт 11: DIDt
<a id="p100709"></a>Байт DID должен быть использован для активации транспортного протокола многокомпонентных данных (multiple data) с более чем одной Целью. DIDt должен иметь такое же значение, как и DIDi. Все другие значения запрещены настоящим стандартом. Процесс использования DIDt см. в [12.5.1.1.1](#p100579).
<a id="p100710"></a>Байт 12: BSt
<a id="p100711"></a>Байт BSt должен определять скорости передачи, поддерживаемые Целевым устройством, см. рисунок 21.


| <a id="p100712"></a>бит 8 | <a id="p100713"></a>бит 7 | <a id="p100714"></a>бит 6 | <a id="p100715"></a>бит 5 | <a id="p100716"></a>бит 4 | <a id="p100717"></a>бит 3 | <a id="p100718"></a>бит 2 | <a id="p100719"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100720"></a>НУЛЬ | <a id="p100721"></a>НУЛЬ | <a id="p100722"></a>НУЛЬ | <a id="p100723"></a>НУЛЬ | <a id="p100724"></a>DSt | <a id="p100725"></a>DSt | <a id="p100726"></a>DSt | <a id="p100727"></a>DSt |


<a id="p100728"></a>Рисунок 21 - Кодирование байта BSt

<a id="p100729"></a>Кодирования битов следующее:
- <a id="p100730"></a>бит 8 - бит 5: Должен быть установлен в значение НУЛЬ;
- <a id="p100731"></a>бит 4: если DSt = ЕДИНИЦЕ, то поддерживается D = 64;
- <a id="p100732"></a>бит 3: если DSt = ЕДИНИЦЕ, то поддерживается D = 32;
- <a id="p100733"></a>бит 2: если DSt = ЕДИНИЦЕ, то поддерживается D = 16;
- <a id="p100734"></a>бит 1: если DSt = ЕДИНИЦЕ, то поддерживается D = 8.
<a id="p100735"></a>Байт 13: BRt
<a id="p100736"></a>Байт BRt должен определять скорости приема данных, поддерживаемые Целевым устройством, см. рисунок 22.


| <a id="p100737"></a>бит 8 | <a id="p100738"></a>бит 7 | <a id="p100739"></a>бит 6 | <a id="p100740"></a>бит 5 | <a id="p100741"></a>бит 4 | <a id="p100742"></a>бит 3 | <a id="p100743"></a>бит 2 | <a id="p100744"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100745"></a>НУЛЬ | <a id="p100746"></a>НУЛЬ | <a id="p100747"></a>НУЛЬ | <a id="p100748"></a>НУЛЬ | <a id="p100749"></a>DRt | <a id="p100750"></a>DRt | <a id="p100751"></a>DRt | <a id="p100752"></a>DRt |


<a id="p100753"></a>Рисунок 22 - Кодирование байта BRt

<a id="p100754"></a>Кодирования битов следующее:
- <a id="p100755"></a>бит 8 - бит 5: Должен быть установлен в значение НУЛЬ;
- <a id="p100756"></a>бит 4: если DRt = ЕДИНИЦЕ, то поддерживается D = 64;
- <a id="p100757"></a>бит 3: если DRt = ЕДИНИЦЕ, то поддерживается D = 32;
- <a id="p100758"></a>бит 2: если DRt = ЕДИНИЦЕ, то поддерживается D = 16;
- <a id="p100759"></a>бит 1: если DRt = ЕДИНИЦЕ, то поддерживается D = 8.
<a id="p100760"></a>Байт 12: TO
<a id="p100761"></a>Байт TO должен определять значение тайм-аута Целевого устройства NFCIP-1 для протокола передачи данных, см. рисунок 23. Счет тайм-аута должен начинаться с последним битом, отправленным Инициатором, и заканчиваться с первым битом, отправленным Целью. Тайм-аут определяется следующим образом:
- <a id="p100762"></a>бит 8 - бит 5: Должен быть установлен в значение НУЛЬ;
- <a id="p100763"></a>бит 4 - бит 1: Время ожидания WT.


| <a id="p100764"></a>бит 8 | <a id="p100765"></a>бит 7 | <a id="p100766"></a>бит 6 | <a id="p100767"></a>бит 5 | <a id="p100768"></a>бит 4 | <a id="p100769"></a>бит 3 | <a id="p100770"></a>бит 2 | <a id="p100771"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100772"></a>НУЛЬ | <a id="p100773"></a>НУЛЬ | <a id="p100774"></a>НУЛЬ | <a id="p100775"></a>НУЛЬ | <a id="p100776"></a>WT | <a id="p100777"></a>WT | <a id="p100778"></a>WT | <a id="p100779"></a>WT |


<a id="p100780"></a>Рисунок 23 - Кодирование байта ТО

<a id="p100781"></a>Время ожидания ответа (RWT) должно быть рассчитано по следующей формуле:
<a id="p100782"></a>RWT = (256 x 16/fc) x 2WT,
<a id="p100783"></a>где значение WT должно быть в диапазоне от 0 до 14, а значение 15 является RFU. Значение WT по умолчанию должно быть 14.
<a id="p100784"></a>Для WT = 0, RWT = RWTMIN (302 мкс).
<a id="p100785"></a>Для WT = 14, RWT = RWTMAX (4 949 мс).
<a id="p100786"></a>Байт 15: PPt
<a id="p100787"></a>Байт PPt определяет дополнительные параметры, используемые Целевым устройством, см. рисунок 24. Кодирования битов, определяется следующим образом:


| <a id="p100788"></a>бит 8 | <a id="p100789"></a>бит 7 | <a id="p100790"></a>бит 6 | <a id="p100791"></a>бит 5 | <a id="p100792"></a>бит 4 | <a id="p100793"></a>бит 3 | <a id="p100794"></a>бит 2 | <a id="p100795"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100796"></a>НУЛЬ | <a id="p100797"></a>НУЛЬ | <a id="p100798"></a>LRt | <a id="p100799"></a>LRt | <a id="p100800"></a>НУЛЬ | <a id="p100801"></a>НУЛЬ | <a id="p100802"></a>Gt | <a id="p100803"></a>NAD |


<a id="p100804"></a>Рисунок 24 - Кодирование байта PPt

<a id="p100805"></a>Кодирование битов должно быть следующим:
- <a id="p100806"></a>бит 8 и бит 7: Должен быть установлен в значение НУЛЬ;
- <a id="p100807"></a>бит 6 и бит 5: Значение Сокращение длины LR (Length Reduction), см. таблицу 5.

<a id="p100808"></a>Таблица 5

<a id="p100809"></a>Определение LRt


| <a id="p100810"></a>LRt | <a id="p100811"></a>LEN<sub>MAX</sub> |
| --- | --- |
| <a id="p100812"></a>00 | <a id="p100813"></a>В передаче данных действительны только Байты с 1 по 64 |
| <a id="p100814"></a>01 | <a id="p100815"></a>В передаче данных действительны только Байты с 1 по 128 |
| <a id="p100816"></a>10 | <a id="p100817"></a>В передаче данных действительны только Байты с 1 по 192 |
| <a id="p100818"></a>11 | <a id="p100819"></a>В передаче данных действительны только Байты с 1 по 252 |


- <a id="p100820"></a>бит 4 и бит 3: Должен быть установлен в значение НУЛЬ;
- <a id="p100821"></a>бит 2: Если установлен в значение ЕДИНИЦА, то доступны Общие байты;
- <a id="p100822"></a>бит 1: Если установлен в значение ЕДИНИЦА, значит, Цель использует NAD.
<a id="p100823"></a>Байт 15 - Байт n: Gt[1] - Gt[n]
<a id="p100824"></a>Байты Gt должны быть необязательными и должны обозначать общую информацию. Максимальная длина ATR_RES за вычетом обязательных байтов дает максимальное число общих байтов.

###### <a id="p100825"></a>12.5.1.3 Обработка ATR_REQ и ATR_RES


###### <a id="p100826"></a>12.5.1.3.1 Правила для Инициатора

<a id="p100827"></a>Когда Инициатор отправил ATR_REQ и получает допустимый ATR_RES, Инициатор должен продолжить работу.
<a id="p100828"></a>В любом другом случае Инициатор должен повторно передать ATR_REQ, прежде чем использовать последовательность деактивации, как определено в [12.7](#p101310).
<a id="p100829"></a>В случае сбоя последовательности деактивации он может использовать команду HLTA только в пассивном режиме связи на fc/128. Команда HLTA определена в пункте 6.4.3 ИСО/МЭК 14443-3.

###### <a id="p100830"></a>12.5.1.3.2 Правила для Цели

<a id="p100831"></a>Когда Цель была выбрана последней командой (только в пассивном режиме) и:
<a id="p100832"></a>a) получает допустимый ATR_REQ, Цель:
- <a id="p100833"></a>должна отправить свой ATR_RES;
- <a id="p100834"></a>должна отключиться, чтобы получить последующий ATR_REQ.
<a id="p100835"></a>b) получает любые другие допустимые или недопустимые кадры, за исключением команды HLTA (см. [12.5.1.3.1](#p100826)) только в пассивном режиме связи на fc/128, Цель:
- <a id="p100836"></a>игнорирует блок и
- <a id="p100837"></a>остается в режиме приема.

###### <a id="p100838"></a>12.5.1.4 Обработка тайм-аута TO

<a id="p100839"></a>В зависимости от изначально выбранного режима, коммуникация является либо активной, либо пассивной. Обработка тайм-аута в активном и пассивном режиме связи различна.

###### <a id="p100840"></a>12.5.1.4.1 Обработка в активном режиме

<a id="p100841"></a>В активном режиме коммуникация осуществляется за счет переключения несущей частоты.
<a id="p100842"></a>Инициатор: Инициатор должен проигнорировать Цель, которая превысила RWT, рассчитанный с использованием байта TO в ATR_REQ от Целевого устройства, и продолжить работу.
<a id="p100843"></a>Цель: Цель должна использовать значение ТО, которое дает возможность общей коммуникации, и должна использовать контрольное pdu, содержащее продление тайм-аута для увеличения определенного RWT. См. [12.6.1.1.1](#p101072).

###### <a id="p100844"></a>12.5.1.4.2 Обработка тайм-аута в пассивном режиме

<a id="p100845"></a>В пассивном режиме коммуникация осуществляется только за счет потока информации. Несущая частота не переключается.
<a id="p100846"></a>Инициатор: Инициатор должен сперва использовать обработку ошибок, затем, если не получает никакого ответа, проигнорировать Целевое устройство, которое превысило заданный тайм-аут, и продолжить коммуникацию.
<a id="p100847"></a>Цель: Цель должна использовать значение ТО, которое дает возможность общей коммуникации, и должна использовать контрольное pdu, содержащее продление тайм-аута для увеличения определенного RWT. См. [12.6.1.1.1](#p101072).

###### <a id="p100848"></a>12.5.1.5 Обработка DID


###### <a id="p100849"></a>12.5.1.5.1 Обработка DID в активном и пассивном режиме

<a id="p100850"></a>Когда Инициатор отправил ATR_REQ, содержащий DID, равный НУЛЮ, и:
<a id="p100851"></a>a) получил ATR_RES, содержащий DID, равный НУЛЮ:
- <a id="p100852"></a>должен отправить Цели pdu, не содержащие DID, и
- <a id="p100853"></a>не должен активировать какие-либо другие Цели, пока данная Цель не будет деактивирована.
<a id="p100854"></a>b) получил ATR_RES, содержащий DID, не равный НУЛЮ:
- <a id="p100855"></a>должен приступить к обработке ошибок.
<a id="p100856"></a>Когда Инициатор отправил ATR_REQ, содержащий DID, не равный НУЛЮ, и:
<a id="p100857"></a>a) получил ATR_RES, содержащий такой же DID:
- <a id="p100858"></a>должен отправить Цели pdu, содержащие DID;
- <a id="p100859"></a>не должен использовать данный DID для любых других Целей и
- <a id="p100860"></a>не должен использовать DID = 0 для любых других Целей.
<a id="p100861"></a>b) получил ATR_RES, содержащий какой-либо другой DID:
- <a id="p100862"></a>должен приступить к обработке ошибок.

##### <a id="p100863"></a>12.5.2 Команды Запрос на побудку и Реакция на побудку

<a id="p100864"></a>Команды Запрос и Реакция на побудку определены только для активного режима связи.

###### <a id="p100865"></a>12.5.2.1 Запрос на побудку (WUP_REQ)

<a id="p100866"></a>Рисунок 25 определяет Запрос на побудку на атрибуты WUP_REQ с байтами его параметров. Инициатор посылает Цели запрос WUP_REQ только в активном режиме связи. Запрос должен быть применен для реактивации отдельного Целевого устройства, деактивированного командой DSL, по его NFCID3.


| <a id="p100867"></a>CMD 1 | <a id="p100868"></a>CMD 2 | <a id="p100869"></a>Байт 1 |  | <a id="p100870"></a>Байт 10 | <a id="p100871"></a>Байт 11 |
| --- | --- | --- | --- | --- | --- |
| <a id="p100872"></a>'D4' | <a id="p100873"></a>'02' | <a id="p100874"></a>nfcid3t1 |  | <a id="p100875"></a>nfcid3t10 | <a id="p100876"></a>DID |


<a id="p100877"></a>Рисунок 25 - Структура WUP_REQ


###### <a id="p100878"></a>12.5.2.1.1 Определение байтов WUP_REQ

<a id="p100879"></a>CMD 1: Должен быть установлен в значение 'D4'.
<a id="p100880"></a>**CMD 2: WUP_REQ**
<a id="p100881"></a>Байт WUP_REQ должен определять команду Wake Up для устройства Инициатора. Значение WUP_REQ должно быть '02'.
<a id="p100882"></a>Байт 1 - Байт 10: NFCID3t
<a id="p100883"></a>10 байтов nfcid3t должны быть определены как произвольный идентификатор Цели. Для команды WUP_REQ Инициатор должен отправить известный произвольный идентификатор NFCID3t, чтобы разбудить Цель.
<a id="p100884"></a>Байт 11: DID
<a id="p100885"></a>Байт DID должен быть использован для активации транспортного протокола многокомпонентных данных (multiple data) с более чем одной Целью. Диапазон DID должен быть определен между 1 и 14. Значение 0 должно использоваться, если DID не используется в течение протокола передачи данных. Все другие значения запрещены настоящим стандартом. Инициатор может присвоить другое значение Цели, которое использовалось до последней команды DSL.

###### <a id="p100886"></a>12.5.2.2 Реакция на побудку (WUP_RES)

<a id="p100887"></a>Рисунок 26 определяет структуру реакции на побудку на атрибут WUP_RES. WUP_RES должна быть ответом на WUP_REQ и должна быть отправлена выбранным Целевым устройством NFCIP-1.


| <a id="p100888"></a>CMD 1 | <a id="p100889"></a>CMD 2 | <a id="p100890"></a>Байт 1 |
| --- | --- | --- |
| <a id="p100891"></a>'D5' | <a id="p100892"></a>'03' | <a id="p100893"></a>DID |


<a id="p100894"></a>Рисунок 26 - Структура WUP_RES


###### <a id="p100895"></a>12.5.2.2.1 Определение байтов WUP_RES

<a id="p100896"></a>CMD 1: Должен быть установлен в значение 'D5'.
<a id="p100897"></a>**CMD 2: WUP_RES**
<a id="p100898"></a>Байт WUP_RES должен определять ответ на WUP_REQ. Значение WUP_RES должно быть '03'.
<a id="p100899"></a>Байт 1: DID
<a id="p100900"></a>Байт DID должен быть использован для активации транспортного протокола многокомпонентных данных (multiple data) с более чем одной Целью. DIDt должен иметь такое же значение, что и DIDi. Все другие значения запрещены настоящим стандартом.

###### <a id="p100901"></a>12.5.2.3 Обработка WUP_REQ и WUP_RES


###### <a id="p100902"></a>12.5.2.3.1 Правила для Инициатора

<a id="p100903"></a>Когда Инициатор отправил WUP_REQ и получает допустимый WUP_RES, Инициатор должен продолжить работу.
<a id="p100904"></a>В любом другом случае Инициатор должен повторно передать WUP_REQ, прежде чем использовать последовательность деактивации, как определено в [12.7](#p101310).
<a id="p100905"></a>В случае сбоя последовательности деактивации для fc/128 в пассивном режиме связи он может использовать команду HLTA (см. пункт 6.4.3 ИСО/МЭК 14443-3).

###### <a id="p100906"></a>12.5.2.3.2 Правила для Цели

<a id="p100907"></a>Когда Цель была деселектирована последней командой (только в активном режиме) и:
<a id="p100908"></a>a) получает WUP_REQ со своим NFCID3, Цель:
- <a id="p100909"></a>должна отправить свой WUP_RES и
- <a id="p100910"></a>должна отключиться, чтобы не получить последующий WUP_REQ.
<a id="p100911"></a>b) получает любые другие допустимые или недопустимые кадры, за исключением команды HLTA только в пассивном режиме связи на fc/128, Цель:
- <a id="p100912"></a>игнорирует блок и
- <a id="p100913"></a>остается в режиме приема.

##### <a id="p100914"></a>12.5.3 Команды Запрос о выборе параметров и Ответ о выборе параметров


###### <a id="p100915"></a>12.5.3.1 Запрос о выборе параметров (PSL_REQ)

<a id="p100916"></a>Инициатор может переключать параметры для последующего транспортного протокола с помощью команды PSL_REQ, см. рисунок 27.


| <a id="p100917"></a>CMD 1 | <a id="p100918"></a>CMD 2 | <a id="p100919"></a>Байт 1 | <a id="p100920"></a>Байт 2 | <a id="p100921"></a>Байт 3 |
| --- | --- | --- | --- | --- |
| <a id="p100922"></a>'D4' | <a id="p100923"></a>'04' | <a id="p100924"></a>DID | <a id="p100925"></a>BRS | <a id="p100926"></a>FSL |


<a id="p100927"></a>Рисунок 27 - Структура PSL_REQ


###### <a id="p100928"></a>12.5.3.1.1 Определение байтов PSL_REQ

<a id="p100929"></a>CMD 1: Должен быть установлен в значение 'D4'.
<a id="p100930"></a>**CMD 2: PSL_REQ**
<a id="p100931"></a>Байт PSL_REQ должен определять команду Запрос о выборе параметров для устройства Инициатора. Значение PSL_REQ должно быть '04'.
<a id="p100932"></a>Байт 1: DID
<a id="p100933"></a>DID должен быть таким же, как DID, определенный при ATR или WUP.
<a id="p100934"></a>Байт 2: BRS
<a id="p100935"></a>Байт BRS, см. рисунок 28, должен определять выбранную скорость передачи данных для устройства Инициатора и Целевого устройства.


| <a id="p100936"></a>бит 8 | <a id="p100937"></a>бит 7 | <a id="p100938"></a>бит 6 | <a id="p100939"></a>бит 5 | <a id="p100940"></a>бит 4 | <a id="p100941"></a>бит 3 | <a id="p100942"></a>бит 2 | <a id="p100943"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100944"></a>НУЛЬ | <a id="p100945"></a>НУЛЬ | <a id="p100946"></a>DSI | <a id="p100947"></a>DSI | <a id="p100948"></a>DSI | <a id="p100949"></a>DRI | <a id="p100950"></a>DRI | <a id="p100951"></a>DRI |


<a id="p100952"></a>Рисунок 28 - Кодирование байта BRS

- <a id="p100953"></a>бит 8 и бит 7: Должен быть установлен в значение НУЛЬ;
- <a id="p100954"></a>бит 6 - бит 4: Длительность бита от Инициатора к Цели см. таблицу 6;
- <a id="p100955"></a>бит 3 - бит 1: Длительность бита от Цели к Инициатору, см. таблицу 6.

<a id="p100956"></a>Таблица 6

<a id="p100957"></a>Кодирование DRI и DSI


| <a id="p100958"></a>DRI и DSI | <a id="p100959"></a>Делитель D |
| --- | --- |
| <a id="p100960"></a>000 | <a id="p100961"></a>1 |
| <a id="p100962"></a>001 | <a id="p100963"></a>2 |
| <a id="p100964"></a>010 | <a id="p100965"></a>4 |
| <a id="p100966"></a>011 | <a id="p100967"></a>8 |
| <a id="p100968"></a>100 | <a id="p100969"></a>16 |
| <a id="p100970"></a>101 | <a id="p100971"></a>32 |
| <a id="p100972"></a>110 | <a id="p100973"></a>64 |
| <a id="p100974"></a>111 | <a id="p100975"></a>RFU |


<a id="p100976"></a>Байт 3: FSL
<a id="p100977"></a>Байт FSL определяет максимальное значение длины кадра, см. рисунок 29.


| <a id="p100978"></a>бит 8 | <a id="p100979"></a>бит 7 | <a id="p100980"></a>бит 6 | <a id="p100981"></a>бит 5 | <a id="p100982"></a>бит 4 | <a id="p100983"></a>бит 3 | <a id="p100984"></a>бит 2 | <a id="p100985"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p100986"></a>НУЛЬ | <a id="p100987"></a>НУЛЬ | <a id="p100988"></a>НУЛЬ | <a id="p100989"></a>НУЛЬ | <a id="p100990"></a>НУЛЬ | <a id="p100991"></a>НУЛЬ | <a id="p100992"></a>LR | <a id="p100993"></a>LR |


<a id="p100994"></a>Рисунок 29 - Кодирование байтов FSL

- <a id="p100995"></a>бит 8 - бит 3: Должны быть все установлены как НУЛЬ;
- <a id="p100996"></a>бит 2 и бит 1: Значение Сокращение длины LR (Length Reduction), см. таблицу 7.

<a id="p100997"></a>Таблица 7

<a id="p100998"></a>Определение LR


| <a id="p100999"></a>LR | <a id="p101000"></a>LEN<sub>MAX</sub> |
| --- | --- |
| <a id="p101001"></a>00 | <a id="p101002"></a>В передаче данных действительны только Байты с 1 по 64 |
| <a id="p101003"></a>01 | <a id="p101004"></a>В передаче данных действительны только Байты с 1 по 128 |
| <a id="p101005"></a>10 | <a id="p101006"></a>В передаче данных действительны только Байты с 1 по 192 |
| <a id="p101007"></a>11 | <a id="p101008"></a>В передаче данных действительны только Байты с 1 по 252 |



###### <a id="p101009"></a>12.5.3.2 Ответ о выборе параметров (PSL_RES)

<a id="p101010"></a>Рисунок 30 определяет структуру кадра PSL_RES.


| <a id="p101011"></a>CMD 1 | <a id="p101012"></a>CMD 2 | <a id="p101013"></a>Байт 1 |
| --- | --- | --- |
| <a id="p101014"></a>'D5' | <a id="p101015"></a>'05' | <a id="p101016"></a>DID |


<a id="p101017"></a>Рисунок 30 - Структура PSL_RES


###### <a id="p101018"></a>12.5.3.2.1 Определение байтов PSL_RES

<a id="p101019"></a>CMD 1: Должен быть установлен в значение 'D5'.
<a id="p101020"></a>**CMD 2: PSL_RES**
<a id="p101021"></a>Байт PSL_RES должен определять команду Ответ о выборе параметров для Целевого устройства. Значение PSL_RES должно быть '05'.
<a id="p101022"></a>Байт 1: DID
<a id="p101023"></a>DID должен быть таким же, как DID, определенный при ATR или WUP.

###### <a id="p101024"></a>12.5.3.3 Обработка PSL_REQ и PSL_RES


###### <a id="p101025"></a>12.5.3.3.1 Правила для Инициатора

<a id="p101026"></a>Инициатор может изменить параметры протокола путем отправки Цели PSL_REQ. После получения допустимого PSL_RES Инициатор:
- <a id="p101027"></a>должен изменить кадровую синхронизацию в формат, определенный в [12.1](#p100460), и
- <a id="p101028"></a>должен продолжить работу.
<a id="p101029"></a>В любом другом случае Инициатор может повторно отправить PSL_REQ, прежде чем использовать последовательность деактивации, как определено в [12.7](#p101310).
<a id="p101030"></a>В случае сбоя последовательности деактивации на fc/128 в пассивном режиме связи он может использовать команду HLTA (см. [12.5.1.3.2](#p100830)).

###### <a id="p101031"></a>12.5.3.3.2 Правила для Цели

<a id="p101032"></a>Когда Цель получила ATR_REQ, послала свой ATR_RES и:
<a id="p101033"></a>a) получает допустимый PSL_REQ, Цель:
- <a id="p101034"></a>должна отправить свой PSL_RES;
- <a id="p101035"></a>должна отключить PSL_REQ (перестать отвечать на полученные PSL_REQ);
- <a id="p101036"></a>должна изменить все параметры на заданные значения, которые указаны в [12.5.3](#p100914), и
- <a id="p101037"></a>должна остаться в режим приема.
<a id="p101038"></a>b) получает недопустимый кадр, Цель:
- <a id="p101039"></a>должна проигнорировать блок;
- <a id="p101040"></a>должна отключить PSL_REQ (перестать отвечать на полученные PSL_REQ);
- <a id="p101041"></a>должна остаться с текущей кадровой синхронизацией и
- <a id="p101042"></a>должна остаться в режим приема.
<a id="p101043"></a>c) получает допустимый кадр, за исключением PSL_REQ, Цель:
- <a id="p101044"></a>должна отключить PSL_REQ (перестать отвечать на полученные PSL_REQ);
- <a id="p101045"></a>должна остаться с текущей кадровой синхронизацией и
- <a id="p101046"></a>должна продолжить работу.

#### <a id="p101047"></a>12.6 Протокол обмена данными


##### <a id="p101048"></a>12.6.1 Запрос на протокол обмена данными и ответ на протокол обмена данными


###### <a id="p101049"></a>12.6.1.1 Запрос на протокол обмена данными (DEP_REQ) и ответ на протокол обмена данными (DEP_RES)

<a id="p101050"></a>Протокол должен быть полудуплексным двусторонним протоколом, поддерживающим блочно-ориентированную передачу данных с обработкой ошибок. Для данных, которые не помещаются в один кадр, определяется механизм формирования цепочки. Формат кадра протокола должен быть следующим:


<table>
<colgroup><col width="11%"><col width="11%"><col width="11%"><col width="11%"><col width="11%"><col width="13%"><col width="13%"><col width="6%"><col width="13%"></colgroup>
<tr><td colspan="9"><a id="p101051"></a>Поле Передача данных</td></tr>
<tr><td><a id="p101052"></a>CMD 1</td><td><a id="p101053"></a>CMD 2</td><td><a id="p101054"></a>Байт 1</td><td><a id="p101055"></a>Байт 2</td><td><a id="p101056"></a>Байт 3</td><td><a id="p101057"></a>Байт 4</td><td><a id="p101058"></a>Байт 5</td><td></td><td><a id="p101059"></a>Байт n</td></tr>
<tr><td colspan="9"><a id="p101060"></a>Заголовок протокола обмена данными</td></tr>
<tr><td><a id="p101061"></a>CMD 1</td><td><a id="p101062"></a>CMD 2</td><td><a id="p101063"></a>PFB</td><td><a id="p101064"></a>[DID]</td><td><a id="p101065"></a>[NAD]</td><td colspan="4"></td></tr>
<tr><td colspan="5"></td><td colspan="4"><a id="p101066"></a>Байты передачи данных</td></tr>
<tr><td colspan="5"></td><td><a id="p101067"></a>Байт данных 1</td><td><a id="p101068"></a>Байт данных 2</td><td></td><td><a id="p101069"></a>Байт данных n</td></tr>
</table>


<a id="p101070"></a>Рисунок 31 - Определение кадров протокола

<a id="p101071"></a>В информационном обмене содержание полезной нагрузки поля передачи данных требует согласия между обменивающимися сторонами.

###### <a id="p101072"></a>12.6.1.1.1 Определение байтов заголовка протокола обмена данными

<a id="p101073"></a>**CMD1:**
<a id="p101074"></a>Если CMD2 является DEP_REQ, то CMD1 должен быть установлен в значение 'D4'.
<a id="p101075"></a>Если CMD2 является DEP_RES, то CMD1 должен быть установлен в значение 'D5'.
<a id="p101076"></a>**CMD 2: DEP_REQ**
<a id="p101077"></a>Байты DEP_REQ определяют команду для протокола обмена данными для устройства Инициатора. Значение DEP_REQ должно быть '06'.
<a id="p101078"></a>**CMD 2: DEP_RES**
<a id="p101079"></a>Байты DEP_RES определяют команду для обмена данными для Целевого устройства. Значение DEP_RES должно быть '07'.
<a id="p101080"></a>Байт 1: PFB
<a id="p101081"></a>Байт PFB должен содержать биты для управления передачей данных и устранения ошибок. Байт PFB используется для передачи информации, необходимой для контроля над процессом передачи. Протокол обмена данными определяет следующие базовые типы pdu:
- <a id="p101082"></a>Информационные pdu для передачи информации на прикладном уровне;
- <a id="p101083"></a>ACK/NACK pdu для передачи положительных или отрицательных подтверждений. ACK/NACK pdu никогда не содержит поле данных. Подтверждение касается последнего полученного блока;
- <a id="p101084"></a>Защищенные pdu, использующие опцию NFC-SEC, как указано в ИСО/МЭК 13157-1;
- <a id="p101085"></a>Контрольные pdu для обмена контрольной информацией между Инициатором и Целью. Определены два типа контрольных pdu;
- <a id="p101086"></a>Продления тайм-аута, содержащие поле данных длиной в 1 байт;
- <a id="p101087"></a>Привлечение внимания, не содержащее поля данных.
<a id="p101088"></a>Таблица 8 определяет кодирование PFB.

<a id="p101089"></a>Таблица 8

<a id="p101090"></a>Кодирование битов PFB с 8 по 6


<table>
<colgroup><col width="19%"><col width="19%"><col width="19%"><col width="42%"></colgroup>
<tr><td><a id="p101091"></a>Бит 8</td><td><a id="p101092"></a>Бит 7</td><td><a id="p101093"></a>Бит 6</td><td><a id="p101094"></a>PFB</td></tr>
<tr><td><a id="p101095"></a>0</td><td><a id="p101096"></a>0</td><td><a id="p101097"></a>0</td><td><a id="p101098"></a>Информационный pdu</td></tr>
<tr><td><a id="p101099"></a>0</td><td><a id="p101100"></a>0</td><td><a id="p101101"></a>1</td><td><a id="p101102"></a>Защищенный pdu</td></tr>
<tr><td><a id="p101103"></a>0</td><td><a id="p101104"></a>1</td><td><a id="p101105"></a>0</td><td><a id="p101106"></a>ACK/NACK pdu</td></tr>
<tr><td><a id="p101107"></a>1</td><td><a id="p101108"></a>0</td><td><a id="p101109"></a>0</td><td><a id="p101110"></a>Контрольный pdu</td></tr>
<tr><td colspan="4"><a id="p101111"></a>Остальные установки являются RFU</td></tr>
</table>


<a id="p101112"></a>Рисунок 32 определяет структуру информационного pdu.


| <a id="p101113"></a>бит 8 | <a id="p101114"></a>бит 7 | <a id="p101115"></a>бит 6 | <a id="p101116"></a>бит 5 | <a id="p101117"></a>бит 4 | <a id="p101118"></a>бит 3 | <a id="p101119"></a>бит 2 | <a id="p101120"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p101121"></a>НУЛЬ | <a id="p101122"></a>НУЛЬ | <a id="p101123"></a>НУЛЬ | <a id="p101124"></a>MI | <a id="p101125"></a>NAD | <a id="p101126"></a>DID | <a id="p101127"></a>PNI | <a id="p101128"></a>PNI |


<a id="p101129"></a>Рисунок 32 - Информационный pdu

- <a id="p101130"></a>бит 8 - бит 6: Должны быть все установлены в значение НУЛЬ;
- <a id="p101131"></a>бит 5: Бит, установленный в значение ЕДИНИЦА, показывает, что активировано формирование цепочки многокомпонентной информации (MI);
- <a id="p101132"></a>бит 4: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен NAD;
- <a id="p101133"></a>бит 3: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен DID;
- <a id="p101134"></a>бит 2 и бит 1: Информация о номере пакета PNI.
<a id="p101135"></a>Информация о номере пакета (PNI) подсчитывает номер пакета, отправленного от Инициатора к Цели, и наоборот, начиная с 0. Данные байты используются для обнаружения ошибок в процессе обработки протоколов.
<a id="p101136"></a>Рисунок 33 определяет структуру ACK/NACK pdu.


| <a id="p101137"></a>бит 8 | <a id="p101138"></a>бит 7 | <a id="p101139"></a>бит 6 | <a id="p101140"></a>бит 5 | <a id="p101141"></a>бит 4 | <a id="p101142"></a>бит 3 | <a id="p101143"></a>бит 2 | <a id="p101144"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p101145"></a>НУЛЬ | <a id="p101146"></a>ЕДИНИЦА | <a id="p101147"></a>НУЛЬ | <a id="p101148"></a>ACK/NACK | <a id="p101149"></a>NAD | <a id="p101150"></a>DID | <a id="p101151"></a>PNI | <a id="p101152"></a>PNI |


<a id="p101153"></a>Рисунок 33 - ACK/NACK pdu

- <a id="p101154"></a>бит 8: Должен быть установлен в значение НУЛЬ;
- <a id="p101155"></a>бит 7: Должен быть установлен в значение ЕДИНИЦА;
- <a id="p101156"></a>бит 6: Должен быть установлен в значение НУЛЬ;
- <a id="p101157"></a>бит 5: Бит, установленный в значение ЕДИНИЦА, означает NACK, в противном случае - ACK;
- <a id="p101158"></a>бит 4: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен NAD;
- <a id="p101159"></a>бит 3: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен DID;
- <a id="p101160"></a>бит 2 и бит 1: Номер пакета PNI.
<a id="p101161"></a>Рисунок 34 определяет контрольный pdu (Внимание - наличие Цели; Продления тайм-аута).


| <a id="p101162"></a>бит 8 | <a id="p101163"></a>бит 7 | <a id="p101164"></a>бит 6 | <a id="p101165"></a>бит 5 | <a id="p101166"></a>бит 4 | <a id="p101167"></a>бит 3 | <a id="p101168"></a>бит 2 | <a id="p101169"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p101170"></a>ЕДИНИЦА | <a id="p101171"></a>НУЛЬ | <a id="p101172"></a>НУЛЬ | <a id="p101173"></a>Внимание/Тайм-аут | <a id="p101174"></a>NAD | <a id="p101175"></a>DID | <a id="p101176"></a>НУЛЬ | <a id="p101177"></a>НУЛЬ |


<a id="p101178"></a>Рисунок 34 - Контрольный pdu

- <a id="p101179"></a>бит 8: Должен быть установлен в значение ЕДИНИЦА;
- <a id="p101180"></a>бит 7 и бит 6: Должны быть установлены в значение НУЛЬ;
- <a id="p101181"></a>бит 5: Если ВНИМАНИЕ, то должен быть НУЛЬ. Если ПРОДЛЕНИЕ ТАЙМ-АУТА, то ЕДИНИЦА;
- <a id="p101182"></a>бит 4: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен NAD;
- <a id="p101183"></a>бит 3: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен DID;
- <a id="p101184"></a>бит 2 и бит 1: Должны быть установлены в значение НУЛЬ.
<a id="p101185"></a>Байт 2: DID
<a id="p101186"></a>Байт DID должен быть таким же, что и определенный в процессе активации протокола.
<a id="p101187"></a>Байт 3: NAD
<a id="p101188"></a>Байт NAD зарезервирован для установления и адресации различных логических соединений как на устройстве Инициаторе, так и на Целевом устройстве. Бит 8 - бит 5 кодируют логический адрес Инициатора, биты с 4 по 1 кодируют логический адрес Цели. Для процесса использования NAD применяются следующие определения:
- <a id="p101189"></a>NAD должен использоваться только для протокола обмена данными;
- <a id="p101190"></a>Если Инициатор использует NAD, Цель также должна использовать NAD;
- <a id="p101191"></a>Если установлен бит MI, то NAD должен быть передан только в первом кадре;
- <a id="p101192"></a>Инициатор никогда не должен использовать NAD для адресации двух различных Целей.
<a id="p101193"></a>Байт 4 - Байт n: байты пользовательских данных
<a id="p101194"></a>Поле данных должно содержать передаваемые данные и является необязательным. Если оно присутствует, оно передает либо данные приложения, либо информацию о статусе. Длина поля данных рассчитывается путем вычитания обязательных и необязательных отправляемых байтов транспортного заголовка обмена данными из длины байта и дополнительного вычитания единицы.

###### <a id="p101195"></a>12.6.1.2 Обработка информации о номере pdu


###### <a id="p101196"></a>12.6.1.2.1 Правила для Инициатора

<a id="p101197"></a>PNI Инициатора для каждой Цели должна быть установлена в исходное состояние, состоящее из НУЛЕЙ.
<a id="p101198"></a>При приеме информационного или подтверждающего pdu с равным значением PNI Инициатор должен инкрементировать текущее значение PNI для данной Цели перед необязательной отправкой нового кадра.

###### <a id="p101199"></a>12.6.1.2.2 Правила для Цели

<a id="p101200"></a>PNI Цели должна быть установлена в исходное состояние, состоящее из НУЛЕЙ.
<a id="p101201"></a>При приеме информационного или подтверждающего pdu с равным значением PNI Цель должна отправить свой ответ с таким же значением PNI и затем инкрементировать значение PNI.

###### <a id="p101202"></a>12.6.1.3 Обработка блоков


###### <a id="p101203"></a>12.6.1.3.1 Общие правила

<a id="p101204"></a>Первый pdu должен быть отправлен Инициатором.
<a id="p101205"></a>Когда pdu с данными указывает, что принято больше информации, pdu должен быть подтвержден - ACK pdu.
<a id="p101206"></a>Контрольные pdu используются только в паре. Контрольный запрос должен всегда сопровождаться Контрольным ответом.

###### <a id="p101207"></a>12.6.1.3.2 Правила для Инициатора

<a id="p101208"></a>При приеме недопустимого pdu должен быть отправлен NACK pdu (за исключением случаев, когда это DSL или RLS).
<a id="p101209"></a>При возникновении тайм-аута должна быть отправлена команда привлечения внимания (за исключением случаев, когда до этого уже был отправлен NACK).
<a id="p101210"></a>При возникновении тайм-аута и когда NACK уже был отправлен ранее, NACK должен быть передан повторно.
<a id="p101211"></a>При приеме ACK pdu, если номер его pdu равен текущему значению PNI Инициатора, то формирование цепочки должно быть продолжено.
<a id="p101212"></a>Если в ответ на DSL_REQ приходит недопустимый DSL_RES, то DSL_REQ может быть отправлен повторно или же Целевая команда проигнорирована.

###### <a id="p101213"></a>12.6.1.3.3 Правила для Цели

<a id="p101214"></a>Цели разрешено отправлять RTO pdu вместо pdu с данными.
<a id="p101215"></a>При приеме pdu с данными, не содержащего формирования цепочки, это должно быть подтверждено pdu с данными.
<a id="p101216"></a>При приеме NACK pdu, если значение PNI равно значению PNI предыдущего посланного pdu, предыдущий блок должен быть передан заново.
<a id="p101217"></a>При приеме ошибочного pdu Цель не должна отвечать и должна оставаться в том же состоянии.
<a id="p101218"></a>При приеме контрольного pdu, кодирующего команду привлечения внимания, Цель должна ответить отправкой реакции на команду привлечения внимания контрольного pdu.

##### <a id="p101219"></a>12.6.2 Продление тайм-аута ответа

<a id="p101220"></a>Продление тайм-аута ответа RTOX (Response timeout extension) должно быть использовано только Целью. Когда Цели требуется больше времени на обработку полученного блока от Инициатора, чем определено в RWT, Цель должна использовать контрольный pdu, использующий запрос на продление тайм-аута ответа, см. рисунок 35. Запрос на продление тайм-аута ответа содержит поле данных длиной в 1 байт. Определение байта показано на рисунке 35.


| <a id="p101221"></a>бит 8 | <a id="p101222"></a>бит 7 | <a id="p101223"></a>бит 6 | <a id="p101224"></a>бит 5 | <a id="p101225"></a>бит 4 | <a id="p101226"></a>бит 3 | <a id="p101227"></a>бит 2 | <a id="p101228"></a>бит 1 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p101229"></a>НУЛЬ | <a id="p101230"></a>НУЛЬ | <a id="p101231"></a>RTOX | <a id="p101232"></a>RTOX | <a id="p101233"></a>RTOX | <a id="p101234"></a>RTOX | <a id="p101235"></a>RTOX | <a id="p101236"></a>RTOX |


<a id="p101237"></a>Рисунок 35 - Байт продления тайм-аута ответа

- <a id="p101238"></a>бит 8 и бит 7: Должен быть установлен в значение НУЛЬ;
- <a id="p101239"></a>бит 6 - бит 1: Значение RTOX.
<a id="p101240"></a>Значения 0 и 60 - 63 для RTOX являются RFU. Для всех остальных значений промежуточное RWTINT рассчитывается по следующей формуле:
<a id="p101241"></a>RWTINT = RWT x RTOX.
<a id="p101242"></a>RWTINT начинается после того, как Инициатор послал свой RTOX-ответ Цели. В случае, когда RWTINT превышает RWT<sub>MAX</sub>, должно использоваться RWTMAX. RWTINT действительно до тех пор, пока Инициатором не будет принят следующий кадр.

##### <a id="p101243"></a>12.6.3 Внимание - наличие Цели

<a id="p101244"></a>Инициатор должен отправить Цели команду привлечения внимания, чтобы убедиться в том, что Цель все еще находится в поле в пассивном режиме, или же для того, чтобы выявить потерю Цели в процессе мультиактивации. Данная команда не должна приводить к изменению текущего состояния Цели.
<a id="p101245"></a>Цель должна ответить Инициатору на допустимый запрос привлечения внимания отправкой команды привлечения внимания, содержащей идентичное поле данных.
<a id="p101246"></a>Если Цель получает некорректное pdu, она не должна реагировать на него и должна остаться в том же состоянии.

##### <a id="p101247"></a>12.6.4 Протокольная операция

<a id="p101248"></a>После последовательности активации Цель должна ждать блок, который имеет право отправить только Инициатор. После отправки блока Инициатор должен переключиться в режим приема и ждать блок до того, как переключиться обратно в режим передачи. Цель может передавать блоки только в ответ на полученные блоки. После ответа Цель должна вернуться в режим приема.
<a id="p101249"></a>Инициатор не должен начинать новую пару запрос/ответ, пока текущая пара запрос/ответ не завершена или если время ожидания кадра превышено и ответа не поступило.

##### <a id="p101250"></a>12.6.5 Мультиактивация

<a id="p101251"></a>Функция мультиактивации позволяет Инициатору удерживать активными несколько Целей одновременно. Это позволяет переключаться напрямую между несколькими Целями без дополнительных затрат времени на деактивацию одной Цели и активацию другой Цели.
<a id="p101252"></a>Для примера мультиактивации см. таблицу 9. Инициатор должен обрабатывать отдельную информацию о номере пакета для каждой активированной Цели.

<a id="p101253"></a>Таблица 9

<a id="p101254"></a>Мультиактивация


| <a id="p101255"></a>Действие Инициатора | <a id="p101256"></a>Статус<br>Цели 1 | <a id="p101257"></a>Статус<br>Цели 2 | <a id="p101258"></a>Статус<br>Цели 3 |
| --- | --- | --- | --- |
| <a id="p101259"></a>Выбрать активный режим |  |  |  |
| <a id="p101260"></a>Активировать Цель 1 с DID = 1 | <a id="p101261"></a>Выбрана (1) | <a id="p101262"></a>Зондирование | <a id="p101263"></a>Зондирование |
| <a id="p101264"></a>Любая коммуникация с DID = 1 | <a id="p101265"></a>Выбрана (1) | <a id="p101266"></a>Зондирование | <a id="p101267"></a>Зондирование |
|  |  |  |  |
| <a id="p101268"></a>Активировать Цель 2 с DID = 2 | <a id="p101269"></a>Выбрана (1) | <a id="p101270"></a>Выбрана (2) | <a id="p101271"></a>Зондирование |
| <a id="p101272"></a>Любая коммуникация с DID = 1,2 | <a id="p101273"></a>Выбрана (1) | <a id="p101274"></a>Выбрана (2) | <a id="p101275"></a>Зондирование |
|  |  |  |  |
| <a id="p101276"></a>Активировать Цель 3 с DID = 3 | <a id="p101277"></a>Выбрана (1) | <a id="p101278"></a>Выбрана (2) | <a id="p101279"></a>Выбрана (3) |
| <a id="p101280"></a>Любая коммуникация с DID = 1,2,3 | <a id="p101281"></a>Выбрана (1) | <a id="p101282"></a>Выбрана (2) | <a id="p101283"></a>Выбрана (3) |
|  |  |  |  |
| <a id="p101284"></a>Последовательность деактивации с DID = 1 | <a id="p101285"></a>Сон | <a id="p101286"></a>Выбрана (2) | <a id="p101287"></a>Выбрана (3) |
| <a id="p101288"></a>Любая коммуникация с DID = 2,3 | <a id="p101289"></a>Сон | <a id="p101290"></a>Выбрана (2) | <a id="p101291"></a>Выбрана (3) |
|  |  |  |  |
| <a id="p101292"></a>Последовательность деактивации с DID = 2 | <a id="p101293"></a>Сон | <a id="p101294"></a>Сон | <a id="p101295"></a>Выбрана (3) |
| <a id="p101296"></a>Любая коммуникация с DID = 3 | <a id="p101297"></a>Сон | <a id="p101298"></a>Сон | <a id="p101299"></a>Выбрана (3) |
|  |  |  |  |
| <a id="p101300"></a>Последовательность деактивации с DID = 3 | <a id="p101301"></a>Сон | <a id="p101302"></a>Сон | <a id="p101303"></a>Сон |



##### <a id="p101304"></a>12.6.6 Больше информации (формирование цепочки)

<a id="p101305"></a>Функция формирования цепочки позволяет Инициатору или Цели передавать информацию, которая не помещается в один блок, путем деления такой информации на несколько блоков. Каждый из таких блоков должен иметь длину менее или равную максимальному размеру кадра (LENMAX).
<a id="p101306"></a>Бит формирования цепочки в PFB протокольного кадра контролирует формирование цепочки кадров. Каждый кадр с набором битов формирования цепочки должен быть подтвержден ACK pdu.
<a id="p101307"></a>Функция формирования цепочки, показанная на рисунке 36, использует 16-байтовую строку, передаваемую в трех блоках.

<a id="p101308"></a> ![12. Транспортный протокол](https://i.bukva.ai/s8td7dH1/img_12.png) 

<a id="p101309"></a>Рисунок 36 - Больше информации (формирование цепочки)


#### <a id="p101310"></a>12.7 Деактивация протокола

<a id="p101311"></a>После обмена данных с помощью протокола обмена данными Инициатор может применить деактивацию протокола обмена данными. После успешной деактивации Инициатор и Цель должны остаться в первоначально выбранном режиме, но Инициатор может выбрать одну из определенных скоростей передачи данных для повторной активации.
<a id="p101312"></a>*См.* ИСО/МЭК 14443-3 п. 6.4.1 и 12.5.2 для повторной активации Целей в пассивном режиме и в активном режиме соответственно.
<a id="p101313"></a>После успешной деактивации Цель не должна реагировать на последующие команды ATR_REQ.
<a id="p101314"></a>Команда RLS_REQ должна переключать Цель обратно в состояние ПИТАНИЕ ВКЛЮЧЕНО. См. [12.7.2.1](#p101355). В данном состоянии Цель должна отвечать на все первоначальные схемы связи, а также на ATR_REQ.

##### <a id="p101315"></a>12.7.1 Команды Запрос на деселекцию и Ответ на деселекцию


###### <a id="p101316"></a>12.7.1.1 Запрос на деселекцию (DSL_REQ)

<a id="p101317"></a>Рисунок 37 определяет команду деселекции DSL_REQ. Инициатор отправляет DSL_REQ Цели.


| <a id="p101318"></a>CMD 1 | <a id="p101319"></a>CMD 2 | <a id="p101320"></a>Байт 1 |
| --- | --- | --- |
| <a id="p101321"></a>'D4' | <a id="p101322"></a>'08' | <a id="p101323"></a>[DID] |


<a id="p101324"></a>Рисунок 37 - Структура DSL_REQ


###### <a id="p101325"></a>12.7.1.1.1 Определение байтов DSL_REQ

<a id="p101326"></a>CMD 1: Должен быть установлен в значение 'D4'.
<a id="p101327"></a>**CMD 2: DSL_REQ**
<a id="p101328"></a>Байт DSL_REQ определяет команду деселекции для устройства Инициатора. Значение DSL_REQ должно быть '08'.
<a id="p101329"></a>Байт 1: DID
<a id="p101330"></a>DID должен быть таким же, как определенный в ходе команд ATR или WUP.

###### <a id="p101331"></a>12.7.1.2 Ответ на деселекцию (DSL_RES)

<a id="p101332"></a>Рисунок 38 определяет команду Ответ на деселекцию DSL_RES. DSL_RES является ответом на DSL_REQ и отправляется от Цели к Инициатору.


| <a id="p101333"></a>CMD 1 | <a id="p101334"></a>CMD 2 | <a id="p101335"></a>Байт 1 |
| --- | --- | --- |
| <a id="p101336"></a>'D5' | <a id="p101337"></a>'09' | <a id="p101338"></a>[DID] |


<a id="p101339"></a>Рисунок 38 - Структура DSL_RES


###### <a id="p101340"></a>12.7.1.2.1 Определение байтов DSL_RES

<a id="p101341"></a>CMD 1: Должен быть установлен в значение 'D5'.
<a id="p101342"></a>**CMD 2: DSL_RES**
<a id="p101343"></a>Байт DSL_RES определяет ответ на команду деселекции для Целевого устройства. Значение DSL_RES должно быть '09'.
<a id="p101344"></a>Байт 1: DID
<a id="p101345"></a>DID должен быть таким же, как в DSL_REQ.

###### <a id="p101346"></a>12.7.1.3 Обработка DSL_REQ и DSL_RES


###### <a id="p101347"></a>12.7.1.3.1 Правила для Инициатора

<a id="p101348"></a>Когда Инициатор отправил DSL_REQ и получил допустимый DLS_RES, Цель была успешно остановлена. Предназначавшийся для данной Цели DID был освобожден.

###### <a id="p101349"></a>12.7.1.3.2 Правила для Цели

<a id="p101350"></a>Когда Цель получила DSL_REQ и послала свой DSL_RES, Цель:
- <a id="p101351"></a>должна оставаться в первоначально выбранном режиме;
- <a id="p101352"></a>должна позволить принимать стандартные скорости передачи данных, указанные в [11.2](#p100293) для пассивного режима связи и в [11.3](#p100437) для активного режима связи;
- <a id="p101353"></a>должна оставаться в режиме приема до тех пор, пока не будет получен допустимый ALL_REQ в пассивном режиме связи на fc/128 или WUP_REQ в активном режиме связи.

##### <a id="p101354"></a>12.7.2 Команды Запрос на освобождение и Ответ на освобождение


###### <a id="p101355"></a>12.7.2.1 Запрос на освобождение (RLS_REQ)

<a id="p101356"></a>Рисунок 39 определяет команду освобождения RLS_REQ. RLS_REQ отправляется от Инициатора к Цели.


| <a id="p101357"></a>CMD 1 | <a id="p101358"></a>CMD 2 | <a id="p101359"></a>Байт 1 |
| --- | --- | --- |
| <a id="p101360"></a>'D4' | <a id="p101361"></a>'0A' | <a id="p101362"></a>[DID] |


<a id="p101363"></a>Рисунок 39 - Структура RLS_REQ


###### <a id="p101364"></a>12.7.2.1.1 Определение байтов RLS_REQ

<a id="p101365"></a>CMD 1: Должен быть установлен в значение 'D4'.
<a id="p101366"></a>**CMD 2: RLS_REQ**
<a id="p101367"></a>Байты RLS_REQ определяют команду освобождения для устройства Инициатора. Значение байтов RLS_REQ должно быть '0A'.
<a id="p101368"></a>Байт 1: DID
<a id="p101369"></a>DID должен быть таким же, как определенный в ходе команд ATR или WUP.

###### <a id="p101370"></a>12.7.2.2 Ответ на освобождение RLS_RES

<a id="p101371"></a>RLS_RES является ответом на RLS_REQ, отправленный от Цели - Инициатору, см. рисунок 40.


| <a id="p101372"></a>CMD 1 | <a id="p101373"></a>CMD 2 | <a id="p101374"></a>Байт 1 |
| --- | --- | --- |
| <a id="p101375"></a>'D5' | <a id="p101376"></a>'0B' | <a id="p101377"></a>[DID] |


<a id="p101378"></a>Рисунок 40 - Структура RLS_RES


###### <a id="p101379"></a>12.7.2.2.1 Определение байтов RLS_RES

<a id="p101380"></a>CMD 1: Должен быть установлен в значение 'D5'.
<a id="p101381"></a>**CMD 2: RLS_RES**
<a id="p101382"></a>Байты RLS_RES определяют команду освобождения для Целевого устройства. Значение байтов RLS_RES должно быть '0B'.
<a id="p101383"></a>Байт 1: DID
<a id="p101384"></a>DID должен быть таким же, как в RLS_REQ.

###### <a id="p101385"></a>12.7.2.3 Обработка RLS_REQ и RLS_RES


###### <a id="p101386"></a>12.7.2.3.1 Правила для Инициатора

<a id="p101387"></a>Когда Инициатор отправил RLS_REQ и получил допустимый RLS_RES, Цель была успешно освобождена. Инициатор может вернуться в свое первоначальное состояние.

###### <a id="p101388"></a>12.7.2.3.2 Правила для Цели

<a id="p101389"></a>Когда Цель получила RLS_REQ и послала свой RLS_RES, Цель должна вернуться в первоначальное состояние.





<a id="p101390"></a>Приложение A
(обязательное)

<a id="p101391"></a>**ВЫЧИСЛЕНИЕ CRC**

<a id="p101392"></a>A.1 CRC для активного и пассивного режима связи на fc/128
<a id="p101393"></a>CRC кадра должен быть функцией от k битов данных, которые состоят из всех битов данных в кадре, за исключением битов четности, S и E, и самого CRC. Поскольку данные кодируются в байтах, число битов k должно быть кратно 8. Для проверки ошибок два CRC-байта должны быть отправлены в стандартном кадре после байтов и перед E.
<a id="p101394"></a>CRC должен быть рассчитан по следующему полиному. Предустановленное значение должно быть (6363), и содержимое регистра не должно быть инверсировано после расчета.

<a id="p101395"></a>G(x) = x16 + x12 + x5 + 1

<a id="p101396"></a>Пример расчета CRC для активного и пассивного режима на fc/128 см. в [A.2](#p101397).
<a id="p101397"></a>A.2 Пример расчета CRC на fc/128
<a id="p101398"></a>Данный пример приведен в пояснительных целях и показывает битовые комбинации, которые будут существовать на физическом уровне. Он включен для проверки реализации кодирования в пассивном режиме связи на fc/128.
<a id="p101399"></a>Процесс кодирования и декодирования может быть удобно реализован с помощью 16-ступенчатого регистра циклического сдвига с соответствующими схемами обратной связи. Согласно рекомендации МСЭ-Т (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 id="p101400"></a>Таблица A.1

<a id="p101401"></a>Начальное заполнение 16-ступенчатого регистра сдвига
в соответствии со значением (6363)


| <a id="p101402"></a>FF1 | <a id="p101403"></a>FF2 | <a id="p101404"></a>FF3 | <a id="p101405"></a>FF4 | <a id="p101406"></a>FF5 | <a id="p101407"></a>FF6 | <a id="p101408"></a>FF7 | <a id="p101409"></a>FF8 | <a id="p101410"></a>FF9 | <a id="p101411"></a>FF0 | <a id="p101412"></a>FF 11 | <a id="p101413"></a>FF 12 | <a id="p101414"></a>FF 13 | <a id="p101415"></a>FF 14 | <a id="p101416"></a>FF 15 | <a id="p101417"></a>FF 16 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p101418"></a>0 | <a id="p101419"></a>1 | <a id="p101420"></a>1 | <a id="p101421"></a>0 | <a id="p101422"></a>0 | <a id="p101423"></a>0 | <a id="p101424"></a>1 | <a id="p101425"></a>1 | <a id="p101426"></a>0 | <a id="p101427"></a>1 | <a id="p101428"></a>1 | <a id="p101429"></a>0 | <a id="p101430"></a>0 | <a id="p101431"></a>0 | <a id="p101432"></a>1 | <a id="p101433"></a>1 |


<a id="p101434"></a>Следовательно, FF1 соответствует msb, а FF16 - lsb.
<a id="p101435"></a>Ниже приведены примеры битовых комбинаций, которые будут передаваться посредством стандартных кадров.
<a id="p101436"></a>*Пример* 1: Передача данных, первый байт = '00', второй байт = '00', CRC добавлен, см. рисунок A.1. Рассчитанный CRC = (1EA0), см. таблицу A.2.


<table>
<colgroup><col width="6%"><col width="16%"><col width="6%"><col width="16%"><col width="6%"><col width="16%"><col width="6%"><col width="16%"><col width="6%"><col width="6%"></colgroup>
<tr><td colspan="10"><a id="p101437"></a>Первый передаваемый бит</td></tr>
<tr><td><a id="p101438"></a>S</td><td><a id="p101439"></a>0100 1000</td><td><a id="p101440"></a>1</td><td><a id="p101441"></a>0010 1100</td><td><a id="p101442"></a>0</td><td><a id="p101443"></a>0110 0100</td><td><a id="p101444"></a>0</td><td><a id="p101445"></a>1111 0011</td><td><a id="p101446"></a>1</td><td><a id="p101447"></a>E</td></tr>
<tr><td></td><td><a id="p101448"></a>(12)</td><td><a id="p101449"></a>P</td><td><a id="p101450"></a>(34)</td><td><a id="p101451"></a>P</td><td><a id="p101452"></a>(26)</td><td><a id="p101453"></a>P</td><td><a id="p101454"></a>(CF)</td><td><a id="p101455"></a>P</td><td></td></tr>
</table>


<a id="p101456"></a>Рисунок A.1 - Пример 1 кодирования CRC

<a id="p101457"></a>Таблица A.2

<a id="p101458"></a>Заполнение 16-ступенчатого регистра сдвига в соответствии
со значением (1EA0)


| <a id="p101459"></a>FF1 | <a id="p101460"></a>FF2 | <a id="p101461"></a>FF3 | <a id="p101462"></a>FF4 | <a id="p101463"></a>FF5 | <a id="p101464"></a>FF6 | <a id="p101465"></a>FF7 | <a id="p101466"></a>FF8 | <a id="p101467"></a>FF9 | <a id="p101468"></a>FF0 | <a id="p101469"></a>FF 11 | <a id="p101470"></a>FF 12 | <a id="p101471"></a>FF 13 | <a id="p101472"></a>FF 14 | <a id="p101473"></a>FF 15 | <a id="p101474"></a>FF 16 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p101475"></a>0 | <a id="p101476"></a>0 | <a id="p101477"></a>0 | <a id="p101478"></a>1 | <a id="p101479"></a>1 | <a id="p101480"></a>1 | <a id="p101481"></a>1 | <a id="p101482"></a>0 | <a id="p101483"></a>1 | <a id="p101484"></a>0 | <a id="p101485"></a>1 | <a id="p101486"></a>0 | <a id="p101487"></a>0 | <a id="p101488"></a>0 | <a id="p101489"></a>0 | <a id="p101490"></a>0 |


<a id="p101491"></a>*Пример* 2: Передача блока данных, первый байт = '12', второй байт = '34', CRC добавлен, см. рисунок A.2. Рассчитанный CRC = 'CF26', см. таблицу A.3.


<table>
<colgroup><col width="6%"><col width="16%"><col width="6%"><col width="16%"><col width="6%"><col width="16%"><col width="6%"><col width="16%"><col width="6%"><col width="6%"></colgroup>
<tr><td colspan="10"><a id="p101492"></a>Первый передаваемый бит</td></tr>
<tr><td><a id="p101493"></a>S</td><td><a id="p101494"></a>0100 1000</td><td><a id="p101495"></a>1</td><td><a id="p101496"></a>0010 1100</td><td><a id="p101497"></a>0</td><td><a id="p101498"></a>0110 0100</td><td><a id="p101499"></a>0</td><td><a id="p101500"></a>1111 0011</td><td><a id="p101501"></a>1</td><td><a id="p101502"></a>E</td></tr>
<tr><td></td><td><a id="p101503"></a>(12)</td><td><a id="p101504"></a>P</td><td><a id="p101505"></a>(34)</td><td><a id="p101506"></a>P</td><td><a id="p101507"></a>(26)</td><td><a id="p101508"></a>P</td><td><a id="p101509"></a>(CF)</td><td><a id="p101510"></a>P</td><td></td></tr>
</table>


<a id="p101511"></a>Рисунок A.2 - Пример 2 кодирования CRC

<a id="p101512"></a>Таблица A.3

<a id="p101513"></a>Заполнение 16-ступенчатого регистра сдвига в соответствии
со значением (CF26)


| <a id="p101514"></a>FF1 | <a id="p101515"></a>FF2 | <a id="p101516"></a>FF3 | <a id="p101517"></a>FF4 | <a id="p101518"></a>FF5 | <a id="p101519"></a>FF6 | <a id="p101520"></a>FF7 | <a id="p101521"></a>FF8 | <a id="p101522"></a>FF9 | <a id="p101523"></a>FF0 | <a id="p101524"></a>FF 11 | <a id="p101525"></a>FF 12 | <a id="p101526"></a>FF 13 | <a id="p101527"></a>FF 14 | <a id="p101528"></a>FF 15 | <a id="p101529"></a>FF 16 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| <a id="p101530"></a>1 | <a id="p101531"></a>1 | <a id="p101532"></a>0 | <a id="p101533"></a>0 | <a id="p101534"></a>1 | <a id="p101535"></a>1 | <a id="p101536"></a>1 | <a id="p101537"></a>1 | <a id="p101538"></a>0 | <a id="p101539"></a>0 | <a id="p101540"></a>1 | <a id="p101541"></a>0 | <a id="p101542"></a>0 | <a id="p101543"></a>1 | <a id="p101544"></a>1 | <a id="p101545"></a>0 |


<a id="p101546"></a>A.3 CRC для активного и пассивного режимов связи на fc/64 и fc/32
<a id="p101547"></a>CRC должен рассчитывается с помощью CCITT CRC-16, область применения которого должна включать поле Длина и поле Полезная нагрузка. Расчет G(x) должен осуществляться следующим образом:

<a id="p101548"></a>G(x) = x16 + x12 + x5 + 1.

<a id="p101549"></a>Предустановленное значение должно быть 0. Пример расчета CRC для активного и пассивного режимов на fc/64 и fc/32 см. в [A.4](#p101550).
<a id="p101550"></a>A.4 Пример расчета CRC на fc/64 и fc/32
<a id="p101551"></a>Типовой кадр является следующим:
<a id="p101552"></a>**'00' '00' '00' '00' '00' '00' 'B2' '4D' '03' 'AB' 'CD' '90' '35'**
<a id="p101553"></a>'B2' '4D' - SYNC. '03' - длина. 'AB' 'CD' - пользовательские данные. '90' '35' - соответствующий CRC.





<a id="p101554"></a>Приложение B
(справочное)

<a id="p101555"></a>**SAK**

<a id="p101556"></a>Рисунок B.1 иллюстрирует использование комбинации SAK в ИСО/МЭК 14443 и ИСО/МЭК 18092.

<a id="p101557"></a> ![12. Транспортный протокол](https://i.bukva.ai/s8td7dH1/img_13.png) 

<a id="p101558"></a>Рисунок B.1 - Комбинация SAK





<a id="p101559"></a>Приложение ДА
(справочное)

<a id="p101560"></a>**СВЕДЕНИЯ**
**О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ**
**НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ**

<a id="p101561"></a>Таблица ДА


<table>
<colgroup><col width="38%"><col width="18%"><col width="44%"></colgroup>
<tr><td><a id="p101562"></a>Обозначение ссылочного международного стандарта</td><td><a id="p101563"></a>Степень соответствия</td><td><a id="p101564"></a>Обозначение и наименование соответствующего национального стандарта</td></tr>
<tr><td><a id="p101565"></a>МСЭ-Т V.41:1988</td><td><a id="p101566"></a>-</td><td><a id="p101567"></a><a href="#p101580">&lt;*&gt;</a></td></tr>
<tr><td><a id="p101568"></a>ИСО/МЭК 13157-1:2010</td><td><a id="p101569"></a>-</td><td><a id="p101570"></a><a href="#p101580">&lt;*&gt;</a></td></tr>
<tr><td><a id="p101571"></a>ИСО/МЭК 14443-2:2010</td><td><a id="p101572"></a>-</td><td><a id="p101573"></a><a href="#p101580">&lt;*&gt;</a></td></tr>
<tr><td><a id="p101574"></a>ИСО/МЭК 14443-3:2011</td><td><a id="p101575"></a>-</td><td><a id="p101576"></a><a href="#p101580">&lt;*&gt;</a></td></tr>
<tr><td><a id="p101577"></a>ИСО/МЭК 14443-4:2008</td><td><a id="p101578"></a>-</td><td><a id="p101579"></a><a href="#p101580">&lt;*&gt;</a></td></tr>
<tr><td colspan="3"><a id="p101580"></a>&lt;*&gt; Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов.</td></tr>
</table>




<a id="p101581"></a>

---