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

ГОСТ Р ИСО/МЭК 18092-2015

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

Телекоммуникации и обмен информацией между системами. Коммуникация в ближнем поле. Интерфейс и протокол (NFCIP-1)

Information technology. Telecommunications and information exchange between systems. Field Communication. Interface and Protocol (NFCIP-1)

ОКС 35.100.10

Дата введения 2016-11-01

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием Государственный научно-исследовательский и конструкторско-технологический институт "ТЕСТ" (ФГУП ГосНИИ "ТЕСТ"), Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 31 августа 2015 г. N 1227-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 18092:2013* "Информационные технологии. Телекоммуникации и обмен информацией между системами. Коммуникация в ближнем поле. Интерфейс и протокол (NFCIP-1)" [ISO/IEC 18092:2013 "Information technology - Telecommunications and information exchange between systems - Field Communication - Interface and Protocol (NFCIP-1)"].
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .


При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ


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

1 Область применения

1 Область применения

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

Обмен информацией между системами требует совпадения у обменивающихся сторон, как минимум, кодов обмена и структуры данных.

2 Соответствие

Система, реализующая активный и пассивный режимы связи, будет соответствовать требованиям настоящего стандарта, если она отвечает всем обязательным требованиям, указанным в настоящем стандарте.

Возможно также реализовать опцию NFC-SEC, как указано в стандарте ИСО/МЭК 13157-1.

3 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты*:
_______________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .


МСЭ-Т V.41:1988 Кодонезависимая система защиты данных от ошибок (ITU-T V.41:1988 Code-independent error-control system)

ИСО/МЭК 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)

ИСО/МЭК 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)

ИСО/МЭК 14443-3:2011 Карточки идентификационные. Бесконтактные карточки на интегральных схемах. Карточки с индуктивной связью через малый зазор. Часть 3. Инициализация и антиконфликтность (ISO/IEC 14443-3:2011 Identification cards - Contactless integrated circuit cards - Proximity cards - Part 3: Initialization and anticollision)

ИСО/МЭК 14443-4:2008 Идентификационные карточки. Бесконтактные карточки на интегральных схемах. Карточки с индуктивной связью через малый зазор. Часть 4. Протокол передачи (ISO/IEC 14443-4:2008 Identification cards - Contactless integrated circuit cards - Proximity cards - Part 4: Transmission protocol)

4 Термины и определения

В настоящем стандарте использованы следующие термины с соответствующими определениями.

4.1 активный режим связи (active communication mode): Режим, в котором как Инициатор, так и Цель используют собственное радиочастотное поле для осуществления связи.

4.2 АМн-модуляция (ASK modulation): Амплитудная манипуляция, при которой амплитуда несущей частоты модулируется по логике передаваемых данных.

4.3 Двоично-десятичный код BCD (Binary Coded Decimal): Система для представления каждого десятичного числа от 0 до 9 в виде четырехразрядного двоичного кода.

Примечание - Двоичные разряды (биты), слева направо, равняются 8, 4, 2 и 1, соответственно, в десятичных числах. Так, например, число 6 в BCD будет выглядеть как 0110.

4.4 конфликт (collision): Передача информации одновременно от двух или более Целей или Инициаторов, в результате чего принимающий такую информацию Инициатор или Цель не в состоянии распознать, от которого именно источника эти данные поступили.

4.5 кадр (frame): Последовательность битов данных и дополнительные биты обнаружения ошибок с разделителями в начале и в конце кадра.

4.6 (): Пороговое значение напряженности поля для обнаружения внешнего излучения радиочастотного поля.

4.7 Инициатор (Initiator): Генерирует радиочастотное поле и начинает связь по NFCIP-1.

4.8 нагрузочная модуляция (load modulation): Процесс амплитудной модуляции радиочастотного поля за счет изменения свойств резонансного контура, помещенного внутрь радиочастотного поля.

4.9 младшим битом вперед (Isb first, least significant bit first): Структура посимвольной передачи данных, где Isb передается прежде, чем все другие биты.

4.10 младшим байтом вперед (LSB first, Least Significant Byte first): Структура посимвольной передачи данных, где LSB передается прежде, чем все другие байты.

4.11 Манчестерское кодирование (Manchester coding): Метод двоичного кодирования, при котором логический уровень на протяжении длительности бита представлен последовательностью двух определенных физических состояний коммуникационной среды.

4.12 коэффициент модуляции (modulation index): Отношение разности между максимальным и минимальным значениями амплитуд модулированного сигнала к сумме этих значений, выраженное в процентах.

4.13 старшим битом вперед (msb first, most significant bit first): Структура посимвольной передачи данных, где msb передается прежде, чем все другие биты.

4.14 старшим байтом вперед (MSB first, Most Significant Byte first): Структура посимвольной передачи данных, где MSB передается прежде, чем все другие байты.

4.15 NFCIP-1-устройство (NFCIP-1 device): Объект настоящего стандарта.

4.16 NFC-идентификатор (NFC Identifier, NFCIDn): Число, сгенерированное случайным образом, которое используется Избежанием радиочастотных конфликтов и Обнаружением единственного устройства как для активного, так и для пассивного режимов связи.

4.17 NFC-SEC: Службы и протокол безопасности NFCIP-1 в соответствии со стандартом ИСО/МЭК 13157-1.

4.18 пассивный режим связи (passive communication mode): Когда Инициатор генерирует радиочастотное поле, а Цель отвечает на команду Инициатора по схеме нагрузочной модуляции.

4.19 Избежание радиочастотных конфликтов (RF Collision Avoidance, RFCA): Способ обнаружить наличие радиочастотного поля на основе несущей частоты, а также метод обнаружения и устранения конфликтов на уровне протокола.

4.20 SAK (Select Acknowledge): Подтверждение выбора в соответствии со стандартом ИСО/МЭК 14443-3.

Примечание - Термин SAK заменяет термин SEL_RES из ИСО/МЭК 18092:2004.

4.21 зондирование (sensing): NFCIP-1-устройство в активном режиме связи ожидает ответ на запрос, отправленный им в радиочастотном поле для обнаружения начала коммуникации и приема данного запроса.

4.22 Обнаружение единственного устройства (Single Device Detection, SDD): Алгоритм, используемый Инициатором для того, чтобы обнаружить одну из нескольких Целей в радиочастотном поле (антиконфликтность по ИСО/МЭК 14443-3).

4.23 Цель (Target): Отвечает на команду Инициатора либо по схеме нагрузочной модуляции (радиочастотное поле сгенерировано Инициатором), либо с помощью модуляции собственного сгенерированного радиочастотного поля.

4.24 Временной период (Time Period): Определяет количество слотов (интервалов времени), используемых для Избежания радиочастотных конфликтов.

4.25 Временной интервал (Time Slot): Метод подготовки временного окна, когда Цель отвечает, а также назначения и идентификации двух или более логических каналов.

4.26 транзакция (transaction): Инициализация, обмен данными и деселекция устройства.

5 Соглашения и обозначения

В настоящем стандарте применены следующие соглашения и обозначения, если не указано иное.

5.1 Представления чисел

Буквы и цифры в одинарных кавычках представляют собой числа в шестнадцатеричной системе счисления.

Установка битов обозначается НУЛЕМ или ЕДИНИЦЕЙ.

Числа в двоичной системе счисления и битовые комбинации представлены строками, состоящими из цифр 0 и 1, со старшим битом слева. Внутри таких строк может использоваться знак X с целью указать, что установка бита не указана внутри строки. Например, (XXXX)b.

5.2 Названия

Названия базовых элементов, например конкретных областей, пишутся с прописной начальной буквы.

6 Сокращения

В настоящем стандарте применены следующие сокращения.

ALL_REQ - Wake up ALL Request (Запрос на побудку ВСЕХ);

ATR - Attribute Request and Attribute Response (Запрос на атрибут и реакция на атрибут);

ATR_REQ - Attribute Request (Запрос на атрибут);

ATR_RES - Attribute Response (Реакция на атрибут);

BCD - Binary Code Decimal (Двоично-десятичный код);

BRi - Receiving bit duration supported by Initiator (Прием длительности бита, поддерживаемой Инициатором);

BRt - Receiving bit duration supported by Target (Прием длительности бита, поддерживаемой Целью);

BSi - Sending bit duration supported by Initiator (Передача длительности бита, поддерживаемой Инициатором);

BSt - Sending bit duration supported by Target (Передача длительности бита, поддерживаемой Целью);

CMD - Command (Команда);

CRC - Cyclic Redundancy Check (Циклический избыточный код);

D - Divisor (Делитель);

DEP - Data Exchange Protocol Request and Data Exchange Protocol Response (Запрос на протокол обмена данными и ответ на протокол обмена данными);

DEP_REQ - Data Exchange Protocol Request (Запрос на протокол обмена данными);

DEP_RES - Data Exchange Protocol Response (Ответ на протокол обмена данными);

DIDi - Initiator Device ID (Идентификатор устройства Инициатора);

DIDt - Target Device ID (Идентификатор Целевого устройства);

DRi - Data rate Received by Initiator (Скорость передачи данных, полученных Инициатором);

DRt - Data rate Received by Target (Скорость передачи данных, полученных Целью);

DSi - Data rate Send by Initiator (Скорость передачи данных, отправленных Инициатором);

DSL - Deselect Request and Deselect Response (Запрос на деселекцию и ответ на деселекцию);

DSL_REQ - Deselect Request (Запрос на деселекцию);

DSL_RES - Deselect Response (Ответ на деселекцию);

DSt - Data rate Send by Target (Скорость передачи данных, отправленных Целью);

