Приказ Минтранса РФ от 31.07 2012 г. N 285 - Приложение № 6 к приказу Минтранса РФ от 31 июля 2012 г. № 285

Приложение № 6
к приказу Минтранса РФ
от 31 июля 2012 г. № 285

Спецификация протокола транспортного уровня

1. Введение

1.1. Обмен данными между абонентским терминалом и системами и аппаратно-программными комплексами осуществляется при помощи сетей подвижной радиотелефонной связи стандартов GSM и UMTS.

1.2. Сетевая модель OSI имеет следующие уровни: физический, канальный, сетевой, транспортный, сеансовый, представления данных и приложений. Для передачи данных между абонентскими терминалами и системами и аппаратно-программными комплексами используются следующие протоколы: транспортный уровень - протокол TCP, сетевой уровень - протокол IP. Соответствие уровней сетевой модели OSI, стека протоколов TCP/IP и протоколов системы представлено в Таблице № 1.

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

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. Типы данных Протокола

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

4.3. Определены следующие типы полей и параметров:

М (Mandatory) - обязательный параметр;

О (Optional) - необязательный параметр.

5. Структуры данных

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

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

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

5.3. Общая длина пакета протокола Транспортного уровня не превышает значения 65535 байт, что соответствует максимальному значению параметра Window Size (максимальный размер целого пакета, принимаемый на стороне приёмника) заголовка протокола TCP. Таблица № 3 определяет состав пакета протокола Транспортного уровня.

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

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. Если поле имеет значение 0 0, то данные в поле SFRD не шифруются.

5.10. Поле CMP (Compressed) определяет, используется ли сжатие данных из поля SFRD. Если поле имеет значение 1, то данные в поле SFRD считаются сжатыми.

5.11. Поле PR (Priority) определяет приоритет маршрутизации данного пакета и может принимать следующие значения:

0 0 - наивысший

0 1 - высокий

1 0 - средний

1 1 - низкий

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

5.12. Поле HL - длина заголовка Транспортного уровня в байтах с учётом байта контрольной суммы (поля HCS).

5.13. Поле НЕ определяет применяемый метод кодирования следующей за данным параметром части заголовка Транспортного уровня.

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

5.15. Поле PID содержит номер пакета Транспортного Уровня, увеличивающийся на 1 при отправке каждого нового пакета на стороне отправителя. Значения в данном поле изменяются по правилам циклического счётчика в диапазоне от 0 до 65535, т.е. при достижении значения 65535, следующее значение 0.

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

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.png

6. Структуры данных

6.1. Структура данных пакета EGTS_PT_APPDATA.

Таблица № 4 описывает формат поля SFRD для пакета типа EGTS_PT_APPDATA.

Таблица № 4. Формат поля SFRD для пакета типа EGTS_PT_APPDATA

Структуры SDR 1, SDR 2, SDR п содержат информацию Протокола уровня поддержки услуг.

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

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

Таблица № 5. Формат поля SFRD для пакета типа EGTS_PT_RESPONSE

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

6.3.2 Параметр PR - код результата обработки части пакета, относящейся к Транспортному уровню. Список возможных кодов результата обработки представлен в Таблице № 14.

6.3.4 Структуры SDR 1, SDR 2, SDR n содержат информацию Уровня поддержки услуг.

6.4. Структура данных пакета EGTS_PT_SIGNED_APPDATA.

Таблица № 6 определяет формат поля SFRD для пакета типа EGTS_PT_SIGNED_APPDATA.

Таблица № 6. Формат поля SFRD для пакета типа EGTS_PT_SIGNED_APPDATA

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

6.10. Параметр SIGD содержит непосредственно данные "цифровой подписи".

6.11. Структуры SDR 1, SDR 2, SDR n содержат информацию Уровня поддержки услуг.

6.12. На каждый пакет типа EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA, поступающий от абонентского терминала на аппаратно-программный комплекс или от аппаратно-программного комплекса на абонентский терминал, отправляется пакет типа EGTS_PT_RESPONSE, содержащий в поле PID номер пакета из пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA. На Рисунке № 3 представлена последовательность обмена пакетами при взаимодействии абонентского терминала и аппаратно-программного комплекса.

