Товары в корзине: 0 шт Оформить заказ
Стр. 1 

69 страниц

563.00 ₽

Купить ГОСТ 33465-2015 — бумажный документ с голограммой и синими печатями. подробнее

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

Распространяется на устройства и системы вызова экстренных оперативных служб, предназначенные для установки на колесные транспортные средства категорий M и N в соответствии с требованиями технического регламента таможенного союза "О безопасности колесных транспортных средств". Стандарт устанавливает требования к протоколам обмена данными между устройством/системой вызова экстренных оперативных служб и инфраструктурой системы вызова экстренных оперативных служб, включая требования к протоколу обмена данными, связанными с предоставлением системой базовой услуги в целях выполнения требований технического регламента таможенного союза "О безопасности колесных транспортных средств" и ГОСТ 33464.

 Скачать PDF

Рекомендуется использовать вместо ГОСТ Р 54619-2011 (ИУС 5-2017)

Оглавление

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

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

3 Термины, определения и сокращения

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

5 Протокол транспортного уровня

     5.1 Назначение протокола транспортного уровня

     5.2 Обеспечение маршрутизации

     5.3 Механизм проверки целостности данных

     5.4 Обеспечение надежности доставки пакетов данных

     5.5 Описание типов данных, используемых в протоколе транспортного уровня

     5.6 Описание структур данных, используемых в протоколе транспортного уровня

     5.7 Описание структуры данных при использовании SMS в качестве резервного канала передачи данных

     5.8 Временные и количественные параметры протокола транспортного уровня при использовании пакетной передачи данных

6 Протокол уровня поддержки услуг (общая часть)

     6.1 Назначение протокола уровня поддержки услуг

     6.2 Обмен информационными сообщениями

     6.3 Обеспечение уведомления о результате доставки и обработки данных уровня поддержки услуг

     6.4 Идентификация принадлежности данных, используемых в протоколе уровня поддержки услуг

     6.5 Определение характеристик данных в протоколе уровня поддержки услуг

     6.6 Структуры данных, используемые в протоколе уровня поддержки услуг

     6.7 Описание сервисов предоставления услуг

     6.8 Временные и количественные параметры протокола уровня поддержки услуг при использовании пакетной передачи данных

7 Сервис экстренного реагирования при аварии протокола уровня поддержки услуг

8 Формат сообщения AL-ACK

Приложение А (справочное) Описание принципа построения навигационно-информационной системы на основе протокола транспортного уровня

Приложение Б (справочное) Анализ протокола транспортного уровня на основе концепции NGTP

Приложение В (обязательное) Коды результатов обработки