etu - elementary time unit (Элементарная единица времени);

fc - Frequency of operating field (carrier frequency) [Частота рабочего поля (несущая частота)];

fd - Baseband frequency of Manchester coding (Групповая частота Манчестерского кодирования);

fs - Subcarrier (Поднесущая частота по ИСО/МЭК 14443-2);

FRT - Frame Response Time (Время отклика кадра);

Gi - Optional information field for Initiator (Необязательное информационное поле для Инициатора);

Gt - Optional information field for Target (Необязательное информационное поле для Цели);

HLTA - HaLT command, Туре А (Команда HaLT, Тип А по ИСО/МЭК 14443-3);

ID - Identification number (Идентификационный номер);

Isb - least significant bit (Младший бит);

LSB - Least Significant Byte (Младший байт);

Ml - Multiple Information link for Data Exchange Protocol (Линк Многокомпонентная информация для протокола обмена данными);

msb - most significant bit (Старший бит);

MSB - Most Significant Byte (Старший байт);

NAD - Node Address (Адрес узла);

NFCID1 - fc/128 UID;

nfcid1n - Byte number n of NFCID1 (Байт номер n NFCID1);

NFCID2 - Random ID for SDD in Passive communication mode at fc/64 and fc/32 bit rates (Произвольный идентификатор для SDD в пассивном режиме связи на скоростях передачи данных fc/64 и fc/32);

nfcid2n - Byte number n of the Random Identifier NFCID2 (Байт номер n произвольного идентификатора NFCID2);

NFCID3 - Random ID for transport protocol activation (Произвольный идентификатор для активации транспортного протокола);

nfcid3n - Byte number n of the Random Identifier NFCID3 (Байт номер n произвольного идентификатора NFCID3);

P - Odd parity bit (Бит проверки на нечетность);

PA - Preamble (Преамбула);

PCD - Proximity Coupling Device (Устройство связи через малый зазор по ИСО/МЭК 14443-2);

pdu - protocol data unit (Блок данных протокола);

PFB - Control information for transaction (Управляющая информация для транзакции);

PICC - Proximity Card (Proximity Integrated Circuit Card) or object (Бесконтактная карта или объект по ИСО/МЭК 14443-2);

PNI - Packet Number Information (Информация о номере пакета);

PPi - Protocol Parameters used by Initiator (Параметры протокола, используемые Инициатором);

PPt - Protocol Parameters used by Target (Параметры протокола, используемые Целью);

PSL - Parameter Selection Request and Parameter Selection Response (Запрос о выборе параметров и ответ о выборе параметров);

PSL_REQ - Parameter Selection Request (Запрос о выборе параметров);

PSL_RES - Parameter Selection Response (Ответ о выборе параметров);

RF - Radio Frequency (Радиочастота);

RFCA - RF Collision Avoidance (Избежание радиочастотных конфликтов);

RFU - Reserved for Future Use (Зарезервировано для использования в будущем);

RLS - Release Request and Release Response (Запрос на освобождение и ответ на освобождение);

RLS_REQ - Release Request (Запрос на освобождение);

RLS_RES - Release Response (Ответ на освобождение);

RWT - Response Waiting Time (Время ожидания ответа);

SB - Start byte for data exchange protocol at fc/128 (Стартовый байт данных для протокола обмена данными на fc/128);

SDD - Single Device Detection (anti-collision) [Обнаружение единственного устройства (антиконфликтность)];

SEL_CMD - Select Command byte (Байт команды избирания);

SYNC - Synchronisation pattern (Синхрогруппа);

TO - Timeout value (Значение тайм-аута);

UID - Unique Identifier (Уникальный идентификатор по ИСО/МЭК 14443-3);

WT - Waiting Time (Время ожидания);

WUP - Wakeup Request and Wakeup Response (Запрос на побудку и реакция на побудку);

WUP_REQ - Wakeup Request (Запрос на побудку);

WUP_RES - Wakeup Response (Реакция на побудку).

7 Общие положения

Цели и Инициаторы NFCIP-1 могут реализовывать как активный, так и пассивный режимы связи.

В активном режиме связи как Инициатором, так и Целью используется собственное радиочастотное поле для коммуникации. Инициатор начинает NFCIP-1-транзакцию. Цель в активном режиме связи отвечает на команду Инициатора посредством модуляции собственного радиочастотного поля.

В пассивном режиме связи Инициатор генерирует радиочастотное поле и начинает транзакцию. Цель в пассивном режиме связи отвечает на команду Инициатора посредством модуляции радиочастотного поля Инициатора, что называется нагрузочной модуляцией.

Настоящий стандарт устанавливает требования для модуляции, скорости передачи данных и двоичного кодирования. Кроме того, он устанавливает требования для начала коммуникации, окончания коммуникации, представления бита и байта, обнаружения кадровой синхронизации и ошибок, обнаружения единственного устройства, выбора протокола и параметров, обмена данными и деселекции устройства с интерфейсом и протоколом коммуникации в ближнем поле (NFCIP-1).

Транзакции начинаются с инициализации устройства и заканчиваются деселекцией устройства. Инициаторы и Цели обмениваются командами, ответами и данными посредством поочередной или полудуплексной двусторонней связи.

NFCIP-1-устройства способны начинать транзакции на скорости передачи данных fc/128, fc/64 и fc/32. Инициаторы выбирают одну из этих скоростей для начала транзакции и затем могут изменить ее при помощи команд PSL_REQ/PSL_RES в течение транзакции.

Режим (активный или пассивный) не подлежит изменению в течение одной транзакции.

8 Радиочастотное поле

8.1 Значения величин

fc=13,56 МГц.

=1,5 А/м (ср. квадр).

=7,5 А/м (ср. квадр).

=0,1875 А/м (ср. квадр).

8.2 Пассивный режим связи

Инициатор в местах, указанных изготовителем, должен генерировать напряженность поля, равную, по крайней мере, и не превышающую (т.е. рабочий объем) в режиме без модуляции.

Цель должна работать непрерывно в пределах между и .

8.3 Активный режим связи

Инициатор и Цель в местах, указанных изготовителем, должны поочередно генерировать радиочастотное поле, равное, по крайней мере, и не превышающее (т.е. рабочий объем) в режиме без модуляции.

8.4 Обнаружение внешнего излучения радиочастотного поля

NFCIP-1-устройства должны уметь обнаруживать внешнее излучение радиочастотного поля на частоте fc с напряженностью поля выше, чем .

9 Интерфейс радиочастотного сигнала

9.1 Длительность бита

Один etu равен 128/(Dfc), где значение делителя D зависит от скорости передачи данных и режима связи, см. таблицу 1.


Таблица 1 - Делитель D

Примечания

1 Инициатор выбирает режим связи (активный или пассивный) и скорость передачи данных (fc/128, fc/64 или fc/32, определены далее).

2 Модуляция и двоичное кодирование на скорости передачи данных за пределами fc/32 выходит за рамки настоящего стандарта.

9.2 Активный режим связи

Цели и Инициаторы должны соответствовать следующим требованиям для обоих направлений связи (Инициатор - Цель и Цель - Инициатор).

9.2.1 Требования для fc/128

9.2.1.1 Скорость передачи

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

9.2.1.2 Модуляция

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

9.2.1.3 Двоичное представление и кодирование

См. 8.1.3 ИСО/МЭК 14443-2 для скорости передачи fc/128.

9.2.1.4 Передача байтов

Инициаторы и цели должны передавать байты младшим битом вперед.

9.2.2 Требования для fc/64 и fc/32

9.2.2.1 Скорости передачи

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

9.2.2.2 Модуляция

См. 9.1.2 ИСО/МЭК 14443-2 для скоростей передачи fc/64 и fc/32. В течение передачи как Инициатор, так и Цель должны соответствовать PCD-значениям. В течение приема как Инициатор, так и Цель должны соответствовать PICC-значениям.

Примечание - Диапазон коэффициента модуляции более строгий, чем в ИСО/МЭК 18092:2004.


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

9.2.2.3 Двоичное представление и кодирование

Манчестерское двоичное кодирование должно применяться, как показано на рисунках 1 и 2.

Форматом двоичного кодирования является Манчестер с логическими уровнями, определенными как:

- логический элемент "НУЛЬ": первая половина длительности бита является амплитудой несущей с полем низкой напряженности, вторая половина длительности бита должна быть амплитудой несущей с полем высокой напряженности (без применения модуляции);

- логический элемент "ЕДИНИЦА": первая половина длительности бита является амплитудой несущей с полем высокой напряженности (без применения модуляции), вторая половина длительности бита должна быть амплитудой несущей с полем низкой напряженности.

Обратная полярность амплитуды должна быть разрешена. Полярность должна быть определена из SYNC.

Рисунок 1 - Манчестерское двоичное кодирование (прямая амплитуда)

Рисунок 1 - Манчестерское двоичное кодирование (прямая амплитуда)

Рисунок 2 - Манчестерское двоичное кодирование (обратная амплитуда)

Рисунок 2 - Манчестерское двоичное кодирование (обратная амплитуда)

9.2.2.4 Передача байтов

Инициаторы и Цели должны передавать байты старшим битом вперед.

9.3 Пассивный режим связи

9.3.1 Режим Инициатор - Цель. Требования для fc/128

См. 9.2.1.

9.3.2 Режим Цель - Инициатор. Требования для fc/128

9.3.2.1 Скорость передачи

См. 9.2.1.1.

9.3.2.2 Модуляция

См. 8.2.2 ИСО/МЭК 14443-2.

