Откройте актуальную версию документа прямо сейчас
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Приложение В
(обязательное)
Спецификация протокола уровня поддержки услуг и спецификация сервисов предоставления услуг
В.1 Назначение протокола уровня поддержки услуг
Протокол уровня поддержки услуг предназначен для обеспечения обмена данными между АСН и системами и аппаратно-программными комплексами в целях обеспечения функционирования информационных услуг. Каждой услуге соответствует отдельный сервис, который является ключевым элементом в рамках системы, построенной с применением протокола.
Протокол уровня поддержки услуг выполняет следующие основные функции:
- обмен информационными сообщениями, содержащими данные для обработки различными сервисами, а также запросы на выдачу информации сервисами;
- обеспечение уведомления о результатах доставки и обработки данных уровня поддержки услуг;
- идентификация принадлежности данных определенному типу сервиса;
- определение характеристики данных (число, тип, состав, размер, кодировка и др.).
В.1.1 Обмен информационными сообщениями
Основной структурой протокола уровня поддержки услуг, содержащей в себе все необходимые данные для обработки информации или запроса на предоставление той или иной услуги, является запись. Каждая запись может иметь в своем составе несколько подзаписей, содержащих необходимые данные и определяющих действия, которые должен произвести сервис, обрабатывающий данную подзапись.
В.1.2 Обеспечение уведомления о результате доставки и обработки данных уровня поддержки услуг На уровне поддержки услуг уведомление отправляющей стороны о результате доставки и обработки данных обеспечивается механизмом подтверждений информационных записей при помощи специальных подзаписей, содержащих идентификатор полученной/обработанной записи.
В.1.3 Идентификация принадлежности данных
Для идентификации принадлежности записи тому или иному сервису используется идентификатор типа сервиса, который определяет функциональные особенности и характеристики обрабатываемых данных. Тип сервиса является его идентификатором при внутриплатформенной маршрутизации и является уникальным в рамках протокола.
В.1.4 Определение характеристики данных
Данные в протоколе уровня поддержки услуг записываются в виде подзаписи, имеющей свой уникальный идентификатор в рамках отдельного типа сервиса, а также строго определенную структуру организации данных в зависимости от подзаписи. Использованием такой организации данных в протоколе достигается однозначное определение типа данных, их физического смысла, размера и способа упаковки.
В.2 Определение структур данных
В.2.1 Общая структура
Общая структура протокола уровня поддержки услуг, которая входит в состав пакета протокола транспортного уровня (см. приложение А), может содержать одну или несколько записей, идущих одна за другой и имеющих различный состав данных, предназначенных разным сервисам.
На рисунке В.1 представлена общая структура данных протокола уровня поддержки услуг.
Рисунок В.1 - Общая структура данных протокола уровня поддержки услуг
В.2.2 Структура отдельной записи
В.2.2.1 Состав записи
Отдельная запись протокола уровня поддержки услуг состоит из заголовка записи и данных записи.
На рисунке В.2 представлен состав отдельной записи протокола уровня поддержки услуг.
Рисунок В.2 - Состав отдельной записи протокола уровня поддержки услуг
В заголовке записи находятся параметры, определяющие типы сервисов получателя и отправителя, идентификатор записи, идентификатор объекта (например, терминала), длину передаваемых данных, а также различные флаги, определяющие наличие опциональных параметров и способ обработки.
Данные записи могут содержать одну или несколько подзаписей определенных типов и содержащих передаваемые данные.
В.2.2.2 Структура записи
В таблице В.1 представлен формат отдельной записи протокола уровня поддержки услуг.
Таблица В.1 - Формат отдельной записи протокола уровня поддержки услуг
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
|||
RL (Record Length) |
M |
USHORT |
2 |
||||||||||
RN (Record Number) |
M |
USHORT |
2 |
||||||||||
RFL (Record Flags) |
М |
BYTE |
1 |
||||||||||
SSOD |
RSOD |
GRP |
RPP |
TMFE |
EVFE |
OBFE |
|
|
|
||||
OID (Object Identifier) |
О |
UINT |
4 |
||||||||||
EVID (Event Identifier) |
О |
UINT |
4 |
||||||||||
TM (Time) |
О |
UINT |
4 |
||||||||||
SST (Source Service Type) |
М |
BYTE |
1 |
||||||||||
RST (Recipient Service Type) |
М |
BYTE |
1 |
||||||||||
RD (Record Data) |
М |
BINARY |
3...65498 |
Поля таблицы В.1 содержат:
RL (Record Length) - параметр определяет размер данных из поля RD;
RN (Record Number) - номер записи. Значения в данном поле изменяются по правилам циклического счетчика в диапазоне от 0 до 65535, т.е. при достижении значения 65535, следующее значение должно быть 0. Значение данного поля используется для подтверждения записи;
RFL (Record Flags) содержит битовые флаги, определяющие наличие в данном пакете полей OID, EVID и ТМ, характеризующих содержащиеся в записи данные;
SSOD (Source Service On Device) - битовый флаг, определяющий расположение сервиса-отправителя:
1 - сервис-отправитель расположен на стороне АСН (авторизуемой телематической платформой (далее - ТП)),
0 - сервис-отправитель расположен на авторизующей ТП.
RSOD (Recipient Service On Device) - битовый флаг, определяющий расположение сервиса-получателя:
1 - сервис-получатель расположен на стороне АСН (авторизуемой ТП),
0 - сервис-получатель расположен на авторизующей ТП.
GRP (Group) - битовый флаг, определяющий принадлежность передаваемых данных определенной группе, идентификатор которой указан в поле OID:
1 - данные предназначены для группы,
0 - принадлежность группе отсутствует.
RPP (Record Processing Priority) - битовое поле, определяющее приоритет обработки данной записи сервисом:
00 - наивысший,
01 - высокий,
10 - средний,
11 - низкий.
TMFE (Time Field Exists) - битовое поле, определяющее наличие в данном пакете поля ТМ:
1 - поле ТМ присутствует,
0 - поле ТМ отсутствует.
EVFE (Event ID Field Exists) - битовое поле, определяющее наличие в данном пакете поля EVID:
1 - поле EVID присутствует,
0 - поле EVID отсутствует.
OBFE (Object ID Field Exists) - битовое поле, определяющее наличие в данном пакете поля OID:
1 - поле OID присутствует;
0 - поле OID отсутствует.
OID (Object Identifier) - идентификатор объекта, сгенерировавшего данную запись или для которого данная запись предназначена (уникальный идентификатор АСН), либо идентификатор группы (при GRP = 1). При передаче от АСН в одном пакете транспортного уровня нескольких записей подряд для разных сервисов, но от одного и того же объекта, поле OID может присутствовать только в первой записи, а в последующих записях может быть опущено;
EVID (Event Identifier) - уникальный идентификатор события. Поле EVID задает глобальный идентификатор события и применяется, когда необходимо логически связать с одним единственным событием набор нескольких информационных сущностей, причем сами сущности могут быть разнесены как по разным информационным пакетам, так и по времени. При этом прикладное ПО имеет возможность объединить все эти сущности воедино в момент представления пользователю информации о событии. Например, если с нажатием тревожной кнопки связывается серия фотоснимков, поле EVID должно быть указано в каждой сервисной записи, связанной с этим событием на протяжении передачи всех сущностей, связанных с данным событием, независимо от того, как долго не длилась передача всего пула информации;
ТМ (Time) - время формирования записи на стороне отправителя (секунды с 00:00:00 01.01.2010 UTC). Если в одном пакете транспортного уровня передаются несколько записей, относящихся к одному объекту и моменту времени, то поле метки времени ТМ может передаваться только в составе первой записи;
SST (Source Service Type) - идентификатор типа сервиса-отправителя, сгенерировавшего данную запись. Например, сервис, обрабатывающий навигационные данные на стороне АСН, сервис команд на стороне ТП и т.д.;
RST (Recipient Service Type) - идентификатор типа сервиса-получателя данной записи. Например, сервис, обрабатывающий навигационные Данные на стороне ТП, сервис обработки команд на стороне АСН и т.д.;
RD (Record Data) - поле, содержащее информацию, присущую определенному типу сервиса (одну или несколько подзаписей сервиса типа, указанного в поле SST или RST, в зависимости от вида предаваемой информации).
В.2.3 Общая структура подзаписей
В таблице В.2 представлен формат отдельной подзаписи протокола уровня поддержки услуг.
Таблица В.2 - Формат отдельной подзаписи протокола уровня поддержки услуг
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
SRT (Subrecord Type) |
М |
BYTE |
1 |
|||||||
SRL (Subrecord Length) |
М |
USHORT |
2 |
|||||||
SRD (Subrecord Data) |
О |
BINARY |
0... 65495 |
Поля таблицы В.2 содержат:
SRT (Subrecord Type) - тип подзаписи (подтип передаваемых данных в рамках общего набора типов одного сервиса). Тип 0 - специальный, зарезервирован за подзаписью подтверждения данных для каждого сервиса. Конкретные значения номеров типов подзаписей определяются логикой самого сервиса. Протокол указывает лишь то, что этот номер должен присутствовать, а нулевой идентификатор зарезервирован;
SRL (Subrecord Length) - длина данных в байтах подзаписи в поле SRD;
SRD (Subrecord Data) - данные подзаписи. Наполнение данного поля специфично для каждого сочетания идентификатора типа сервиса и типа подзаписи.
На каждую информационную запись уровня поддержки услуг должно быть отправлено подтверждение, которое содержит подзапись с информацией об идентификаторе подтверждаемой записи и результате ее обработки. Описание и формат подтверждения представлены в перечислении а) В.3.2.2.
На рисунке В.3 представлен алгоритм работы механизма подтверждений протокола уровня поддержки услуг.
Каждое сообщение протокола содержит в себе заголовок и контрольную сумму транспортного уровня и одну или несколько записей уровня поддержки услуг. Причем в одном сообщении могут содержаться как информационные записи, так и подтверждения на ранее принятые записи.
В.3 Описание сервисов предоставления услуг
В.3.1 Список сервисов
Под сервисом в настоящем стандарте подразумевается элемент инфраструктуры ТП, обеспечивающий функциональное выполнение алгоритма той или иной услуги с использованием описываемого протокола.
В таблице В.3 представлен список поддерживаемых сервисов, их функциональное описание и соответствующие идентификаторы (поле "Код") в десятичном виде.
В.3.2 Сервис EGTS_AUTH_SERVICE
В.3.2.1 Общие положения
Для описания данного сервиса вводятся понятия: "авторизуемая ТП", "авторизующая ТП".
Авторизуемая ТП - платформа, которая инициирует обмен данными между платформами с запросом на идентификацию (путем передачи записи с идентификационными данными на авторизующую ТП). В качестве авторизуемой ТП, в основном, выступает АСН. Запись с запросом на идентификацию содержит следующие данные:
- идентификатор АСН (авторизуемой ТП), который необходим для регистрации в базе данных (далее - БД) авторизующей ТП.
Рисунок В.3 - Диаграмма обмена сообщениями
Таблица В.3 - Список сервисов, поддерживаемых протоколом
Код |
Название |
Описание |
1 |
EGTS_AUTH_SERVICE |
Данный тип сервиса применяется для осуществления процедуры аутентификации АСН (авторизуемой ТП) на авторизующей ТП. При использовании TCP/IP протокола в качестве транспорта, АСН (авторизуемая ТП) должна проходить данную процедуру, и только после успешного завершения данной процедуры происходит дальнейшее взаимодействие |
2 |
EGTS_TELEDATA_SERVICE |
Сервис предназначен для обработки телематической информации (координатные данные, данные о срабатывании датчиков и т.д.), поступающей от АСН. Сервис описан в приложении Б |
3 |
EGTS_COMMANDS_SERVICE |
Данный тип сервиса предназначен для обработки управляющих и конфигурационных команд, информационных сообщений и статусов, передаваемых между АСН, ТП и операторами |
4 |
EGTS_FIRMWARE_SERVICE |
Сервис предназначен для передачи на АСН конфигурации и непосредственно самого программного обеспечения аппаратной части самого АСН, а также различного периферийного оборудования, подключенного к АСН и поддерживающего возможность удаленного обновления программного обеспечения |
Примечание - АСН (авторизуемая ТП) может быть зарегистрирована как в БД одной "домашней" авторизующей ТП, так и на нескольких, произвольно удаленных ТП;
- набор данных, которые необходимы для однозначной идентификации АСН (или авторизуемой ТП) на стороне авторизующей ТП.
Авторизующая ТП - платформа, которая принимает запись с запросом на идентификацию от АСН (авторизуемой ТП). Кроме того, эта платформа проверяет полученные данные (идентификаторы, тип клиента) в своей БД, и при необходимости, производит запрос к АСН (авторизуемой ТП), используя имеющуюся таблицу маршрутизации.
Данный тип сервиса применяется для:
- осуществления процедур идентификации и аутентификации при установлении соединения между АСН (авторизуемой ТП) и авторизующей ТП;
- получения учетных данных АСН (или авторизуемой ТП) на стороне авторизующей ТП;
- получения информации на авторизующей ТП об инфраструктуре на стороне АСН (авторизуемой ТП) - например, составе и версиях ПО модулей, блоков, периферийного оборудования и т.д.
Примечание - Данная функция настоящего сервиса является опциональной и АСН (авторизуемая ТП) сама принимает решение об объеме информации, отправляемой на авторизующую ТП;
- получения информации на авторизующей ТП о ТС;
- передачи авторизующей ТП на АСН (авторизуемую ТП) перечня поддерживаемых сервисов;
- передачи авторизующей ТП на АСН (авторизуемую ТП) данных о способе и параметрах шифрования;
- передачи АСН (авторизуемой ТП) на авторизующую ТП аутентификационных данных для реализации шифрования данных;
- реализации алгоритма "запросов" на использование сервисов на стороне АСН (авторизуемой ТП).
Примечание - Настоящий протокол предполагает реализацию использования сервисов авторизующей ТП на стороне АСН (авторизуемой ТП). Следует различать "простой" алгоритм использования сервисов и алгоритм "запросов". "Простой" алгоритм подразумевает, что для АСН (авторизуемой ТП) доступны все сервисы, и в этом случае авторизуемой ТП разрешено сразу отправлять данные для требуемого сервиса после прохождения процедуры авторизации. Алгоритм "запросов" на использование сервисов подразумевает, что перед тем, как использовать тот или иной тип сервиса (отправлять данные), АСН (авторизуемая ТП) должна получить от авторизующей ТП информацию о доступных для использования сервисов. "Запрос" на использование сервисов может быть выполнен как на этапе авторизации, так и после нее;
- передачи АСН (авторизуемой ТП) от авторизующей ТП результатов процедуры аутентификации.
Сервис должен быть использован АСН (авторизуемой ТП) только в случае применения в качестве транспорта протокола TCP/IP после создания каждого нового соединения с авторизующей ТП.
Описание полного пакета подзаписей сервиса EGTS_AUTH_SERVICE для реализации перечисленных выше функций приведено В.3.2.2.
Описание алгоритма авторизации АСН на авторизующей ТП приведено в В.3.2.3.
Особенности алгоритма авторизации авторизуемой ТП на авторизующей ТП В.3.2.4.
В.3.2.2 Описание подзаписей сервиса EGTS_AUTH_SERVICE
В таблице В.4 представлен список подзаписей, используемых сервисом EGTS_AUTH_SERVICE.
Таблица В.4 - Список подзаписей сервиса EGTS_AUTH_SERVICE
Код |
Название |
Описание |
0 |
EGTS_SR_RECORD_RESPONSE |
Подзапись применяется для осуществления подтверждения процесса обработки записи протокола уровня поддержки услуг. Данный тип подзаписи должен поддерживаться всеми сервисами |
1 |
EGTS_SR_TERM_IDENTITY |
Подзапись используется только АСН при запросе авторизации на авторизующей ТП и содержит учетные данные АСН |
2 |
EGTS_SR_MODULE_DATA |
Подзапись предназначена для передачи на ТП информации об инфраструктуре на стороне АСН, о составе, состоянии и параметрах блоков и модулей АСН. Данная подзапись является опциональной, и разработчик АСН сам принимает решение о необходимости заполнения полей и отправки данной подзаписи. Одна подзапись описывает один модуль. В одной записи может передаваться последовательно несколько таких подзаписей, что позволяет передать данные об отдельных составляющих всей аппаратной части АСН и периферийного оборудования |
3 |
EGTS_SR_VEHICLE_DATA |
Подзапись применяется АСН для передачи на ТП информации о ТС |
5 |
EGTS_SR_DISPATCHER_IDENTITY |
Подзапись используется только авторизуемой ТП при запросе авторизации на авторизующей ТП и содержит учетные данные авторизуемой АСН |
6 |
EGTS_SR_AUTH_PARAMS |
Подзапись используется авторизующей ТП для передачи на АСН данных о способе и параметрах шифрования, требуемого для дальнейшего взаимодействия |
7 |
EGTS_SR_AUTH_INFO |
Подзапись предназначена для передачи на авторизующую ТП аутентификационных данных АСН (авторизуемой ТП) с использованием ранее переданных со стороны авторизующей ТП параметров для осуществления шифрования данных |
8 |
EGTS_SR_SERVICE_INFO |
Данный тип подзаписи используется для информирования принимающей стороны, АСН или ТП, в зависимости от направления отправки, о поддерживаемых сервисах, а также для запроса определенного набора требуемых сервисов (от АСН к ТП) |
9 |
EGTS_SR_RESULT_CODE |
Подзапись применяется авторизующей ТП для информирования АСН (авторизуемой ТП) о результатах процедуры аутентификации АСН |
а) подзапись EGTS_SR_RECORD_RESPONSE
В таблице В.5 представлен формат подзаписи EGTS_SR_RECORD_RESPONSE.
Таблица В.5 - Формат подзаписи EGTS_SR_RECORD_RESPONSE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
CRN (Confirmed Record Number) |
М |
USHORT |
2 |
|||||||
RST (Record Status) |
М |
BYTE |
1 |
Поля подзаписи EGTS_SR_RECORD_RESPONSE:
- CRN (Confirmed Record Number) - номер подтверждаемой записи (значение поля RN из обрабатываемой записи),
- RST (Record Status) - статус обработки записи.
При получении подтверждения отправителем, он анализирует поле RST подзаписи EGTS_SR_ RECORD_RESPONSE и, в случае получения статуса об успешной обработке, стирает запись из внутреннего хранилища, иначе, в случае ошибки и в зависимости от причины, производит соответствующие действия.
Рекомендуется совмещать подтверждение транспортного уровня (тип пакета EGTS_PT_RESPONSE) с подзаписями - подтверждениями уровня поддержки услуг EGTS_SR_RECORD_RESPONSE;
б) подзапись EGTS_SR_TERM_IDENTITY
В таблице В.6 представлен формат подзаписи EGTS_SR_TERM_IDENTITY сервиса EGTS_AUTH_SERVICE.
Таблица В.6 - Формат подзаписи EGTS_SR_TERM_IDENTITY сервиса EGTS_AUTH_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
TID (Terminal Identifier) |
M |
UINT |
4 |
|||||||
Flags |
M |
BYTE |
1 |
|||||||
MNE |
BSE |
NIDE |
SSRA |
LNGCE |
IMSIE |
IMEIE |
HDIDE |
|||
HDID (Home Dispatcher Identifier) |
O |
USHORT |
2 |
|||||||
IMEI (International Mobile Equipment Identity) |
O |
STRING |
15 |
|||||||
IMSI (International Mobile Subscriber Identity) |
O |
STRING |
16 |
|||||||
LNGC (Language Code) |
О |
STRING |
3 |
|||||||
NID (Network Identifier) |
О |
BINARY |
3 |
|||||||
BS (Buffer Size) |
О |
USHORT |
2 |
|||||||
MSISDN (Mobile Station Integrated Services Digital Network Number) |
О |
STRING |
15 |
Поля подзаписи EGTS_SR_TERM_IDENTITY:
- TID (Terminal Identifier) - уникальный идентификатор, назначаемый при программировании АСН. Наличие значения 0 в данном поле означает, что АСН не прошел процедуру конфигурирования или прошел ее не полностью. Данный идентификатор назначается оператором и однозначно определяет набор учетных данных АСН. TID назначается при инсталляции АСН как дополнительного оборудования и передаче оператору учетных данных АСН (IMSI, IMEI, serial_id). В случае использования АСН в качестве штатного устройства, TID сообщается оператору автопроизводителем вместе с учетными данными (VIN, IMSI, IMEI),
- HDIDE (Home Dispatcher Identifier Exists) - битовый флаг, который определяет наличие поля HDID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается),
- IMEIE (International Mobile Equipment Identity Exists) - битовый флаг, который определяет наличие поля IMEI в подзаписи (если бит равен 1, то поле передается, если 0, то не передается),
- IMSIE (International Mobile Subscriber Identity Exists) - битовый флаг, который определяет наличие поля IMSI в подзаписи (если бит равен 1, то поле передается, если 0, то не передается),
- LNGCE (Language Code Exists) - битовый флаг, который определяет наличие поля LNGC в подзаписи (если бит равен 1, то поле передается, если 0, то не передается),
- SSRA - битовый флаг предназначен для определения алгоритма использования сервисов (если бит равен 1, то используется "простой" алгоритм, если 0, то алгоритм "запросов" на использование сервисов),
- NIDE (Network Identifier Exists) - битовый флаг определяет наличие поля NID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается),
- BSE (Buffer Size Exists) - битовый флаг, определяющий наличие поля BS в подзаписи (если бит равен 1, то поле передается, если 0, то не передается),
- MNE (Mobile Network Exists) - битовый флаг, определяющий наличие поля MSISDN в подзаписи (если бит равен 1, то поле передается, если 0, то не передается),
- HDID (Home Dispatcher Identifier) - идентификатор "домашней" ТП (подробная учетная информация о терминале хранится на данной ТП),
- IMEI (International Mobile Equipment Identity) - идентификатор мобильного устройства (модема). При невозможности определения данного параметра, АСН должна заполнять данное поле значением 0 во всех 15 символах,
- IMSI (International Mobile Subscriber Identity) - идентификатор мобильного абонента. При невозможности определения данного параметра АСН должна заполнять данное поле значением 0 во всех 16 символах,
- LNGC (Language Code) - код языка, предпочтительного к использованию на стороне АСН, по [13], например "rus" - русский;
- NID (Network Identifier) - идентификатор сети оператора, в которой зарегистрирована АСН на данный момент. Используются 20 младших бит. Представляет пару кодов MCC-MNC (на основе рекомендаций [14]).
Таблица В.6 иллюстрирует структуру поля NID,
- BS (Buffer Size) - максимальный размер буфера приема АСН в байтах. Размер каждого пакета информации, передаваемого на АСН, не должен превышать данного значения. Значение поля BS может принимать различные значения, например 800, 1000, 1024, 2048,4096 и т.д., и зависит от реализации аппаратной и программной частей конкретной АСН,
- MSISDN (Mobile Station Integrated Services Digital Network Number) - телефонный номер мобильного абонента. При невозможности определения данного параметра устройство должно заполнять данное поле значением 0 во всех 15 символах (формат описан в [15]).
Передача поля HDID определена настройками АСН и целесообразна при возможности подключении АСН к ТП, отличной от "домашней", например при использовании территориально распределенной сети ТП. При использовании только одной "домашней" ТП передача HDID не требуется.
"Простой" алгоритм использования сервисов, указанный в В.3.2.1, подразумевает, что для АСН (авторизуемой ТП) доступны все сервисы, и в таком режиме АСН разрешено сразу отправлять данные для требуемого сервиса. В зависимости от действующих на авторизующей ТП для данной АСН разрешений, в ответ на пакет с данными для сервиса может быть возвращена запись-подтверждение с соответствующим признаком ошибки. В системах с простым распределением прав на использование сервисов рекомендуется применять именно "простой" алгоритм. Это сокращает объем передаваемого трафика и время, затрачиваемое АСН на авторизацию.
Алгоритм "запросов" на использование сервисов подразумевает, что перед тем, как использовать тот или иной тип сервиса (отправлять данные), АСН должна получить от ТП информацию о доступных для использования сервисов. Запрос на использование сервисов можно осуществлять как на этапе авторизации, так и после нее. На этапе авторизации запрос на использование того или иного сервиса производится путем добавления подзаписей типа SR_SERVICE_INFO и установка бита 7 поля SRVP в значение 1.
После процедуры авторизации запрос на использование сервиса может быть также осуществлен при помощи подзаписей SR_SERVICE_INFO.
Таблица В.7 - Формат поля NID подзаписи EGTS_SR_TERM_IDENTITY сервиса EGTS_AUTH_SERVICE
Биты 20...23 |
Биты 10...19 |
Биты 0...9 |
Тип |
Тип данных |
Размер, байт |
- |
МСС (Mobile Country Code) |
MNC (Mobile Network Code) |
M |
BINARY |
3 |
Совокупность МСС и MNC определяет уникальный идентификатор сотового оператора сетей GSM, CDMA, TETRA, UMTS, а также некоторых операторов спутниковой связи. Параметры поля NID подзаписи EGTS_SR_TERM_IDENTITY:
- МСС (Mobile Country Code) - код страны,
- MNC (Mobile Network Code) - код мобильной сети в пределах страны;
в) подзапись EGTS_SR_MODULE_DATA
В таблице В.8 представлен формат подзаписи EGTS_SR_MODULE_DATA сервиса EGTS_AUTH_SERVICE.
Таблица В.8 - Формат подзаписи EGTS_SR_MODULE_DATA сервиса EGTS_AUTH_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
МТ (Module Type) |
М |
BYTE |
1 |
|||||||
VID (Vendor Identifier) |
М |
UINT |
4 |
|||||||
FWV (Firmware Version) |
М |
USHORT |
2 |
|||||||
SWV (Software Version) |
М |
USHORT |
2 |
|||||||
MD (Modification) |
М |
BYTE |
1 |
|||||||
ST (State) |
М |
BYTE |
1 |
|||||||
SRN (Serial Number) |
О |
STRING |
0 ... 32 |
|||||||
D (Delimiter) |
М |
BYTE |
1 |
|||||||
DSCR (Description) |
О |
STRING |
0 ... 32 |
|||||||
D (Delimiter) |
М |
BYTE |
1 |
Поля подзаписи SR_MODULE_DATA:
- МТ (Module Type) - тип модуля, определяет функциональную принадлежность модуля (1 - основной модуль; 2 - модуль ввода-вывода; 3 - модуль навигационного приемника; 4 - модуль беспроводной связи). Здесь указаны рекомендованные правила нумерации типов модулей. Конкретная реализация сервиса авторизации может вводить и расширять собственную нумерацию типов, включая все внешние периферийные контроллеры,
- VID (Vendor Identifier) - код производителя,
- FWV (Firmware Version) - версия аппаратной части модуля (старший байт - число до точки - major version, младший - после точки - minor version, например версия 2.34 будет представлена числом 0x0222),
- SWV (Software Version) - версия программной части модуля (старший байт - число до точки, младший - после точки),
- MD (Modification) - код модификации программной части модуля,
- ST (State) - состояние (1 - включен, 0 - выключен, >127 - неисправность см. Коды результатов обработки),
- SRN (Serial Number) - серийный номер модуля,
- D (Delimiter) - разделитель строковых параметров (всегда имеет значение 0),
- DSCR (Description) - краткое описание модуля;
г) подзапись EGTS_SR_VEHICLE_DATA
В таблице В.9 представлен формат подзаписи EGTS_SR_VEHICLE_DATA сервиса EGTS_AUTH_SERVICE.
В случае использования АСН в конфигурации дополнительного оборудования данная подзапись должна передаваться совместно с EGTS_SR_TERM_IDENTITY Идентификация АСН в этом случае производится на основании значения поля VIN.
Таблица В.9 - Формат подзаписи EGTS_SR_VEHICLE_DATA сервиса EGTS_AUTH_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
VIN (Vehicle Identification Number) |
М |
STRING |
17 |
|||||||
VHT (Vehicle Type) |
М |
UINT |
4 |
|||||||
VPST (Vehicle Propulsion Storage Type) |
М |
UINT |
4 |
Поля подзаписи EGTS_SR_VEHICLE_DATA:
- VIN (Vehicle Identification Number) - идентификационный номер
транспортного средства (структура описана в [16]);
- VHT - тип ТС:
Bit 31-4 не используется;
Bit 3-0:
0001 - пассажирский (Class M1),
0001 - пассажирский (Class M1),
0010 - автобус (Class M2),
0011 - автобус (Class МЗ);
- VPST - тип энергоносителя ТС:
если все биты 0, то тип не задан,
Bit 31-6 не используется,
Bit 5: 1 - водород,
Bit 4: 1 - электричество (более 42 В и 100 ),
Bit 3: 1 - жидкий пропан (LPG),
Bit 2: 1 - сжиженный природный газ (CNG),
Bit 1: 1 - дизель,
Bit 0:1 - бензин;
д) подзапись EGTS_SR_DISPATCHER_IDENTITY
В таблице В.10 представлен формат подзаписи EGTS_SR_DISPATCHER_
IDENTITY сервиса EGTS_AUTH_SERVICE.
Таблица В.10 - Формат подзаписи EGTS_SR_DISPATCHER_IDENTITY сервиса EGTS_AUTH_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
DT (Dispatcher Type) |
М |
BYTE |
1 |
|||||||
DID (Dispatcher ID) |
М |
UINT |
4 |
|||||||
DSCR (Description) |
О |
STRING |
0...255 |
Поля подзаписи EGTS_SR_DISPATCHER_IDENTITY:
- DT (Dispatcher Type) - тип диспетчера,
- DID (Dispatcher ID) - уникальный идентификатор диспетчера,
- DSCR (Description) - краткое описание;
е) подзапись EGTS_SR_AUTH_PARAMS
В таблице В.11 представлен формат подзаписи EGTS_SR_AUTH_PARAMS сервиса EGTS_AUTH_SERVICE.
Таблица В.11 - Формат подзаписи EGTS_SR_AUTH_PARAMS сервиса EGTS_AUTH_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
FLG (Flags) |
M |
BYTE |
1 |
|||||||
- |
EXE |
SSE |
MSE |
ISLE |
PKE |
ENA |
||||
PKL (Public Key Length) |
О |
USHORT |
2 |
|||||||
PBK (Public Key) |
О |
BINARY |
0...512 |
|||||||
ISL (Identity String Length) |
О |
USHORT |
2 |
|||||||
MSZ (Mod Size) |
О |
USHORT |
2 |
|||||||
SS (Server Sequence) |
О |
STRING |
0...255 |
|||||||
D (Delimiter) |
О |
BYTE |
1 |
|||||||
EXP (Exp) |
О |
STRING |
0...255 |
|||||||
D (Delimiter) |
О |
BYTE |
1 |
Поля подзаписи EGTS_SR_AUTH_PARAMS:
- EXE - битовый флаг, определяет наличие поля ЕХР и следующего за ним разделителя D (если 1, то поля присутствуют),
- SSE - битовый флаг, определяет наличие поля SS и следующего за ним разделителя D (если 1, то поля присутствуют),
- MSE - битовый флаг, определяет наличие поля MSZ (если 1, то поле присутствует),
- ISLE - битовый флаг, определяет наличие поля ISL (если 1, то поле присутствует),
- РKЕ - битовый флаг, определяет наличие полей PKL и РВK (если 1, то поля присутствуют),
- ENA - битовое поле, определяющее требуемый алгоритм шифрования пакетов. Если данное поле содержит значение 0 0, то шифрование не применяется, и подзапись EGTS_SR_AUTH_PARAMS содержит только один байт, иначе, в зависимости от типа алгоритма, наличие дополнительных параметров определяется остальными битами поля FLG,
- PKL (Public Key Length) - длина публичного ключа в байтах,
- РВK (Public Key) - данные публичного ключа,
- ISL (Identity String Length) - результирующая длина идентификационных данных,
- MSZ (ModSize) - параметр, применяемый в процессе шифрования,
- SS (Server Sequence) - специальная серверная последовательность байт, применяемая в процессе шифрования,
- D (Delimiter) - разделитель строковых параметров (всегда имеет значение 0),
- EXP (Exp) - специальная последовательность, используемая в процессе шифрования.
Если запрашиваемый алгоритм шифрования (если требуется использование шифрования) поддерживается, то авторизуемой стороной производится формирование и отправка записи EGTS_SR_AUTH_INFO, зашифрованной по указанному алгоритму. При этом биты 11 и 12 в поле KEYS заголовка транспортного уровня устанавливаются в соответствующие значения, и весь последующий обмен данными производится с использованием шифрования.
Если требуемый алгоритм шифрования не поддерживается, инициирующая сторона отправляет подзапись EGTS_SR_ RECORD_RESPONSE с соответствующим признаком ошибки;
ж) подзапись EGTS_SR_AUTH_INFO
В таблице В.12 представлен формат подзаписи EGTS_SR_AUTH_INFO сервиса EGTS_AUTH_SERVICE.
Таблица В.12 - Формат подзаписи EGTS_SR_AUTH_INFO сервиса EGTS_AUTH_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
UNM (User Name) |
М |
STRING |
0...32 |
|||||||
D (Delimiter) |
М |
BYTE |
1 |
|||||||
UPSW (User Password) |
М |
STRING |
0...32 |
|||||||
D (Delimiter) |
М |
BYTE |
1 |
|||||||
SS (Server Sequence) |
О |
STRING |
0...255 |
|||||||
D (Delimiter) |
О |
BYTE |
1 |
Поля подзаписи EGTS_SR_AUTH_INFO:
- UNM (User Name) - имя пользователя,
- D (Delimiter) - разделитель строковых параметров (всегда имеет значение 0),
- UPSW (User Password) - пароль пользователя,
- SS (Server Sequence) - специальная серверная последовательность байт, передаваемая в подзаписи EGTS_SR_AUTH_PARAMS (необязательное поле, наличие зависит от используемого алгоритма шифрования);
и) подзапись EGTS_SR_SERVICE_INFO
В таблице В.13 представлен формат подзаписи EGTS_SR_SERVICE_INFO Сервиса EGTS_AUTH_SERVICE.
Таблица В. 13 - Формат подзаписи EGTS_SR_SERVICE_INFO сервиса EGTS_AUTH_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
ST (Service Type) |
М |
BYTE |
1 |
|||||||
SST (Service Statement) |
М |
BYTE |
1 |
|||||||
SRVP (Service Parameters) |
М |
BYTE |
1 |
|||||||
SRVA |
- |
SRVRP |
Поля подзаписи EGTS_SR_SERVICE_INFO:
- ST (Service Type) - тип сервиса, определяет функциональную принадлежность (например, EGTS_TELEDATA_SERVICE, EGTS_ECALL_SERVICE и т.д.),
- SST (Service Statement) - определяет текущее состояние сервиса.
В таблице В.14 представлен перечень возможных состояний сервиса, его кодовое обозначение и описание;
- SRVP (Service Parameters) - определяет параметры сервиса;
- SRVA (Service Attribute) - битовый флаг, атрибут сервиса:
0 - поддерживаемый сервис,
0 - запрашиваемый сервис.
- SRVRP (Service Routing Priority) - битовое поле, приоритет с точки зрения трансляции на него данных (в случае масштабирования системы и применения нескольких экземпляров приложений одного типа сервиса) определяется битами 0 и 1:
00 - наивысший,
01 - высокий,
10 - средний,
11 - низкий.
Таблица В.14 - Список возможных состояний сервиса
Код |
Название |
Описание |
0 |
EGTS_SST_IN_SERVICE |
Сервис в рабочем состоянии и разрешен к использованию |
128 |
EGTS_SST_OUT_OF_SERVICE |
Сервис в нерабочем состоянии (выключен) |
129 |
EGTS_SST_DENIED |
Сервис запрещен для использования |
130 |
EGTS_SST_NO_CONF |
Сервис не настроен |
131 |
EGTS_SST_TEMP_UNAVAIL |
Сервис временно недоступен |
к) подзапись EGTS_SR_RESULT_CODE
В таблице В.15 представлен формат подзаписи EGTS_SR_RESULT_CODE сервиса EGTS_AUTH_SERVICE.
Таблица В.15 - Формат подзаписи EGTS_SR_RESULT_CODE сервиса EGTS_AUTH_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
RCD (Result Code) |
М |
BYTE |
1 |
Поля подзаписи EGTS_SR_SERVICE_INFO:
- RCD (Result Code) - код, определяющий результат выполнения операции авторизации (см. таблицу А.14 приложения А).
В.3.2.3 Описание процедуры авторизации АСН на авторизирующей ТП
Для работы АСН в инфраструктуре оператора ей должен быть назначен уникальный идентификатор UNIT_ID, которому должны соответствовать определенные значения IMEI, IMSI и другие учетные данные АСН, необходимые для осуществления взаимодействия в системе оператора.
Конфигурирование АСН может быть произведено одним из способов:
1) после регистрации АСН в сети GSM или UMTS инфраструктура сотового оператора отслеживает появление нового устройства и инициирует отправку ему зашифрованного SMS-сообщения с учетными данными. Шифрование производится ключом и алгоритмом, известными данной АСН и сохраненным к моменту конфигурирования в хранилище оператора. Для определения ключей и алгоритмов шифрования на стороне АСН используются соответствующие поля из заголовка протокола транспортного уровня, а также данные о ключах, зашитых в памяти АСН. Учетные данные передаются в виде конфигурационного файла с использованием подзаписи EGTS_SR_SERVICE_ FULL_DATA или EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE.
Файл конфигурации должен содержать:
- параметр EGTS_GPRS_APN (параметры точки доступа для установления GPRS сессии), параметр EGTS_ SERVER_ADDRESS, определяющий адрес и порт сервера, с которым необходимо установить TCP/IP соединение;
- уникальный идентификатор АСН UNIT_ID. В конфигурационном файле также могут присутствовать другие параметры, необходимые для работы АСН. Далее АСН производит расшифровку SMS-сообщения, проверяет корректность структур данных, вычисляет и сравнивает с полученными в сообщении значениями контрольные суммы. Если расшифровка и проверка прошли успешно, АСН устанавливает GPRS сессию и соединяется с указанным сервером по TCP/IP. После прохождения процедуры аутентификации АСН отправляет подтверждение об успешной конфигурации в виде подзаписи EGTS_SR_RECORD_RESPONSE с кодом EGTS_PC_OK на полученную запись EGTS_SR_SERVICE_FULL_DATA или EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE.
На рисунке В.4 представлен описанный алгоритм конфигурирования АСН;
2) после регистрации АСН в сети GSM или GPRS устанавливается GPRS сессия и TCP/IP соединение с сервером, информация об адресе которого уже записана в памяти АСН. При прохождении процедуры аутентификации, инфраструктура оператора анализирует параметр TID из подзаписи EGTS_SR_TERM_IDENTITY (см. таблица В.6). Если TID имеет значение 0, производится процедура конфигурирования при помощи сервиса EGTS_FIRMWARE_ SERVICE, как описано в способе 1, отправляется файл конфигурации с использованием подзаписи EGTS_SR_
Рисунок В.4 - Алгоритм конфигурации АСН с использованием SMS
SERVICE_FULL_DATA или EGTS_SR_SERVICE_PART_DATA. Далее, после прихода подтверждения получения конфигурационного файла от АСН, ему отправляется результат авторизации с кодом EGTS_PC_ID_NFOUND, указывающий, что TID = 0 в системе не найден. После этого сервер, не разрывая соединение с АСН, ожидает повторной авторизации АСН, но уже с корректным параметром TID.
На рисунке В.5 приведен описанный алгоритм конфигурирования АСН.
Рисунок В.5 - Алгоритм конфигурации АСН с использованием GPRS
Если авторизация прошла успешно, ТП, в зависимости от алгоритма запроса использования сервисов, может перед подзаписью EGTS_SR_RESULT_CODE добавлять подзаписи типа EGTS_SR_SERVICE_INFO, определяющие состав сервисов, разрешенных для АСН и поддерживаемых ТП. Это означает, что АСН сразу после авторизации может использовать только перечисленные сервисы, даже если он предполагает "простой" алгоритм поддержи прав использования сервисов.
Если используется алгоритм "запросов" использования сервисов, то АСН не может использовать сервисы, разрешение на использование которых не получено от стороны ТП. Причем разрешение на некоторые запрашиваемые сервисы может прийти позже. Например, когда сервисы находятся на удаленных ТП, и от этих ТП в асинхронном режиме приходят ответы на запросы. В таком случае ТП, используя имеющиеся данные маршрутизации, отправляет асинхронный запрос на использование сервисов удаленной ТП, если идентификатор HDID указан в подзаписи EGTS_SR_TERM_IDENTITY при авторизации АСН.
На рисунке В.6 представлен изложенный алгоритм обмена сообщениями на этапе авторизации АСН на стороне ТП.
После успешного подключения АСН к ТП по протоколу TCP/IP, АСН должна быть авторизована. Для передачи первичных аутентификационных данных АСН должна отправить сообщение, содержащее подзапись EGTS_ SR_TERM_IDENTITY (сообщение 1) в течение времени EGTS_SL_NOT_AUTH_TO (см. таблицу В.20 ).
Получив сообщение с подзаписью EGTS_SR_TERM_IDENTITY, ТП отправляет на него сообщение 2 с подтверждением о приеме EGTS_SR_RECORD_RESPONSE на запись с идентификатором ID = 1. Необходимо использовать идентификатор пакета PID = 1 при каждой новой сессии авторизации на ТП. Далее, в зависимости от настроек (используется ли шифрование, применяется ли дополнительный алгоритм авторизации), ТП отправляет пакет (сообщение 3) с подзаписью EGTS_SR_AUTH_PARAM, содержащей параметры, необходимые для осуществления шифрования и/или алгоритма расширенной авторизации. Если шифрование и алгоритм расширенной авторизации не используется, то вместо подзаписи EGTS_SR_AUTH_PARAM ТП может отправить подзапись EGTS_ SR_RESULT_CODE с результатом проведения процедуры авторизации АСН.
Рисунок В.6 - Алгоритм обмена сообщениями на этапе авторизации АСН на ТП
Далее АСН отправляет сообщение 4 с подтверждением EGTS_SR_RECORD_RESPONSE на сообщение 3 с ID = 2. При использовании расширенного алгоритма авторизации и/или шифрования, АСН передает сообщение 5, закодированное по правилам шифрования, указанным в сообщении 3 от ТП и содержащем подзапись EGTS_SR_ AUTH_INFO сданными для расширенной авторизации.
После получения EGTS_SR_AUTH_INFO ТП отправляет сообщение 6 с подтверждением на сообщение 5 с ID = 3 и выполняет процедуру авторизации. ТП формирует сообщение 7 с результатом проведения авторизации в виде подзаписи EGTS_SR_RESULT_CODE, а также в случае успешной авторизации может добавить информацию о разрешенных для использования данной АСН услуг в виде подзаписей EGTS_SR_SERVICE_INFO.
АСН формирует сообщение 8 с подтверждением на сообщение 7 с ID = 4. АСН может сформировать сообщение 9 и добавить подзаписи EGTS_SR_SERVICE_INFO, содержащие информацию о требуемых услугах (если применяется процедура использования сервисов "по запросу") и/или поддерживаемых сервисах на стороне АСН.
Далее ТП создает сообщение 10 с подтверждением на сообщение 9 с ID = 5.
На этом этап авторизации заканчивается, и АСН переходит на этап обмена информационными сообщениями с ТП согласно установленному в АСН режиму работы.
В том случае, если процедура авторизации проходит неудачно (неверные аутентификационные данные АСН, запрет доступа данной АСН к ТП и т.д.), то после отправки сообщения, содержащего подзапись EGTS_SR_ RESULT_CODE с указанием в ней соответствующего кода, ТП должна разорвать установленное терминалом TCP/IP соединение.
В.3.2.4 Описание процедуры авторизации ТП на авторизующей ТП
Данная процедура авторизации предполагает, что информация об адресе авторизующей ТП записана в БД авторизуемой ТП.
На рисунке В.7 представлен алгоритм авторизации между платформами.
Рисунок В.7 - Алгоритм обмена сообщениями на этапе авторизации авторизуемой ТП на авторизующей ТП
Примечание - На рисунке не представлены сообщения, которые обеспечивают (при необходимости, в зависимости от настроек) алгоритмы шифрование и расширенной авторизации. Для реализации алгоритмов шифрования и расширенной авторизации используются подзаписи EGTS_SR_AUTH_PARAM, EGTS_SR_AUTH_INFO авторизующей и авторизуемой ТП, соответственно. Порядок обмена сообщениями с указанными подзаписями между авторизуемой и авторизующей ТП совпадает с алгоритмом обмена сообщениями на этапе авторизации АСН на ТП, указанным на рисунке В.6.
Для передачи первичных аутентификационных данных авторизуемая ТП должна отправить сообщение, содержащее подзапись SR_DISPATCHER_IDENTITY (сообщение 1) в течение времени EGTS_SL_NOT_AUTH_TO (см. таблицу В.20).
Необходимо использовать идентификатор пакета PID = 1 при каждой новой сессии авторизации на ТП.
Получив сообщение с подзаписью SR_DISPATCHER_IDENTITY, авторизующая ТП отправляет на него сообщение 2 с подтверждением о приеме EGTS_SR_RECORD_RESPONSE на запись с идентификатором ID = 1.
Получив подзапись SR_DISPATCHER_IDENTITY, авторизующая ТП анализирует параметр DID из подзаписи (см. таблицу В. 10). При благополучном завершении авторизации, авторизующая ТП формирует подзапись EGTS_SR_RESULT_CODE = EGTS_PC_OK с положительным результатом и передает ее в сообщении 3. Соответственно авторизуемая ТП отправляет сообщение 4 с подтверждением EGTS_SR_RECORD_RESPONSE на сообщение 3 с ID = 2.
Затем авторизуемая и авторизующая ТП последовательно предоставляют друг другу информацию о доступных сервисах, используя подзаписи EGTS_SR_SERVICE_INFO в сообщениях 5 и 7 соответственно. На указанные сообщения 5 и 7 авторизующая и авторизуемая платформы формируют подтверждения (сообщения 6 и 8 соответственно).
В.3.3 Сервис EGTS_FIRMWARE_SERVICE
Данный тип сервиса предназначен для передачи на АСН конфигурации и обновления ПО аппаратной части модулей и блоков самой АСН, а также периферийного оборудования, подключенного к АСН.
В.3.3.1 Описание подзаписей
Для осуществления взаимодействия в рамках данного сервиса, используется несколько подзаписей, описание и код которых представлены в таблице В.16.
Таблица В. 16 - Список подзаписей сервиса EGTS_FIRMWARE_SERVICE
Код |
Название |
Описание |
0 |
EGTS_SR_RECORD_RESPONSE |
Подзапись применяется для осуществления подтверждения записи протокола уровня поддержки услуг из пакета типа EGTS_PT_APPDATA |
33 |
EGTS_SR_SERVICE_PART_DATA |
Подзапись предназначена для передачи на АСН данных, которые разбиваются на части и передаются последовательно. Данная подзапись применяется для передачи больших объектов, длина которых не позволяет передать их на АСН одним пакетом |
34 |
EGTS_SR_SERVICE_FULL_DATA |
Подзапись предназначена для передачи на АСН данных, которые не разбиваются на части, а передаются одним пакетом |
а) подзапись EGTS_SR_SERVICE_PART_DATA
Данный тип подзаписи может использоваться сервисом для передачи сущностей на АСН.
В таблице В.17 представлен формат подзаписи EGTS_SR_SERVICE_PART_DATA сервиса EGTS_ FIRMWARE_SERVICE.
Параметр EPQ содержит число частей, которое будет передано, а параметр PN номер текущей части. Поле ID однозначно определяет сущность, которой принадлежит передаваемая часть. Значения параметров EPQ и PN для данной подзаписи должны содержать значения в диапазоне от 1 до 65535, причем значение из поля PN должно быть меньше или равно значению из поля EPQ. Если это условие нарушается, то данные из такой подзаписи не принимаются.
Идентификатор объекта ID, поля PN и EPQ, а также идентификатор источника записи OID из заголовка уровня маршрутизации сервисов позволяют однозначно определить, какая часть и какого объекта получена для обработки. Это дает возможность при достаточной пропускной способности канала одновременно передавать сущности для обновления ПО различных аппаратных частей АСН и периферийного оборудования.
Таблица В. 17 - Формат подзаписи EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
ID (Identity) |
М |
USHORT |
2 |
|||||||
PN (Part Number) |
M |
USHORT |
2 |
|||||||
EPQ (Expected Parts Quantity) |
М |
USHORT |
2 |
|||||||
ODH (Object Data Header) |
О |
BINARY |
0...71 |
|||||||
OD (Object Data) |
М |
BINARY |
1...65400 |
Поля данной подзаписи:
- ID (Identity) - уникальный идентификатор передаваемой сущности. Инкрементируется при начале отправки новой сущности. Данный параметр позволяет однозначно идентифицировать, какой именно сущности данная часть принадлежит,
- PN (Part Number) - последовательный номер текущей части передаваемой сущности,
- EPQ (Expected Parts Quantity) - ожидаемое число частей передаваемой сущности,
- ODH (Object Data Header) - заголовок, содержащий параметры, характеризующие передаваемую сущность. Данный заголовок передается только для первой части сущности. При передаче второй и последующих частей, данное поле не передается.
В таблице В.18 представлен формат заголовка передаваемой сущности подзаписи EGTS_SR_SERVICE_ PART_DATA сервиса EGTS_FIRMWARE_ SERVICE,
- OD (Object Data) - непосредственно данные передаваемой сущности.
Таблица В.18 - Формат заголовка передаваемой сущности подзаписи EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
||
ОА (Object Attribute) |
М |
BYTE |
1 |
|||||||||
- |
ОТ (Object Type) |
МТ (Module Туре) |
||||||||||
CMI (Component or Module Identifier) |
М |
BYTE |
1 |
|||||||||
VER (Version) |
М |
USHORT |
2 |
|||||||||
WOS (Whole Object Signature) |
М |
USHORT |
2 |
|||||||||
FN (File Name) |
О |
STRING |
0...64 |
|||||||||
D (Delimiter) |
M |
BYTE |
1 |
Поля данной подзаписи:
- ОА (Object Attribute) - характеристика принадлежности передаваемой сущности,
- ОТ (Object Type) - тип сущности по содержанию. Определены следующие значения данного поля:
00 - данные внутреннего ПО ("прошивка"),
01 - блок конфигурационных параметров.
- МТ (Module Type) - тип модуля, для которого предназначена передаваемая сущность. Определены следующие значения данного поля:
00 - периферийное оборудование,
01 - АСН.
- CMI (Componentor Module Identifier) - номер компонента в случае принадлежности сущности непосредственно АСН или идентификатор периферийного модуля/порта, подключенного к АСН, в зависимости от значения параметра МТ,
- VER (Version) - версия передаваемой сущности (старший байт - число до точки - major version, младший, после точки - minor version, например версия 2.34 будет представлена числом 0x0222),
- WOS (Whole Object Signature) - сигнатура (контрольная сумма), всей передаваемой сущности. Используют алгоритм CRC16-CCITT,
- FN (File Name)- имя файла передаваемой сущности (данное поле опционально и может иметь нулевую длину),
- D - разделитель строковых параметров (всегда имеет значение 0);
б) подзапись EGTS_SR_SERVICE_FULL_DATA
В таблице В.19 представлен формат подзаписи EGTS_SR_SERVICE_FULL_DATA сервиса EGTS_ FIRMWARE_SERVICE.
Таблица В.19 - Формат подзаписи EGTS_SR_SERVICE_FULL_DATA сервиса EGTS_FIRMWARE_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
ODH (Object Data Header) |
М |
BINARY |
7...71 |
|||||||
OD (Object Data) |
М |
BINARY |
1...65400 |
Поля данной подзаписи:
- ODH (Object Data Header) - заголовок, содержащий параметры, характеризующие передаваемую сущность. Структура данного параметра полностью совпадает со структурой, представленной в таблице В.17. Для подзаписи EGTS_SR_SERVICE_FULL_DATA параметр ODH является обязательным и присутствует в каждой такой подзаписи.
- OD (Object Data) - непосредственно данные передаваемой сущности;
в) подзапись EGTS_SR_RECORD_RESPONSE
Данная подзапись имеет такую же структуру, как описано в перечислении а) В.3.2.2, и применяется для подтверждения получения и обработки подзаписей EGTS_SR_SERVICE_PART_DATA и EGTS_SR_SERVICE_FULL_DATA. При этом на все подзаписи EGTS_SR_SERVICE_PART_DATA, кроме последней, при успешной обработке в составе EGTS_SR_RECORD_RESPONSE должен передаваться код результата, равный EGTS_PC_IN_PROGRESS. На последнюю подзапись EGTS_SR_SERVICE_PART_DATA и каждую EGTS_SR_SERVICE_FULL_DATA при успешном приеме и обработке со стороны АСН должна передаваться подзапись EGTS_SR_RECORD_RESPONSE, содержащая код EGTS_PC_OK, что будет воспринято сервисом как удачная попытка отправки всей сущности.
В.3.3.2 Временные и количественные параметры протокола уровня поддержки услуг при использовании пакетной передачи данных
В таблице В.20 представлены временные и количественные параметры протокола уровня поддержки услуг.
Таблица В.20 - Временные и количественные параметры протокола уровня поддержки услуг
Название |
Тип данных |
Диапазон значений |
Значение по умолчанию |
Описание |
EGTS_SL_NOT_AUTH_TO |
BYTE |
0 ... 255 |
6 |
Время ожидания прихода сообщения от АСН (авторизуемой ТП), которое содержит данные для осуществления процедуры авторизации на стороне авторизующей ТП после установления АСН (авторизуемой ТП) нового подключения по протоколу TCP/IP, с. Если в течение данного времени сообщение не поступает, авторизующая ТП должна разорвать установленное с АСН (авторизуемой ТП) TCP/IP соединение |
В.3.4 Сервис EGTS_COMMANDS_SERVICE
Данный тип сервиса предназначен для обработки команд, сообщений и подтверждений, передаваемых между АСН, ТП и клиентскими приложениями.
В.3.4.1 Описание подзаписей
В таблице В.21 представлен список подзаписей сервиса EGTS_COMMAND_SERVICE, их описание и кодовое обозначение.
Таблица В.21 - Список подзаписей сервиса EGTS_COMMAND_SERVICE
Код |
Название |
Описание |
0 |
EGTS_SR_RECORD_RESPONSE |
Подзапись применяется для подтверждения процесса обработки записи протокола уровня поддержки услуг. Данный тип подзаписи должен поддерживаться всеми сервисами |
51 |
EGTS_SR_COMMAND_DATA |
Подзапись используется АСН и ТП для передачи команд, информационных сообщений, подтверждений доставки, подтверждений выполнения команд, подтверждения прочтения сообщений и т.п. |
а) подзапись EGTS_SR_COMMAND_DATA
В таблице В.22 представлен формат подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE.
Таблица В.22 - Формат подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
||
СТ (Command Type) |
ССТ (Command Confirmation Type) |
М |
BYTE |
1 |
||||||||
CID (Command Identifier) |
М |
UINT |
4 |
|||||||||
SID (Source Identifier) |
М |
UINT |
4 |
|||||||||
- |
ACFE |
CHSFE |
М |
BYTE |
1 |
|||||||
CHS (Charset) |
О |
BYTE |
1 |
|||||||||
ACL (Authorization Code Length) |
О |
BYTE |
1 |
|||||||||
AC (Authorization Code) |
О |
BINARY |
0 ... 255 |
|||||||||
CD (Command Data) |
О |
BINARY |
0 ... 65205 |
Поля данной подзаписи:
- СТ (Command Type) - тип команды:
0001 = CT_COMCONF - подтверждение о приеме, обработке или
результат выполнения команды,
0010 = CT_MSGCONF - подтверждение о приеме, отображении и/или
обработке информационного сообщения,
0011 = CT_MSGFROM - информационное сообщение от АСН,
0100 = CT_MSGTO - информационное сообщение для вывода на
устройство отображения АСН,
0101 = СТ_СОМ - команда для выполнения на АСН,
0110 = CT_DELCOM - удаление из очереди на выполнение переданной
ранее команды,
0111 = CT_SUBREQ - дополнительный подзапрос для выполнения (к
переданной ранее команде), 1000 = CT_DELIV - подтверждение о доставке
команды или информационного сообщения.
- ССТ (Command Confirmation Type) - тип подтверждения (имеет смысл для
типов команд CT_COMCONF, CT_MSGCONF, CT_DELIV):
0000 = CC_OK - успешное выполнение, положительный ответ,
0001 = CC_ERROR - обработка завершилась ошибкой,
0010 = CC_ILL - команда не может быть выполнена по причине
отсутствия в списке разрешенных (определенных протоколом) команд или
отсутствия разрешения на выполнение данной команды,
0011 = CC_DEL - команда успешно удалена,
0100 = CC_NFOUND - команда для удаления не найдена,
0101 = CC_NCONF - успешное выполнение, отрицательный ответ,
0110 = CC_INPROG - команда передана на обработку, но для ее
выполнения требуется длительное время (результат выполнения еще не
известен).
- CID (Command Identifier) - идентификатор команды, сообщения.
Значение из данного поля должно быть использовано стороной,
обрабатывающей/выполняющей команду или сообщение, для создания
подтверждения. Подтверждение должно содержать в поле CID то же значение,
что содержалось в самой команде или сообщении при отправке;
- SID (Source Identifier) - идентификатор отправителя (уровня
прикладного ПО, например, уникальный идентификатор пользователя в системе
диспетчеризации) данной команды или подтверждения;
- ACFE (Authorization Code Field Exists) - битовый флаг, определяющий
наличие полей ACL и АС в подзаписи:
1 = поля ACL и АС присутствуют в подзаписи,
0 = поля ACL и АС отсутствуют в подзаписи.
- CHSFE (Charset Field Exists) - битовый флаг, определяющий наличие
поля CHS в подзаписи:
1 = поле CHS присутствует в подзаписи,
0 = поле CHS отсутствует в подзаписи.
- CHS (Charset) - кодировка символов, используемая в поле CD,
содержащем тело команды. При отсутствии данного поля по умолчанию должны
использовать кодировку СР-1251. Определены следующие значения поля CHS
(десятичный вид):
0 = СР-1251,
0 = IA5 (CCITT T.50)/ASCII (ANSI X3.4),
0 = бинарные данные,
0 = Latin 1 [17],
0 = бинарные данные,
0 = JIS(X 0208-1990),
0 = Cyrilic [18],
0 = Latin/Hebrew [19],
0 = UCS2 [20].
- ACL (Authorization Code Length) - длина в байтах поля АСН,
содержащего код авторизации на стороне получателя;
- AC (Authorization Code) - код авторизации, используемый на принимающей
стороне (АСН) и обеспечивающий ограничение доступа на выполнение отдельных
команд. Если указанный в данном поле код не совпадает с ожидаемым
значением, то в ответ на такую команду или сообщение АСН должна отправить
подтверждение с типом CC_ILL;
- CD (Command Data) - тело команды, параметры, данные возвращаемые на
команду-запрос, использующие кодировку из поля CHS или значение по
умолчанию. Размер данного поля определяют, исходя из общей длины записи
протокола уровня поддержки услуг и длины предшествующих полей в данной
подзаписи.
В таблице В.23 представлен формат команд терминала. Список команд, и
их описание представлены в перечислении б) В.3.4.1 Данное поле может
иметь нулевую длину (отсутствовать) в тех случаях, когда в ответ на
команду или сообщение для АСН не передаются никакие данные.
Таблица В.23 - Формат команд терминала
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
ADR (Address) |
М |
USHORT |
2 |
|||||||
SZ(Size) |
ACT (Action) |
М |
BYTE |
1 |
||||||
CCD (Command Code) |
М |
USHORT |
2 |
|||||||
DT (Data) |
О |
BINARY |
0 ... 65200 |
Поля формата команд терминала:
- ADR (Address) - адрес модуля, для которого данная команда
предназначена. Адрес определяют, исходя из начальной конфигурации
АСН или из списка модулей, который может быть получен при регистрации
терминала через сервис EGTS_AUTH_SERVICE и передачи подзаписей
EGTS_SR_MODULE_DATA;
- SZ (Size) - объем памяти для параметра (используется совместно с
действием АСТ=3. При добавлении нового параметра в АСН, данное поле
определяет, что для нового параметра требуется байт памяти в АСН;
- ACT (Action) - описание действия, используемое в случае типа
команды (поле СТ = СТ_СОМ подзаписи EGTS_SR_COMMAND _DATA). Значение поля
может быть одним из следующих вариантов:
0 - параметры передаваемой команды, которая задается кодом из
поля CCD,
0 - запрос значения. Используется для запроса информации,
хранящейся в АСН. Запрашиваемый параметр определяется кодом из поля CCD,
0 - установка значения. Используется для установки нового
значения определенному параметру в АСН. Устанавливаемый параметр
определяется кодом из поля CCD, а его значение полем DT,
0 - добавление нового параметра в АСН. Код нового параметра
указывается в поле CCD, его тип в поле SZ, а значение в поле DT,
0 - удаление имеющегося параметра из АСН. Код удаляемого
параметра указывается в поле CCD.
- CCD (Command Code) - код команды при АСТ=0 (см. таблицу В.21)
или код параметра при АСТ=1..4 (см. таблицу В.24);
- DT (Data) - запрашиваемые данные или параметры, необходимые для
выполнения команды. Данные записываются в данное поле в формате,
зависящем от типа команды (см. таблицу В.24).
В таблице В.24 представлен формат подтверждения на ранее переданную
команду для терминала при СТ = CT_COMCONF при условии, если с АСН
передана сопутствующая информация. Описанная структура подтверждения на
ранее переданную команду содержится в поле CD (см. таблицу В.22).
Таблица В.24 - Формат подтверждения на команду для терминала
Бит 7 |
Бит 6 |
Бит 5 |
Бит 4 |
Бит 3 |
Бит 2 |
Бит 1 |
Бит 0 |
Тип |
Тип данных |
Размер, байт |
ADR (Address) |
М |
USHORT |
2 |
|||||||
CCD (Command Code) |
М |
USHORT |
2 |
|||||||
DT (Data) |
О |
BINARY |
0 ... 65200 |
Поля формата подтверждения на команду для терминала:
- ADR (Address) - адрес модуля, от которого передано подтверждение. Адрес определяют исходя из начальной конфигурации АСН или из списка модулей, который может быть получен при регистрации терминала через сервис EGTS_AUTH_SERVICE и передачи подзаписей EGTS_SR_MODULE_DATA;
- CCD (Command Code) - код команды (см. таблицу В.25) или параметра (см. таблицу В.26), в соответствии с которым передана сопутствующая информация в поле DT;
- DT (Data) - сопутствующие данные, тип и состав которых определен значением поля CCD. Список и состав сопутствующих данных, передаваемых в подтверждении на некоторые команды, представлен в таблице В.27;
б) описание команд, параметров и подтверждений
В таблице В.25 представлен список команд для АСН, их кодовое обозначение, тип и предельно допустимое значение параметров.
Таблица В.25 - Список команд для АСН
Название команды |
Код |
Тип и предельно допустимые значения параметров |
Описание |
EGTS_RAW_DATA |
0x0000 |
BINARY (до 65200 байт) |
Команда для передачи произвольных данных. Применяется, например, для передачи команд, сообщений и данных на периферийные устройства, модули, подключенные к основному блоку Терминала, в определяемом данным модулем формате. При этом терминал не должен анализировать данные из поля DT и в неизменном виде передать их по адресу, определяемому полем ADR |
EGTS_TEST_MODE |
0x0001 |
BYTE |
Команда начала/окончания тестирования терминала: 1 - начало тестирования; 0 - окончание тестирования |
EGTS_TEST_GET_ERRORS |
0x0004 |
- |
Запрос кодов ошибок |
EGTS_TEST_CLEAR_ERRORS |
0x0005 |
- |
Очистка кодов ошибок. Для обработки данной команды оператор должен установить корректные значения полей ACL и АСН |
EGTS_CONFIG_RESET |
0x0006 |
- |
Возврат к заводским установкам. Удаляются все установленные пользователем параметры, и производится возврат к заводским установкам. Для обработки данной команды оператор должен установить корректные значения полей ACL и АСН |
EGTS_SET_AUTH_CODE |
0x0007 |
BINARY |
Установка кода авторизации на стороне АСН. Для обработки данной команды оператор должен установить корректные значения полей ACL и АСН. После подтверждения данной команды, АСН будет использовать уже новые данные для сравнения со значением из поля АСН в некоторых присылаемых на АСН командах |
EGTS_RESTART |
0x0008 |
- |
Команда производит перезапуск основного ПО АСН. Для обработки данной команды оператор должен установить корректные значения полей ACL и АСН |
В таблице В.26 представлен список параметров АСН.
Таблица В.26 - Список параметров АСН
Имя параметра |
Код |
Тип параметра |
Значение по умолчанию |
Описание |
Радио mute (только для конфигурации дополнительного оборудования) | ||||
EGTS_RADIO_MUTE_DELAY |
0x0201 |
INT |
500 |
Задержка между установкой сигнала радио mute и началом проигрывания звука, мс |
EGTS_RADIO_UNMUTE_DELAY |
0x0202 |
INT |
500 |
Задержка между снятием сигнала радио mute и окончанием проигрывания звука, мс |
Установка общего назначения | ||||
EGTS_GPRS_APN |
0x0203 |
STRING |
Параметр, определяющий точку доступа GPRS |
|
EGTS_SERVER_ADDRESS |
0x0204 |
STRING |
|
Адрес и порт сервера для связи с использованием TCP/IP протокола |
EGTS_SIM(USIM)_PIN |
0x0205 |
INT |
0 |
PIN код SIM (USIM)карты |
EGTS_AUTOMATIC_REGISTRATION |
0x0207 |
BOOLEAN |
1 |
Флаг, разрешающий автоматическую регистрацию SIM (USIM) в сети после включения питания |
EGTS_SELFTEST_INTERVAL |
0x0208 |
INT |
0 |
Интервал проведения внутреннего тестирования, часы. Если значение установлено в 0, то самотестирование не проводится |
EGTS_POST_TEST_REGISTRATION_TIME |
0x0209 |
INT |
0 |
Промежуток времени, в течение которого терминал остается зарегистрированным в сети после передачи результатов самотестирования оператору системы, с |
EGTS_GARAGE_MODE_END_DISTANCE |
0x020B |
INT |
300 |
Дистанция, на которой режим "автосервис" выключается автоматически, м |
EGTS_GARAGE_MODE_PIN |
0x020C |
ENUM {NONE=0, PIN_1=1, .. PIN_8=8} |
0 |
Линия, сигнализирующая, что система находится в режиме "в гараже" NONE - нет сигнализации режима PIN_X - PIN_X линия, активируемая, когда система находится в данном режиме |
EGTS_TEST_MODE_WATCHDOG |
0x020E |
INT |
10 |
Интервал тревожного счетчика в режиме тестирования, мин |
Конфигурация и конфигурационные данные услуг | ||||
Пакетная передача данных | ||||
EGTS_USE_GPRS_WHITE_LIST |
0x0230 |
BOOLEA |
1 |
Параметр, указывающий на необходимость использования GPRS_WHITE_LIST при организации пакетной передачи данных |
EGTS_GPRS_WHITE_LIST |
0x0231 |
ARRAY OF STRING |
,, , , , , , , , ,,, , ,,, |
Список сетей, в которых разрешена пакетная передача данных. Если список GPRS_WHITWE_LIST пуст, то пакетная передача данных запрещена, MCC (Mobile Country Code) 3 символа + MNC(Mobile Network Code) 3 символа |
Режим тестирования | ||||
EGTS_TEST_REGISTRATION_TIMEOUT |
0x0241 |
INT |
5 |
Если АСН была зарегистрирована в сети посредством нажатия на кнопку включения дополнительных услуг, и команда на запуск сессии тестирования не была получена со стороны оператора системы в течение данного промежутка времени, то терминал должен прекратить регистрацию в сети, мин |
EGTS_TEST_REGISTRATION_PERIOD |
0x0242 |
INT |
0 |
Если АСН была зарегистрирована в сети посредством нажатия на кнопку включения дополнительных услуг, то последующая регистрация терминала в сети при нажатии на кнопку включения дополнительных услуг возможна не ранее чем через данный промежуток времени. Если значение установлено в 0, то ограничений на последующую регистрацию терминала в сети не накладывается, мин |
Прочие параметры | ||||
EGTS_GNSS_POWER_OFF_TIME |
0x0301 |
INT |
0 |
Промежуток времени, через который отключается питание ГНСС приемника после выключения зажигания, мс |
EGTS_GNSS_DATA_RATE |
0x0302 |
INT/ 1, 2,5, 10 |
1 |
Темп выдачи данных ГНСС приемником, Гц |
EGTS_GNSS_MIN_ELEVATION |
0x0303 |
INT/ 5...15 |
5 |
Минимальное значение угла возвышения (угла отсечки) навигационных космических аппаратов, градусы |
Параметры устройства | ||||
EGTS_UNIT_SERIAL_NUMBER |
0x0400 |
STRING |
Серийный номер устройства |
|
EGTS_UNIT_HW_VERSION |
0x0401 |
STRING |
HIT |
Версия аппаратной платформы |
EGTS_UNIT_SW_VERSION |
0x0402 |
STRING |
Версия программного обеспечения |
|
EGTS_UNIT_VENDOR_ID |
0x0403 |
INT |
0 |
Идентификатор поставщика устройства |
Параметры устройства | ||||
EGTS_UNIT_ID |
0x0404 |
INT |
0 |
Уникальный идентификатор устройства, назначаемый оператором системы при первой активизации устройства |
EGTS_UNIT_IMEI |
0x0405 |
STRING |
Номер IMEI |
|
EGTS_UNIT_RS485_BAUD_RATE |
0x0406 |
INT |
19200 |
Скорость порта RS485 |
EGTS_UNIT_RS485_STOP_BITS |
0x0407 |
INT |
1 |
Число стоп битов при передаче данных через порт RS485 |
EGTS_UNIT_RS485_PARITY |
0x0408 |
INT/0,1,2 |
0 |
Способ проверки на четность при передаче данных через порт RS485: 0 - проверка не производится; 1 - проверка типа ODD; 2 - проверка типа EVEN |
EGTS_UNIT_LANGUAGE_ID |
0x0410 |
INT |
0 |
Предпочтительный язык для голосового общения по [13]: 0x5F - русский |
EGTS_UNIT_HOME_DISPATCHER_ID |
0x0411 |
INT |
0 |
Идентификатор телематической платформы, в хранилище которой находится информация об учетных данных устройства, списке предоставляемых услуг и их статусах |
Параметры устройства | ||||
EGTS_SERVICE_AUTH_METHOD |
0x0412 |
INT |
1 |
Метод использования услуг: 1 - простой метод (подразумевает, что все услуги по умолчанию доступны терминалу); 0 - с подтверждением (разрешены к использованию только те услуги, информация о разрешении использования которых пришла с телематической платформы) |
EGTS_SERVER_CHECK_IN_PERIOD |
0x0413 |
INT |
30 |
Время между попытками установить соединение TCP/IP с сервером, с |
EGTS_SERVER_CHECK_IN_ATTEMPTS |
0x0414 |
INT |
5 |
Число попыток установления TCP/IP соединения с сервером, по достижению которого будет произведена повторная установка сессии верхнего уровня (GPRS) |
EGTS_SERVER_PACKET_TOUT |
0x0415 |
INT |
5 |
Время, в течение которого терминал ожидает подтверждения с сервера на отправленный пакет, с |
Параметры устройства | ||||
EGTS_SERVER_PACKET_RETRANS-MIT_ATTEMPTS |
0x0416 |
INT 3 |
3 |
Число попыток повторной отправки неподтвержденного пакета, по достижении которого терминал производит повторную инициализацию сессии на уровне TCP/IP |
EGTS_UNIT_MIC_LEVEL |
0x0417 |
INT/0...10 |
8 |
Уровень чувствительности микрофона |
EGTS_UNIT_SPK_LEVEL |
0x0418 |
INT/0...10 |
6 |
Уровень громкости динамика |
Значения следующих параметров АСН могут быть запрошены, но не могут быть изменены или удалены при помощи сервиса команд: EGTS_UNIT_SERIAL_NUMBER, EGTS_UNIT_HW_VERSION, EGTS_UNIT_SW_VERSlON, EGTS_UNIT_VENDOR_ID, EGTS_UNIT_IMEI. Значения указанных параметров выставляются производителями соответствующих модулей и блоков терминала, а также разработчиками ПО для них.
Устройствами, установленными в конфигурации штатной системы, должна быть реализована поддержка следующих параметров:
- EGTS_GPRS_APN;
- EGTS_SERVER_ADDRESS;
- EGTS_SIM (USIM)_PIN;
- EGTS_AUTOMATIC_REGISTRATION;
- EGTS_SELFTEST_INTERVAL;
- EGTS_POST_TEST_REGISTRATION_TIME;
- EGTS_TEST_MODE_END_DISTANCE;
- EGTS_GARAGE_MODE_END_DISTANCE;
- EGTS_TEST_MODE_WATCHDOG;
- EGTS_USE_GPRS_WHITE_LIST;
- EGTS_GPRS_WHITE_LIST;
- EGTS_TEST_REGISTRATION_TIMEOUT;
- EGTS_TEST_REGISTRATION_PERIOD;
- EGTS_GNSS_POWER_OFF_TIME;
- EGTS_GNSS_DATA_RATE;
- EGTS_GNSS_MIN_ELEVATION;
- EGTS_UNIT_SERIAL_NUMBER;
- EGTS_UNIT_HW_VERSION;
- EGTS_UNIT_SW_VERSION;
- EGTS_UNIT_VENDOR_ID;
- EGTS_UNIT_ID;
- EGTS_UNIT_LANGUAGE_ID;
- EGTS_UNIT_IMEI;
- EGTS_UNIT_HOME_DISPATCHER_ID.
В таблице В.27 представлен список подтверждений на команды и сообщения от АСН, их кодовое обозначение, тип и предельно допустимое значение параметров.
Таблица В.27 - Список подтверждений на команды и сообщения от АСН
Название команды |
Код |
Тип и число параметров |
Описание |
EGTS_RAW_DATA |
0x0000 |
BINARY (до 65200 байт) |
Данные, поступающие от периферийных устройств, модулей, подключенных к АСН, в определяемом данным модулем формате |
EGTS_SELF_TEST_RESULT |
0x0002 |
STRING |
Сообщение о результатах самодиагностики. Генерируется АСН автоматически без запроса от оператора |
EGTS_TEST_GET_ERRORS |
0x0004 |
BINARY (16 байт) |
Список кодов ошибок состояний блоков, модулей и подсистем терминала |
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.