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

89 страниц

563.00 ₽

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

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

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

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

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

Распространяется на систему экстренного реагирования при авариях «ЭРА-ГЛОНАСС». Стандарт устанавливает требования к протоколам обмена данными между автомобильной системой/устройством вызова экстренных оперативных служб и инфраструктурой системы «ЭРА-ГЛОНАСС», включая требования к протоколу обмена данными, связанными с предоставлением системой «ЭРА-ГЛОНАСС» базовой услуги по ГОСТ Р 54721 в целях выполнения требований технического регламента [6] и ГОСТ Р 54620.

  Скачать PDF

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

Действие завершено 01.01.2019

Оглавление

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 Сервис экстренного реагирования при аварии протокола уровня поддержки услуг

     7.1 Назначение сервиса экстренного реагирования при аварии

     7.2 Минимально необходимый набор функций АС для использования услуги EGTS_ECALL_SERVICE

     7.3 Состав и описание подзаписей сервиса EGTS_ECALL_SERVICE

     7.4 Использование сервиса EGTS_COMMANDS_SERVICE

     7.5 Список и описание команд, параметров и подтверждений при использовании сервиса EGTS_ECALL_SERVICE

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

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

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

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

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

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

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

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

Показать даты введения Admin

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

Стр. 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

ГОСТ Р 54619— 2011

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

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

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

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

Москва

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

2013

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения стандартов организаций — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

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

1    РАЗРАБОТАН Открытым акционерным обществом «Навигационно-информационные системы» (ОАО «НИС»)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 363 «Радионавигация»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 8 декабря 2011 г. № 754-ст

4    В настоящем стандарте учтены основные нормативные положения следующих международных

документов:

-    Технические требования (TS) Европейского института стандартов электросвязи (European Telecommunications Standards Institute, ETSI) и партнерской Ассоциации групп телекоммуникационных компаний (3rd Generation Partnership Project (3GPP) к системе и протоколам передачи данных применительно к общеевропейской системе eCall;

-    Технические требования (TS) Европейского института стандартов электросвязи (European Telecommunications Standards Institute, ETSI) к цифровым телекоммуникационным сетям в части сервиса отправки и приема коротких сообщений

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

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

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

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

Таблица 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 присутствуют в пакете. Данное поле устанавливает диспетчер той телематической платформы, на которой сгенерирован пакет, или АС, сгенерировавшая пакет для отправки на телематическую платформу, в случае установки в ней параметра «HOME DISPATCHERJD», определяющего ее адрес, по которому данная АС зарегистрирована

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

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

Поле РТ может принимать следующие значения:

0    — EGTS_PT_RESPONSE (подтверждение на протокол транспортного уровня);

1    — EGTS_PT_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг);

2    — EGTS_PT_SIGNED_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг с цифровой подписью)

PRA

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

RCA

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

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

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

TTL

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

HCS

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

SFRD

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

SFRCS

Контрольная сумма.

Для подсчета контрольной суммы по данным из поля SFRD используется алгоритм CRC-16—CCITT. Данное поле присутствует только в том случае, если есть поле SFRD. Пример программного кода расчета CRC-16 приведен в приложении Г

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

5.6.2 Структуры данных в зависимости от типа пакета

В зависимости от типа пакета протокола транспортного уровня структура поля SFRD имеет различный формат.

5.6.2.1    Структура данных пакета EGTSPTAPPDATA

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

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

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

5.6.2.3    Структура данных пакета EGTSPTSIGNEDAPPDATA

Пакет данного типа применяется для передачи помимо структур, содержащих информацию уровня поддержки услуг, также информацию о «цифровой подписи», идентифицирующей отправителя данного пакета. Структура данных поля SFRD пакета EGTS_PT_SIGNED_APPDATA представлена в таблице 7.

5.6.2.4    На каждый пакет типа EGTS PT APPDATA или EGTS PT SIGNED APPDATA, поступающий от АС на телематическую платформу или от нее на АС, должен быть отправлен пакет типа EGTS PT RESPONSE, содержащий в поле PID номер пакета из пакета EGTS PT APPDATA или EGTS РТ SIGNED APPDATA.

9

ГОСТ P 54619—2011


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


