Таблица 1

1.4. Взаимодействие ТС ОРМ с оборудованием ПУ на транспортном уровне осуществляется по схеме "клиент - сервер":

- в качестве "сервера" должна выступать ТС ОРМ;

- в качестве "клиента" выступает оборудование ПУ.

1.4.1. Для взаимодействия ТС ОРМ и ПУ организованы четыре канала передачи данных:

- кпд 1 - канал управления;

- кпд 2 - канал данных;

- кпд 3 - канал мониторинга;

- кпд 4 - канал неформатированных данных.

1.4.2. Канал управления (кпд 1) служит для передачи:

- от ПУ в ТС ОРМ запросов (команд);

- от ТС ОРМ на ПУ ответов и "сигналов".

1.4.3. Канал данных (кпд 2) служит для передачи:

- от ТС ОРМ на ПУ блоков данных отчетов генерируемых ТС ОРМ в качестве ответов на запросы из ПУ, "сигнала" Heartbeat;

- от ПУ в ТС ОРМ подтверждений о принятии блоков данных отчетов.

1.4.4. Канал мониторинга (кпд 3) служит для передачи:

- от ПУ в ТС ОРМ запросов о текущей конфигурации оборудования, системного и прикладного ПО ТС ОРМ и запросов на модификацию конфигурации;

- от ТС ОРМ на ПУ ответов на запросы ПУ, "сигналов".

1.4.5. Канал неформатированных данных (кпд 4) служит для передачи:

- от ПУ в ТС ОРМ команд на виды передаваемых неформатированных данных;

- от ТС ОРМ на ПУ неформатированных данных, "сигналов".

1.4.6. кпд 1, кпд 2, кпд 3, кпд 4 представляют собой ТСР-соединения, создаваемые для подключения на заранее определенные порты оборудования ТС ОРМ. ТС ОРМ выполняет прослушивание данных портов для создания ТСР-соединений с ПУ.

1.5. ПУ выполняет попытки установления подключения с ТС ОРМ в соответствии с задаваемым интервалом по предоставленным ТС ОРМ ТСР-портам.

1.5.1. Установление ПУ соединений с ТС ОРМ по каналам кпд 1, кпд 2 осуществляется в следующей последовательности:

- ПУ устанавливает ТСР-соединение с ТС ОРМ по порту канала кпд 1;

- выполняется процедура взаимной SSL/TLS аутентификации в соответствии с п. 1.20 настоящего Приложения;

- ПУ устанавливает ТСР-соединение с ТС ОРМ по порту канала кпд 2;

- выполняется процедура взаимной SSL/TLS аутентификации в соответствии с п. 1.20 настоящего Приложения

- после успешной аутентификации ПУ выполняет создание сессии с ТС ОРМ;

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

1.5.2. Установление ПУ соединений с ТС ОРМ по каналам кпд 3 и кпд 4 осуществляется независимо друг от друга и от наличия установленных соединений по каналам кпд 1 и кпд 2:

- ПУ устанавливает ТСР-соединение с ТС ОРМ по ТСР-порту канала кпд 3/кпд 4;

- выполняется процедура взаимной SSL/TLS аутентификации в соответствии с п. 1.20 настоящего Приложения;

- после успешной аутентификации ПУ выполняет создание сессии с ТС ОРМ.

1.6. После успешной аутентификации ПУ посылает на ТС ОРМ команды в соответствии с Приложением N 7.

1.7. ПУ разрывает соединения с ТС ОРМ, если в течении трех периодов приема "сигнала" Heartbeat в каналах не было сетевой активности. При отсутствии подтверждения посланного "сигнала" Heartbeat в течение времени "максимальный размер задержки подтверждения запроса или сигнала" ТС ОРМ разрывает соединения с ПУ по соответствующему каналу.

1.8. ТС ОРМ должны обеспечивать одновременное подключение нескольких ПУ. Максимальное количество одновременно подключенных ПУ для одной ТС ОРМ - 100. ТС ОРМ обслуживает подключенные ПУ независимо друг от друга.