9.3.2.3 Частота поднесущей

См. 8.2.3 ИСО/МЭК 14443-2.

9.3.2.4 Модуляция поднесущей

См. 8.2.4 ИСО/МЭК 14443-2 для скорости передачи fc/128.

9.3.2.5 Двоичное представление и кодирование

См. 8.2.5.1 ИСО/МЭК 14443-2.

9.3.2.6 Передача байтов

Инициаторы и Цели должны передавать байты младшим битом вперед.

9.3.3 Режим Инициатор - Цель. Требования для fc/64 и fc/32

9.3.3.1 Скорость передачи

См. 9.2.2.1.

9.3.3.2 Модуляция

См. 9.1.2 ИСО/МЭК 14443-2 для скорости передачи fc/64 и fc/32. В течение передачи Инициатор должен соответствовать PCD-значениям.

Примечание - Диапазон коэффициента модуляции более строгий, чем в ИСО/МЭК 18092:2004.

9.3.3.3 Двоичное представление и кодирование

См. 9.2.2.3.

9.3.3.4 Передача байтов

См. 9.2.2.4.

9.3.4 Режим Цель - Инициатор. Требования для fc/64 и fc/32

9.3.4.1 Скорость передачи

См. 9.2.2.1.

9.3.4.2 Модуляция

Цель должна быть способна коммуницировать с Инициатором посредством области индуктивной связи с помощью нагрузочной модуляции, применяемой к fc радиочастотного поля Инициатора со значением амплитуды PICC-нагрузочной модуляции, указанным в 8.2.2 ИСО/МЭК 14443-2. Инициатор должен быть способен получать сигнал с амплитудой нагрузочной модуляции, как указано для PCD-приема в ИСО/МЭК 14443-2, 8.2.2.

Примечание - Минимальная величина амплитуды нагрузочной модуляции для Цели и Инициатора была изменена по сравнению с ИСО/МЭК 18092:2004.

9.3.4.3 Двоичное представление и кодирование

См. 9.2.2.3.

9.3.4.4 Передача байтов

См. 9.2.2.4.

10 Общий ход выполнения протокола

Общий ход выполнения протокола между NFCIP-1-устройствами должен осуществляться посредством следующих последовательных операций:

- Любое NFCIP-1-устройство в исходном положении должно находиться в режиме Цели, не генерировать радиочастотное поле и ждать команды от Инициатора.

- Оно может переключиться в режим Инициатора и выбрать либо активный, либо пассивный режим связи, а также скорость передачи данных.

- Инициаторы должны провести проверку на наличие внешнего излучения радиочастотного поля и не должны активировать свое собственное радиочастотное поле в том случае, если внешнее излучение радиочастотного поля обнаружено. См. 8.4.

- В случае, если внешнее излучение радиочастотного поля не обнаружено, Инициатор должен активировать свое собственное радиочастотное поле для приведения в действие Цели.

- Обмен командами и ответами в том же режиме связи и на той же скорости передачи данных.

На рисунке 3 показан общий ход выполнения инициализации и обнаружения единственного устройства для активного и пассивного режимов связи на различных скоростях передачи данных.

Общий ход выполнения протокола описывает ход выполнения инициализации и выбора Целей либо в пассивном режиме связи, либо в активном режиме связи на одной из возможных скоростей передачи данных. Избежание радиочастотных конфликтов описано в 11.1. Пассивный режим связи описан в 11.2. Инициализация и SDD на скорости fc/128 описаны в 11.2.1, инициализация и SDD на скоростях fc/64 и fc/32 описаны в 11.2.2. Активный режим связи описан в 11.3.

Активация протокола описана в 12.5. Выбор параметров описан в 12.5.3. Протокол обмена данными описан в 12.6. Деактивация описана в 12.7.

11 Инициализация

Этот раздел описывает протокол инициализации и обнаружения радиочастотных конфликтов для Целей в активном и пассивном режиме связи. Инициатор должен уметь обнаруживать радиочастотный конфликт, который возникает, когда по крайней мере две Цели одновременно передают битовые комбинации с одной или более позициями битов, в которых они передают дополнительные значения.

На рисунке 3 показан общий ход выполнения инициализации и обнаружения единственного устройства для активного и пассивного режимов связи на различных скоростях передачи данных.

Рисунок 3 - Общий ход инициализации и обнаружения единственного устройства

Рисунок 3 - Общий ход инициализации и обнаружения единственного устройства

11.1 Избежание радиочастотных конфликтов

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

11.1.1 Первоначальное избежание радиочастотных конфликтов

Для того чтобы начать коммуникацию с Целевым устройством в активном или пассивном режиме связи, Инициатор должен непрерывно контролировать присутствие внешнего излучения радиочастотного поля. См. 8.4.

Если Инициатор не обнаруживает радиочастотного поля в пределах временных рамок , то он должен включить свое собственное радиочастотное поле либо заново запустить Первоначальное избежание радиочастотных конфликтов. Целочисленное значение n должно быть сгенерировано случайным образом. Рисунок 4 определяет временные рамки Первоначального избежания радиочастотных конфликтов при инициализации.

Рисунок 4 - Первоначальное избежание радиочастотных конфликтов

- время начальной задержки (>4096/fc);
- время ожидания радиочастоты (512/fc);
n - случайным образом сгенерированное число периодов времени для (03);
- начальное контрольное время между включением радиочастотного поля и началом посылки команды или кадра данных (>5 мс)

Рисунок 4 - Первоначальное избежание радиочастотных конфликтов

Радиочастотное поле, сгенерированное Инициатором, должно быть выключено в активном режиме связи. Радиочастотное поле, сгенерированное Инициатором, не должно быть выключено в пассивном режиме связи.

11.1.2 Избежание радиочастотных конфликтов при ответе

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

Рисунок 5 - Последовательность избежания радиочастотных конфликтов при ответе в процессе активации

- время активной задержки, время зондирования между отключенной радиочастотой Инициатор/Цель и Цель/Инициатор (768/fc 2559/fc);
- время ожидания радиочастоты (512/fc);
n - случайным образом сгенерированное число периодов времени для (03);
- активное контрольное время между включением радиочастотного поля и началом посылки команды (>1024/fc)

Рисунок 5 - Последовательность избежания радиочастотных конфликтов при ответе в процессе активации

11.2 Пассивный режим связи

11.2.1 Инициализация и Обнаружение единственного устройства на fc/128

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


Таблица 2 - Кодирование SAK

Параметру uid0 должно быть присвоено значение '08'.

Если бит 3 представлен (1)b, Инициатор должен проигнорировать любой другой бит SAK. Если бит 3 представлен (0)b, Инициатор должен интерпретировать бит 7 и проигнорировать другие биты. Если биту 3 присвоено значение (1)b, Цель должна присвоить всем остальным битам SAK значение (0)b.

Примечания

1 UID заменяет NFCID1 из ИСО/МЭК 18092:2004, a uid* заменяет nfcid1 из ИСО/МЭК 18092:2004.

2 Если бит 6 в SAK представлен (1)b, то устройство поддерживает протокол, как определено в ИСО/МЭК 14443-4.

11.2.2 Инициализация и обнаружение единственного устройства на fc/64 и fc/32

11.2.2.1 Начало и конец коммуникации

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

Рисунок 6 - Начало и конец коммуникации

Рисунок 6 - Начало и конец коммуникации

После того как одно NFCIP-1-устройство закончило коммуникацию, другое должно задержаться на время не менее 864/fc, прежде чем начать передачу за счет отправки последовательности-преамбулы, как показано на рисунке 7.

Рисунок 7 - Задержка между последовательными кадрами

Рисунок 7 - Задержка между последовательными кадрами

11.2.2.2 Формат кадра

Формат кадра должен состоять из Преамбулы, Синхрогруппы, Длины, Полезной нагрузки и CRC, см. рисунок 8.

Преамбула должна состоять минимум из 48 битов логических элементов НУЛЬ.

Синхрогруппа должна состоять из 2 байтов. 1-й байт в Синхрогруппе должен быть 'В2', 2-й байт должен быть '4D'.

Рисунок 8 - Формат кадра

Рисунок 8 - Формат кадра

Длина должна быть 8-битным полем, а его значение должно быть установлено в соответствии с количеством байт, передаваемых в Полезной нагрузке, плюс 1. Диапазон Длины должен быть в пределах от 2 до 255, остальные параметры являются RFU.

Полезная нагрузка должна состоять из n 8-бит-байтовых данных, где n означает количество байтов данных.

CRC должен быть рассчитан согласно А.3.

11.2.2.3 Обнаружение единственного устройства на fc/64 и fc/32

Основным методом SDD-процедуры должен быть метод временных интервалов. Номер интервала должен быть целочисленным значением за исключением нуля. Инициатор должен отправлять запросы на опрос. Цель должна отвечать в случайном порядке в каждый временной интервал. Инициатор должен уметь читать NFCID2-данные (см. 11.2.2.4) Цели(ей) в различных временных интервалах.

После получения NFCID2-данных от Цели(ей) в рабочее поле Инициатор может коммуницировать с несколькими Целями.

При согласии между обменивающимися сторонами могут поддерживаться до 16 временных интервалов. Номер временного интервала может быть указан значением TSN в кадре запроса на опрос от Инициатора.

Цель, которая уже запитана, отвечает Инициатору после получения от Инициатора кадра запроса на опрос, согласно следующим правилам:

1. Цель должна сгенерировать случайное число R в диапазоне от 0 до TSN.

2. Цель должна дождаться временного интервала, который соответствует R, и затем отправить кадр ответа при опросе и ждать следующего запроса. Цель может игнорировать запрос на опрос для того, чтобы сократить число конфликтов при ответе.