А — маршрутизация и отправка пакета на другую телематическую платформу; В — обработка данных протокола уровня

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


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

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

Бит 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...65517

SDR 2

О

BINARY

9...65517

SDRn

О

BINARY

9...65517

Примечания

1    Параметр RPID — идентификатор пакета транспортного уровня, подтверждение на который формируется.

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

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

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

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

Тип

Тип данных

Размер, байт

SIGL(Signature Length)

М

SHORT

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 — структуры, содержащие информацию уровня поддержки услуг Таких структур может быть одна или несколько, идущих одна за другой.

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


АС


ТП


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


Пакет РТ RESPONSE на PID1 = 1 (подтверждение авторизации)


■*


Пакет РТ APPDATAPID = 2 (телематические данные)


Пакет РТ RESPONSE на PID = 2 (подтверждение телематических данных)


Пакет РТ APPDATAPID = п (команда)


Пакет РТ RESPONSE на PID = п (подтверждение пакета с командой)




Рисунок 2 — Взаимодействие АС и телематической платформы на уровне пакетов транспортного уровня

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

передачи данных

5.7.1    Структура SMS-сообщения

При использовании SMS для передачи пакетов данных протокола транспортного уровня используется режим PDU [2], [3]. Режим PDU позволяет передавать не только текстовую, но и бинарную информацию через сервис SMS оператора сотовой связи GSM. Описываемый протокол транспортного уровня оперирует бинарными данными, поэтому режим PDU наиболее подходит для использования SMS в качестве резервного канала передачи транспортного уровня.

5.7.1.1    Для передачи SMS-сообщения используется 8-битовая кодировка. Формат SMS-сообщения для отправки в режиме PDU представлен в таблице 8 и использует структуру, описанную в [3, раздел 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

TPUDHI

TP_SRR

TP_VPF

TP_RD

TP_MTI

м

1

TP_MR (Message Reference)

м

1


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

Тип

Размер, байт

TP_DA_L (Destination Address Length)

M

1

TP_DA_T (Destination Address Type)

M

1

TP_DA (Destination Address)

M

6

TP PID (Protocol Identifier)

M

1

TPJDCS (Data Coding Schema)

M

1

TP_VP (Validity Period)

0

0, 1, 7

TPJJDL (User Data Length)

M

1

TP UD (User Data)

0

0...140

5.7.1.2 Описание параметров, входящих в состав SMS-сообщения в режиме PDU, приведено ниже:

-    SMSC_AL — длина полезных данных адреса SMSC в октетах;

-    SMSC_AT — тип формата адреса SMSC.

Возможные значения параметров SMSC AT представлены в таблице 10. Поле опциональное и наличие его зависят от значения параметра SMSCAL (если значение SMSC_AL больше 0, то данное поле

присутствует);

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

-    TP MTI (Message Type Indicator) — тип сообщения (должен содержать бинарное значение 01);

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

-    TP_VPF (Validity Period Format) — формат параметра TP_VP. Возможные значения поляТР УРР представлены в таблице 9;

-    TP_SRR (Status Report Request) — поле определяет необходимость отправки подтверждения со стороны SMSC на данное сообщение (если данный бит имеет значение 1, то требуется подтверждение);

-    TPJJDHI (User Data Header Indicator) — поле определяет, передается ли заголовок пользовательских данных TP_UD_HEADER (если поле имеет значение 1, то заголовок присутствует);

-    TP RP (Reply Path) — поле определяет, присутствует ли поле RP в сообщении;

-    TP MR — идентификатор сообщения (должен увеличиваться на 1 при каждой отправке нового сообщения);

-    TP_DA_L — длина полезных данных адреса получателя в октетах;

-    TP_DA_T—тип формата адреса получателя. Возможные значения параметров TPDAT и SMSCAT представлены в таблице 10;

-    TP_DA — адрес получателя. Кодировка номера проводится по тем же правилам, что и в параметре SMSCA;

-    ТР_РЮ — идентификатор протокола (должен содержать значение 00);

-    TP_DCS — тип кодировки данных (должен содержать значение 0x04, определяющее 8-битную кодировку сообщения, отсутствие компрессии);

-    TP_VP — время актуальности данного сообщения. Формат данного поля определяется значением из таблицы 9. Параметр является опциональным. Его наличие и размер зависят от значения поля TP_VPF;

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

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

13

Таблица 9 — Формат поля TP_VP в зависимости от значения поля TP_VPF

Значение битов

Описание

0

0

Поле TP_VP не передается

1

0

Поле TP_VP имеет формат «относительное время» и размер 1 байт

0

1

Поле TP_VP имеет формат «расширенное время» и размер 7 байт

1

1

Поле TP_VP имеет формат «абсолютное время» и размер 7 байт

Таблица 10 — Формат полей TP_DA_T и SMSC_AT (тип адреса)

Бит 7

Бит 6

Бит 5

Бит 4

Бит 3

Бит 2

Бит 1

Бит 0

Размер, байт

1

TON

NPI

1

Параметры полей TP_DA_T и SMSC_AT, приведенные в таблице 10, имеют следующее назначение:

-    TON (Type Of Number) — тип номера. Параметр TON может принимать следующие значения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бит 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-ldentifier «В»)