1.9. В ТС ОРМ на одновременном выполнении могут находиться не менее 50 одновременно запущенных задач, осуществляющих подготовку данных.

1.10. Каждому идентифицированному на ТС ОРМ ПУ назначается приоритет выполнения задач. В случае поступления на ТС ОРМ задач от различных ПУ вероятность постановки на выполнение задачи конкретного ПУ зависит от назначенного приоритета данного ПУ и приоритетов других ПУ. Распределение вероятности запуска задач от различных ПУ задается приоритетом каждого конкретного ПУ. Конфигурация по умолчанию должна обеспечивать равномерное распределение вероятности запуска задач от каждого ПУ. ТС ОРМ должны обеспечивать возможность конфигурирования приоритетов ПУ. ТС ОРМ должны обеспечивать одновременное выполнение задач по каждому идентифицированному ПУ:

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

- по пополнению справочников - не менее 1;

- по принадлежности абонентов - не менее 4.

1.11. Единицей обмена в кпд 1, кпд 2, кпд 3 и кпд 4 является "Сообщение" (Message). Форматы "Сообщений" описаны в Приложении N 7 на языке абстрактного описания синтаксиса (ASN.1) согласно ГОСТ Р ИСО/МЭК 8824-1-2001. Способ кодирования сериализованных "Сообщений" соответствует отличительным (DER) по ГОСТ Р ИСО/МЭК 8825-1-2003.

1.12. Интерфейс взаимодействия между ПУ и ТС ОРМ предусматривает наличие следующих видов "Сообщений":

- "запросы" - передаются от ПУ в ТС ОРМ по кпд 1;

- "ответы" - передаются из ТС ОРМ на ПУ по кпд 1;

- "сигналы" - передаются из ТС ОРМ на ПУ по кпд 1 и кпд 2 (для кпд 2 только "сигнал" Heartbeat);

- "отчеты" - формируются ТС ОРМ в качестве ответов на запросы из ПУ, передаются на ПУ по кпд 2;

- "подтверждения" о принятии "отчетов" - передаются из ПУ в ТС ОРМ по кпд 2;

- "подтверждения" о принятии "сигналов" - передаются из ПУ в ТС ОРМ по кпд 1 и кпд 2 (для кдп 2 только для "сигнала" Heartbeat).

1.13. Интерфейс взаимодействия между ПУ и ТС ОРМ по каналу кпд 3 предусматривает наличие следующих видов "Сообщений":

- "запросы";

- "ответы";

- "сигнал" Heartbeat;

- подтверждения о принятии "сигнала" Heartbeat и ответов.

1.14. Интерфейс взаимодействия между ПУ и ТС ОРМ по каналу кпд 4 предусматривает наличие следующих видов "Сообщений":

- "запросы" - передаются от ПУ в ТС ОРМ;

- "ответы" - передаются из ТС ОРМ на ПУ;

- "сигналы" - передаются из ТС ОРМ на ПУ;

- "отчеты" - формируются ТС ОРМ в качестве ответов на запросы из ПУ;

- "подтверждения" о принятии "отчетов" - передаются из ПУ в ТС ОРМ;

- "подтверждения" о принятии "сигналов" - передаются из ПУ в ТС ОРМ.

1.15. ТС ОРМ выполняет любые действия, связанные с выдачей информации о пользователях услуг связи и предоставленных им услугах связи, управлением и мониторингом КТС и ПО ТС ОРМ только по "запросам" ПУ.

1.15.1. ТС ОРМ обеспечивает прием и обработку следующих "запросов", передаваемых с ПУ по кпд 1:

- "Запрос на открытие сессии" (ConnectRequest);

- "Запрос на закрытие сессии" (DisconnectRequest);

- "Запрос готовности данных" (DataReadyRequest);

- "Запрос загрузки данных" (DataLoadRequest);

- "Запрос удаления данных" (DataDropRequest);

- "Запрос прерывания загрузки данных" (DataInterruptRequest);