┌─────────────────────┐                 ┌───────────────────────┐

│Абонентский терминал │                 │ Аппаратно-программный │

│                     │                 │       комплекс        │

└──────┬──────────────┘                 └────────────────┬──────┘

       │                                                 │

       │                                                 │

       │       Пакет PT_APPDATA PID=1 (Авторизация)      │

       ├────────────────────────────────────────────────►│

       │                                                 │

       │    Пакет PT_RESPONSE на PID=1 (Подтверждение    │

       │                   Авторизации)                  │

       │◄────────────────────────────────────────────────┤

       │                                                 │

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

       ├────────────────────────────────────────────────►│

       │                                                 │

       │    Пакет РТ_RESPONSE на PID=2 (Подтверждение    │

       │              Телематических данных)             │

       │◄────────────────────────────────────────────────┤

       │                  ...                            │

       │         Пакет PT_APPDATA PID=n (Команда)        │

       │◄────────────────────────────────────────────────┤

       │                                                 │

       │    Пакет PT_RESPONSE на PID=n (Подтверждение    │

       │                пакета с командой)               │

       ├────────────────────────────────────────────────►│

┌──────┴──────┐                                  ┌───────┴────────┐

│             │                                  │                │

└─────────────┘                                  └────────────────┘

Рисунок № 3. Взаимодействие абонентского терминала и аппаратно-программного комплекса на уровне пакетов Транспортного уровня

7. Структура данных при использовании SMS-сервиса в качестве резервного канала передачи

7.1. При использовании SMS для передачи пакетов данных Протокола используется режим PDU. Режим PDU позволяет передавать не только текстовую, но и бинарную информацию через SMS-сервис оператора подвижной радиотелефонной связи.

7.2. Для передачи используется структура SMS-SUBMIT с 8-ми битной кодировкой. Таблица № 7 описывает формат SMS сообщения для отправки в PDU режиме.

Таблица № 7. Формат SMS с использованием PDU режима (SMS-SUBMIT)

7.3. SMSC AL - длина полезных данных адреса SMSC в октетах плюс 1 октет поля SMSC AT.

7.4. SMSC AT - тип формата адреса SMSC. Возможные значения параметров SMSC AT представлены в Таблице № 7. Поле опциональное, его наличие зависит от значения параметра SMSC AL (если значение SMSC AL > 0, то данное поле присутствует).

7.5. SMSC А - адрес SMSC. Каждая десятичная цифра номера представлена в виде 4-х бит (младшие 4 бита - цифра более старшего разряда, старшие 4 бита -цифра меньшего разряда). При этом, если количество цифр в номере нечётное, то в битах с 4 по 7 последнего байта номера устанавливается значение 0xF (1111b). Данный параметр опциональный и его наличие зависит от значения параметра SMSC AL. В случае отсутствия параметра SMSC А, используется SMSC из SIM карты.

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 Т и SMSC AT представлены в Таблице № 9.

7.15. TP DA - адрес получателя. Кодировка номера производится по тем же правилам, что и в параметре SMSC А.

7.16. TP PID - идентификатор протокола (содержит значение 00).

7.17. TP DCS - тип кодировки данных (содержит значение 0x04, определяющий 8-ми битную кодировку сообщения, отсутствие компрессии).

7.18. TP VP - время актуальности данного сообщения. Таблица № 8 описывает формат данного параметра.

7.19. TP UDL - длина данных сообщения из поля TP DL, в байтах для используемой 8-ми битной кодировки.

7.20. TP UD - непосредственно передаваемые пользовательские данные. Таблица № 10 описывает формат данного поля.

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

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

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 - зарезервировано.

Таблица № 10. Формат поля TP_UD

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

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

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

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

02 - зарезервировано;

03 - не используется;

04 - 7F = зарезервировано;

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

А0 - BF = зарезервировано;

С0 - DF = для специального использования SC;

Е0 - FF = зарезервировано.

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

7.26. IED "А", IED "В", IED "N" - данные информационных элементов "А", "В" и "N" соответственно.

7.27. UD - данные пользователя. Размер данного поля определяется наличием заголовка пользовательских данных РТ 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.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)