о

1

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

о

1

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

о

1...П

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

о

1

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

о

1

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

о

1...П

UD (User Data)

м

1 ...140

ГОСТ P 54619—2011

Параметры поля TP_UD, приведенные в таблице 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 «14» — параметры, определяющие размер данных информационных элементов «А», «В» и «14» соответственно, в байтах, без учета размера данного поля;

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

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

В случае если идентификатор информационного элемента IEI заголовка пользовательских данных TP_UDJHEADER имеет значение 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 для обмена данными между АС и телематической платформой пакеты, упакованные по правилам протокола транспортного уровня и протокола уровня поддержки услуг, помещаются в поле TP_UD (см. таблицу 8), при этом полный размер пакета протокола не должен превышать 140 байт. В этом случае механизм авторизации не используется и подтверждение на переданные пакеты не требуется. После успешной отправки SMS информация считается доставленной.

5.7.2.2    Для отправки SMS, содержащего цифровую подпись, используется пакет транспортного уровня типа EGTS_PT_SIGNED_APPDATA.

5.7.2.3    В случае если размер пакета данных протокола превышает 140 байт, используется механизм конкатенации SMS-сообщений, который определен в [3, подпункт 9.2.3.24.1]. Суть данного механизма

15

состоит в том, что передаваемые пользовательские данные разбиваются на части и отправляются отдельными SMS-сообщениями. При этом каждое такое сообщение содержит специальную структуру, определяющую общее количество частей передаваемых данных и порядок их сборки на принимающей стороне. В качестве такой структуры используется поле TPUDHEADER, которое содержит информационный элемент, характеризующий часть конкатенируемого SMS-сообщения. Таким образом, исходя из размера заголовка данных пользователя и максимального числа частей длинного сообщения, равного 255, максимально возможный размер пакета при использовании 8-битной кодировки может составлять 255 (140-6) = 34170 байт.

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    Обмен информационными сообщениями

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

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

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

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

ГОСТ P 54619—2011

Содержание

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

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

3    Термины, определения, обозначения и сокращения........................ 2

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    Обеспечение уведомления о результатах доставки и обработки данных уровня поддержки

услуг............................................. 16

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

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

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

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

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

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

7.1    Назначение сервиса экстренного реагирования при аварии.................. 42

7.2 Минимально необходимый набор функций АС для использования услуги EGTS_ECALL_SERVICE    42

7.3    Состав и описание подзаписей сервиса EGTS ECALL SERVICE............... 42

7.4    Использование сервиса EGTS COMMANDS SERVICE.................... 47

7.5    Список и описание команд, параметров и подтверждений при использовании сервиса

EGTS_ECALL_SERVICE.................................... 48

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

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

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

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

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

языке СГ...................................... 58

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

языке СГ...................................... 59

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

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

ГОСТ P 54619—2011

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

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

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

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

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

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

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

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

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

Запись RID = 1

Запись RID = 2

Запись RID = N

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

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

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

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

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

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

Подзапись 1

Подзапись N

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

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

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

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

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

Таблица 14 — Формат отдельной записи протокола уровня поддержки услуг

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

Тип

Тип данных