- "Запрос на создание задачи по обработке информации" (CreateTaskRequest);

- "Запрос на постановку/снятие объекта наблюдения на контроль" (UNIControlTaskRequest);

- "Запрос на создание задачи по обработке неформализованных данных" (NonFormalizedTaskRequest).

1.15.2. ТС ОРМ должны обеспечивать одновременную передачу блоков данных отчетов для нескольких завершенных поисковых задач по каналу кпд 2. ТС ОРМ должны обеспечивать возможность многократной передачи отчетов выполненных задач на ПУ.

1.15.3. По запросу ПУ "Запрос загрузки данных" канала кпд 1 ТС ОРМ должны обеспечивать передачу блоков отчетов по каналу кпд 2 по запрошенной задаче без внесения дополнительных временных задержек между операциями по получению записей результата задачи и преобразования их в блоки.

1.15.4. На каждый "запрос" по кпд 1 ТС ОРМ на ПУ посылается "ответ" о принятии к обработке этого запроса. ТС ОРМ обеспечивают посылку по кпд 1 на ПУ следующих "ответов":

- "Ответ на запрос открытия сессии" (ConnectResponse);

- "Ответ на запрос закрытия сессии" (DisconnectResponse);

- "Ответ на запрос готовности данных" (DataReadyResponse);

- "Ответ на запрос загрузки данных" (DataLoadResponse);

- "Ответ на запрос удаления данных" (DataDropResponse);

- "Ответ на запрос прерывания загрузки данных" (DataInterruptResponse);

- "Ответ на запрос создания задачи" (TaskResponse);

- "Ответ на запрос на постановку/снятие объекта наблюдения на контроль" (UNIControlTaskResponse);

- "Ответ на запрос создания задачи по обработке неформализованных данных" (NonFormalizedTaskResponse).

1.15.5. По "Запросу на создание задачи по обработке информации" ТС ОРМ обеспечивают подготовку и выдачу информации из БД ТС ОРМ для следующих групп задач:

- "Задачи пополнения справочников (нормативно-справочная информация)" (DictionaryTask);

- "Задачи поисков по принадлежности абонентов" (AbonentsTask);

- "Задачи поисков по соединениям абонентов" (ConnectionsTask);

- "Задачи предоставления сведений о наличии данных" (PresenseTask).

В группу "Задачи пополнения справочников (нормативно-справочная информация)" входят запросы на получение информации справочников:

- операторы почтовой связи и их филиалы, связи, обслуживаемые ТС ОРМ;

- справочник типов документов, удостоверяющих личность;

- справочник узлов почтовой связи.

В группу "Задачи поисков по принадлежности абонентов" входят:

- "Задача на поиск информации об идентификаторах абонентов сети оператора связи, зарегистрированных на физическое или юридическое лицо" (AbonentsTask).

Поиск информации выполняется в накапливаемой ТС ОРМ информации о юридических лицах, заключивших договоры на предоставление услуг почтовой связи.

В группу "Задачи поисков по соединениям абонентов" входят:

- "Задача на поиск соединений абонентов" (ConnectionsTask).

В случае, если в качестве параметров "задачи на поиск соединений абонентов" указаны только диапазон времени и (опционально) филиал оператора связи, ТС ОРМ должны сформировать результат выполнения поисковой задачи, содержащий все соединения всех абонентов за указанный диапазон времени.

В группу "Задачи предоставления сведений о наличии данных" (PresenseTask) входят:

- запрос наличия информации по пользователям услугами почтовой связи;

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

- запрос наличия справочников.

1.15.6. По "Запросу на создание задачи по обработке неформализованных данных" ТС ОРМ обеспечивают подготовку и выдачу информации из БД ТС ОРМ по следующим видам запросов:

- "запрос получения списка типов сущностей" неформализованных данных ТС ОРМ (GetEntities);

- "запрос получения списка атрибутов сущности" (GetEntityAttributes);

- "задача поиска неформализованных данных" (ValidateN onFormalizedTask);

