ГОСТ Р 56360-2015. Национальный стандарт Российской Федерации. Глобальная навигационная спутниковая система. Аппаратура спутниковой навигации для оснащения колесных транспортных средств категории M, используемых для коммерческих перевозок пассажиров. Общие технические требования
Приложение А
(обязательное)
СПЕЦИФИКАЦИЯ ПРОТОКОЛА ТРАНСПОРТНОГО УРОВНЯ
А.1. Введение
А.1.1. Обмен данными между АСН, системами и аппаратно-программными комплексами осуществляется при помощи сетей подвижной радиотелефонной связи стандартов GSM.
А.1.2. Сетевая модель OSI имеет следующие уровни: физический, канальный, сетевой, транспортный, сеансовый, представления данных и приложений. Для передачи данных между АСН, системами и аппаратно-программными комплексами используют следующие протоколы: транспортный уровень - протокол TCP, сетевой уровень - протокол IP. Соответствие уровней сетевой модели 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 | Физический |
| |||
А.1.3. Общая длина пакета протокола транспортного уровня не превышает значения 65535 байт.
А.2. Протокол транспортного уровня
А.2.1. Обеспечение маршрутизации
В качестве адресов маршрутизации используют идентификаторы аппаратно-программных комплексов, которые уникальны в рамках одной сети.
А.2.2. Механизм проверки целостности данных
Для части пакета транспортного уровня использован алгоритм вычисления циклического избыточного кода CRC-8.
Для части пакета уровня поддержки услуг использован алгоритм вычисления циклического избыточного кода CRC-16.
А.2.3. Обеспечение надежности доставки
Отправляющая сторона после передачи пакета ожидает на него подтверждение в виде пакета определенного типа, содержащего идентификатор ранее переданного пакета и код результата его обработки на принимающей стороне. Ожидание составляет определенный промежуток времени, зависящий от типа используемого протокола транспортного уровня (значение данного параметра TL_RESPONSE_TO указано в таблице А.13).
После получения подтверждения отправляющая сторона производит анализ кода результата. Коды результатов обработки регламентированы протоколом и представлены в таблице А.14. Пакет считается недоставленным в том случае, если подтверждение не приходит по истечении времени TL_RESPONSE_TO. Недоставленные пакеты отправляют повторно (число попыток отправки регламентировано протоколом. В таблице А.13 указано значение данного параметра - TL_RESEND_ATTEMPTS). По достижении предельного числа попыток отправки канал передачи данных признают ненадежным и уничтожают установленную сессию (разрыв соединения в случае использования протокола TCP/IP в качестве транспортного протокола) и выполняют попытку создания новой сессии (соединения) через время, определяемое параметром TL_RECONNECT_TO (см. таблицу А.13).
А.3. Построение систем и аппаратно-программных комплексов на основе протокола транспортного уровня
А.3.1. Все сервисы в рамках одного аппаратно-программного комплекса соединяются с диспетчером (часть аппаратно-программного комплекса, выполняющая функции координации межсистемного взаимодействия и маршрутизации) и не имеют непосредственных связей между собой.
А.3.2. АСН также осуществляет взаимодействие с сервисами аппаратно-программного комплекса через компонент "диспетчер". При этом он идентифицируется по специальным пакетам, содержащим уникальный номер АСН UNIT_ID, назначаемый ему при регистрации в сети, а также другие учетные данные и информацию о состоянии модулей и блоков АСН.
А.3.3. Протоколом транспортного уровня (далее - протокол) зарезервирован диапазон номеров типов сервисов до 63. Пользовательские сервисы имеют типы с номерами, начиная с 64.
А.4. Описание типов данных
А.4.1. Протоколом определены и использованы несколько различных типов данных полей и параметров, указанных в таблице А.2.
Таблица А.2
Типы данных протокола
Тип данных | Размер, байт | Диапазон значений | Описание |
BOOLEAN | 1 | TRUE = 1, FALSE = 0 | Логический тип, принимающий только два значения TRUE или FALSE |
BYTE | 1 | 0...255 | Целое число без знака |
USHORT | 2 | 0...65535 | Целое число без знака |
UINT | 4 | 0...4294967295 | Целое число без знака |
ULONG | 8 | 0...18446744073709551615 | Целое число без знака |
SHORT | 2 | -32768...+32767 | Целое число со знаком |
INT | 4 | -2147483648...+2147483647 | Целое число со знаком |
FLOAT | 4 | +/- 1,2 E - 38...3,4 E + 38 | Дробное число со знаком |
DOUBLE | 8 | +/- 2,2 E - 308...1,7 E + 308 | Дробное число со знаком |
STRING | Переменный. Размер определен внешними параметрами или применением специального символа-терминатора (код 0x00) |
| Содержит последовательность печатных символов в кодировке по умолчанию CP-1251 |
BINARY | Переменный. Размер определен внешними параметрами |
| Содержит последовательность данных типа BYTE |
ARRAY OF TYPE | Переменный. Размер определен внешними параметрами |
| Содержит последовательность одного из вышеуказанных типов (TYPE), кроме BINARY. Экземпляры типов идут последовательно один за другим |
А.4.2. Многобайтовые типы данных USHORT, UINT, ULONG, FLOAT и DOUBLE используют порядок следования байт little - endian (младший байт вперед). Байты, составляющие последовательность в типах STRING и BINARY, интерпретируются как есть, т.е. обрабатываются в порядке их поступления.
А.4.3. Определены следующие типы полей и параметров:
- M (Mandatory) - обязательный параметр;
- O (Optional) - необязательный параметр.
А.5. Структуры данных
А.5.1. Состав пакета протокола представлен на рисунке А.1.
Заголовок протокола транспортного уровня | Данные уровня поддержки услуг | Контрольная сумма данных уровня поддержки услуг |
Рисунок А.1. Состав пакета протокола транспортного уровня
А.5.2. Пакет данных протокола состоит из заголовка, поля данных уровня поддержки услуг, а также поля контрольной суммы данных уровня поддержки услуг.
А.5.3. Общая длина пакета протокола не превышает значения 65535 байт, что соответствует максимальному значению параметра Window Size (максимальный размер целого пакета, принимаемый на стороне приемника) заголовка протокола TCP. В таблице А.3 указан состав пакета протокола.
Таблица А.3
Состав пакета протокола транспортного уровня
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
PRV (Protocol Version) | M | BYTE | 1 | |||||||
SKID (Security Key ID) | M | BYTE | 1 | |||||||
- | - | |||||||||
PRF (Prefix) | RTE | ENA | CMP | PR | M | BYTE | 1 | |||
- | - | - | ||||||||
HL (Header Length) | M | BYTE | 1 | |||||||
HE (Header Encoding) | M | BYTE | 1 | |||||||
FDL (Frame Data Length) | M | USHORT | 2 | |||||||
PID (Packet Identifier) | M | USHORT | 2 | |||||||
PT (Packet Type) | M | BYTE | 1 | |||||||
PRA (Peer Address) | O | USHORT | 2 | |||||||
RCA (Recipient Address) | O | USHORT | 2 | |||||||
TTL (Time To Live) | O | BYTE | 1 | |||||||
HCS (Header Check Sum) | M | BYTE | 1 | |||||||
SFRD (Services Frame Data) | O | BINARY | 0...65517 | |||||||
SFRCS (Services Frame Data Check Sum) | O | USHORT | 0,2 | |||||||
А.5.4. Заголовок протокола состоит из следующих полей: PRV, PRF, PR, CMP, ENA, RTE, HL, HE, FDL, PID, PT, PRA, RCA, TTL, HCS. Протокол уровня поддержки услуг представлен полем SFRD, контрольная сумма поля уровня поддержки услуг - в поле SFRCS.
А.5.5. Параметр PRV содержит значение 0x01. Значение данного параметра инкрементируется каждый раз при внесении изменений в структуру заголовка.
А.5.6. Параметр SKID определяет идентификатор ключа, используемого при шифровании.
А.5.7. Параметр PRF определяет префикс заголовка протокола и содержит значение 00.
А.5.8. Поле RTE (Route) определяет необходимость дальнейшей маршрутизации данного пакета на удаленный аппаратно-программный комплекс, а также наличие опциональных параметров PRA, RCA, TTL, необходимых для маршрутизации данного пакета. Если поле имеет значение 1, то необходима маршрутизация, и поля PRA, RCA, TTL присутствуют в пакете. Данное поле устанавливает диспетчер того аппаратно-программного комплекса, на котором сгенерирован пакет, или АСН, сгенерировавшая пакет для отправки на аппаратно-программный комплекс, в случае установки в нем параметра "HOME_DISPATCHER_ID", определяющего адрес аппаратно-программного комплекса, на котором данная АСН зарегистрирована.
А.5.9. Поле ENA (Encryption Algorithm) определяет код алгоритма, используемый для шифрования данных из поля SFRD. Если поле имеет значение 00, то данные в поле SFRD не шифруют.
А.5.10. Поле CMP (Compressed) определяет, используется ли сжатие данных из поля SFRD. Если поле имеет значение 1, то данные в поле SFRD считаются сжатыми.
А.5.11. Поле PR (Priority) определяет приоритет маршрутизации данного пакета и может принимать следующие значения:
- 00 - наивысший;
- 01 - высокий;
- 10 - средний;
- 11 - низкий.
При получении пакета диспетчер производит маршрутизацию пакета с более высоким приоритетом быстрее, чем пакетов с низким приоритетом.
А.5.12. Поле HL - длина заголовка протокола в байтах с учетом байта контрольной суммы (поля HCS).
А.5.13. Поле HE определяет применяемый метод кодирования следующей за данным параметром части заголовка протокола.
А.5.14. Поле FDL определяет размер в байтах поля данных SFRD, содержащего информацию протокола уровня поддержки услуг.
А.5.15. Поле PID содержит номер пакета транспортного уровня, увеличивающийся на 1 при отправке каждого нового пакета на стороне отправителя. Значения в данном поле изменяются по правилам циклического счетчика в диапазоне от 0 до 65535, т.е. при достижении значения 65535 следующее значение 0.
А.5.16. Поле PT - тип пакета транспортного уровня. Поле PT может принимать следующие значения:
- 0 - EGTS_PT_RESPONSE (подтверждение на пакет транспортного уровня);
- 1 - EGTS_PT_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг);
- 2 - EGTS_PT_SIGNED_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг с цифровой подписью).
А.5.17. Поле PRA - адрес аппаратно-программного комплекса, на котором данный пакет сгенерирован. Данный адрес является уникальным в рамках сети и используется для создания пакета-подтверждения на принимающей стороне.
А.5.18. Поле RCA - адрес аппаратно-программного комплекса, для которого данный пакет предназначен. По данному адресу производят идентификацию принадлежности пакета определенного аппаратно-программного комплекса и его маршрутизацию при использовании промежуточных аппаратно-программных комплексов.
А.5.19. Поле TTL - время жизни пакета при его маршрутизации между аппаратно-программными комплексами. Использование данного параметра предотвращает зацикливание пакета при ретрансляции в системах со сложной топологией адресных пунктов. Первоначально TTL устанавливается аппаратно-программным комплексом, сгенерировавшим данный пакет. Значение TTL устанавливается равным максимально допустимому числу аппаратно-программных комплексов между отправляющим и принимающим аппаратно-программным комплексом. Значение TTL уменьшается на единицу при трансляции пакета через каждый аппаратно-программный комплекс, при этом пересчитывается контрольная сумма заголовка протокола. При достижении данным параметром значения 0 и при обнаружении необходимости дальнейшей маршрутизации пакета происходят уничтожение пакета и выдача подтверждения с соответствующим кодом PC_TTLEXPIRED, указанным в таблице А.14.
А.5.20. Поле HCS - контрольная сумма заголовка протокола (начиная с поля PRV до поля HCS, не включая поле HCS). Для подсчета значения поля HCS ко всем байтам указанной последовательности применяется алгоритм CRC-8.
А.5.21. Поле SFRD - структура данных, зависящая от типа пакета и содержащая информацию протокола уровня поддержки услуг.
А.5.22. Поле SFRCS - контрольная сумма поля протокола уровня поддержки услуг. Для подсчета контрольной суммы по данным из поля SFRD используется алгоритм CRC-16. Данное поле присутствует только в том случае, если есть поле SFRD.
А.5.23. Блок-схема алгоритма обработки пакета данных протокола при приеме представлена на рисунке А.2 (см. вкладку).
Рисунок А.2. Блок-схема алгоритма обработки пакета данных
протокола транспортного уровня при приеме
А.6. Структуры данных
А.6.1. Структура данных пакета EGTS_PT_APPDATA
В таблице А.4 представлен формат поля SFRD для пакета типа EGTS_PT_APPDATA.
Таблица А.4
Формат поля SFRD для пакета типа EGTS_PT_APPDATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SDR 1 (Service Data Record) | O | BINARY | 9...65517 | |||||||
SDR 2 | O | BINARY | 9...65517 | |||||||
... |
|
|
| |||||||
SDR n | O | BINARY | 9...65517 | |||||||
Структуры SDR 1, SDR 2, SDR n содержат информацию протокола уровня поддержки услуг.
А.6.2. Структура данных пакета EGTS_PT_RESPONSE
Содержит информацию о результате обработки данных протокола, полученного ранее. В таблице А.5 представлен формат поля SFRD для пакета типа EGTS_PT_RESPONSE.
Таблица А.5
Формат поля SFRD для пакета типа EGTS_PT_RESPONSE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RPID (Response Packet ID) | M | USHORT | 2 | |||||||
PR (Processing Result) | M | BYTE | 1 | |||||||
SDR 1 (Service Data Record) | O | BINARY | 9...65517 | |||||||
SDR 2 | O | BINARY | 9...65517 | |||||||
... |
|
|
| |||||||
SDR n | O | BINARY | 9...65517 | |||||||
А.6.2.1. Параметр RPID - идентификатор пакета транспортного уровня, подтверждение на который сформировано.
А.6.2.2. Параметр PR - код результата обработки части пакета, относящейся к транспортному уровню. Список возможных кодов результата обработки представлен в таблице А.14.
А.6.2.3. Структуры SDR 1, SDR 2, SDR n содержат информацию уровня поддержки услуг.
А.6.3. Структура данных пакета EGTS_PT_SIGNED_APPDATA
В таблице А.6 представлен формат поля SFRD для пакета типа EGTS_PT_SIGNED_APPDATA.
Таблица А.6
Формат поля SFRD для пакета типа EGTS_PT_SIGNED_APPDATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SIGL (Signature Length) | M | SHORT | 2 | |||||||
SIGD (Signature Data) | O | BINARY | 0...512 | |||||||
SDR 1 (Service Data Record) | O | BINARY | 9...65515 | |||||||
SDR 2 | O | BINARY | 9...65515 | |||||||
... |
|
|
| |||||||
SDR n | O | BINARY | 9...65515 | |||||||
А.6.3.1. Параметр SIGL определяет длину данных цифровой подписи из поля SIGD.
А.6.3.2. Параметр SIGD содержит непосредственно данные цифровой подписи.
А.6.3.3. Структуры SDR 1, SDR 2, SDR n содержат информацию уровня поддержки услуг.
А.6.4. На каждый пакет типа EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA, поступающий от АСН на аппаратно-программный комплекс или от аппаратно-программного комплекса на АСН, отправляется пакет типа EGTS_PT_RESPONSE, содержащий в поле PID номер пакета из пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA. На рисунке А.3 представлена последовательность обмена пакетами при взаимодействии АСН и аппаратно-программного комплекса.
Рисунок А.3. Взаимодействие АСН и аппаратно-программного
комплекса на уровне пакетов транспортного уровня
А.7. Структура данных при использовании SMS-сервиса в качестве резервного канала передачи
А.7.1. При использовании SMS-сообщения для передачи пакетов данных протокола задействован режим PDU. Режим PDU позволяет передавать не только текстовую, но и бинарную информацию через SMS-сервис оператора подвижной радиотелефонной связи.
А.7.2. Для передачи использована структура SMS-SUBMIT с 8-битной кодировкой. В таблице А.7 представлен формат SMS-сообщения для отправки в режиме PDU.
Таблица А.7
Формат SMS с использованием режима PDU (SMS-SUBMIT)
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
SMSC AL (SMSC Address Length) | M | 1 | |||||||
SMSC AT (SMSC Address Type) | O | 0,1 | |||||||
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
SMSC A (SMSC Address) | O | 0,6 | |||||||
TP RP | TP UDHI | TP SRR | TP VPF | TP RD | TP MTI | Тип | Размер, байт | ||
TP MR (Message Reference) | M | 1 | |||||||
TP DA L (Destination Address Length) | M | 1 | |||||||
TP DA T (Destination Address Type) | M | 1 | |||||||
TP DA (Destination Address) | M | 6 | |||||||
TP PID (Protocol Identifier) | M | 1 | |||||||
TP DCS (Data Coding Schema) | M | 1 | |||||||
TP VP (Validity Period) | O | 0, 1, 7 | |||||||
TP UDL (User Data Length) | M | 1 | |||||||
TP UD (User Data) | O | 0...140 | |||||||
А.7.3. SMSC AL - длина полезных данных адреса SMSC в октетах плюс 1 октет поля SMSC AT.
А.7.4. SMSC AT - тип формата адреса SMSC. Возможные значения параметров SMSC AT представлены в таблице А.7. Поле опциональное, его наличие зависит от значения параметра SMSC AL (если значение SMSC AL > 0, то данное поле присутствует).
А.7.5. SMSC A - адрес SMSC. Каждая десятичная цифра номера представлена в виде 4 бит (младшие 4 бита - цифра более старшего разряда, старшие 4 бита - цифра меньшего разряда). При этом если число цифр в номере нечетное, то в битах с 4 по 7 последнего байта номера устанавливается значение 0xF (1111b). Данный параметр опциональный, и его наличие зависит от значения параметра SMSC AL. В случае отсутствия параметра SMSC A использован SMSC из SIM (USIM) карты.
А.7.6. TP MTI (Message Type Indicator) - тип сообщения (содержит бинарное значение 01).
А.7.7. TP RD (Reject Duplicates) определяет, необходимо ли SMSC принимать данное сообщение на обработку, если существует предыдущее необработанное отправленное с данного номера сообщение, которое имеет такое же значение поля TP MR и такой же номер получателя в поле TP DA.
А.7.8. TP VPF (Validity Period Format) - формат параметра TP VP.
А.7.9. TP SRR (Status Report Request) определяет необходимость отправки подтверждения со стороны SMSC на данное сообщение (если данный бит имеет значение 1, то требуется подтверждение).
А.7.10. TP UDHI (User Data Header Indicator) определяет, передается ли заголовок пользовательских данных TP UD HEADER (если поле имеет значение 1, то заголовок присутствует).
А.7.11. TP RP (Reply Path) определяет, присутствует ли поле RP в сообщении.
А.7.12. TP MR - идентификатор сообщения (увеличивается на 1 при каждой отправке нового сообщения).
А.7.13. TP DA L - длина полезных данных адреса получателя (определяется как число символов в номере получателя). Например, если адрес получателя "79991234567", то TP DA L = 0Bh (11).
А.7.14. TP DA T - тип формата адреса получателя. Возможные значения параметров TP DA T и SMSC AT представлены в таблице А.8.
Таблица А.8
Формат полей TP_DA_T и SMSC_AT (тип адреса)
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Размер, байт |
1 | TON | NPI | 1 | |||||
А.7.15. TP DA - адрес получателя. Кодировка номера произведена по тем же правилам, что и в параметре SMSC A.
А.7.16. TP PID - идентификатор протокола (содержит значение 00).
А.7.17. TP DCS - тип кодировки данных (содержит значение 0x04, определяющий 8-битную кодировку сообщения, отсутствие компрессии).
А.7.18. TP VP - время актуальности данного сообщения. В таблице А.9 представлен формат данного параметра.
Таблица А.9
Формат поля TP_VP в зависимости от значения поля TP_VPF
Значение битов | Описание | |
0 | 0 | Поле TP VP не передается |
1 | 0 | Поле TP VP имеет формат "относительное время" и размер 1 байт |
0 | 1 | Поле TP VP имеет формат "расширенное время" и размер 7 байт |
1 | 1 | Поле TP VP имеет формат "абсолютное время" и размер 7 байт |
А.7.19. TP UDL - длина данных сообщения из поля TP DL в байтах для используемой 8-битной кодировки.
А.7.20. TP UD - непосредственно передаваемые пользовательские данные. В таблице А.10 представлен формат данного поля.
Таблица А.10
Формат поля TP_UD
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
LUDH (Length of User Data Header) | O | 1 | |||||||
IEI "A" (Information-Element-Identifier "A") | O | 1 | |||||||
LIE "A" (Length of Information-Element "A") | O | 1 | |||||||
IED "A" (Information-Element-Data of "A") | O | 1...n | |||||||
IEI "B" (Information-Element-Identifier "B") | O | 1 | |||||||
LIE "B" (Length of Information-Element "B") | O | 1 | |||||||
IED "B" (Information-Element-Data of "B") | O | 1...n | |||||||
IEI "N" (Information-Element-Identifier "N") | O | 1 | |||||||
LIE "N" (Length of Information-Element "N") | O | 1 | |||||||
IED "N" (Information-Element-Data of "N") | O | 1...n | |||||||
UD (User Data) | M | 1...140 | |||||||
А.7.21. TON (Type Of Number) - тип номера. TON может принимать следующие значения:
- 000 - неизвестный;
- 001 - международный формат;
- 010 - национальный формат;
- 011 - специальный номер, определяемый сетью;
- 100 - номер абонента;
- 101 - буквенно-цифровой (коды с 7-битной кодировкой по умолчанию);
- 110 - укороченный;
- 111 - зарезервировано.
А.7.22. NPI (Numeric Plan Identification) - тип плана нумерации (применимо для значений поля TON = 000, 001, 010). NPI может принимать следующие значения:
- 0000 - неизвестный;
- 0001 - план нумерации ISDN телефонии;
- 0011 - план нумерации при передаче данных;
- 0100 - телеграф;
- 1000 - национальный;
- 1001 - частный;
- 1111 - зарезервировано.
А.7.23. LUDH - длина заголовка пользовательских данных в байтах без учета размера данного поля.
А.7.24. IEI "A", IEI "B", IEI "N" - идентификатор информационного элемента "A", "B" и "N" соответственно, который определяет тип информационного элемента и может принимать следующие значения (в шестнадцатеричной системе):
- 00 - часть конкатенируемого SMS-сообщения;
- 01 - индикатор специального SMS-сообщения;
- 02 - зарезервировано;
- 03 - не используется;
- 04 - 7F - зарезервировано;
- 80 - 9F - для специального использования SME;
- A0 - BF - зарезервировано;
- C0 - DF - для специального использования SC;
- E0 - FF - зарезервировано.
А.7.25. LIE "A", LIE "B", LIE "N" - параметры, определяющие размер данных информационных элементов "A", "B" и "N" соответственно, в байтах без учета размера данного поля.
А.7.26. IED "A", IED "B", IED "N" - данные информационных элементов "A", "B" и "N2" соответственно.
А.7.27. UD - данные пользователя. Размер данного поля определяется наличием заголовка пользовательских данных PT UD HEADER, состоящего из полей LUDH, IEI, LIE, IED. Если заголовок не передается, то размер равен значению из поля TP UDL, указанного в таблице А.7. Если заголовок передается, то размер поля вычисляется как разность (TP UDL - LUDH-1).
А.7.28. В том случае, если идентификатор информационного элемента IEI заголовка пользовательских данных TP_UD_HEADER имеет значение 00, структура поля IED будет иметь вид, представленный в таблице А.11.
Таблица А.11
Формат поля данных информационного элемента,
характеризующего часть конкатенируемого SMS-сообщения
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
CSMRN (Concatenated Short Message Reference Number) | M | 1 | |||||||
MNSM (Maximum Number of Short Messages) | M | 1 | |||||||
SNCSM (Sequence Number of Current Short Message) | M | 1 | |||||||
А.7.29. CSMRN - номер конкатенируемого SMS-сообщения. Имеет одинаковое значение для всех частей длинного SMS-сообщения.
А.7.30. MNSM - общее число сообщений, из которых состоит длинное SMS-сообщение. Содержит значения в диапазоне от 1 до 255.
А.7.31. SNCSM - номер передаваемой части длинного SMS-сообщения. Инкрементируется при отправке каждой новой части длинного сообщения. Содержит значение в диапазоне от 1 до 255. Если значение данного поля превышает значение из поля MNSM или равно нулю, то принимающая сторона игнорирует весь информационный элемент.
А.7.32. При приеме SMS-сообщения использован формат SMS-DELIVER с 8-битной кодировкой. В таблице А.12 представлен формат SMS-сообщения в режиме PDU при получении.
Таблица А.12
Формат принимаемого SMS-сообщения в режиме PDU (SMS-DELIVER)
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
SMSC_AL (SMSC Address Length) | M | 1 | |||||||
SMSC_AT (SMSC Address Type) | O | 0,1 | |||||||
SMSC_A (SMSC Address) | O | 0,6 | |||||||
TP_RP | TP_UDHI | TP_SRI | - | TP_MMS | TP_MTI | M | 1 | ||
TP_OA_L (Originating Address Length) | M | 1 | |||||||
TP_OA_T (Originating Address Type) | M | 1 | |||||||
TP_OA (Originating Address) | M | 0 - 10 | |||||||
TP_PID (Protocol Identifier) | M | 1 | |||||||
TP_DCS (Data Coding Schema) | M | 1 | |||||||
TP_SCTS (SMSC Time Stamp) | M | 1 | |||||||
TP_UDL (User Data Length) | M | 1 | |||||||
TP_UD (User Data) | O | 0...40 | |||||||
А.7.33. SMSC_AL - длина полезных данных адреса SMSC в октетах плюс 1 октет поля SMSC_AT.
А.7.34. SMSC_AT - тип формата адреса SMSC. Возможные значения параметров SMSC_AT представлены в таблице А.7. Поле опциональное, и его наличие зависит от значения параметра SMSC_AL (если значение SMSC_AL > 0, то данное поле присутствует).
А.7.35. SMSC_A - адрес SMSC. Каждая десятичная цифра номера представлена в виде 4 бит (младшие 4 бита - цифра старшего разряда, старшие 4 бита - цифра младшего разряда), при этом если число цифр в номере нечетное, то в битах с 4 по 7 последнего байта номера устанавливается значение 0xF (1111b).
А.7.36. TP_MTI (Message Type Indicator) - тип сообщения (содержит бинарное значение 00).
А.7.37. TP_MMS (More Messages to Send) определяет наличие сообщений на стороне SMSC, ожидающих доставки данному получателю. Параметр может иметь следующие значения:
- 0 - есть еще SMS-сообщения для доставки;
- 1 - сообщений для доставки нет.
А.7.38. TP_SRI (Status Report Indication) показывает наличие запроса со стороны, отправившей данное сообщение, об уведомлении о доставке. Может принимать следующие значения:
- 0 - уведомление не будет передаваться отправителю;
- 1 - уведомление будет отправлено.
А.7.39. TP_UDHI (User Data Header Indicator) определяет, передается ли заголовок пользовательских данных TP_UD_HEADER (если поле имеет значение 1, то заголовок присутствует).
А.7.40. TP_RP (Reply Path) определяет присутствие поля RP в сообщении.
А.7.41. TP_OA_L - длина полезных данных адреса отправителя.
А.7.42. TP_OA_T - тип формата адреса отправителя. Возможные значения параметров TP_OA_T и SMSC_AT представлены в таблицах А.7, А.12.
А.7.43. TP_OA - адрес отправителя. Кодировка номера производится по тем же правилам, что и в параметре SMSC_A.
А.7.44. TP_PID - идентификатор протокола.
А.7.45. TP_DCS - тип кодировки данных (содержит значение 0x04, определяющее 8-битную кодировку сообщения, отсутствие компрессии).
А.7.46. TP_SCTS - время, когда данное сообщение было передано в транспортный уровень SMSC. Формат данного параметра определен значением из таблицы А.12.
А.7.47. TP_UDL - длина данных сообщения из поля TP_DL в байтах для используемой 8-битной кодировки.
А.7.48. TP_UD - непосредственно передаваемые пользовательские данные. Формат данного поля в зависимости от значения поля TP_UDHI представлен в таблице А.7.
А.8. Формат передаваемой информации
А.8.1. При использовании SMS-сервиса для обмена данными между АСН и аппаратно-программным комплексом пакеты, упакованные по правилам протокола и протокола уровня поддержки услуг, помещаются в поле TP_UD (см. таблицу А.10), при этом полный размер пакета протокола не превышает 140 байт.
А.8.2. Для отправки SMS-сообщения, содержащего "цифровую подпись", используется пакет типа EGTS_PT_SIGNED_APPDATA.
А.8.3. В том случае, если размер пакета данных протокола превышает 140 байт, используется механизм конкатенации SMS-сообщений. Суть данного механизма состоит в том, что передаваемые пользовательские данные разбивают на части и отправляют отдельными SMS-сообщениями. Каждое сообщение содержит специальную структуру, определяющую общее число частей передаваемых данных и порядок их сборки на принимающей стороне. В качестве такой структуры использовано поле TP_UD_HEADER, которое содержит информационный элемент, характеризующий часть конкатенируемого SMS-сообщения.
Максимально возможный размер пакета при использовании 8-битной кодировки составляет 34170 байт.
А.9. Временные и количественные параметры протокола транспортного уровня при использовании пакетной передачи данных
А.9.1. Таблица А.13 содержит описание временных и количественных параметров протокола.
Таблица А.13
Временные и количественные параметры протокола
транспортного уровня
Наименование | Тип данных | Диапазон значений | Значение по умолчанию | Описание |
TL RESPONSE TO | BYTE | 0...255 | 5 | Время ожидания подтверждения пакета на транспортном уровне, отсчитываемое с момента его отправки стороной, сгенерировавшей пакет, с |
TL RESEND ATTEMPTS | BYTE | 0...255 | 3 | Число повторных попыток отправки неподтвержденного пакета стороной, сгенерировавшей пакет. Отсчитывается после истечения времени параметра TL_RESPONSE_TO при отсутствии пакета подтверждения |
TL RECONNECT TO | BYTE | 0...255 | 30 | Время, по истечении которого осуществляется повторная попытка установления канала связи после его разрыва, с |
Таблица А.14
Коды результатов обработки
Значение | Обозначение | Описание |
0 | EGTS_PC_OK | Успешно обработано |
1 | EGTS_PC_IN_PROGRESS | В процессе обработки |
128 | EGTS_PC_UNS_PROTOCOL | Неподдерживаемый протокол |
129 | EGTS_PC_DECRYPT_ERROR | Ошибка декодирования |
130 | EGTS_PC_PROC_DENIED | Обработка запрещена |
131 | EGTS_PC_INC_HEADERFORM | Неверный формат заголовка |
132 | EGTS_PC_INC_DATAFORM | Неверный формат данных |
133 | EGTS_PC_UNS_TYPE | Неподдерживаемый тип |
134 | EGTS_PC_NOTEN_PARAMS | Неверное число параметров |
135 | EGTS_PC_DBL_PROC | Попытка повторной обработки |
136 | EGTS_PC_PROC_SRC_DENIED | Обработка данных от источника запрещена |
137 | EGTS_PC_HEADERCRC_ERROR | Ошибка контрольной суммы заголовка |
138 | EGTS_PC_DATACRC_ERROR | Ошибка контрольной суммы данных |
139 | EGTS_PC_INVDATALEN | Некорректная длина данных |
140 | EGTS_PC_ROUTE_NFOUND | Маршрут не найден |
141 | EGTS_PC_ROUTE_CLOSED | Маршрут закрыт |
142 | EGTS_PC_ROUTE_DENIED | Маршрутизация запрещена |
143 | EGTS_PC_INVADDR | Неверный адрес |
144 | EGTS_PC_TTLEXPIRED | Превышено количество ретрансляции данных |
145 | EGTS_PC_NO_ACK | Нет подтверждения |
146 | EGTS_PC_OBJ_NFOUND | Объект не найден |
147 | EGTS_PC_EVNT_NFOUND | Событие не найдено |
148 | EGTS_PC_SRVC_NFOUND | Сервис не найден |
149 | EGTS_PC_SRVC_DENIED | Сервис запрещен |
150 | EGTS_PC_SRVC_UNKN | Неизвестный тип сервиса |
151 | EGTS_PC_AUTH_DENIED | Авторизация запрещена |
152 | EGTS_PC_ALREADY_EXISTS | Объект уже существует |
153 | EGTS_PC_ID_NFOUND | Идентификатор не найден |
154 | EGTS_PC_INC_DATETIME | Неправильная дата и время |
155 | EGTS_PC_IO_ERROR | Ошибка ввода/вывода |
156 | EGTS_PC_NO_RES_AVAIL | Недостаточно ресурсов |
157 | EGTS_PC_MODULE_FAULT | Внутренний сбой модуля |
158 | EGTS_PC_MODULE_PWR_FLT | Сбой в работе цепи питания модуля |
159 | EGTS_PC_MODULE_PROC_FLT | Сбой в работе микроконтроллера модуля |
160 | EGTS_PC_MODULE_SW_FLT | Сбой в работе программы модуля |
161 | EGTS_PC_MODULE_FW_FLT | Сбой в работе внутреннего ПО модуля |
162 | EGTS_PC_MODULE_IO_FLT | Сбой в работе блока ввода/вывода модуля |
163 | EGTS_PC_MODULE_MEM_FLT | Сбой в работе внутренней памяти модуля |
164 | EGTS_PC_TEST_FAILED | Тест не пройден |
А.10. Пример реализации алгоритма расчета контрольной суммы CRC-16 на языке C
/*
Name : CRC-16 CCITT
Poly : 0x1021 
Init : 0Xffff
Revert: false
XorOut: 0x0000
Check: 0x29B1 ("123456789")
*/
const unsigned short Crc16Table[256] = {
0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
0x8108, 0x9129, 0Xa14A, 0Xb16B, 0Xc18C, 0Xd1AD, 0Xe1CE, 0Xf1EF,
0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
0x9339, 0x8318, 0Xb37B, 0Xa35A, 0Xd3BD, 0Xc39C, 0Xf3FF, 0Xe3DE,
0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
0Xa56A, 0Xb54B, 0x8528, 0x9509, 0Xe5EE, 0Xf5CF, 0Xc5AC, 0Xd58D,
0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
0Xb75B, 0Xa77A, 0x9719, 0x8738, 0Xf7DF, 0Xe7FE, 0Xd79D, 0Xc7BC,
0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
0Xc9CC, 0Xd9ED, 0Xe98E, 0Xf9AF, 0x8948, 0x9969, 0Xa90A, 0Xb92B,
0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
0Xdbfd, 0Xcbdc, 0Xfbbf, 0Xeb9E, 0x9B79, 0x8B58, 0Xbb3B, 0Xab1A,
0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
0Xedae, 0Xfd8F, 0Xcdec, 0Xddcd, 0Xad2A, 0Xbd0B, 0x8D68, 0x9D49,
0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
0Xff9F, 0Xefbe, 0Xdfdd, 0Xcffc, 0Xbf1B, 0Xaf3A, 0x9F59, 0x8F78,
0x9188, 0x81A9, 0Xb1CA, 0Xa1EB, 0Xd10C, 0Xc12D, 0Xf14E, 0Xe16F,
0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
0x83B9, 0x9398, 0Xa3FB, 0Xb3DA, 0Xc33D, 0Xd31C, 0Xe37F, 0Xf35E,
0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
0Xb5EA, 0Xa5CB, 0x95A8, 0x8589, 0Xf56E, 0Xe54F, 0Xd52C, 0Xc50D,
0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
0Xa7DB, 0Xb7FA, 0x8799, 0x97B8, 0Xe75F, 0Xf77E, 0Xc71D, 0Xd73C,
0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
0Xd94C, 0Xc96D, 0Xf90E, 0Xe92F, 0x99C8, 0x89E9, 0Xb98A, 0Xa9AB,
0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
0Xcb7D, 0Xdb5C, 0Xeb3F, 0Xfb1E, 0x8BF9, 0x9BD8, 0Xabbb, 0Xbb9A,
0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
0Xfd2E, 0Xed0F, 0Xdd6C, 0Xcd4D, 0Xbdaa, 0Xad8B, 0x9DE8, 0x8DC9,
0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
0Xef1F, 0Xff3E, 0Xcf5D, 0Xdf7C, 0Xaf9B, 0Xbfba, 0x8FD9, 0x9FF8,
0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0
};
unsigned short Crc16(unsigned char * pcBlock, unsigned short len)
{
unsigned short crc = 0Xffff;
while (len--)
;
returncrc;
}
А.11. Пример реализации алгоритма расчета контрольной суммы CRC-8 на языке C
/*
Name : CRC-8
Poly : 0x31 
Init : 0xFF
Revert: false
XorOut: 0x00
Check : 0xF7 ("123456789")
*/
const unsigned char CRC8Table[256] = {
0x00, 0x31, 0x62, 0x53, 0xC4, 0xF5, 0xA6, 0x97,
0xB9, 0x88, 0xDB, 0xEA, 0x7D, 0x4C, 0x1F, 0x2E,
0x43, 0x72, 0x21, 0x10, 0x87, 0xB6, 0xE5, 0xD4,
0xFA, 0xCB, 0x98, 0xA9, 0x3E, 0x0F, 0x5C, 0x6D,
0x86, 0xB7, 0xE4, 0xD5, 0x42, 0x73, 0x20, 0x11,
0x3F, 0x0E, 0x5D, 0x6C, 0xFB, 0xCA, 0x99, 0xA8,
0xC5, 0xF4, 0xA7, 0x96, 0x01, 0x30, 0x63, 0x52,
0x7C, 0x4D, 0x1E, 0x2F, 0xB8, 0x89, 0xDA, 0xEB,
0x3D, 0x0C, 0x5F, 0x6E, 0xF9, 0xC8, 0x9B, 0xAA,
0x84, 0xB5, 0xE6, 0xD7, 0x40, 0x71, 0x22, 0x13,
0x7E, 0x4F, 0x1C, 0x2D, 0xBA, 0x8B, 0xD8, 0xE9,
0xC7, 0xF6, 0xA5, 0x94, 0x03, 0x32, 0x61, 0x50,
0xBB, 0x8A, 0xD9, 0xE8, 0x7F, 0x4E, 0x1D, 0x2C,
0x02, 0x33, 0x60, 0x51, 0xC6, 0xF7, 0xA4, 0x95,
0xF8, 0xC9, 0x9A, 0xAB, 0x3C, 0x0D, 0x5E, 0x6F,
0x41, 0x70, 0x23, 0x12, 0x85, 0xB4, 0xE7, 0xD6,
0x7A, 0x4B, 0x18, 0x29, 0xBE, 0x8F, 0xDC, 0xED,
0xC3, 0xF2, 0xA1, 0x90, 0x07, 0x36, 0x65, 0x54,
0x39, 0x08, 0x5B, 0x6A, 0xFD, 0xCC, 0x9F, 0xAE,
0x80, 0xB1, 0xE2, 0xD3, 0x44, 0x75, 0x26, 0x17,
0xFC, 0xCD, 0x9E, 0xAF, 0x38, 0x09, 0x5A, 0x6B,
0x45, 0x74, 0x27, 0x16, 0x81, 0xB0, 0xE3, 0xD2,
0xBF, 0x8E, 0xDD, 0xEC, 0x7B, 0x4A, 0x19, 0x28,
0x06, 0x37, 0x64, 0x55, 0xC2, 0xF3, 0xA0, 0x91,
0x47, 0x76, 0x25, 0x14, 0x83, 0xB2, 0xE1, 0xD0,
0xFE, 0xCF, 0x9C, 0xAD, 0x3A, 0x0B, 0x58, 0x69,
0x04, 0x35, 0x66, 0x57, 0xC0, 0xF1, 0xA2, 0x93,
0xBD, 0x8C, 0xDF, 0xEE, 0x79, 0x48, 0x1B, 0x2A,
0xC1, 0xF0, 0xA3, 0x92, 0x05, 0x34, 0x67, 0x56,
0x78, 0x49, 0x1A, 0x2B, 0xBC, 0x8D, 0xDE, 0xEF,
0x82, 0xB3, 0xE0, 0xD1, 0x46, 0x77, 0x24, 0x15,
0x3B, 0x0A, 0x59, 0x68, 0xFF, 0xCE, 0x9D, 0xAC
};
unsigned char CRC8(unsigned char *lpBlock, unsigned char len)
{
unsigned char crc = 0xFF;
while (len--)
;
returncrc;
}
Подписаться на обновления