Размер, байт

RL (Record Length)

M

USHORT

2

RN (Record Number)

M

USHORT

2

17

Введение

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

Система экстренного реагирования при авариях «ЭРА-ГЛОНАСС» предназначена для снижения тяжести последствий дорожно-транспортных происшествий и иных чрезвычайных ситуаций на дорогах Российской Федерации посредством уменьшения времени реагирования экстренных оперативных служб.

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

Настоящий стандарт предоставляет все необходимые данные о формате и правилах передачи сообщений и должен использоваться для разработки подсистем передачи данных на стороне автомобильной системы вызова экстренных оперативных служб и оператора системы «ЭРА-ГЛОНАСС».

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

ГОСТ Р 54620-2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Автомобильная система вызова экстренных оперативных служб. Общие технические требования

ГОСТ Р 54721-2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Общий порядок оказания системой базовой услуги

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

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

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

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

-    производителями автомобильных систем экстренного реагирования при авариях (терминалов «ЭРА-ГЛОНАСС»);

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

-    оператором системы «ЭРА-ГЛОНАСС»;

-    разработчиками и поставщиками услуг на основе навигационно-информационной платформы системы «ЭРА-ГЛОНАСС».

IV

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

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

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

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

Global navigation satellite system.

Accident emergency response system.

Protocols of data transmission from in-vehicle emergency call system to emergency response system infrastructure

Дата введения — 2012—09—01

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

Настоящий стандарт распространяется на систему экстренного реагирования при авариях «ЭРА-ГЛОНАСС» (далее — система).

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

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

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

ГОСТ Р ИСО/МЭК 7498-1—99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

ГОСТ Р 52928-2010 Система спутниковая навигационная глобальная. Термины и определения

ГОСТ Р 54620-2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Автомобильная система вызова экстренных оперативных служб. Общие технические требования

ГОСТ Р 54721-2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Общий порядок оказания системой базовой услуги

ГОСТ 7.75-97 Система стандартов по информации, библиотечному и издательскому делу. Коды наименований языков

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

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

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

3.1    В настоящем стандарте применены термины по ГОСТ Р 52928, ГОСТ Р ИСО/МЭК 7498-1, ГОСТ Р 54620, а также следующие термины с соответствующими определениями:

3.1.1    автомобильная система вызова экстренных оперативных служб «ЭРА-ГЛОНАСС»; АС:

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

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

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

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

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

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

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

3.1.7    система-112: Система обеспечения вызова экстренных оперативных служб по единому номеру «112».

3.1.8    единый номер «112»: Единый номер вызова экстренных оперативных служб, установленный в российской системе и плане нумерации.

3.1.9    оператор системы экстренного реагирования при авариях «ЭРА-ГЛОНАСС» (оператор системы): Юридическое лицо, осуществляющее деятельность по эксплуатации системы «ЭРА-ГЛОНАСС», в том числе по обработке информации, содержащейся в ее базе данных.

3.2 В настоящем стандарте применены следующие обозначения и сокращения НИС    —    навигационно-информационные системы;

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

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

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

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

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

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

2

ГОСТ P 54619—2011

цифровая

подпись

ЭРА

СР-1251

CRC-8(16)

DNS

eCall

EGTS

FTP

IP

GSM

HTTP

IMAP

ISDN

Little-endian

NGTP

OSI

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

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

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

—    Cyclic Redundancy Code (циклический избыточный код);

—    Domain Name System (система доменных имен);

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

—    Era Glonass Telematics Standard (телематический стандарт для системы «ЭРА-ГЛОНАСС»);

—    File Transfer Protocol (протокол передачи файлов);

—    Internet Protocol (межсетевой протокол);

—    Global System for Mobile communications (глобальный цифровой стандарт для мобильной сотовой связи);

—    HyperText Transfer Protocol (протокол передачи гипертекста);

—    Internet Message Access Protocol (протокол прикладного уровня для доступа к электронной почте);

—    Integrated Services Digital Network (цифровая сеть с интеграцией обслуживания);

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

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

PDU

POP3

SC

SIM

SME

SMS

SMSC

SMTP

TCP

TFTP

telnet

UDP