Коммуникация между Инициатором и Целью должна проводиться следующим образом:

1. Цель получает питание от рабочего поля, сгенерированного Инициатором.

2. Цель должна быть готова к получению запроса на опрос от Инициатора максимум через 2 секунды с момента получения питания.

3. Цель должна ждать запроса на опрос, отправленного Инициатором. Инициатор может отправить запрос на опрос, не дожидаясь готовности Цели.

4. Если Инициатору не удается получить ответа при опросе, то Инициатор может отправить запрос на опрос еще раз. Инициатор пассивного режима связи должен сохранять радиочастотное питание, пока осуществляется SDD-процедура.

Задержка Td между окончанием кадра запроса и первым временным интервалом должна быть 51264/fc.

Блок временного интервала Ts должен быть 25664/fc.

Рисунок 9 иллюстрирует примерную ситуацию процедуры SDD по временным интервалам. В данном примере отвечают пять Целей. Инициатор может получить ответную информацию от Целей 2, 4 и 5, но не от Целей 1 и 3. Причина в конфликте, произошедшем во временном интервале 1.

Инициатор может повторять SDD-процедуру.

Рисунок 9 - Обнаружение единственного устройства по временным интервалам

Рисунок 9 - Обнаружение единственного устройства по временным интервалам

11.2.2.4 Содержание NFCID2

Идентификатор NFCID2 должен быть 8-байтовым числом, служащим для идентификации NFCIP-1-устройств. 2-байтовый код префикса должен сопровождаться 6-байтовым числом в NFCID2. Код префикса должен определять характеристики для 6-байтового числа.

6-байтовое число должно быть сгенерировано случайным образом, когда код префикса '01' 'FE'. Другие параметры для кода префикса являются RFU.

11.2.2.5 Формат кадра запроса на опрос

Для обнаружения Цели Инициатор должен отправить кадр запроса на опрос, см. рисунок 10.

Рисунок 10 - Формат кадра запроса на опрос

Рисунок 10 - Формат кадра запроса на опрос

Преамбула должна состоять минимум из 48 битов логических элементов НУЛЬ.

Синхрогруппа (SYNC) должна состоять из 2 байтов. 1-й байт в Синхрогруппе должен быть 'В2', 2-й байт должен быть '4D'.

Поле Длина должно быть установлено как '06'.

1-й байт полезной нагрузки должен быть установлен в '00'.

2-й и 3-й байты полезной нагрузки должны быть установлены в 'FF', другие параметры являются RFU.

4-й байт полезной нагрузки должен быть установлен в '00', другие параметры являются RFU.

TSN должен быть '00', '01', '03', '07' или '0F'. Любые другие параметры являются RFU.

CRC должен быть рассчитан согласно А.3.

Рисунок 9 иллюстрирует пример, где TSN равен '03'. Если TSN установлен как '00', то только временной интервал 0 должен быть использован.

11.2.2.6 Формат кадра ответа при опросе

Цель должна отправить следующий кадр как ответ при опросе на запрос на опрос, см. рисунок 11.

Рисунок 11 - Формат кадра ответа при опросе

Рисунок 11 - Формат кадра ответа при опросе

Преамбула должна состоять минимум из 48 битов логических элементов НУЛЬ.

Синхрогруппа (SYNC) должна состоять из 2 байтов. 1-й байт Синхрогруппы должен быть 'В2', 2-й байт должен быть '4D'.

Поле Длина должно быть установлено как '12'.

Стартовый байт полезной нагрузки должен быть установлен как '01'. Полезная нагрузка должна состоять из 8 байтов NFCID2 и 8 байтов Pad. Значение Pad должно быть проигнорировано для обмена данными.

CRC должен быть рассчитан согласно А.3.

11.3 Активный режим связи

11.3.1 Инициализация на fc/128, fc/64 и fc/32

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

11.3.2 Избежание радиочастотных конфликтов в активном режиме связи

Избежание радиочастотных конфликтов должно быть выполнено в соответствии с временной диаграммой на рисунке 12.

- Инициатор должен осуществить Первоначальное избежание радиочастотных конфликтов.

- Первой командой, отправляемой Инициатором, является ATR_REQ в активном режиме связи на выбранной скорости передачи.

- Инициатор должен выключить радиочастотное поле.

- Цель осуществляет Избежание радиочастотных конфликтов при ответе.

- Цель посылает ATR_RES в ответ на ATR_REQ на той же скорости передачи, на которой она получила ATR_REQ, и выключает радиочастотное поле.

- Инициатор осуществляет Избежание радиочастотных конфликтов при ответе с n=0.

- Инициатор посылает PSL_REQ для того, чтобы изменить параметр, или посылает DEP_REQ, чтобы начать протокол обмена данными.

Рисунок 12 - Ход выполнения инициализации в активном режиме связи

Рисунок 12 - Ход выполнения инициализации в активном режиме связи

11.3.2.1 Избежание конфликтов в активном режиме связи

В случае, когда в поле находятся две или более Целей, то Цель с наименьшим n будет отвечать первой, а другая Цель отвечать не будет.

В случае, когда две или более Целей отвечают в один и тот же временной период, Инициатор обнаружит конфликт и повторно отправит ATR_REQ, описанный в 12.5.1.1.

После того как ответ от первой Цели обнаружен Инициатором, Инициатор и Цель должны использовать n=0 для дальнейшей коммуникации.

12 Транспортный протокол

С транспортным протоколом работают в трех частях:

- Активация протокола, которая включает в себя запрос на атрибуты и выбор параметров.

- Протокол обмена данными.

- Деактивация протокола, включающая деселекцию и освобождение.

12.1 Передача данных

Данные пользователя должны передаваться в поле Передача данных в формате кадра. Рисунок 13 указывает положение поля Передача данных в разных форматах кадра.

Структура формата кадра для fc/128 определяется в ИСО/МЭК 14443-3, 6.2.3.2. Стартовый байт SB должен быть установлен в значение 'F0'. LEN-байт должен быть равен длине поля Передача данных плюс 1. Диапазон LEN должен быть в пределах от 3 до 255. Е1 является CRC для формата кадра fc/128, как описано в разделе А.1. Другие параметры LEN запрещены настоящим стандартом.

Подпункт 11.2.2.2 настоящего стандарта определяет формат кадра для fc/64 и fc/32, в том числе Преамбулу РА и Синхрогруппу SYNC.

LEN-байт должен быть равен длине поля Передача данных плюс 1. Значение LEN должно быть в пределах от 3 до 255. E2 является CRC для формата кадра fc/64 и fc/32, как описано в разделе А.3. Другие параметры LEN запрещены настоящим стандартом.

Поле Передача данных содержит байты обязательных команд CMD1 и CMD2, как описано в подразделе 12.4, и байты данных: Байт 1 - Байт n. Содержимое с Байта 1 по Байт n зависит от байта команды CMD2 и может содержать информацию. В таком случае они являются обязательными. Байты данных являются необязательными.

Рисунок 13 - Формат кадра передачи данных

Рисунок 13 - Формат кадра передачи данных

12.2 Ход выполнения активации пассивного режима связи

Для активации должна быть применена следующая последовательность:

1. Инициатор должен осуществить последовательность Первоначального избежания радиочастотных конфликтов в соответствии с 11.1.1.

2. Инициатор должен осуществить инициализацию и SDD для пассивного режима связи на выбранной скорости передачи, как определено в 11.2.

3. Должна быть проверена поддержка протокола NFCIP-1 на различных скоростях передачи в соответствии с запросом на атрибут, как описано в 12.5.1.1.

4. Цель может вернуться к инициализации и SDD, если ни один ATR_REQ не поддерживается.

5. ATR_REQ может быть отправлен Инициатором в качестве следующей команды после получения подтверждения о доступности запроса на атрибут.

6. Цель должна отправить свой ATR_RES в ответ на ATR_REQ. Цель должна отвечать на ATR_REQ только в том случае, если ATR_REQ получен непосредственно после выбора.

7. Если Цель поддерживает какой-либо изменяемый параметр в ATR_REQ, PSL_REQ может быть использован Инициатором в качестве следующей команды после получения ATR_REQ для измения* параметров.
________________
* Текст документа соответствует оригиналу. - .

8. Цель должна отправить PSL_RES в ответ на PSL_REQ.

9. Цели не нужно дополнять Выбор параметров при отсутствии у нее поддержки каких-либо изменяемых параметров в ATR_RES.

10. Прозрачные данные должны быть отправлены с использованием транспортного протокола обмена данными.

Последовательность активации от Инициатора к Цели в пассивном режиме связи показана на рисунке 14.

12.3 Ход выполнения активации активного режима связи

Следующая последовательность активации для протокола в активном режиме связи должна быть применена:

1. Инициатор должен осуществить последовательность Первоначального избежания радиочастотных конфликтов в соответствии с 11.1.1.

2. Инициатор должен переключиться в активный режим связи и выбрать скорость передачи.

3. Инициатор должен отправить ATR_REQ.

4. Цель должна отправить свой ATR_RES в ответ на ATR_REQ. После успешного ответа устройство выбирается.

5. Если Инициатор обнаруживает конфликт данных, ATR_REQ должен быть отправлен повторно.

6. Если Цель поддерживает какой-либо изменяемый параметр в ATR_REQ, PSL_REQ может быть использован Инициатором в качестве следующей команды после получения ATR_REQ для измения* параметров.
________________
* Текст документа соответствует оригиналу. - .