- "задача предоставления сведений о наличии неформализованных данных" (NonFormalizedPresenseTask).

1.15.7. По "Запросу на постановку/снятие объекта наблюдения на контроль";

- "запрос на создание объекта наблюдения и постановки его на контроль" (CreateUNIRequest);

- "запрос на снятие объекта наблюдения с контроля и удаление объекта наблюдения" (DropUNIRequest).

1.15.8. ТС ОРМ по "задаче поиска неформализованных данных" могут предоставлять доступ ПУ к системным журналам ТС ОРМ.

1.15.9. ТС ОРМ должны обеспечивать выполнение поисковых задач по строковым критериям, содержащими символы маскирования, включающие:

- "*" - обозначает любую комбинацию символов;

- "?" - обозначает любой один возможный символ.

ТС ОРМ должны обеспечивать выполнение поисковых задач по критериям, содержащим последовательность цифр с символом маскирования пробел (" "), означающим любую одну цифру.

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

1.15.10. В случае возникновения в ТС ОРМ исключительных ситуаций на ПУ передаются следующие "Сообщения" типа "Сигналы", содержащие информацию об уровне важности исключительной ситуации, ее влиянии на сохранность данных и выполнение задач:

- "Нет данных (связи) с ИС ОПС" - посылается в случае отсутствия от ИС ОПС информации в течение трех часов либо при отсутствии связи с ИС ОПС;

- "Перезапуск ПО" (RestartDB);

- "Попытка несанкционированного доступа" (UnauthorizedAccess);

- "Критическая ошибка ПО, потеря данных, дальнейшая работа невозможна" (CriticalError);

- "Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна" (MajorError);

- "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" (MinorError);

- "Тестовый пакет" (Heartbeat). Единственный, из "сигналов", передающийся по кпд 1, кпд 2, кпд 3, кпд 4 в отсутствие иной сетевой активности.

В ответ на "сигналы", поступившие от ТС ОРМ, ПУ должно передавать "подтверждения сигнала" об их приеме.

1.15.11. ТС ОРМ по "Запросу удаления данных" (DataDropRequest) должны:

- прерывать задачу, находящуюся на выполнении;

- удалять данные отчета по завершившейся задаче.

1.16. Требования к функционированию канала кпд 1 приведены в Приложении N 3.

1.17. Требования к функционированию канала кпд 2 приведены в Приложении N 4.

1.18. Требования к функционированию канала кпд 3 приведены в Приложении N 5.

1.19. Требования к функционированию канала кпд 4 приведены в Приложении N 6.

1.20. При установлении соединения ПУ и ТС ОРМ должны быть взаимно аутентифицированы. Аутентификация выполняется установлением SSL/TLS-соединения поверх установленного ТСР-соединения между ПУ и ТС ОРМ. Для взаимной аутентификации ПУ и ТС ОРМ предварительно создаются Х.509-сертификаты, которые сообщаются ПУ и ТС ОРМ. В случае невозможности аутентифицировать одну из сторон ТСР-соединение разрывается. Созданный для ПУ сертификат используется для аутентификации только одного данного ПУ на одной ТС ОРМ по всем каналам передачи данных - кпд 1, кпд 2, кпд 3, кпд 4. ПУ и ТС ОРМ должны использовать TLS версии 1.0. Требования к сертификатам (длины ключей, прочие параметры) должны согласовываться для каждой пары ТС ОРМ и ПУ отдельно.

1.21. Открытие сессии осуществляется выполнением процедуры аутентификации согласно п. 1.20 настоящего Приложения перед началом выполнения всех запросов. Открытие сессии осуществляется посылкой по каналу управления от ПУ к ТС ОРМ "Запроса на открытие сессии" (ConnectRequest).

1.22. "Запрос на открытие сессии" устанавливает следующие параметры сессии:

- "максимальное время отсутствия активности сессии" (session-timeout) - интервал времени, по истечении которого сессия принудительно прерывается от ТС ОРМ;

- "максимальный размер блока данных отчетов" (max-data-length) в строках записей БД;

