ГОСТ 33465-2023. Межгосударственный стандарт. Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Протоколы обмена данными устройства/системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях
5 Протокол транспортного уровня
5.1 Назначение протокола транспортного уровня
5.1.1 Протокол транспортного уровня предназначен для обеспечения маршрутизации информации протокола уровня поддержки услуг между пунктами инфраструктуры системы экстренного реагирования при авариях и УСВ, использующих данный протокол, проверки целостности и правильной последовательности данных, а также обеспечения надежности доставки до пункта назначения.
5.1.2 Описание принципа построения системы на основе протокола транспортного уровня приведено в приложении А.
5.1.3 Анализ протокола транспортного уровня на основе концепции NGTP приведен в приложении Б.
5.2 Обеспечение маршрутизации
В основу протокола транспортного уровня положен принцип гибкой маршрутизации пакетов данных между взаимоувязанными элементами распределенной сети ТП, использующих данный протокол. В качестве адресов маршрутизации используются идентификаторы ТП, которые должны быть уникальны в рамках одной взаимоувязанной сети.
5.3 Механизм проверки целостности данных
Проверка целостности передаваемой информации основана на применении контрольных сумм заголовка транспортного уровня и данных уровня поддержки услуг. Принимающая сторона подсчитывает контрольные суммы и сравнивает их с соответствующими значениями, записанными отправляющей стороной в определенные поля пакета. Если контрольные суммы не совпадают, то считается, что целостность нарушена, на что отправляется подтверждение в виде кода ошибки результата обработки.
В целях обеспечения минимизации использования системных ресурсов при обработке пакетов протокола в части транспортного уровня и данных уровня поддержки услуг используются различные поля и алгоритмы обеспечения контроля целостности. При этом используется механизм, основанный на подсчете контрольной суммы, передаваемой последовательности байтов (CRC).
Для части пакета транспортного уровня используется алгоритм вычисления циклического избыточного кода CRC-8.
Для части пакета уровня поддержки услуг используется алгоритм вычисления циклического избыточного кода CRC-16.
5.4 Обеспечение надежности доставки пакетов данных
5.4.1 Механизм обеспечения надежной доставки основан на использовании подтверждений ранее отправленных пакетов. Отправляющая сторона после передачи пакета ожидает на него подтверждения в виде пакета определенного типа, содержащего идентификатор ранее переданного пакета и код результата его обработки на принимающей стороне. Ожидание производится в течение определенного промежутка времени, регламентированного протоколом транспортного уровня и зависящего от типа используемого транспортного протокола нижнего уровня (параметр TL_RESPONSE_TO) (см. 5.8). После получения подтверждения отправляющая сторона производит анализ кода результата.
Коды результатов обработки также регламентированы протоколом транспортного уровня и представлены в приложении В.
5.4.2 В зависимости от результата анализа пакет считается доставленным или недоставленным. Пакет также считается недоставленным, если подтверждение не приходит по истечении времени TL_RESPONSE_TO (см. 5.8). Недоставленные пакеты отправляются повторно (число попыток отправки регламентировано настоящим протоколом и определяется параметром TL_RESEND_ATTEMPTS) (см. 5.8). По достижении предельного числа попыток отправки канал передачи данных считается ненадежным, и производится уничтожение установленной сессии (разрыв соединения в случае использования TCP/IP протокола в качестве транспортного) и попытка создания новой сессии (соединения) через время, определяемое параметром TL_RECONNECT_TO (см. 5.8).
5.5 Описание типов данных, используемых в протоколе транспортного уровня
5.5.1 Протоколом транспортного уровня определены и используются несколько различных типов данных полей и параметров. Состав и описание типов данных, используемых в протоколе транспортного уровня, представлены в таблице 2.
Таблица 2
Состав и описание типов данных, используемых
в протоколе транспортного уровня
Тип данных | Размер, байт | Диапазон значений | Описание |
BOOLEAN | 1 | TRUE-1, FALSE-0 | Логический тип, принимающий только два значения, TRUE или FALSE |
BYTE | 1 | 0 ... 255 | Целое число без знака |
USHORT | 2 | 0 ... 65535 | Целое число без знака |
UINT | 4 | 0 ... 4294967295 | Целое число без знака |
ULONG | 8 | 0... 18446744073709551615 | Целое число без знака |
SHORT | 2 | - 32768 ... + 32767 | Целое число со знаком |
INT | 4 | - 2147483648 ... + 2147483647 | Целое число со знаком |
FLOAT | 4 | +/- 1,2 E - 38 ... 3,4 E + 38 | Дробное число со знаком (см. [4]) |
DOUBLE | 8 | +/- 2,2 E - 308 ... 1,7 E + 308 | Дробное число со знаком (см. [4]) |
STRING | Переменный. Размер определяется внешними параметрами или применением специального символа-терминатора (код 0x00) | - | Содержит последовательность печатных символов в кодировке по умолчанию CP-1251, если явно не указана другая кодировка (при помощи дополнительного параметра) |
BINARY | Переменный. Размер определяется внешними параметрами | - | Содержит последовательность данных типа BYTE |
ARRAYOFTYPE | Переменный. Размер определяется внешними параметрами | - | Может содержать последовательность одного из вышеуказанных типов (TYPE), кроме BINARY. Порядок следования байтов и размер каждого элемента используемого типа определяются самим типом. Экземпляры типов идут последовательно один за другим. Например: ARRAY OF STRING содержит в своем составе 10 экземпляров типа STRING, при этом размер каждого экземпляра определяется разделителем (код 0x00), который должен присутствовать между экземплярами |
5.5.2 Многобайтовые типы данных USHORT, UINT, ULONG, FLOAT и DOUBLE используют порядок следования байтов little-endian (младший байт вперед). Байты, составляющие последовательность в типах STRING и BINARY, должны интерпретироваться как есть, т.е. обрабатываться в порядке их поступления.
5.5.3 В протоколе транспортного уровня определены следующие типы полей и параметров:
- M (mandatory) - обязательный параметр. Параметр должен передаваться всегда;
- O (optional) - необязательный. Параметр может не передаваться, и его присутствие определяется другими параметрами, входящими в пакет.
5.6 Описание структур данных, используемых в протоколе транспортного уровня
5.6.1 Общая структура пакета протокола транспортного уровня определяется составом пакета и его форматом.
5.6.1.1 Пакет протокола транспортного уровня состоит из заголовка, поля "данные уровня поддержки услуг", а также поля контрольной суммы "данных уровня поддержки услуг".
Состав пакета протокола транспортного уровня представлен на рисунке 1.
Заголовок протокола транспортного уровня | Данные уровня поддержки услуг | Контрольная сумма данных уровня поддержки услуг |
Рисунок 1 - Состав пакета протокола транспортного уровня
5.6.1.2 Общая длина пакета протокола транспортного уровня не превышает значения 65535 байт, что соответствует максимальному значению параметра Window Size (максимальный размер целого пакета, принимаемый на стороне приемника) заголовка протокола TCP. Такое значение максимального размера пакета позволяет более эффективно использовать каналы передачи данных, базируясь только на стандартном методе управления потоком данных, заложенном в протоколе TCP/IP (см. [3]).
Формат пакета транспортного уровня представлен в таблице 3.
Таблица 3
Состав пакета протокола транспортного уровня
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
PRV (Protocol Version) | M | BYTE | 1 | |||||||
SKID (Security Key ID) | M | BYTE | 1 | |||||||
PRF (Prefix) | RTE | ENA | CMP | PR | M | BYTE | 1 | |||
HL (Header Length) | M | BYTE | 1 | |||||||
HE (Header Encoding) | M | BYTE | 1 | |||||||
FDL (Frame Data Length) | M | USHORT | 2 | |||||||
PID (Packet Identifier) | M | USHORT | 2 | |||||||
PT (Packet Type) | M | BYTE | 1 | |||||||
PRA (Peer Address) | O | USHORT | 2 | |||||||
RCA (Recipient Address) | O | USHORT | 2 | |||||||
TTL (Time To Live) | O | BYTE | 1 | |||||||
HCS (Header Check Sum) | M | BYTE | 1 | |||||||
SFRD (Services Frame Data) | O | BINARY | 0 ... 65517 | |||||||
SFRCS (Services Frame Data Check Sum) | O | USHORT | 0, 2 | |||||||
5.6.1.3 Заголовок протокола транспортного уровня состоит из следующих параметров (полей): PRV, PRF, PR, CMP, ENA, RTE, HL, HE, FDL, PID, PT, PRA, RCA, TTL, HCS. Протокол уровня поддержки услуг представлен полем SFRD, контрольная сумма поля уровня поддержки услуг содержится в поле SFRCS.
Описание вышеуказанных параметров (полей) приведено в таблице 4.
Таблица 4
Описание параметров (полей), входящих в состав пакета
протокола транспортного уровня
Обозначение параметра (поля) | Назначение параметра (поля) |
PRV | Параметр определяет версию используемой структуры заголовка и должен содержать значение 0x01. Значение данного параметра инкрементируется каждый раз при внесении изменений в структуру заголовка |
SKID | Параметр определяет идентификатор ключа, используемый при шифровании |
PRF | Параметр определяет префикс заголовка транспортного уровня и для данной версии должен содержать значение 00 |
RTE (Route) | Битовое поле определяет необходимость дальнейшей маршрутизации данного пакета на удаленную ТП, а также наличие опциональных параметров PRA, RCA, TTL, необходимых для маршрутизации данного пакета. Если поле имеет значение 1, то необходима маршрутизация и поля PRA, RCA, TTL присутствуют в пакете. Данное поле устанавливает диспетчер той ТП, на которой сгенерирован пакет, или УСВ, сгенерировавшая пакет для отправки на ТП (в случае установки в ней параметра HOME_DISPATCHER_ID, определяющего ее адрес, на который данная УСВ зарегистрирована). В случае отсутствия в УСВ параметра HOME_DISPATCHER_ID маршрутизация пакета производится по внутренним правилам диспетчера, обрабатывающего пакет |
ENA (Encryption Algorithm) | Битовое поле определяет код алгоритма, используемый для шифрования данных из поля SFRD. Если поле имеет значение 00, то данные в поле SFRD не шифруются. Состав и коды алгоритмов не определены в данной версии протокола |
CMP (Compressed) | Битовое поле определяет, используется ли сжатие данных из поля SFRD. Если поле имеет значение 1, то данные в поле SFRD считаются сжатыми. Алгоритм сжатия не определен в данной версии протокола |
PR (Priority) | Битовое поле определяет приоритет маршрутизации данного пакета и может принимать следующие значения: 00 - наивысший; 01 - высокий; 10 - средний; 11 - низкий. Установка большего приоритета позволяет передавать пакеты, содержащие срочные данные, такие как, например, пакет с минимальным набором данных базовой услуги системы экстренного реагирования при авариях или данные о срабатывании сигнализации на ТС. При получении пакета диспетчер, анализируя данное поле, производит маршрутизацию пакета с более высоким приоритетом быстрее, чем пакета с низким приоритетом, тем самым достигается более оперативная обработка при наступлении критически важных событий |
HL | Длина заголовка протокола транспортного уровня в байтах с учетом байта контрольной суммы (поля HCS) |
HE | Определяет применяемый метод кодирования следующей за данным параметром части заголовка протокола транспортного уровня. Зарезервировано |
FDL | Определяет размер в байтах поля данных SFRD, содержащего информацию протокола уровня поддержки услуг |
PID | Содержит номер пакета протокола транспортного уровня, увеличивающийся на 1 на стороне отправителя при отправке каждого нового пакета. Значения в данном поле изменяются по правилам циклического счетчика в диапазоне от 0 до 65535, т.е. при достижении значения 65535 следующее значение должно быть 0 |
PT | Тип пакета протокола транспортного уровня. Поле PT может принимать следующие значения: 0 - EGTS_PT_RESPONSE (подтверждение на протокол транспортного уровня); 1 - EGTS_PT_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг); 2 - EGTS_PT_SIGNED_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг с цифровой подписью) |
PRA | Адрес ТП, на которой данный пакет сгенерирован. Данный адрес является уникальным в рамках связной сети и используется для создания пакета-подтверждения на принимающей стороне |
RCA | Адрес ТП, для которой данный пакет предназначен. По данному адресу производится идентификация принадлежности пакета определенной ТП и его маршрутизация при использовании промежуточных ТП |
TTL | Время жизни пакета при его маршрутизации между ТП. Использование данного параметра предотвращает зацикливание пакета при ретрансляции в системах со сложной топологией адресных пунктов. Первоначально TTL устанавливается ТП, сгенерировавшей данный пакет. Значение TTL устанавливается равным максимально допустимому числу ТП между отправляющей и принимающей платформами. Значение TTL уменьшается на единицу при трансляции пакета через каждую ТП, при этом пересчитывается контрольная сумма заголовка протокола транспортного уровня. При достижении данным параметром значения 0 и при обнаружении необходимости дальнейшей маршрутизации пакета происходит уничтожение пакета и выдача подтверждения с соответствующим кодом (PC_TTLEXPIRED, см. приложение В) |
SFRCS | Контрольная сумма. Для подсчета контрольной суммы по данным из поля SFRD используется алгоритм CRC-16 - CCITT. Данное поле присутствует только в том случае, если есть поле SFRD. Пример программного кода расчета CRC-16 приведен в приложении Г. |
SFRD | Структура данных, зависящая от типа пакета и содержащая информацию протокола уровня поддержки услуг |
HCS | Контрольная сумма заголовка протокола транспортного уровня (начиная с поля PRV до поля HCS, не включая последнего). Для подсчета значения поля HCS ко всем байтам указанной последовательности применяется алгоритм CRC-8. Пример программного кода расчета CRC-8 приведен в приложении Д |
5.6.1.4 Блок-схема алгоритма сборки пакета ПТУ при приеме представлена на рисунке 2.
А - маршрутизация и отправка пакета на другую ТП;
Б - обработка данных протокола уровня поддержки услуг
Рисунок 2 - Блок-схема алгоритма сборки пакета ПТУ
при приеме
5.6.1.5 Кодировка печатных символов при сборке ПТУ осуществляется с использованием таблиц, приведенных в приложении Е.
5.6.2 Структуры данных в зависимости от типа пакета
В зависимости от типа пакета протокола транспортного уровня структура поля SFRD имеет различный формат.
5.6.2.1 Структура данных пакета EGTS_PT_APPDATA
Пакет данного типа предназначен для передачи одной или нескольких структур, содержащих информацию протокола уровня поддержки услуг. Структура данных поля SFRD пакета EGTS_PT_APPDATA представлена в таблице 5.
Таблица 5
Формат поля SFRD для пакета типа EGTS_PT_APPDATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SDR 1 (Service Data Record) | O | BINARY | 9 ... 65517 | |||||||
SDR 2 | O | BINARY | 9 ... 65517 | |||||||
... | ... | ... | ... | |||||||
SDRn | O | BINARY | 9 ... 65517 | |||||||
Примечание - Структуры SDR 1, SDR 2, SDRn содержат информацию протокола уровня поддержки услуг. Таких структур в составе поля SFRD может быть одна или несколько, идущих одна за другой. Описание внутреннего состава структур представлено в разделе 6. | ||||||||||
5.6.2.2 Структура данных пакета EGTS_PT_RESPONSE
С помощью данного типа пакета осуществляется подтверждение пакета протокола транспортного уровня. Данный тип пакета содержит информацию о результате обработки данных протокола транспортного уровня, полученного ранее. Структура данных поля SFRD пакета EGTS_PT_RESPONSE представлена в таблице 6.
Таблица 6
Формат поля SFRD для пакета типа EGTS_PT_RESPONSE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RPID (Response Packet ID) | M | USHORT | 2 | |||||||
PR (Processing Result) | M | BYTE | 1 | |||||||
SDR 1 (Service Data Record) | O | BINARY | 9... 65514 | |||||||
SDR 2 | O | BINARY | 9... 65514 | |||||||
... | ... | ... | ... | |||||||
SDRn | O | BINARY | 9... 65514 | |||||||
Примечания 1 Параметр RPID - идентификатор пакета транспортного уровня, подтверждение на который формируется. 2 Параметр PR - код результата обработки части пакета, относящейся к транспортному уровню (подсчет контрольных сумм заголовка транспортного уровня и данных уровня поддержки услуг, проверка размера пакета и т.д.). Список возможных кодов результата обработки представлен в приложении В. 3 Структуры SDR 1, SDR 2, SDRn - структуры, содержащие информацию уровня поддержки услуг. Таких структур может быть одна или несколько, идущих одна за другой. | ||||||||||
5.6.2.3 Структура данных пакета EGTS_PT_SIGNED_APPDATA
Пакет данного типа применяется для передачи помимо структур, содержащих информацию уровня поддержки услуг, также информацию о "цифровой подписи", идентифицирующей отправителя данного пакета. Структура данных поля SFRD пакета EGTS_PT_SIGNED_APPDATA представлена в таблице 7.
Таблица 7
Формат поля SFRD для пакета типа EGTS_PT_SIGNED_APPDATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SIGL (Signature Length) | M | USHORT | 2 | |||||||
SIGD (Signature Data) | O | BINARY | 0 ... 512 | |||||||
SDR 1 (Service Data Record) | O | BINARY | 9... 65515 | |||||||
SDR 2 | O | BINARY | 9... 65515 | |||||||
... | ... | ... | ... | |||||||
SDRn | O | BINARY | 9... 65515 | |||||||
Примечания 1 Параметр SIGL - определяет длину данных "цифровой подписи" из поля SIGD. 2 Параметр SIGD - содержит непосредственно данные "цифровой подписи". 3 Структуры SDR 1, SDR 2, SDRn - структуры, содержащие информацию уровня поддержки услуг. Таких структур может быть одна или несколько, идущих одна за другой. | ||||||||||
5.6.2.4 На каждый пакет типа EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA, поступающий от УСВ на ТП или от нее на УСВ, должен быть отправлен пакет типа EGTS_PT_RESPONSE, содержащий в поле PID номер пакета из пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA.
На рисунке 3 представлена последовательность обмена пакетами при взаимодействии УСВ и ТП.
Рисунок 3 - Взаимодействие УСВ и ТП
на уровне пакетов транспортного уровня
5.7 Описание структуры данных при использовании SMS в качестве резервного канала передачи данных
5.7.1 Структура SMS-сообщения
При использовании SMS для передачи пакетов данных протокола транспортного уровня используется режим PDU (см. [5], [6]). Режим PDU позволяет передавать не только текстовую, но и бинарную информацию через сервис SMS оператора сотовой связи GSM. Описываемый протокол транспортного уровня оперирует бинарными данными, поэтому PDU-режим наиболее подходит для использования SMS в качестве резервного канала передачи транспортного уровня.
5.7.1.1 Для передачи SMS-сообщения используется 8-битная кодировка. Формат SMS-сообщения для отправки в PDU-режиме представлен в таблице 8 и использует соответствующую структуру (структура представлена в [6] (раздел 9)).
Таблица 8
Формат SMS с использованием PDU-режима
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
SMSC_AL (SMSC Address Length) | M | 1 | |||||||
SMSC_AT (SMSC Address Type) | O | 0,1 | |||||||
SMSC_A (SMSC Address) | O | 0,6 | |||||||
TP_RP | TP_UDHI | TP_SRR | TP_VPF | TP_RD | TP_MTI | M | 1 | ||
TP_MR (MessageReference) | M | 1 | |||||||
TP_DA_L (Destination Address Length) | M | 1 | |||||||
TP_DA_T (Destination Address Type) | M | 1 | |||||||
TP_DA (Destination Address) | M | 6 | |||||||
TP_PID (ProtocolIdentifier) | M | 1 | |||||||
TP_DCS (Data Coding Schema) | M | 1 | |||||||
TP_VP (ValidityPeriod) | O | 0, 1, 7 | |||||||
TP_UDL (User Data Length) | M | 1 | |||||||
TP_UD (UserData) | O | 0... 140 | |||||||
5.7.1.2 Описание параметров, входящих в состав SMS-сообщения в PDU-режиме, приведено ниже:
- SMSC_AL - длина полезных данных адреса SMSC в октетах;
- SMSC_AT - тип формата адреса SMSC.
Возможные значения параметров SMSC_AT представлены в таблице 9.
Таблица 9
Формат полей TP_DA_T и SMSC_AT (тип адреса)
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Размер, байт |
1 | TON | NPI | 1 | |||||
Параметры полей TP_DA_T и SMSC_AT, приведенные в таблице 9, имеют следующие назначения:
- TON (Type Of Number) - тип номера. Параметр TON может принимать следующие значения:
а) 000 - неизвестный;
б) 001 - международный формат;
в) 010 - национальный формат;
г) 011 - специальный номер, определяемый сетью;
д) 100 - номер абонента;
е) 101 - буквенно-цифровой код (коды приведены в [5] с 7-битной кодировкой по умолчанию);
ж) 110 - укороченный;
и) 111 - зарезервировано;
- NPI (NumericPlanIdentification) - тип плана нумерации (применимо для значений поля TON-000,001,010). NPI может принимать следующие значения:
а) 0000 - неизвестный;
б) 0001 - план нумерации ISDN телефонии;
в) 0011 - план нумерации при передаче данных;
г) 0100 - телеграф;
д) 1000 - национальный;
е) 1001 - частный;
ж) 1111 - зарезервировано.
Поле опциональное, и наличие его зависит от значения параметра SMSC_AL (если значение SMSC_AL больше 0, то данное поле присутствует);
- SMSC_A - адрес SMSC. Каждая десятичная цифра номера представлена в виде 4 бит (младшие 4 бита - цифра более старшего разряда, старшие 4 бита - цифра меньшего разряда), при этом если число цифр в номере нечетное, то в битах с 4 по 7 последнего байта номера устанавливается значение 0xF (1111b). Данный параметр опциональный, и его наличие зависит от значения параметра SMSC_AL. В случае отсутствия параметра SMSC_A используется SMSC из SIM-карты;
- TP_MTI - (Message Type Indicator) тип сообщения (должен содержать бинарное значение 01);
- TP_RD - (Reject Duplicates) поле определяет, необходимо ли SMSC принимать данное сообщение на обработку, если существует предыдущее необработанное отправленное с данного номера сообщение, которое имеет такое же значение поля TP_MR и такой же номер получателя в поле TP_DA;
- TP_VPF - (Validity Period Format) формат параметра TP_VP. Возможные значения поля TP_VPF представлены в таблице 10;
Таблица 10
Формат поля TP_VP в зависимости от значения поля TP_VPF
Значение битов | Описание | |
0 | 0 | Поле TP_VP не передается |
1 | 0 | Поле TP_VP имеет формат "относительное время" и размер 1 байт |
0 | 1 | Поле TP_VP имеет формат "расширенное время" и размер 7 байт |
1 | 1 | Поле TP_VP имеет формат "абсолютное время" и размер 7 байт |
- TP_SRR - (Status Report Request) поле определяет необходимость отправки подтверждения со стороны SMSC на данное сообщение (если данный бит имеет значение 1, то требуется подтверждение);
- TP_UDHI - (User Data Header Indicator) поле определяет, передается ли заголовок пользовательских данных TP_UD_HEADER (если поле имеет значение 1, то заголовок присутствует);
- TP_RP - (Reply Path) поле определяет, присутствует ли поле RP в сообщении;
- TP_MR - идентификатор сообщения (должен увеличиваться на 1 при каждой отправке нового сообщения);
- TP_DA_L - длина полезных данных адреса получателя в октетах;
- TP_DA_T - тип формата адреса получателя. Возможные значения параметров TP_DA_T и SMSC_AT представлены в таблице 9;
- TP_DA - адрес получателя. Кодировка номера производится по тем же правилам, что и в параметре SMSC_A;
- TP_PID - идентификатор протокола (должен содержать значение 00);
- TP_DCS - тип кодировки данных (должен содержать значение 0x04, определяющий 8-битную кодировку сообщения, отсутствие компрессии);
- TP_VP - время актуальности данного сообщения. Формат данного поля определяется значением из таблицы 10. Параметр является опциональным. Его наличие и размер зависят от значения поля TP_VPF;
- TP_UDL - длина данных сообщения из поля TP_DL в байтах для используемой 8-битной кодировки;
- TP_UD - непосредственно передаваемые пользовательские данные. Формат данного поля, в зависимости от значения поля TP_UDHI, представлен в таблице 11.
Таблица 11
Формат поля TP_UD
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
LUDH (Length of User Data Header) | O | 1 | |||||||
IEI "A" (Information-Element-Identifier "A") | O | 1 | |||||||
LIE "A" (Length of Information-Element "A") | O | 1 | |||||||
IED "A" (Information-Element-Data of "A") | O | 1 ... n | |||||||
IEI "B" (Information-Element-Identifier "B") | O | 1 | |||||||
LIE "B" (Length of Information-Element "B") | O | 1 | |||||||
IED "B" (Information-Element-Data of "B") | O | 1 ... n | |||||||
IEI "N" (Information-Element-Identifier "N") | O | 1 | |||||||
LIE "N" (Length of Information-Element "N") | O | 1 | |||||||
IED "N" (Information-Element-Data of "N") | O | 1 ... n | |||||||
UD (User Data) | M | 1...140 | |||||||
Параметры поля TP_UD, приведенные в таблице 11, имеют следующие назначения:
- LUDH - длина заголовка пользовательских данных в байтах без учета размера данного поля;
- IEI "A", IEI "B", IEI "N" - идентификатор информационного элемента "A", "B" и "N" соответственно, который определяет тип информационного элемента и может принимать следующие значения (в шестнадцатеричной системе):
а) 00 - часть конкатенируемого SMS-сообщения;
б) 01 - индикатор специального SMS-сообщения;
в) 02 - зарезервировано;
г) 03 - не используется;
д) 04 - 7F - зарезервировано;
е) 80 - 9F - для специального использования SME;
ж) A0 - BF - зарезервировано;
и) C0 - DF - для специального использования SC;
к) E0 - FF - зарезервировано.
- LIE "A", LIE "B", LIE "N" - параметры, определяющие размер данных информационных элементов "A", "B" и "N" соответственно в байтах без учета размера данного поля;
- IED "A", IED "B", IED "N" - данные информационных элементов "A", "B" и "N" соответственно;
- UD - данные пользователя. Размер данного поля определяется наличием заголовка пользовательских данных TP_UD_HEADER, состоящего из полей LUDH, IEI, LIE, IED. Если заголовок не передается, то размер равен значению поля TP_UDL, указанному в таблице 8. Если заголовок передается, то размер поля вычисляется как разность (TP_UDL - LUDH-1).
В случае, если идентификатор информационного элемента IEI заголовка пользовательских данных TP_UD_HEADER имеет значение 00, структура поля IED будет иметь вид, указанный в таблице 12.
Таблица 12
Формат поля данных информационного элемента,
характеризующего часть конкатенируемого SMS-сообщения
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
CSMRN (Concatenated Short Message Reference Number) | M | 1 | |||||||
MNSM (Maximum Number of Short Messages) | M | 1 | |||||||
SNCSM (Sequence Number of Current Short Message) | M | 1 | |||||||
Примечания 1 CSMRN - номер конкатенируемого SMS-сообщения должен иметь одинаковое значение для всех частей длинного SMS-сообщения. 2 MNSM - общее количество сообщений, из которых состоит длинное SMS. Должен содержать значения в диапазоне от 1 до 255. 3 SNCSM - номер передаваемой части длинного SMS-сообщения. Инкрементируется при отправке каждой новой части длинного сообщения. Должен содержать значение в диапазоне от 1 до 255. Если значение данного поля превышает значение из поля MNSM или равно нулю, то принимающая сторона должна игнорировать весь информационный элемент. | |||||||||
5.7.1.3 УСВ, которые поддерживают функцию мониторинга ТС, при приеме SMS-сообщения используют формат SMS-DELIVER с 8-битной кодировкой. Формат принимаемого SMS-сообщения в PDU режиме должен соответствовать формату, указанному в ГОСТ 33472.
5.7.2 Описание формата передаваемой информации
5.7.2.1 При использовании SMS для обмена данными между УСВ и ТП пакеты, упакованные по правилам протокола транспортного уровня и протокола уровня поддержки услуг, помещаются в поле TP_UD (см. таблицу 8), при этом полный размер пакета протокола не должен превышать 140 байт. В этом случае механизм авторизации не используется и подтверждения протокола транспортного уровня в виде пакета типа EGTS_PT_RESPONSE и уровня поддержки услуг в виде подзаписи EGTS_SR_RECORD_RESPONSE на переданные пакеты не требуются. Признаком успешного прохождения пакета до УСВ является уведомление о доставке SMS.
На подзапись EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE, содержащую команду или сообщение, требуется подтверждающая подзапись EGTS_SR_COMMAND_DATA с соответствующим значением полей CT (CommandType) и CCT (CommandConfirmationType). В случае отправки команды на УСВ через SMS соответствующий пакет EGTS, содержащий подтверждение о приеме команды в виде подзаписи EGTS_SR_COMMAND_DATA, должен быть передан с УСВ через SMS.
5.7.2.2 Для отправки SMS, содержащего "цифровую подпись", используется пакет транспортного уровня типа EGTS_PT_SIGNED_APPDATA.
5.7.2.3 В случае, если размер пакета данных протокола превышает 140 байт, используется механизм конкатенации SMS-сообщений (см. [6], (9.2.3.24.1)). Суть данного механизма состоит в том, что передаваемые пользовательские данные разбиваются на части и отправляются отдельными SMS-сообщениями. При этом каждое такое сообщение содержит специальную структуру, определяющую общее число частей передаваемых данных и порядок их сборки на принимающей стороне. В качестве такой структуры используется поле TP_UD_HEADER, которое содержит информационный элемент, характеризующий часть конкатенируемого SMS-сообщения. Таким образом, исходя из размера заголовка данных пользователя и максимального числа частей длинного сообщения, равного 255, максимально возможный размер пакета при использовании 8-битной кодировки может составлять 255(140 - 6) = 34170 байт.
При использовании SMS в качестве канала передачи пакетов EGTS на УСВ ограничивают размер одного пакета EGTS значением 10(140 - 6) = 1360 байт, т.к. использование большего размера может привести к переполнению внутреннего приемного буфера УСВ. Максимальный размер 1360 байт позволит передавать элементарное сообщение EGTS с использованием цифровой подписи (поля SIGL/SIGD) и кода авторизации (ACL/AC).
5.8 Временные и количественные параметры протокола транспортного уровня при использовании пакетной передачи данных
Наименование и описание временных и количественных параметров протокола транспортного уровня приведены в таблице 13.
Таблица 13
Временные и количественные параметры протокола
транспортного уровня
Название | Тип данных | Диапазон значений | Значение по умолчанию | Описание |
TL_RESPONSE_TO | BYTE | 0 ... 255 | 5 | Время ожидания подтверждения пакета на транспортном уровне, отсчитываемое с момента его отправки стороной, сгенерировавшей пакет, с |
TL_RESEND_ATTEMPTS | BYTE | 0 ... 255 | 3 | Число повторных попыток отправки неподтвержденного пакета |
TL_RECONNECT_TO | BYTE | 0 ... 255 | 30 | Время, по истечении которого будет осуществляться повторная попытка установления канала связи после его разрыва, с |
5.9 Передача МНД в некорректируемом виде
5.9.1 Передача МНД в некорректируемом виде с использованием тонального модема
Передаваемый с использованием тонального модема объем МНД всегда равен 140 байт.
При этом полезная (задействованная) часть блока данных МНД вместе с данными Optional Additional Data, указанными в ГОСТ 33464-2023 (таблица В.1), размещаются в начале блока данных, а незадействованные, оставшиеся свободными байты заполняются буферным значением (как правило, нулевым).
При передаче МНД в некорректируемом виде незадействованные байты используются следующим образом:
- в первые два байта помещается номер ключа шифрования, при помощи которого УВС был сформирован код аутентификации МНД;
- далее следует массив данных кода аутентификации объемом 32 байта, сформированной по алгоритму (см. [7]);
- оставшиеся незадействованными байты заполняются нулевыми значениями до достижения установленного объема блока данных в 140 байт.
Код аутентификации формируется для массива данных от первого байта блока МНД по байт (включая его), предшествующий номеру ключа, т.е. по всем полезным данным МНД.
5.9.2 Передача МНД в некорректируемом виде с использованием SMS
Для передачи МНД по резервному каналу с использованием SMS используется расширение сервиса EGTS_ECALL_SERVICE. При этом должна быть сформирована подзапись EGTS_SR_SIGNED_RAW_MSD_DATA, за которой закреплен идентификационный номер 41.
Структура подзаписи EGTS_SR_SIGNED_RAW_MSD_DATA приведена в таблице 14.
Таблица 14
Структура подзаписи EGTS_SR_SIGNED_RAW_MSD_DATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SK# (Security Key Number) | M | SHORT | 2 | |||||||
SD (Signature Data) | M | BINARY | 32 | |||||||
MSD (Minimal Set of Data) | M | BINARY | 0...83 | |||||||
Описание полей:
- SK# - Security Key Number - номер ключа, при помощи которого УВС был сформирован код аутентификации МНД;
- SD - Signature Data - массив размером 32 байта данных кода аутентификации, сформированный по алгоритму (см. [7]). Код аутентификации формируется по всем данным поля MSD;
- MSD - минимальный набор данных (полезная часть данных МНД и Optional Additional Data указаны в 5.9.1).
Подписаться на обновления