7. Цель должна отправить PSL_RES в ответ на PSL_REQ.

8. Цели не нужно дополнять Выбор параметров при отсутствии у нее поддержки каких-либо изменяемых параметров в ATR_RES.

Последовательность активации от Инициатора к Цели в активном режиме связи показана на рисунке 15.

Рисунок 14 - Протокол активации в пассивном режиме связи

Рисунок 14 - Протокол активации в пассивном режиме связи

Рисунок 15 - Протокол активации в активном режиме связи

Рисунок 15 - Протокол активации в активном режиме связи

12.4 Команды

Байты команд состоят из CMD1 и CMD2, как указано в таблице 3.


Таблица 3 - Набор команд протокола NFCIP-1

12.5 Активация протокола

12.5.1 Команды Запрос на атрибут и Реакция на атрибут

12.5.1.1 Запрос на атрибут (ATR_REQ)

Данный подпункт определяет запрос на атрибут ATR_REQ со всеми его байтами параметров, см. рисунок 16. Инициатор должен отправить ATR_REQ выбранной Цели.

Рисунок 16 - Структура ATR_REQ

Рисунок 16 - Структура ATR_REQ

12.5.1.1.1 Определение байтов ATR_REQ

CMD 1: Должен быть установлен в значение 'D4'.

CMD 2: ATR_REQ