—    Open Systems Interconnection Basic Reference Model (базовая эталонная модель взаимодействия открытых систем — абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов);

—    Protocol Description Unit (элемент описания протокола);

—    Post Office Protocol Version 3 (протокол почтового отделения, версия 3);

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

—    Subscriber Identification Module (модуль идентификации абонента);

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

—    Short Message Service (сервис коротких сообщений);

—    Short Message Service Center (центр обработки коротких сообщений);

—    Simple Mail Transfer Protocol (простой протокол передачи почты);

—    Transmission Control Protocol (протокол управления передачей);

—    Trivial File Transfer Protocol (простой протокол передачи файлов);

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

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

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

4.1    Сетевая модель взаимодействия открытых систем согласно ГОСТ Р ИСО/МЭК 7498-1 определяет следующие уровни обмена данными:

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

-    канальный;

-    сетевой;

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

-    сеансовый;

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

4.2    В терминах сетевой модели OSI в системе «ЭРА-ГЛОНАСС» для передачи данных между автомобильной системой вызова экстренных оперативных служб и оператором системы используются следующие протоколы:

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

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

Соответствие сетевой модели OSI, стека протоколов TCP/IP и протоколов передачи данных системы «ЭРА-ГЛОНАСС» представлено в таблице 1.

3

Таблица 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    Настоящий стандарт устанавливает требования к следующим видам протоколов обмена информацией между элементами системы «ЭРА-ГЛОНАСС»:

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

-    протокол уровня поддержки услуг, включая базовую услугу, оказываемую системой «ЭРА-ГЛОНАСС».

Примечание — Описание базовой услуги, оказываемой системой «ЭРА-ГЛОНАСС», приведено в ГОСТ Р 54721.

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

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

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

5.1.1    Протокол транспортного уровня предназначен для обеспечения маршрутизации информации протокола уровня поддержки услуг между пунктами инфраструктуры системы «ЭРА-ГЛОНАСС» и АС, использующих данный протокол, проверки целостности и правильной последовательности данных, а также для обеспечения надежности доставки до пункта назначения.

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

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

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

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

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

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

4

ГОСТ P 54619—2011

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

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

Для части пакета транспортного уровня используется алгоритм вычисления циклического избыточного кода CRC-8.

Для части пакета уровня поддержки услуг используется алгоритм вычисления циклического избыточного кода CRC-16.

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

5.4.1    Механизм обеспечения надежной доставки основан на использовании подтверждений ранее отправленных пакетов. Отправляющая сторона после передачи пакета ожидает на него подтверждения в виде пакета определенного типа, содержащего идентификатор ранее переданного пакета и код результата его обработки на принимающей стороне. Ожидание проводится в течение определенного промежутка времени, регламентированного протоколом транспортного уровня и зависящего от типа используемого транспортного протокола нижнего уровня (параметр TL RESPONSE TO в таблице 13). После получения подтверждения отправляющая сторона производит анализ кода результата.

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

5.4.2    В зависимости от результата анализа пакет считается доставленным или недоставленным. Пакет считается недоставленным также в случае, если подтверждение не приходит по истечении времени TL_RESPONSE_TO (см. таблицу 13). Недоставленные пакеты отправляются повторно (число попыток отправки регламентировано настоящим протоколом и определяется параметром TL_RESEND_ATTEMPTS, указанным в таблице 13). По достижении предельного числа попыток отправки канал передачи данных считается ненадежным, и проводятся уничтожение установленной сессии (разрыв соединения в случае использования TCP/IP протокола в качестве транспортного) и попытка создания новой сессии (соединения) через время, определяемое параметром TL_RECONNECT_TO (см. таблицу 13).

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

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

5.5.2    Многобайтовые типы данных USHORT, UINT, ULONG, FLOAT и DOUBLE используют порядок следования байт 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

Дробное число со знаком

DOUBLE

8

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

Дробное число со знаком

STRING

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

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

BINARY

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

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

ARRAY OFTYPE

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

Может содержать последовательность одного из вышеуказанных типов (TYPE), кроме BINARY. Порядок следования байт и размер каждого элемента используемого типа определяются самим типом. Экземпляры типов идут последовательно один за другим. Н1апример: 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 [1].

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

6