- "размер окна для канала передачи данных" (data-packet-window-size);

- "максимальная длительность задержки начала передачи блоков отчетов" (data-load-timeout);

- "максимальный размер задержки подтверждения о получении данных" (data-packet-response-timeout);

- "максимальный размер задержки подтверждения запроса или сигнала" (request-response-timeout).

Любое сообщение в соответствии с ASN.1-протоколом взаимодействия ТС ОРМ и ПУ (Приложение N 8) считается сетевой активностью.

1.22.1. ТС ОРМ при получении сообщения "Запрос на открытие сессии" анализируют параметр "размер окна для канала передачи данных", определяет максимально возможный размер окна, не превышающий полученного от ПУ. ТС ОРМ определяют минимальные значения таймаутов из параметров сессии, выбирая их не меньше, чем переданные в сообщении "Запрос на открытие сессии" (ConnectRequest). Рассчитанные значения размеров окна и таймаутов ТС ОРМ передает на ПУ в сообщении "Ответ на открытие сессии" (ConnectResponse). Полученные ПУ значения в сообщении "Ответ на открытие сессии" являются параметрами сессии между ПУ и ТС ОРМ.

1.23. Закрытие сессии осуществляется посылкой по каналу управления или каналу мониторинга от ПУ к ТС ОРМ "Запроса на закрытие сессии" или по истечению допустимого времени отсутствия активности ТС ОРМ, с посылкой сообщения-сигнала "Прерывание текущей сессии по таймауту". При этом ТС ОРМ и ПУ осуществляют разрыв текущих ТСР соединений канала управления и канала данных или канала мониторинга или канала неформатированных данных

1.24. ПУ посылает ТС ОРМ "запросы" асинхронно, независимо от получения от ТС ОРМ "ответа" о приеме предыдущего "запроса".

1.25. "Запрос на создание задачи по обработке информации" приводит к созданию в ТС ОРМ задачи по обработке данных в БД ТС ОРМ, которой присваивается номер (идентификатор) задачи, передаваемый в "Ответе на запрос создания задачи" (TaskResponse). Идентификаторы задач генерируются ТС ОРМ независимо от сессий и являются уникальными в данной ТС ОРМ. ТС ОРМ присваивают идентификаторы задачам и выполняет обработку задач независимо для различных ПУ.

1.26. ПУ получает информацию о ходе выполнения и завершения обработки задач в ИС, посылая запрос "Запрос готовности данных". После завершения выполнения задачи, данные, сформированные в результате выполнения задачи, становятся доступными для загрузки в ПУ или для удаления.

1.27. ТС ОРМ при получении "Запрос загрузки данных" по кпд 1 формируют сообщения типа "отчет", состоящие из блоков данных обработанной задачи и передает их на ПУ по кпд 2.

1.28. Количество строк в каждом блоке не превышает параметр "максимальный размер блока данных отчетов", заданный при открытии сессии.

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

1.30. Данные задачи, полученные в одной сессии, могут быть считаны и/или удалены в другой сессии ПУ, инициировавшим данную задачу. Данные по завершенной задаче доступны между сессиями по тому же идентификатору задачи. При получении задачи "запрос загрузки данных" (DataLoadRequest) от ПУ, не являющегося инициатором данной задачи, ТС ОРМ посылают ответ на "запрос загрузки данных", в котором указывается отсутствие результата исполнения задачи (data-exists), а в поле "краткое описание ошибки" (error-description) записывается расшифровка отказа в доступе к данным задачи. Далее ТС ОРМ посылают на этот ПУ "сигнал" попытки несанкционированного доступа (unauthorized-access) и ожидают его подтверждения.

1.31. ТС ОРМ производят уничтожение данных, сформированных в результате выполнения задачи и самой выполненной задачи после поступления с ПУ запроса на удаление данных.

1.32. В случае возникновения в ТС ОРМ или каналах передачи данных исключительных ситуаций на ПУ передаются "Сообщения" типа "Сигнал".