Байт ATR_REQ должен определять запрос на атрибут для Инициатора. Значение ATR_REQ должно быть установлено как `00'.

Байт 1 - Байт 10: NFCID3i

10 байтов nfcid3i определяют случайный идентификатор Инициатора NFCID3i. NFCID3 должен быть идентификатором, динамически генерируемым приложением, и должен быть постоянным в течение одной коммуникации. Для пассивного режима связи fc/64 и fc/32 NFCID3i должен быть заменен на NFCID2t.

Байт 11: DIDi

Байт DID должен быть использован для активации транспортного протокола многокомпонентных данных (multiple data) с более чем одной Целью. Диапазон DIDi должен быть определен между 1 и 14. Значение НУЛЬ должно использоваться, если DIDi не используется в течение протокола передачи данных. Все другие значения запрещены настоящим стандартом.

Байт 12: BSi

Устройство Инициатор должно указать поддерживаемые им скорости отправляемых данных (D) в байте BSi, см. рисунок 17.

Рисунок 17 - Кодирование байта BSi

Рисунок 17 - Кодирование байта BSi

Кодирования битов следующее:

- бит 8 - бит 5: должен быть установлен в значение НУЛЬ, все остальные значения являются RFU;

- бит 4: если DSi=ЕДИНИЦЕ, то поддерживается D=64;

- бит 3: если DSi=ЕДИНИЦЕ, то поддерживается D=32;

- бит 2: если DSi=ЕДИНИЦЕ, то поддерживается D=16;

- бит 1: если DSi=ЕДИНИЦЕ, то поддерживается D=8.

Байт 13: BRi

Устройство Инициатор должно указать поддерживаемые им скорости передачи данных (см. таблицу 1) в байте BRi, см. рисунок 18.

Рисунок 18 - Кодирование байта BRi

Рисунок 18 - Кодирование байта BRi

Кодирования битов следующее:

- бит 8 - бит 5: должен быть установлен в значение НУЛЬ, все остальные значения являются RFU;

- бит 4: если DRi=ЕДИНИЦЕ, то поддерживается D=64;

- бит 3: если DRi=ЕДИНИЦЕ, то поддерживается D=32;

- бит 2: если DRi=ЕДИНИЦЕ, то поддерживается D=16;

- бит 1: если DRi=ЕДИНИЦЕ, то поддерживается D=8.

Байт 14: PPi

Байт PPi определяет дополнительные параметры, используемые устройством Инициатором, см.рисунок 19.

Рисунок 19 - Кодирование байта PPi

Рисунок 19 - Кодирование байта PPi

Кодирование битов должно быть следующим:

- бит 8: SECi. Если установлен в значение ЕДИНИЦА, Инициатор поддерживает NFC-SEC; НУЛЬ означает отсутствие поддержки;

- бит 7: RFU. Инициатор должен установить его в значение НУЛЬ. Цель должна игнорировать его;

- бит 6 и бит 5: Значение Сокращение длины LR (Length Reduction), см. таблицу 4.


Таблица 4 - Определение LRi

- бит 4 и бит 3: RFU. Инициатор должен установить его в значение НУЛЬ. Цель должна игнорировать его;

- бит 2: Если установлен в значение ЕДИНИЦА, то доступны Общие байты;

- бит 1: Если установлен в значение ЕДИНИЦА, значит, Инициатор использует NAD.

Байт 15 - Байт n: Gi[1] - Gi[n]

Общие байты должны быть необязательными и должны обозначать общую информацию. Максимальная длина ATR_REQ за вычетом обязательных байтов дает максимальное число общих байтов.

12.5.1.2 Реакция на атрибут (ATR_RES)

ATR_RES, см. рисунок 20, должна быть реакцией на ATR_REQ и должна быть отправлена выбранным Целевым устройством NFCIP-1.

Рисунок 20 - Структура ATR_RES

Рисунок 20 - Структура ATR_RES

12.5.1.2.1 Определение байтов ATR_RES

CMD 1: Должен быть установлен в значение 'D5'.

CMD 2: ATR_RES

Байт ATR_RES должен определять ответ Цели на ATR_REQ, отправленный Инициатором. Значение CMD1 для ATR_RES должно быть установлено как '01'.

Байт 1 - Байт 10: NFCID3t

10 байтов nfcid3t определяют произвольный идентификатор Цели NCID3t. NFCID3 должен быть идентификатором, генерируемым приложением. Содержание NFCID3 может быть такими же, как NFCID1 или NFCID2.

Байт 11: DIDt

Байт DID должен быть использован для активации транспортного протокола многокомпонентных данных (multiple data) с более чем одной Целью. DIDt должен иметь такое же значение, как и DIDi. Все другие значения запрещены настоящим стандартом. Процесс использования DIDt см. в 12.5.1.1.1.

Байт 12: BSt

Байт BSt должен определять скорости передачи, поддерживаемые Целевым устройством, см. рисунок 21.

Рисунок 21 - Кодирование байта BSt

Рисунок 21 - Кодирование байта BSt

Кодирования битов следующее:

- бит 8 - бит 5: Должен быть установлен в значение НУЛЬ;

- бит 4: если DSt=ЕДИНИЦЕ, то поддерживается D=64;

- бит 3: если DSt=ЕДИНИЦЕ, то поддерживается D=32;

- бит 2: если DSt=ЕДИНИЦЕ, то поддерживается D=16;

- бит 1: если DSt=ЕДИНИЦЕ, то поддерживается D=8.

Байт 13: BRt

Байт BRt должен определять скорости приема данных, поддерживаемые Целевым устройством, см. рисунок 22.

Рисунок 22 - Кодирование байта BRt

Рисунок 22 - Кодирование байта BRt

Кодирования битов следующее:

- бит 8 - бит 5: Должен быть установлен в значение НУЛЬ;

- бит 4: если DRt=ЕДИНИЦЕ, то поддерживается D=64;

- бит 3: если DRt=ЕДИНИЦЕ, то поддерживается D=32;

- бит 2: если DRt=ЕДИНИЦЕ, то поддерживается D=16;

- бит 1: если DRt=ЕДИНИЦЕ, то поддерживается D=8.

Байт 12: TO

Байт ТО должен определять значение тайм-аута Целевого устройства NFCIP-1 для протокола передачи данных, см. рисунок 23. Счет тайм-аута должен начинаться с последним битом, отправленным Инициатором, и заканчиваться с первым битом, отправленным Целью. Тайм-аут определяется следующим образом:

- бит 8 - бит 5: Должен быть установлен в значение НУЛЬ;

- бит 4 - бит 1: Время ожидания WT.

Рисунок 23 - Кодирование байта ТО

Рисунок 23 - Кодирование байта ТО

Время ожидания ответа (RWT) должно быть рассчитано по следующей формуле:

RWT=(25616/fc)2,

где значение WT должно быть в диапазоне от 0 до 14, а значение 15 является RFU. Значение WT по умолчанию должно быть 14.

Для WT=0, RWT=RWT (302 мкс).

Для WT=14, RWT=RWT (4949 мс).

Байт 15: PPt

Байт PPt определяет дополнительные параметры, используемые Целевым устройством, см. рисунок 24. Кодирования битов, определяется следующим образом:

Рисунок 24 - Кодирование байта PPt

Рисунок 24 - Кодирование байта PPt

Кодирование битов должно быть следующим:

- бит 8 и бит 7: Должен быть установлен в значение НУЛЬ;

- бит 6 и бит 5: Значение Сокращение длины LR (Length Reduction), см. таблицу 5.


Таблица 5 - Определение LRt

- бит 4 и бит 3: Должен быть установлен в значение НУЛЬ;

- бит 2: Если установлен в значение ЕДИНИЦА, то доступны Общие байты;

- бит 1: Если установлен в значение ЕДИНИЦА, значит, Цель использует NAD.

Байт 15 - Байт n: Gt[1] - Gt[n]

Байты Gt должны быть необязательными и должны обозначать общую информацию. Максимальная длина ATR_RES за вычетом обязательных байтов дает максимальное число общих байтов.

12.5.1.3 Обработка ATR_REQ и ATR_RES

12.5.1.3.1 Правила для Инициатора

Когда Инициатор отправил ATR_REQ и получает допустимый ATR_RES, Инициатор должен продолжить работу.

В любом другом случае Инициатор должен повторно передать ATR_REQ, прежде чем использовать последовательность деактивации, как определено в 12.7.

В случае сбоя последовательности деактивации он может использовать команду HLTA только в пассивном режиме связи на fc/128. Команда HLTA определена в пункте 6.4.3 ИСО/МЭК 14443-3.

12.5.1.3.2 Правила для Цели

Когда Цель была выбрана последней командой (только в пассивном режиме) и:

a) получает допустимый ATR_REQ, Цель:

- должна отправить свой ATR_RES;

- должна отключиться, чтобы получить последующий ATR_REQ.

b) получает любые другие допустимые или недопустимые кадры, за исключением команды HLTA (см. 12.5.1.3.1) только в пассивном режиме связи на fc/128, Цель:

- игнорирует блок и

- остается в режиме приема.

12.5.1.4 Обработка тайм-аута ТО

В зависимости от изначально выбранного режима, коммуникация является либо активной, либо пассивной. Обработка тайм-аута в активном и пассивном режиме связи различна.

12.5.1.4.1 Обработка в активном режиме

В активном режиме коммуникация осуществляется за счет переключения несущей частоты.

Инициатор: Инициатор должен проигнорировать Цель, которая превысила RWT, рассчитанный с использованием байта ТО в ATR_REQ от Целевого устройства, и продолжить работу.

Цель: Цель должна использовать значение ТО, которое дает возможность общей коммуникации, и должна использовать контрольное pdu, содержащее продление тайм-аута для увеличения определенного RWT. См. 12.6.1.1.1.

12.5.1.4.2 Обработка тайм-аута в пассивном режиме

В пассивном режиме коммуникация осуществляется только за счет потока информации. Несущая частота не переключается.

Инициатор: Инициатор должен сперва использовать обработку ошибок, затем, если не получает никакого ответа, проигнорировать Целевое устройство, которое превысило заданный тайм-аут, и продолжить коммуникацию.

Цель: Цель должна использовать значение ТО, которое дает возможность общей коммуникации, и должна использовать контрольное pdu, содержащее продление тайм-аута для увеличения определенного RWT. См. 12.6.1.1.1.

12.5.1.5 Обработка DID

12.5.1.5.1 Обработка DID в активном и пассивном режиме

Когда Инициатор отправил ATR_REQ, содержащий DID, равный НУЛЮ, и:

a) получил ATR_RES, содержащий DID, равный НУЛЮ:

- должен отправить Цели pdu, не содержащие DID, и

- не должен активировать какие-либо другие Цели, пока данная Цель не будет деактивирована.

b) получил ATR_RES, содержащий DID, не равный НУЛЮ:

- должен приступить к обработке ошибок.

Когда Инициатор отправил ATR_REQ, содержащий DID, не равный НУЛЮ, и:

a) получил ATR_RES, содержащий такой же DID:

- должен отправить Цели pdu, содержащие DID;

- не должен использовать данный DID для любых других Целей и

- не должен использовать DID=0 для любых других Целей.

b) получил ATR_RES, содержащий какой-либо другой DID:

- должен приступить к обработке ошибок.

12.5.2 Команды Запрос на побудку и Реакция на побудку

Команды Запрос и Реакция на побудку определены только для активного режима связи.

12.5.2.1 Запрос на побудку (WUP_REQ)

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

Рисунок 25 - Структура WUP_REQ

Рисунок 25 - Структура WUP_REQ

12.5.2.1.1 Определение байтов WUP_REQ

CMD 1: Должен быть установлен в значение 'D4'.

CMD 2: WUP_REQ

Байт WUP_REQ должен определять команду Wake Up для устройства Инициатора. Значение WUP_REQ должно быть '02'.

Байт 1 - Байт 10: NFCID3t

10 байтов nfcid3t должны быть определены как произвольный идентификатор Цели. Для команды WUP_REQ Инициатор должен отправить известный произвольный идентификатор NFCID3t, чтобы разбудить Цель.

Байт 11: DID

Байт DID должен быть использован для активации транспортного протокола многокомпонентных данных (multiple data) с более чем одной Целью. Диапазон DID должен быть определен между 1 и 14. Значение 0 должно использоваться, если DID не используется в течение протокола передачи данных. Все другие значения запрещены настоящим стандартом. Инициатор может присвоить другое значение Цели, которое использовалось до последней команды DSL.

12.5.2.2 Реакция на побудку (WUP_RES)

Рисунок 26 определяет структуру реакции на побудку на атрибут WUP_RES. WUP_RES должна быть ответом на WUP_REQ и должна быть отправлена выбранным Целевым устройством NFCIP-1.

Рисунок 26 - Структура WUP_RES

Рисунок 26 - Структура WUP_RES

12.5.2.2.1 Определение байтов WUP_RES

CMD 1: Должен быть установлен в значение 'D5'.

CMD 2: WUP_RES

Байт WUP_RES должен определять ответ на WUP_REQ. Значение WUP_RES должно быть '03'.

Байт 1: DID

Байт DID должен быть использован для активации транспортного протокола многокомпонентных данных (multiple data) с более чем одной Целью. DIDt должен иметь такое же значение, что и DIDi. Все другие значения запрещены настоящим стандартом.

12.5.2.3 Обработка WUP_REQ и WUP_RES

12.5.2.3.1 Правила для Инициатора

Когда Инициатор отправил WUP_REQ и получает допустимый WUP_RES, Инициатор должен продолжить работу.

В любом другом случае Инициатор должен повторно передать WUP_REQ, прежде чем использовать последовательность деактивации, как определено в 12.7.

В случае сбоя последовательности деактивации для fc/128 в пассивном режиме связи он может использовать команду HLTA (см. пункт 6.4.3 ИСО/МЭК 14443-3).

12.5.2.3.2 Правила для Цели

Когда Цель была деселектирована последней командой (только в активном режиме) и:

a) получает WUP_REQ со своим NFCID3, Цель:

- должна отправить свой WUP_RES и

- должна отключиться, чтобы не получить последующий WUP_REQ.

b) получает любые другие допустимые или недопустимые кадры, за исключением команды HLTA только в пассивном режиме связи на fc/128, Цель:

- игнорирует блок и

- остается в режиме приема.

12.5.3 Команды Запрос о выборе параметров и Ответ о выборе параметров

12.5.3.1 Запрос о выборе параметров (PSL_REQ)

Инициатор может переключать параметры для последующего транспортного протокола с помощью команды PSL_REQ, см. рисунок 27.

Рисунок 27 - Структура PSL_REQ

Рисунок 27 - Структура PSL_REQ

12.5.3.1.1 Определение байтов PSL_REQ

CMD 1: Должен быть установлен в значение 'D4'.

CMD 2: PSL_REQ

Байт PSL_REQ должен определять команду Запрос о выборе параметров для устройства Инициатора. Значение PSL_REQ должно быть '04'.

Байт 1: DID

DID должен быть таким же, как DID, определенный при ATR или WUP.

Байт 2: BRS

Байт BRS, см. рисунок 28, должен определять выбранную скорость передачи данных для устройства Инициатора и Целевого устройства.

Рисунок 28 - Кодирование байта BRS

Рисунок 28 - Кодирование байта BRS

- бит 8 и бит 7: Должен быть установлен в значение НУЛЬ;

- бит 6 - бит 4: Длительность бита от Инициатора к Цели см. таблицу 6;

- бит 3 - бит 1: Длительность бита от Цели к Инициатору, см. таблицу 6.


Таблица 6 - Кодирование DRI и DSI

Байт 3: FSL

Байт FSL определяет максимальное значение длины кадра, см. рисунок 29.

Рисунок 29 - Кодирование байтов FSL

Рисунок 29 - Кодирование байтов FSL

- бит 8 - бит 3: Должны быть все установлены как НУЛЬ;

- бит 2 и бит 1: Значение Сокращение длины LR (Length Reduction), см. таблицу 7.


Таблица 7 - Определение LR

12.5.3.2 Ответ о выборе параметров (PSL_RES)

Рисунок 30 определяет структуру кадра PSL_RES.

Рисунок 30 - Структура PSL_RES

Рисунок 30 - Структура PSL_RES

12.5.3.2.1 Определение байтов PSL_RES

CMD 1: Должен быть установлен в значение 'D5'.

CMD 2: PSL_RES

Байт PSL_RES должен определять команду Ответ о выборе параметров для Целевого устройства. Значение PSL_RES должно быть '05'.

Байт 1: DID

DID должен быть таким же, как DID, определенный при ATR или WUP.

12.5.3.3 Обработка PSL_REQ и PSL_RES

12.5.3.3.1 Правила для Инициатора

Инициатор может изменить параметры протокола путем отправки Цели PSL_REQ. После получения допустимого PSL_RES Инициатор:

- должен изменить кадровую синхронизацию в формат, определенный в 12.1, и

- должен продолжить работу.

В любом другом случае Инициатор может повторно отправить PSL_REQ, прежде чем использовать последовательность деактивации, как определено в 12.7.

В случае сбоя последовательности деактивации на fc/128 в пассивном режиме связи он может использовать команду HLTA (см. 12.5.1.3.2).

12.5.3.3.2 Правила для Цели

Когда Цель получила ATR_REQ, послала свой ATR_RES и:

a) получает допустимый PSL_REQ, Цель:

- должна отправить свой PSL_RES;

- должна отключить PSL_REQ (перестать отвечать на полученные PSL_REQ);

- должна изменить все параметры на заданные значения, которые указаны в 12.5.3, и

- должна остаться в режим приема.

b) получает недопустимый кадр, Цель:

- должна проигнорировать блок;

- должна отключить PSL_REQ (перестать отвечать на полученные PSL_REQ);

- должна остаться с текущей кадровой синхронизацией и

- должна остаться в режим приема.

c) получает допустимый кадр, за исключением PSL_REQ, Цель:

- должна отключить PSL_REQ (перестать отвечать на полученные PSL_REQ);

- должна остаться с текущей кадровой синхронизацией и

- должна продолжить работу.

12.6 Протокол обмена данными

12.6.1 Запрос на протокол обмена данными и ответ на протокол обмена данными

12.6.1.1 Запрос на протокол обмена данными (DEP_REQ) и ответ на протокол обмена данными (DEP_RES)

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

Рисунок 31 - Определение кадров протокола

Рисунок 31 - Определение кадров протокола

В информационном обмене содержание полезной нагрузки поля передачи данных требует согласия между обменивающимися сторонами.

12.6.1.1.1 Определение байтов заголовка протокола обмена данными

CMD 1:

Если CMD2 является DEP_REQ, то CMD1 должен быть установлен в значение 'D4'.

Если CMD2 является DEP_RES, то CMD1 должен быть установлен в значение 'D5'.

CMD 2: DEP_REQ

Байты DEP_REQ определяют команду для протокола обмена данными для устройства Инициатора. Значение DEP_REQ должно быть '06'.

CMD 2: DEP_RES

Байты DEP_RES определяют команду для обмена данными для Целевого устройства. Значение DEP_RES должно быть '07'.

Байт 1: PFB

Байт PFB должен содержать биты для управления передачей данных и устранения ошибок. Байт PFB используется для передачи информации, необходимой для контроля над процессом передачи. Протокол обмена данными определяет следующие базовые типы pdu:

- Информационные pdu для передачи информации на прикладном уровне;

- ACK/NACK pdu для передачи положительных или отрицательных подтверждений. ACK/NACK pdu никогда не содержит поле данных. Подтверждение касается последнего полученного блока;

- Защищенные pdu, использующие опцию NFC-SEC, как указано в ИСО/МЭК 13157-1;

- Контрольные pdu для обмена контрольной информацией между Инициатором и Целью. Определены два типа контрольных pdu;

- Продления тайм-аута, содержащие поле данных длиной в 1 байт;

- Привлечение внимания, не содержащее поля данных.

Таблица 8 определяет кодирование PFB.


Таблица 8 - Кодирование битов PFB с 8 по 6

Рисунок 32 определяет структуру информационного pdu.

Рисунок 32 - Информационный pdu

Рисунок 32 - Информационный pdu

- бит 8 - бит 6: Должны быть все установлены в значение НУЛЬ;

- бит 5: Бит, установленный в значение ЕДИНИЦА, показывает, что активировано формирование цепочки многокомпонентной информации (Ml);

- бит 4: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен NAD;

- бит 3: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен DID;

- бит 2 и бит 1: Информация о номере пакета PNI.

Информация о номере пакета (PNI) подсчитывает номер пакета, отправленного от Инициатора к Цели, и наоборот, начиная с 0. Данные байты используются для обнаружения ошибок в процессе обработки протоколов.

Рисунок 33 определяет структуру ACK/NACK pdu.

Рисунок 33 - ACK/NACK pdu

Рисунок 33 - ACK/NACK pdu

- бит 8: Должен быть установлен в значение НУЛЬ;

- бит 7: Должен быть установлен в значение ЕДИНИЦА;

- бит 6: Должен быть установлен в значение НУЛЬ;

- бит 5: Бит, установленный в значение ЕДИНИЦА, означает NACK, в противном случае - АСK;

- бит 4: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен NAD;

- бит 3: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен DID;

- бит 2 и бит 1: Номер пакета PNI.

Рисунок 34 определяет контрольный pdu (Внимание - наличие Цели; Продления тайм-аута).

Рисунок 34 - Контрольный pdu

Рисунок 34 - Контрольный pdu

- бит 8: Должен быть установлен в значение ЕДИНИЦА;

- бит 7 и бит 6: Должны быть установлены в значение НУЛЬ;

- бит 5: Если ВНИМАНИЕ, то должен быть НУЛЬ. Если ПРОДЛЕНИЕ ТАЙМ-АУТА, то ЕДИНИЦА;

- бит 4: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен NAD;

- бит 3: Бит, установленный в значение ЕДИНИЦА, показывает, что доступен DID;

- бит 2 и бит 1: Должны быть установлены в значение НУЛЬ.

Байт 2: DID

Байт DID должен быть таким же, что и определенный в процессе активации протокола.

Байт 3: NAD

Байт NAD зарезервирован для установления и адресации различных логических соединений как на устройстве Инициаторе, так и на Целевом устройстве. Бит 8 - бит 5 кодируют логический адрес Инициатора, биты с 4 по 1 кодируют логический адрес Цели. Для процесса использования NAD применяются следующие определения:

- NAD должен использоваться только для протокола обмена данными;

- Если Инициатор использует NAD, Цель также должна использовать NAD;

- Если установлен бит Ml, то NAD должен быть передан только в первом кадре;

- Инициатор никогда не должен использовать NAD для адресации двух различных Целей.

Байт 4 - Байт n: байты пользовательских данных

Поле данных должно содержать передаваемые данные и является необязательным. Если оно присутствует, оно передает либо данные приложения, либо информацию о статусе. Длина поля данных рассчитывается путем вычитания обязательных и необязательных отправляемых байтов транспортного заголовка обмена данными из длины байта и дополнительного вычитания единицы.

12.6.1.2 Обработка информации о номере pdu

12.6.1.2.1 Правила для Инициатора

PNI Инициатора для каждой Цели должна быть установлена в исходное состояние, состоящее из НУЛЕЙ.

При приеме информационного или подтверждающего pdu с равным значением PNI Инициатор должен инкрементировать текущее значение PNI для данной Цели перед необязательной отправкой нового кадра.

12.6.1.2.2 Правила для Цели

PNI Цели должна быть установлена в исходное состояние, состоящее из НУЛЕЙ.

При приеме информационного или подтверждающего pdu с равным значением PNI Цель должна отправить свой ответ с таким же значением PNI и затем инкрементировать значение PNI.

12.6.1.3 Обработка блоков

12.6.1.3.1 Общие правила

Первый pdu должен быть отправлен Инициатором.

Когда pdu с данными указывает, что принято больше информации, pdu должен быть подтвержден АСK pdu.

Контрольные pdu используются только в паре. Контрольный запрос должен всегда сопровождаться Контрольным ответом.

12.6.1.3.2 Правила для Инициатора

При приеме недопустимого pdu должен быть отправлен NACK pdu (за исключением случаев, когда это DSL или RLS).

При возникновении тайм-аута должна быть отправлена команда привлечения внимания (за исключением случаев, когда до этого уже был отправлен NACK).

При возникновении тайм-аута и когда NACK уже был отправлен ранее, NACK должен быть передан повторно.

При приеме АСK pdu, если номер его pdu равен текущему значению PNI Инициатора, то формирование цепочки должно быть продолжено.

Если в ответ на DSL_REQ приходит недопустимый DSL_RES, то DSL_REQ может быть отправлен повторно или же Целевая команда проигнорирована.

12.6.1.3.3 Правила для Цели

Цели разрешено отправлять RTO pdu вместо pdu с данными.

При приеме pdu с данными, не содержащего формирования цепочки, это должно быть подтверждено pdu с данными.

При приеме NACK pdu, если значение PNI равно значению PNI предыдущего посланного pdu, предыдущий блок должен быть передан заново.

При приеме ошибочного pdu Цель не должна отвечать и должна оставаться в том же состоянии.

При приеме контрольного pdu, кодирующего команду привлечения внимания, Цель должна ответить отправкой реакции на команду привлечения внимания контрольного pdu.

12.6.2 Продление тайм-аута ответа

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

Рисунок 35 - Байт продления тайм-аута ответа

Рисунок 35 - Байт продления тайм-аута ответа

- бит 8 и бит 7: Должен быть установлен в значение НУЛЬ;

- бит 6 - бит 1: Значение RTOX.

Значения 0 и 60-63 для RTOX являются RFU. Для всех остальных значений промежуточное RWT рассчитывается по следующей формуле:

RWT=RWTRTOX.

RWT начинается после того, как Инициатор послал свой RTOX-ответ Цели. В случае, когда RWT превышает RWT, должно использоваться RWT. RWT действительно до тех пор, пока Инициатором не будет принят следующий кадр.

12.6.3 Внимание - наличие Цели

Инициатор должен отправить Цели команду привлечения внимания, чтобы убедиться в том, что Цель все еще находится в поле в пассивном режиме, или же для того, чтобы выявить потерю Цели в процессе мультиактивации. Данная команда не должна приводить к изменению текущего состояния Цели.

Цель должна ответить Инициатору на допустимый запрос привлечения внимания отправкой команды привлечения внимания, содержащей идентичное поле данных.

Если Цель получает некорректное pdu, она не должна реагировать на него и должна остаться в том же состоянии.

12.6.4 Протокольная операция

После последовательности активации Цель должна ждать блок, который имеет право отправить только Инициатор. После отправки блока Инициатор должен переключиться в режим приема и ждать блок до того, как переключиться обратно в режим передачи. Цель может передавать блоки только в ответ на полученные блоки. После ответа Цель должна вернуться в режим приема.

Инициатор не должен начинать новую пару запрос/ответ, пока текущая пара запрос/ответ не завершена или если время ожидания кадра превышено и ответа не поступило.

12.6.5 Мультиактивация

Функция мультиактивации позволяет Инициатору удерживать активными несколько Целей одновременно. Это позволяет переключаться напрямую между несколькими Целями без дополнительных затрат времени на деактивацию одной Цели и активацию другой Цели.

Для примера мультиактивации см. таблицу 9. Инициатор должен обрабатывать отдельную информацию о номере пакета для каждой активированной Цели.


Таблица 9 - Мультиактивация

12.6.6 Больше информации (формирование цепочки)

Функция формирования цепочки позволяет Инициатору или Цели передавать информацию, которая не помещается в один блок, путем деления такой информации на несколько блоков. Каждый из таких блоков должен иметь длину менее или равную максимальному размеру кадра (LEN).

Бит формирования цепочки в PFB протокольного кадра контролирует формирование цепочки кадров. Каждый кадр с набором битов формирования цепочки должен быть подтвержден АСk pdu.

Функция формирования цепочки, показанная на рисунке 36, использует 16-байтовую строку, передаваемую в трех блоках.

Рисунок 36 - Больше информации (формирование цепочки)

Рисунок 36 - Больше информации (формирование цепочки)

12.7 Деактивация протокола

После обмена данных с помощью протокола обмена данными Инициатор может применить деактивацию протокола обмена данными. После успешной деактивации Инициатор и Цель должны остаться в первоначально выбранном режиме, но Инициатор может выбрать одну из определенных скоростей передачи данных для повторной активации.

См. ИСО/МЭК 14443-3 п.6.4.1 и 12.5.2 для повторной активации Целей в пассивном режиме и в активном режиме соответственно.

После успешной деактивации Цель не должна реагировать на последующие команды ATR_REQ.

Команда RLS_REQ должна переключать Цель обратно в состояние ПИТАНИЕ ВКЛЮЧЕНО. См. 12.7.2.1. В данном состоянии Цель должна отвечать на все первоначальные схемы связи, а также на ATR_REQ.

12.7.1 Команды Запрос на деселекцию и Ответ на деселекцию

12.7.1.1 Запрос на деселекцию (DSL_REQ)

Рисунок 37 определяет команду деселекции DSL_REQ. Инициатор отправляет DSL_REQ Цели.

Рисунок 37 - Структура DSL_REQ

Рисунок 37 - Структура DSL_REQ

12.7.1.1.1 Определение байтов DSL_REQ

CMD 1: Должен быть установлен в значение 'D4'.

CMD 2: DSL_REQ

Байт DSL_REQ определяет команду деселекции для устройства Инициатора. Значение DSL_REQ должно быть '08'.

Байт 1: DID

DID должен быть таким же, как определенный в ходе команд ATR или WUP.

12.7.1.2 Ответ на деселекцию (DSL_RES)

Рисунок 38 определяет команду Ответ на деселекцию DSL_RES. DSL_RES является ответом на DSL_REQ и отправляется от Цели к Инициатору.

Рисунок 38 - Структура DSL_RES

Рисунок 38 - Структура DSL_RES

12.7.1.2.1 Определение байтов DSL_RES

CMD 1: Должен быть установлен в значение 'D5'.

CMD 2: DSL_RES

Байт DSL_RES определяет ответ на команду деселекции для Целевого устройства. Значение DSL_RES должно быть '09'.

Байт 1: DID

DID должен быть таким же, как в DSL_REQ.

12.7.1.3 Обработка DSL_REQ и DSL_RES

12.7.1.3.1 Правила для Инициатора

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

12.7.1.3.2 Правила для Цели

Когда Цель получила DSL_REQ и послала свой DSL_RES, Цель:

- должна оставаться в первоначально выбранном режиме;

- должна позволить принимать стандартные скорости передачи данных, указанные в 11.2 для пассивного режима связи и в 11.3 для активного режима связи;

- должна оставаться в режиме приема до тех пор, пока не будет получен допустимый ALL_REQ в пассивном режиме связи на fc/128 или WUP_REQ в активном режиме связи.

12.7.2 Команды Запрос на освобождение и Ответ на освобождение

12.7.2.1 Запрос на освобождение (RLS_REQ)

Рисунок 39 определяет команду освобождения RLS_REQ. RLS_REQ отправляется от Инициатора к Цели.

Рисунок 39 - Структура RLS_REQ

Рисунок 39 - Структура RLS_REQ

12.7.2.1.1 Определение байтов RLS_REQ

CMD 1: Должен быть установлен в значение 'D4'.

CMD 2: RLS_REQ

Байты RLS_REQ определяют команду освобождения для устройства Инициатора. Значение байтов RLS_REQ должно быть '0А'.

Байт 1: DID

DID должен быть таким же, как определенный в ходе команд ATR или WUP.

12.7.2.2 Ответ на освобождение RLS_RES

RLS_RES является ответом на RLS_REQ, отправленный от Цели - Инициатору, см. рисунок 40.

Рисунок 40 - Структура RLS_RES

Рисунок 40 - Структура RLS_RES

12.7.2.2.1 Определение байтов RLS_RES

CMD 1: Должен быть установлен в значение 'D5'.

CMD 2: RLS_RES

Байты RLS_RES определяют команду освобождения для Целевого устройства. Значение байтов RLS_RES должно быть '0В'.

Байт 1: DID

DID должен быть таким же, как в RLS_REQ.

12.7.2.3 Обработка RLS_REQ и RLS_RES

12.7.2.3.1 Правила для Инициатора

Когда Инициатор отправил RLS_REQ и получил допустимый RLS_RES, Цель была успешно освобождена. Инициатор может вернуться в свое первоначальное состояние.

12.7.2.3.2 Правила для Цели

Когда Цель получила RLS_REQ и послала свой RLS_RES, Цель должна вернуться в первоначальное состояние.

Приложение A (обязательное). Вычисление CRC

Приложение A
(обязательное)

А.1 CRC для активного и пассивного режима связи на fc/128

CRC кадра должен быть функцией от k битов данных, которые состоят из всех битов данных в кадре, за исключением битов четности, S и Е, и самого CRC. Поскольку данные кодируются в байтах, число битов k должно быть кратно 8. Для проверки ошибок два CRC-байта должны быть отправлены в стандартном кадре после байтов и перед E.

CRC должен быть рассчитан по следующему полиному. Предустановленное значение должно быть (6363), и содержимое регистра не должно быть инверсировано после расчета.

G(x)=x+x+x+1

Пример расчета CRC для активного и пассивного режима на fc/128 см. в A.2.

A.2 Пример расчета CRC на fc/128

Данный пример приведен в пояснительных целях и показывает битовые комбинации, которые будут существовать на физическом уровне. Он включен для проверки реализации кодирования в пассивном режиме связи на fc/128.

Процесс кодирования и декодирования может быть удобно реализован с помощью 16-ступенчатого регистра циклического сдвига с соответствующими схемами обратной связи. Согласно рекомендации МСЭ-Т (ITU-T V.41 Code-independent error control system), Приложение I, рисунки I-1/V.41 и I-2/V.41, триггеры регистра должны быть пронумерованы от FF1 до FF16. FF1 должен быть самым левым триггером, в который данные смещаются. FF16 должен быть самым правым триггером, из которого данные смещаются. Таблица А.1 определяет начальное заполнение регистра.


Таблица А.1 - Начальное заполнение 16-ступенчатого регистра сдвига в соответствии со значением (6363)

Следовательно, FF1 соответствует msb, a FF16 - Isb.

Ниже приведены примеры битовых комбинаций, которые будут передаваться посредством стандартных кадров.

Пример 1: Передача данных, первый байт ='00', второй байт ='00', CRC добавлен, см. рисунок А.1. Рассчитанный CRC=(1ЕА0), см. таблицу А.2.

Рисунок A.1 - Пример 1 кодирования CRC

Первый передаваемый бит

Рисунок A.1 - Пример 1 кодирования CRC

Таблица А.2 - Заполнение 16-ступенчатого регистра сдвига в соответствии со значением (1ЕА0)

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

Рисунок А.2 - Пример 2 кодирования CRC

Первый передаваемый бит

Рисунок А.2 - Пример 2 кодирования CRC

Таблица A.3 - Заполнение 16-ступенчатого регистра сдвига в соответствии со значением (CF26)

A.3 CRC для активного и пассивного режимов связи на fc/64 и fc/32

CRC должен рассчитывается* с помощью CCITT CRC-16, область применения которого должна включать поле Длина и поле Полезная нагрузка. Расчет G(x) должен осуществляться следующим образом:
____________________
* Текст документа соответствует оригиналу. - .

G(x)=x+x+x+1.

Предустановленное значение должно быть 0. Пример расчета CRC для активного и пассивного режимов на fc/64 и fc/32 см. в А.4.

A.4 Пример расчета CRC на fc/64 и fc/32

Типовой кадр является следующим:

'00' '00' '00' '00' '00' '00' 'В2' '4D' '03' 'АВ' 'CD' '90' '35'

'В2' '4D' - SYNC. '03' - длина. 'АВ' 'CD' - пользовательские данные. '90' '35' - соответствующий CRC.

Приложение B (справочное). SAK

Приложение B
(справочное)

Рисунок В.1 иллюстрирует использование комбинации SAK в ИСО/МЭК 14443 и ИСО/МЭК 18092.

Рисунок В.1 - Комбинация SAK

Рисунок В.1 - Комбинация SAK

Приложение ДА (справочное). Сведения о соответствии ссылочных международных стандартов национальным стандартам Российской Федерации

Приложение ДА
(справочное)

Таблица ДА

Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2015