Приложение Г (справочное) Пример реализации алгоритма расчета контрольной суммы CRC16 на языке С/*

Приложение Д (справочное) Пример реализации алгоритма расчета контрольной суммы CRC8 на языке С/*

Приложение Е (справочное) Таблицы кодировки символов

Библиография

 
Дата введения01.01.2017
Добавлен в базу05.05.2017
Актуализация01.01.2019

Этот ГОСТ находится в:

Организации:

12.11.2015УтвержденМежгосударственный Совет по стандартизации, метрологии и сертификации82-П
15.12.2016УтвержденФедеральное агентство по техническому регулированию и метрологии2035-ст
ИзданСтандартинформ2017 г.
РазработанАО НТЦ Интернавигация

Global navigation satellite system. Road accident emergency response system. Data exchange protocol between in-vehicle emergency call device/system and emergency response system infrastructure

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

МЕЖГОСУДАРСТВЕННЫЙ СОВЕТ ПО СТАНДАРТИЗАЦИИ, МЕТРОЛОГИИ И СЕРТИФИКАЦИИ

(МГС)

ГОСТ

33465-

2015

INTERSTATE COUNCIL FOR STANDARDIZATION, METROLOGY AND CERTIFICATION (ISC)

МЕЖГОСУДАРСТВЕННЫЙ

СТАНДАРТ

Глобальная навигационная спутниковая система

СИСТЕМА ЭКСТРЕННОГО РЕАГИРОВАНИЯ ПРИ АВАРИЯХ

Протокол обмена данными устройства/системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях

Издание официальное

Москва

Стандартинформ

2017

Предисловие

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены в ГОСТ 1.0-2015 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2015 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1    РАЗРАБОТАН Некоммерческим партнерством «Содействие развитию и использованию навигационных технологий» и акционерным обществом «Научно-технический центр современных навигационных технологий «Интернавигация» (АО «НТЦ «Интернавигация»)

2    ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3    ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации по результатам голосования (протокол от 12 ноября 2015 г. № 82-П)

За принятие стандарта проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004—97

Код страны по МК(ИСО 3166) 004—97

Сокращенное наименование национального органа по стандартизации

Армения

AM

Минэкономики Республики Армения

Беларусь

BY

Госстандарт Республики Беларусь

Киргизия

KG

Кыргызстандарт

Россия

RU

Росстандарт

Таджикистан

TJ

Таджикстандарт

4    Приказом Федерального агентства по техническому регулированию и метрологии от 15 декабря 2016 г. № 2035-ст межгосударственный стандарт ГОСТ 33465-2015 введен в действие в качестве национального стандарта Российской Федерации с 1 января 2017 г.

5    Настоящий стандарт подготовлен на основе применения ГОСТ Р 54619-2011 1

6    ВВЕДЕН ВПЕРВЫЕ

Информация об изменениях к настоящему стандарту публикуется в ежегодном информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Таблица 3 — Состав пакета протокола транспортного уровня

Бит 7 Бит 6

Бит 5

Бит 4 Бит 3

Бит 2

Бит 1 Бит 0

Тип

Тип данных

Размер, байт

PRV (Protocol Version)

M

BYTE

1

SKID (Security Key ID)

М

BYTE

1

PRF (Prefix)

RTE

ENA

CMP

PR

М

BYTE

1

HL (Header Length)

М

BYTE

1

HE (Header Encoding)

М

BYTE

1

FDL (Frame Data Length)

М

USHORT

2

PID (Packet Identifier)

М

USHORT

2

PT (Packet Type)

М

BYTE

1

PRA (Peer Address)

О

USHORT

2

RCA (Recipient Address)

О

USHORT

2

TTL (Time To Live)

О

BYTE

1

HCS (Header Check Sum)

м

BYTE

1

SFRD (Services Frame Data)

о

BINARY

0 ... 65517

SFRCS (Services Frame Data Check Sum)

о

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 присутствуют в пакете. Данное поле устанавливает диспетчер той телематической платформы, на которой сгенерирован пакет, или УСВ, сгенерировавшая пакет для отправки на телематическую платформу (в случае установки в ней параметра FIOME_DISPATCFIER_ID, определяющего ее адрес, на который данная УСВ зарегистрирована). В случае отсутствия в УСВ параметра FIOME_DISPATCFIER_ID маршрутизация пакета производится по внутренним правилам диспетчера, обрабатывающего пакет

ENA (Encryption Algorithm)

Битовое поле определяет код алгоритма, используемый для шифрования данных из поля SFRD. Если поле имеет значение 0 0, то данные в поле SFRD не шифруются. Состав и коды алгоритмов не определены в данной версии протокола

Обозначение параметра (поля)

Назначение параметра (поля)

СМР

(Compressed)

Битовое поле определяет, используется ли сжатие данных из поля SFRD. Если поле имеет значение 1, то данные в поле SFRD считаются сжатыми. Алгоритм сжатия не определен в данной версии протокола

PR (Priority)

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

00    — наивысший;

01    — высокий;

10    — средний;

11    — низкий.

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

HL

Длина заголовка протокола транспортного уровня в байтах с учетом байта контрольной суммы (поля HCS)

HE

Определяет применяемый метод кодирования следующей за данным параметром части заголовка протокола транспортного уровня. Зарезервировано

FDL

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

PID

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

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 используется алгоритм CRC16—CCITT. Данное поле присутствует только в том случае, если есть поле SFRD. Пример программного кода расчета CRC-16 приведен в приложении Г.

SFRD

Структура данных, зависящая от типа пакета и содержащая информацию протокола уровня поддержки услуг

HCS

Контрольная сумма заголовка протокола транспортного уровня (начиная с поля PRV до поля HCS, не включая последнего). Для подсчета значения поля HCS ко всем байтам указанной последовательности применяется алгоритм CRC-8. Пример программного кода расчета CRC-8 приведен в приложении Д

5.6.1.4 Блок-схема алгоритма сборки пакета протокола транспортного уровня при приеме представлена на рисунке 2.

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)

О

BINARY

9 ... 65517

SDR 2

О

BINARY

9 ... 65517

SDRn

О

BINARY

9 ... 65517

Примечание — Структуры SDR 1, SDR 2, SDRn содержат информацию протокола уровня поддержки услуг. Таких структур в составе поля SFRD может быть одна или несколько, идущих одна за другой. Описание внутреннего состава структур представлено в разделе 6.

5.6.2.2 Структура данных пакета EGTS_PT_RESPONSE

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

9


Отправка

EGTS_PT_RESPONSE

V

( КОНЕЦ )


TTL=TTL-1, пересчет HCS, отправка на другую ТП


Код

EGTS_PC_U N S_PROTOCOL

Код

EGTS_PC_INC_HEADERFORM

Код

EGTS_PC_HEADERCRC_ERROR

Код

EGTS_PC_TTLEXPIRED


Код

EGTS_PC_OK

Код

EGTS_PC_DATACRC_ERROR

Код

EGTS_PC_DECRYPT_ERROR


А - маршрутизация и отправка пакета на другую ТП;

В - обработка данных протокола уровня поддержки услуг


Рисунок 2 — Блок-схема алгоритма сборки пакета протокола транспортного

уровня при приеме


Таблица 6 — Формат поля SFRD для пакета типа EGTS_PT_RESPONSE

Бит 7 Бит 6 Бит 5 Бит 4 Бит 3 Бит 2 Бит 1 Бит 0

Тип

Тип данных

Размер, байт

RPID (Response Packet ID)

М

USHORT

2

PR (Processing Result)

М

BYTE

1

SDR 1 (Service Data Record)

О

BINARY

9... 65514

SDR 2

О

BINARY

9... 65514

SDRn

О

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.

5.6.2.4    На каждый пакет типа EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA, поступающий от УСВ на телематическую платформу или от нее на УСВ, должен быть отправлен пакет типа EGTS_PT_RESPONSE, содержащий в поле РЮ номер пакета из пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA.

На рисунке 3 представлена последовательность обмена пакетами, при взаимодействии УСВ и телематической платформы.

Таблица 7— Формат поля SFRD для пакета типа EGTS_PT_SIGNED_APPDATA

Бит 7 Бит 6 Бит 5 Бит 4 БитЗ Бит 2 Бит 1 БитО

Тип

Тип данных

Размер, байт

SIGL (Signature Length)

М

USHORT

2

SIGD (Signature Data)

О

BINARY

0 ... 512

SDR 1 (Service Data Record)

О

BINARY

9... 65515

SDR 2

О

BINARY

9... 65515

SDRn

О

BINARY

9... 65515

Примечания

1    Параметр SIGL — определяет длину данных «цифровой подписи» из поля SIGD.

2    Параметр SIGD — содержит непосредственно данные «цифровой подписи».

3    Структуры SDR 1, SDR 2, SDRn - структуры, содержащие информацию уровня поддержки услуг. Таких структур может быть одна или несколько, идущих одна за другой.

11

AC


Пакет РТ APPDATAPID=1 (Авторизация)


>



Рисунок 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)

М

1

SMSC_AT (SMSC Address Type)

О

0,1

SMSC_A (SMSC Address)

О

0,6

TP_RP

TPJJDHI

TP_SRR

TP_VPF

TP_RD

TP_MTI

М

1

TP_MR (MessageReference)

М

1

TP_DA_L (Destination Address Length)

М

1

TP_DA_T (Destination Address Type)

м

1

Бит 7 Бит 6 Бит 5 Бит 4 Бит 3 Бит 2 Бит 1 Бит 0

Тип

Размер, байт

TP_DA (Destination Address)

M

6

TP_PID (Protocolldentifier)

M

1

TP_DCS (Data Coding Schema)

M

1

TP_VP (ValidityPeriod)

О

0, 1, 7

TPJJDL (User Data Length)

M

1

TPJJD (UserData)

О

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 может принимать следующие значения:

а)    ООО — неизвестный;

б)    001 — международный формат;

в)    010 — национальный формат;

г)    011 —специальный номер, определяемый сетью;

д)    100 — номер абонента;

е)    101 — буквенно-цифровой код (коды согласно [5] с 7-битной кодировкой по умолчанию);

ж)    110 — укороченный;

и) 111 —зарезервировано.

-    NPI (NumericPIanldentification) — тип плана нумерации (применимо для значений поля TON- 000,001,010). NPI может принимать следующие значения:

а)    0000 — неизвестный;

б)    0001 — план нумерации ISDN телефонии;

в)    0011 — план нумерации при передаче данных;

г)    0100 — телеграф;

д)    1000 — национальный;

е)    1001 — частный;

ж)    1111 —зарезервировано.

Поле опциональное и наличие его зависит от значения параметра SMSC_AL (если значение SMSC_AL больше 0, то данное поле присутствует);

-    SMSC_A — адрес SMSC. Каждая десятичная цифра номера представлена в виде четырех бит (младшие 4 бита — цифра более старшего разряда, старшие 4 бита — цифра меньшего разряда), при этом, если число цифр в номере нечетное, то в битах с 4 по 7 последнего байта номера устанавливается значение OxF (1111b). Данный параметр опциональный и его наличие зависит от значения параметра SMSC_AL. В случае отсутствия параметра SMSC_A, используется SMSC из SIM-карты;

-    ТР_МТ1 — (Message Type Indicator) тип сообщения (должен содержать бинарное значение 01);

-    TP_RD — (Reject Duplicates) поле определяет, необходимо ли SMSC принимать данное сообщение на обработку, если существует предыдущее необработанное отправленное с данного номера сообщение, которое имеет такое же значение поля TP_MR и такой же номер получателя в поле TP_DA;

13

- 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, то требуется подтверждение);

-TPJJDHI — (User Data Header Indicator) поле определяет, передается ли заголовок пользовательских данных TPJJDJHEADER (если поле имеет значение 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;

-    TPJJDL — длина данных сообщения из поля TP_DL, в байтах для используемой 8-битной кодировки;

-    TPJJD — непосредственно передаваемые пользовательские данные. Формат данного поля в зависимости от значения поля TPJJDHI представлен в таблице 11.

Таблица 11—Формат поля TPJJD

Бит 7 Бит 6 Бит 5 Бит 4 Бит 3 Бит 2 Бит 1 Бит 0

Тип

Размер, байт

LUDH (Length of User Data Header)

О

1

IEI «А» (Information-Element-ldentifier «А»)

О

1

LIE «А» (Length of Information-Element «А»)

О

1

IED «А» (Information-Element-Data of «А»)

О

1 ... п

IEI «В» (Information-Element-Identifier «В»)

О

1

LIE «В» (Length of Information-Element «В»)

О

1

IED «В» (Information-Element-Data of «В»)

О

1 ... п

IEI «N» (Information-Element-Identifier «N»)

О

1

LIE «N» (Length of Information-Element «N»)

О

1

IED «N» (Information-Element-Data of «N»)

О

1 ... п

UD (User Data)

М

1... 140

ГОСТ 33465-2015

Параметры поля TPJJD, приведенные в таблице 11, имеют следующие назначения:

-    LUDH —длина заголовка пользовательских данных в байтах без учета размера данного поля;

-    IEI «А», IEI «В» , IEI «N» — идентификатор информационного элемента «А», «В» и «N» соответственно, который определяет тип информационного элемента и может принимать следующие значения (в шестнадцатеричной системе):

а)    00 — часть конкатенируемого SMS-сообщения;

б)    01 — индикатор специального SMS-сообщения;

в)    02 — зарезервировано;

г)    03 — не используется;

д)    04 — 7F— зарезервировано;

е)    80 — 9F— для специального использования SME;

ж)    АО — BF— зарезервировано;

и)    СО — DF— для специального использования SC;

к)    Е0 — FF— зарезервировано.

-    LIE «А», LIE «В», LIE «N» — параметры, определяющие размер данных информационных элементов «А», «В» и «N» соответственно в байтах без учета размера данного поля;

-    IED «А», IED «В» , IED «N» —данные информационных элементов «А», «В» и «N» соответственно;

-    UD — данные пользователя. Размер данного поля определяется наличием заголовка пользовательских данных TP_UD_HEADER, состоящего из полей LUDH, IEI, LIE, IED. Если заголовок не передается, то размер равен значению поля TPJJDL, указанного в таблице 8. Если заголовок передается, то размер поля вычисляется, как разность (TPJJDL — 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)

М

1

MNSM (Maximum Number of Short Messages)

М

1

SNCSM (Sequence Number of Current Short Message)

М

1

Примечания

1    CSMRN — номер конкатенируемого SMS-сообщения должен иметь одинаковое значение для всех частей длинного SMS-сообщения.

2    MNSM — общее число сообщений, из которых состоит длинное SMS. Должен содержать значения в диапазоне от 1 до 255.

3    SNCSM — номер передаваемой части длинного SMS-сообщения. Инкрементируется при отправке каждой новой части длинного сообщения. Должен содержать значение в диапазоне от 1 до 255. Если значение данного поля превышает значение из поля MNSM или равно нулю, то принимающая сторона должна игнорировать весь информационный элемент.

5.7.2 Описание формата передаваемой информации

5.7.2.1 При использовании SMS для обмена данными между УСВ и телематической платформой пакеты, упакованные по правилам протокола транспортного уровня и протокола уровня поддержки услуг, помещаются в поле TPJJD (см. таблицу 8), при этом полный размер пакета протокола не должен превышать 140 байт. В этом случае механизм авторизации не используется и подтверждения протокола транспортного уровня в виде пакета типа EGTS_PT_RESPONSE и уровня поддержки услуг в виде подзаписи EGTS_SR_RECORD_RESPONSE на переданные пакеты не требуются. Признаком успешного прохождения пакета до УСВ является уведомление о доставке SMS.

На подзапись EGTS_SR_COMMAND_DATA сервиса EGTS_COMMAND_SERVICE, содержащую команду или сообщение, требуется подтверждающая подзапись EGTS_SR_COMMAND_DATA с соответствующим значением полей СТ (CommandType) и ССТ (CommandConfirmationType). В случае отправки команды на УСВ через SMS соответствующий пакет EGTS, содержащий подтверждение о приеме команды в виде подзаписи EGTS_SR_COMMAND_DATA, должен быть передан с УСВ через SMS.

15

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

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

6 Протокол уровня поддержки услуг (общая часть)

6.1    Назначение протокола уровня поддержки услуг

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

6.1.2    Протокол уровня поддержки услуг выполняет следующие основные функции:

-    обмен информационными сообщениями, содержащими данные для обработки различными сервисами, а также запросы на выдачу информации сервисами;

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

-    идентификация принадлежности данных определенному типу сервиса;

-    определение характеристик данных (число, тип, состав, размер, кодировка и др.).

6.2    Обмен информационными сообщениями

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

ГОСТ 33465-2015

Содержание

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

2    Нормативные ссылки..................................................................1

3    Термины, определения и сокращения....................................................1

4    Общие положения....................................................................3

5    Протокол транспортного уровня.........................................................4

5.1    Назначение протокола транспортного уровня..........................................4

5.2    Обеспечение маршрутизации.......................................................4

5.3    Механизм проверки целостности данных..............................................4

5.4    Обеспечение надежности доставки пакетов данных.....................................5

5.5    Описание типов данных, используемых в протоколе транспортного уровня.................5

5.6    Описание структур данных, используемых в протоколе транспортного уровня...............6

5.7    Описание структуры данных при использовании SMS в качестве резервного канала передачи

данных.........................................................................12

5.8    Временные и количественные параметры протокола транспортного уровня при использовании

пакетной передачи данных........................................................16

6    Протокол уровня поддержки услуг (общая часть)..........................................16

6.1    Назначение протокола уровня поддержки услуг.......................................16

6.2    Обмен информационными сообщениями.............................................16

6.3    Обеспечение уведомления о результате доставки и обработки данных уровня поддержки

услуг...........................................................................17

6.4    Идентификация принадлежности данных, используемых в протоколе уровня поддержки услуг. .17

6.5    Определение характеристик данных в протоколе уровня поддержки услуг.................17

6.6    Структуры данных, используемые в протоколе уровня поддержки услуг...................17

6.7    Описание сервисов предоставления услуг............................................20

6.8    Временные и количественные параметры протокола уровня поддержки услуг

при использовании пакетной передачи данных........................................42

7    Сервис экстренного реагирования при аварии протокола уровня поддержки услуг..............42

8    Формат сообщения AL-ACK...........................................................52

Приложение А (справочное) Описание принципа построения навигационно-информационной

системы на основе протокола транспортного уровня...........................53

Приложение Б (справочное) Анализ протокола транспортного уровня на основе концепции NGTP . .55

Приложение В (обязательное) Коды результатов обработки..................................56

Приложение Г (справочное) Пример реализации алгоритма расчета контрольной суммы CRC16

на языке С/*............................................................58

Приложение Д (справочное) Пример реализации алгоритма расчета контрольной суммы CRC8

на языке С/*............................................................59

Приложение Е (справочное) Таблицы кодировки символов...................................60

Библиография........................................................................63

ГОСТ 33465-2015

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

6.3    Обеспечение уведомления о результате доставки и обработки данных уровня

поддержки услуг

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

6.4    Идентификация принадлежности данных, используемых в протоколе уровня

поддержки услуг

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

6.5    Определение характеристик данных в протоколе уровня поддержки услуг

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

6.6    Структуры данных, используемые в протоколе уровня поддержки услуг

6.6.1 Общая структура

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

Данные уровня поддержки услуг

Запись RID = 1

Запись RID = 2

Запись RID = N

Рисунок 4 — Общая структура данных уровня поддержки услуг

6.6.2 Структура отдельной записи

6.6.2.1 Состав записи

Отдельная запись протокола уровня поддержки услуг состоит из заголовка записи и данных записи. Состав отдельной записи представлен на рисунке 5.

Заголовок записи

Данные записи

Подзапись 1

Подзапись N

Рисунок 5 — Состав отдельной записи уровня поддержки услуг

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

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

6.6.2.2 Структура записи

Структура отдельной записи уровня поддержки услуг приведена в таблице 14.

17

Введение

Настоящий стандарт входит в комплекс стандартов «Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях» и является одним из базовых стандартов комплекса.

Система экстренного реагирования при авариях предназначена для снижения тяжести последствий дорожно-транспортных происшествий и иных происшествий на дорогах посредством уменьшения времени доведения информации об указанных происшествиях до экстренных оперативных служб. В Республике Беларусь система экстренного реагирования при авариях называется «ЭРА-РБ», в Республике Казахстан — «ЭВАК», в Российской Федерации — «ЭРА-ГЛОНАСС». Аналогом указанных систем является разрабатываемая общеевропейская система eCall, с которой вышеуказанные системы гармонизированы по основным функциональным свойствам (использование тонального модема как основного механизма передачи данных; унифицированные состав и формат обязательных данных, передаваемых в составе минимального набора данных о дорожно-транспортном происшествии, единообразные правила установления и завершения двустороннего голосового соединения с лицами, находящимися в кабине транспортного средства и др.).

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

Настоящий стандарт предоставляет все необходимые данные о формате и правилах передачи сообщений и должен использоваться для разработки подсистем передачи данных на стороне устрой-ства/системы вызова экстренных оперативных служб и оператора системы экстренного реагирования при авариях.

Основные положения настоящего стандарта взаимоувязаны с основополагающим стандартом комплекса стандартов «Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях».

В настоящем стандарте учтены основные положения соответствующих региональных (европейских) и международных стандартов и международных документов по стандартизации:

-    по сетевой модели взаимодействия открытых систем — в части используемых протоколов транспортного и сетевого уровня для передачи данных между усгройством/системой вызова экстренных оперативных служб и оператором системы;

-    по общеевропейской системе безопасности в экстренных ситуациях eCall — в части состава передаваемого устройством/системой вызова экстренных оперативных служб минимального набора данных;

-    по мобильной (подвижной связи) — в части передачи данных с использованием SMS-сообщений.

Настоящий стандарт предназначен для использования:

-    производителями устройств/систем экстренного реагирования при авариях;

-    автопроизводителями;

-    оператором системы экстренного реагирования при авариях;

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

IV

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Глобальная навигационная спутниковая система СИСТЕМА ЭКСТРЕННОГО РЕАГИРОВАНИЯ ПРИ АВАРИЯХ

Протокол обмена данными устройства/системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях

Global navigation satellite system. Road accident emergency response system. Data exchange protocol between in-vehicle emergency call device/system and emergency response system infrastructure

Дата введения — 2017—01—01

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

Настоящий стандарт распространяется на устройства и системы вызова экстренных оперативных служб, предназначенные для установки на колесные транспортные средства категорий М и N в соответствии с требованиями технического регламента [1].

Настоящий стандарт устанавливает требования к протоколам обмена данными между устрой-ством/системой вызова экстренных оперативных служб и инфраструктурой системы вызова экстренных оперативных служб (далее — система), включая требования к протоколу обмена данными, связанными с предоставлением системой базовой услуги в целях выполнения требований технического регламента [1] и ГОСТ 33464.

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

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

ГОСТ 33464-2015 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Устройство/система вызова экстренных оперативных служб. Общие технические требования

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по соответствующим ежемесячным информационным указателям, опубликованным в текущем году. Если ссылочный стандарт заменен (изменен), то при пользовании настоящим стандартом следует руководствоваться заменяющим (измененным) стандартом. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3    Термины, определения и сокращения

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

В настоящем стандарте применены термины по ГОСТ 33464, а также следующие термины с соответствующими определениями:

3.1.1    минимальный набор данных; МНД: Набор данных, передаваемый устройством/системой вызова экстренных оперативных служб при дорожно-транспортном происшествии и включающий в себя информацию о координатах и параметрах движения аварийного транспортного средства и вре-

Издание официальное

мени аварии, VIN-коде транспортного средства и другую информацию, необходимую для экстренного реагирования.

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

3.1.3    протокол передачи данных: Набор правил и соглашений, определяющих содержимое, формат, параметры времени, последовательность и проверку ошибок в сообщениях, которыми обмениваются сетевые устройства.

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

3.1.5    система экстренного реагирования при авариях: Федеральная государственная территориально-распределенная автоматизированная информационная система, обеспечивающая оперативное получение с использованием сигналов глобальной навигационной спутниковой системы ГЛОНАСС совместно с другой действующей ГНСС информации о дорожно-транспортных происшествиях и иных чрезвычайных ситуациях на автомобильных дорогах, обработку, хранение и передачу этой информации экстренным оперативным службам, а также доступ к указанной информации заинтересованных государственных органов, органов местного самоуправления, должностных лиц, юридических и физических лиц.

Примечание — В Республике Беларусь система экстренного реагирования при авариях называется «ЭРА-РБ», в Республике Казахстан — «ЭВАК», в Российской Федерации — «ЭРА-ГЛОНАСС». Аналогом вышеуказанных систем является разрабатываемая общеевропейская система eCall, с которой эти системы гармонизированы по основным функциональным свойствам (использование тонального модема как основного механизма передачи данных; унифицированные состав и формат обязательных данных, передаваемых в составе минимального набора данных о дорожно-транспортном происшествии, единообразные правила установления и завершения двустороннего голосового соединения с лицами, находящимися в кабине транспортного средства и др.).

3.1.6    система вызова экстренных оперативных служб; СВ: Система, выполняющая функции устройства вызова экстренных оперативных служб, обеспечивающая передачу сообщения о транспортном средстве при дорожно-транспортном и ином происшествиях в автоматическом режиме.

Примечания

1    Система вызова экстренных оперативных служб позволяет осуществлять передачу сообщения о транспортном средстве при дорожно-транспортном и ином происшествиях также и в ручном режиме.

2    Категории транспортных средств, подлежащих оснащению системами вызова экстренных оперативных служб, установлены в [1].

3.1.7    устройство вызова экстренных оперативных служб; УВ: Устройство, осуществляющее и обеспечивающее определение координат, скорости и направления движения транспортного средства с помощью сигналов не менее двух действующих глобальных навигационных спутниковых систем, передачу сообщения о транспортном средстве при дорожно-транспортном и ином происшествиях в ручном режиме и двустороннюю голосовую связь с экстренными и оперативными службами по сетям подвижной радиотелефонной связи.

Примечания

1    Устройство вызова экстренных оперативных служб может осуществлять передачу сообщения о транспортном средстве при дорожно-транспортном и ином происшествиях также и в автоматическом режиме. Типы аварий транспортного средства, определяемых автоматически, а также сроки реализации устройством функции автоматической передачи сообщения о транспортном средстве установлены в [1].

2    Категории транспортных средств, подлежащих оснащению устройствами вызова экстренных оперативных служб, установлены в [1].

3.2 Сокращения

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

НИС    —    навигационно-информационные системы;

ОЗУ    —    оперативное запоминающее устройство;

ПО    —    программное обеспечение;

ППУ    —    протокол уровня поддержки услуг;

2

ГОСТ 33465-2015

ПТУ

тп

тс

УСВ

Цифровая

подпись

ЭРА

СР-1251

CRC-8(16)

DNS

eCall

EGTS

FTP

IP

GSM

HTTP

IMAP

ISDN

Little-endian

NGTP

OSI

PDU

POP3

SC

SIM

SME

SMS

SMSC

SMTP

TCP

TFTP

telnet

UDP

—    протокол транспортного уровня;

—    телематическая платформа;

—    транспортное средство;

—    устройство/система вызова экстренных оперативных служб;

—    информация в электронной форме, которая используется для идентификации отправителя данных;

—    экстренное реагирование при авариях;

—    набор символов и кодировка, являющаяся стандартной 8-битной кодировкой для всех русских версий Microsoft Windows;

—    циклический избыточный код;

—    система доменных имен;

—    общеевропейская система экстренного реагирования при авариях;

—    телематический стандарт для системы экстренного реагирования при авариях;

—    протокол передачи файлов;

—    протокол Интернет;

—    глобальный цифровой стандарт для мобильной сотовой связи;

—    протокол передачи гипертекста;

—    протокол прикладного уровня для доступа к электронной почте;

—    цифровая сеть с интеграцией обслуживания;

—    младший байт вперед (порядок следования байт);

—    телематический протокол следующего поколения. Архитектура и концепция построения;

—    базовая эталонная модель взаимодействия открытых систем — абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов;

—    элемент описания протокола;

—    протокол почтового отделения, версия 3;

—    сервис-центр, ответственный за обработку, хранение и передачу SMS-сообщений получателям;

—    модуль идентификации абонента;

—    объекты, способные отправлять и получать SMS-сообщения;

—    сервис коротких сообщений;

—    центр обработки коротких сообщений;

—    простой протокол передачи почты;

—    протокол управления передачей;

—    простой протокол передачи файлов;

—    сетевой протокол для реализации текстового интерфейса по сети;

—    протокол пользовательских дейтаграмм.

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

4.1    Сетевая модель взаимодействия открытых систем согласно [2] определяет следующие уровни обмена данными:

-    физический;

-    канальный;

-    сетевой;

-    транспортный;

-    сеансовый;

-    представления данных и приложений.

4.2    В терминах сетевой модели OSI в системе экстренного реагирования при авариях для передачи данных между УСВ и оператором системы используются следующие протоколы:

-    TCP — транспортный уровень;

-    IP — сетевой уровень.

3

Соответствие сетевой модели OSI, стека протоколов TCP/IP и протоколов передачи данных системы экстренного реагирования при авариях представлено в таблице 1.

Таблица 1 — Соответствие уровней модели OSI, стека протоколов TCP/IP и протоколов системы

Модель OSI

Стек протоколов TCP/IP

Протоколы

TCP/IP

Протоколы системы

Номер уровня

Название уровня

Номер уровня

Название уровня

7

Приложений

4

Приложений

FTP, HTTP, POP3, IMAP, telnet, SMTP, DNS, TFTP

Уровень поддержки услуг

6

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

данных

5

Сеансовый

Транспортный уровень

4

Транспортный

3

Транспортный

TCP, UDP

TCP

3

Сетевой

2

Межсетевой

IP

IP

2

Канальный

1

Доступ к сети

1

Физический

4.3    Настоящий стандарт устанавливает требования к следующим видам протоколов обмена информацией между элементами системы экстренного реагирования при авариях:

-    протокол транспортного уровня;

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

4.4    Настоящий стандарт также устанавливает требования к формату сообщения AL-ACK, которое высылается посредством использования тонального модема [3].

5 Протокол транспортного уровня

5.1    Назначение протокола транспортного уровня

5.1.1    Протокол транспортного уровня предназначен для обеспечения маршрутизации информации протокола уровня поддержки услуг между пунктами инфраструктуры системы экстренного реагирования при авариях и УСВ, использующих данный протокол, проверки целостности и правильной последовательности данных, а также обеспечения надежности доставки до пункта назначения.

5.1.2    Описание принципа построения системы на основе протокола транспортного уровня приведено в приложении А.

5.1.3    Анализ протокола транспортного уровня на основе концепции NGTP приведен в приложении Б.

5.2    Обеспечение маршрутизации

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

5.3    Механизм проверки целостности данных

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

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

4

ГОСТ 33465-2015

поля и алгоритмы обеспечения контроля целостности. При этом используется механизм, основанный на подсчете контрольной суммы, передаваемой последовательности байт (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.

5.5.2    Многобайтовые типы данных USHORT, UINT, ULONG, FLOATnDOUBLE используют порядок следования байт little-endian (младший байт вперед). Байты, составляющие последовательность в типах STRING и BINARY, должны интерпретироваться как есть, т. е. обрабатываться в порядке их поступления.

5.5.3    В протоколе транспортного уровня определены следующие типы полей и параметров:

-    М (mandatory) — обязательный параметр. Параметр должен передаваться всегда;

-    О (optional) — необязательный. Параметр может не передаваться, и его присутствие определяется другими параметрами, входящими в пакет.

Таблица 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

Целое число со знаком

Окончание таблицы 2

Тип данных

Размер, байт

Диапазон значений

Описание

INT

4

-2147483648... +2147483647

Целое число со знаком

FLOAT

4

± 1,2 Е —38 ... 3,4 Е + 38

Дробное число со знаком в соответствии с [4]

DOUBLE

8

± 2,2 Е —308 ... 1,7 Е + 308

Дробное число со знаком в соответствии с [4]

STRING

Переменный. Размер определяется внешними параметрами или применением специального символа-терминатора (код 0x00)

Содержит последовательность печатных символов в кодировке по умолчанию СР-1251, если явно не указана другая кодировка (при помощи дополнительного параметра)

BINARY

Переменный. Размер определяется внешними параметрами

Содержит последовательность данных типа BYTE

ARRAYOFTYPE

Переменный. Размер определяется внешними параметрами

Может содержать последовательность одного из вышеуказанных типов (TYPE), кроме BINARY. Порядок следования байт и размер каждого элемента используемого типа определяется самим типом. Экземпляры типов идут последовательно один за другим. Например: ARRAY OF STRING содержит в своем составе 10 экземпляров типа STRING, при этом размер каждого экземпляра определяется разделителем (код 0x00), который должен присутствовать между экземплярами

5.6 Описание структур данных, используемых в протоколе транспортного уровня

5.6.1    Общая структура пакета протокола транспортного уровня определяется составом пакета и его форматом.

5.6.1.1    Пакет протокола транспортного уровня состоит из заголовка, поля «данные уровня поддержки услуг», а также поля контрольной суммы «данных уровня поддержки услуг».

Состав пакета протокола транспортного уровня представлен на рисунке 1.

Заголовок протокола

Данные уровня поддержки

Контрольная сумма данных уровня

транспортного уровня

услуг

поддержки услуг

Рисунок 1 — Состав пакета протокола транспортного уровня

5.6.1.2 Общая длина пакета протокола транспортного уровня не превышает значения 65535 байт, что соответствует максимальному значению параметра Window Size (максимальный размер целого пакета, принимаемый на стороне приемника) заголовка протокола TCP. Такое значение максимального размера пакета позволяет более эффективно использовать каналы передачи данных, базируясь только на стандартном методе управления потоком данных, заложенном в протоколе TCP/IP [3].

Формат пакета транспортного уровня представлен в таблице 3.

6

1

Приказом Федерального агентства по техническому регулированию и метрологии от 15 декабря 2016 г. № 2035-ст национальный стандарт ГОСТ Р 54619-2011 отменен с 1 июня 2017 г.

© Стандартинформ, 2017

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