Введение
В настоящее время Минздравом в рамках национального проекта «Здравоохранение» реализуется федеральный проект «Создания единого цифрового контура здравоохранения на основе ЕГИСЗ» (далее – «Цифровой контур»). Проект направлен на создание механизмов взаимодействия медицинских организаций на основе ЕГИСЗ, что должно обеспечить цифровое преобразование и повышение эффективности функционирования отрасли здравоохранения на всех уровнях и создать условия для использования гражданами электронных услуг и сервисов в сфере здравоохранения. Более подробно об этом рассказано тут http://www.kmis.ru/blog/o-proekte-sozdaniia-edinogo-tsifrovogo-kontura .
Решение поставленных проектом задач будет осуществляться посредством внедрения и развития в регионах России информационных систем трёх основных видов:
- государственных информационных систем в сфере здравоохранения (ГИС СЗ) субъектов РФ – то, что ранее мы привычно называли региональными медицинскими информационными системами (РМИС).
- медицинских информационных систем медицинских организаций (МИС МО)
- информационных систем фармацевтических организаций (ИС ФО)
Частью 4 ст. 91 323-ФЗ, а также подпунктом 5.2.200 «Положения о Министерстве здравоохранения Российской Федерации», утверждённого постановлением правительства РФ от 19.06.2012 № 608, предусмотрено, что Минздравом должны быть разработаны и нормативно утверждены требования к этим информационным системам.
Во исполнение этого положения издан приказ Минздрава №911н от 24.12.2018 «Об утверждении Требований к государственным информационным системам в сфере здравоохранения субъектов Российской Федерации, медицинским информационным системам медицинских организаций и информационным системам фармацевтических организаций».
Работа над документом велась Минздравом с привлечением экспертного сообщества в течение 2018 года. За основу были взятые утвержденные министром здравоохранения 1 февраля 2016 года «Методические рекомендации по обеспечению функциональных возможностей медицинских информационных систем медицинских организаций (МИС МО)» http://portal.egisz.rosminzdrav.ru/materials/351, а также «Методические рекомендации по обеспечению функциональных возможностей региональных медицинских информационных систем (РМИС)», утверждённые 28 июня 2016 года http://portal.egisz.rosminzdrav.ru/materials/391.
Приказом Минздрава предусмотрено, что:
Государственные информационные системы в сфере здравоохранения субъектов Российской Федерации (ГИС СЗ) предназначены для сбора, хранения, обработки и предоставления информации, необходимой для информационной поддержки управления деятельностью в сфере охраны здоровья, включая информацию о медицинских и фармацевтических организациях и об осуществлении ими медицинской и фармацевтической деятельности.
Медицинские информационные системы медицинских организаций (МИС МО) предназначены для сбора, хранения, обработки и представления информации, необходимой для автоматизации процессов оказания и учета медицинской помощи и информационной поддержки медицинских работников, включая информацию о пациентах, об оказываемой им медицинской помощи и о медицинской деятельности медицинских организаций.
Информационные системы фармацевтических организаций (ИС ФО) содержат информацию, необходимую для автоматизации процессов осуществления фармацевтической деятельности и информационной поддержки фармацевтических работников, включая информацию о фармацевтических организациях и об осуществлении ими фармацевтической деятельности.
МИС МО может быть представлена как самостоятельным продуктом, так и быть частью (подсистемой) единой региональной ГИС СЗ. В последнем случае, кроме прямых требований к ГИС СЗ, предусмотренных регулятором, она также должна соответствовать и всем установленным требованиям к МИС МО.
Обратим внимание, что согласно определению, ГИС СЗ должна содержать информацию по всем медицинским и фармацевтическим организациям региона, а это значит, что в ней должны быть представлены сведения и о частных организация, а не только государственных или муниципальных.
Операторами МИС МО, ГИС СЗ и ИС ФО являются региональные органы управления, уполномоченные на реализацию программ информатизации здравоохранения или организации, ими определенные. Таким образом, с юридической точки зрения оператором систем может быть не только региональное министерство или департамент здравоохранения – но и, например, министерство или департамент по информационным технологиям, если такое решение примет местная исполнительная власть субъекта РФ.
Главные особенности
В отличие от действовавших ранее «Методических рекомендаций», Приказ 911н имеет ряд существенных моментов, на которые необходимо обязательно обратить внимание и учитывать в текущей работе.
Самое первое – это общий характер документа. Раньше по МИС МО был свой документ, по РМИС – свой, а по ИФ ФО его вообще не было. Теперь Минздрав издал единый нормативно-правовой акт, регулирующий нормативные требования ко всем информационным системам здравоохранения.
Второе – документом урегулированы не только и не столько требования к функциям, но и требования к безопасности, применяемым общесистемным решениям и протоколам, а также к информационному взаимодействию информационных систем между собой, а также с ЕГИСЗ.
Требования к функциональным возможностям носят теперь обобщённый характер и направлены на информационное сопровождение ключевых бизнес-процессов как внутри МО, так и в сфере управления здравоохранением, а не на детальное прописывание реализации той или иной функции. Иными словами, ранее Минздрав своими «Метод. рекомендациями» точно и детально говорил, какая функция должна быть в той или иной подсистеме, и какова должна быть глубина реализации этой функции. Теперь регулятор формулирует свои требования скорее к процессам, а не к функциям, оставляя тем самым разработчикам больше свободы в практической реализации требуемых возможностей и даже в известной степени открывая пространство для новых идей, развития и конкуренции, но вынуждая при этом обеспечивать глубину проработки информационной системы в том или ином процессе.
Сами требования к функциям теперь даны в очень сжатой форме. Например, «Методические рекомендации по обеспечению функциональных возможностей МИС МО» содержали раньше 82 страницы текста, в новом Приказе Минздрава эти же функциональные возможности описаны на 4 листах.
Еще одно важное изменение: и в «Метод. рекомендациях» и в первых версиях Приказа 911н предусматривался поэтапный переход и развитие функциональных возможностей. Для этого все они были разделены на «базовый» и «расширенный» наборы. Базовые возможности следовало реализовать в течение 1 года после вступления приказа в силу (т.е. с 1 января 2020 г.), а расширенные – к 31.12.2020. Все это в финальной версии документа было удалено. Таким образом, как только приказ вступит в силу – все это требования к ГИС СЗ, МИС МО и ИС ФО сразу становятся обязательными к соблюдению.
Импортозамещение
Из технологических требований, пожалуй, самым главным и тяжелым для отрасли будет п. 9 б), согласно которому создание и последующее развитие информационных систем в сфере здравоохранения должны соответствовать требованиям постановления Правительства РФ от 16.11.2015 г. № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд». Мы детально рассмотрели этот нормативный акт и дополнения к нему в статьеhttps://webiomed.ru/blog/o-trebovaniiakh-k-informatsionnym-sistemam-zdravookhraneniia-v-chasti-podderzhki-otechestvennogo-po/
Для ясности поясним, что данное требование в приказе 911н означает, что МИС МО, ГИС СЗ и ИС ФО, начиная с 1 июля 2019 г., должны:
• Присутствовать в «Едином реестре российских программ для электронных вычислительных машин и баз данных», https://reestr.minsvyaz.ru/
• Обеспечивать работу пользователей на ПК и терминалах (тонких клиентах)
• Обеспечивать идентификацию и аутентификацию пользователей, в том числе с помощью ЕСИА.
• Работать в русском интерфейсе.
• Не требовать дополнительное ПО и шрифты, имеющие ограничения на его свободное распространение на территории РФ (читай – в Крыму).
• В случае работы через браузер поддерживать применение не менее 3 браузеров разных производителей, сведения хотя бы об одном из которых включены в единый реестр российского ПО.
• Поддерживать работу клиентской части под управлением не менее 2 ОС, включенных в единый реестр российского ПО, а также работу под управлением сертифицированных версий Microsoft Windows версии 7 и выше.
• Поддерживать работу серверной части под управлением не менее 2 ОС, включенных в единый реестр российского ПО, а также работу под управлением сертифицированных версий Microsoft Windows Server версии 2008 и выше.
• Иметь реализованные и задокументированные программные интерфейсы (API) для интеграции с другими системами, в том числе с ЕГИСЗ и иными информационными системами в сфере здравоохранения.
• Поддерживать достаточно широкий спектр возможностей по импорту/экспорту данных.
• Иметь развитую документацию, поставляемую с системой в электронной форме на русском языке.
Ну и наконец обратим внимание, что разработчик соответствующих систем должен будет соблюдать ряд дополнительных требований при оказании услуг технической поддержки, включая:
- Информационная поддержка пользователей должна осуществляться на всей территории РФ без ограничений.
- Сопровождение пользователей обеспечивается по телефону и электронной почте на русском языке в круглосуточном режиме.
- Контактная и иная информация должна быть доступна на официальном сайте компании-производителя.
- Должна быть обеспечена возможность сторонним разработчикам тестировать свои продукты в режиме интеграции с поставленной МИС МО, ГИС СЗ или ИС ФО.
Думаю, в настоящее время у нас на рынке пока отсутствуют программные продукты, которые абсолютно соответствовали бы всем заявленным требованиям импортозамещения и при этом имели бы выверенный и глубокий функционал, соответствующий всем положениям приказа. Боюсь, у операторов соответствующих систем некоторое время будет очень сложный выбор между продуктами, которые имеют всю необходимую функциональность и интеграции, но скорее всего лишь частичное соответствие импортозамещению и продуктами, полностью соответствующие предъявленным техническим требованиям – но не имеющие достаточной функциональности.
Ключевые технологические требования
Первый момент, на который обратим внимание – это требование п.9 к), согласно которому программно-технические средства информационных систем должны обеспечивать «… возможность информационного взаимодействия информационных систем между собой». Не секрет, что у нас в отрасли сейчас имеется серьезная проблема, связанная с тем, что в ряде регионов применяются различные МИС, информационный обмен между которыми не осуществляется. Более того, по-прежнему есть отдельные медицинские организации, чьи информационные системы не взаимодействуют ни с ЕГИСЗ, ни с региональными сервисами – такими как ИЭМК, «Электронная регистратура» и т.д. Причина этого явления достаточно часто была в технической незрелости отдельных решений или в нежелании разработчиков выполнять интеграции: предоставлять API и документацию. Именно как ответ на эту проблему ряд ОУЗ стали применять различные «интеграционные шины» и отдельные продукты для обмена данными.
Теперь Минздрав ввел правовые основания требовать наличие возможности интеграции от разработчиков информационных систем. Думаю, наличие этого требования постепенно сделает применение различных «интеграционных шин» неоправданным с нормативной точки зрения. Логика de jure выстраивается такая: если в регионе используется некая общая региональная система, не позволяющая подключить МИС МО или ИС ФО к себе – то эту проблему можно будет с нормативной точки зрения устранять путем доработки ГИС СЗ, а не путем применения отдельной интеграционной шины.
Из других важных технологических требований к ГИС СЗ, МИС МО и ИС ФО выделим следующее:
1. Должна быть обеспечена защита информации, содержащейся в соответствующей информационной системе, посредством применения организационных и технических мер защиты.
2. Программно-технические средства информационных систем должны:
a. Располагаться на территории РФ.
b. Иметь действующие сертификаты, выданные ФСБ и ФСТЭК в отношении применяемых средств защиты информации.
c. Хранить информацию в форме электронных документов, обеспечивая ее резервное копирование и восстановление.
d. Обеспечить контроль доступа к документам, протоколируя и сохраняя сведения о предоставлении доступа и операциях с документами и метаданными, а также осуществляя автоматическое ведение журналов учета точного времени и фактов размещения, удаления и изменения информации.
e. Обеспечивать бесперебойное ведение базы данных и защиту от несанкционированного доступа. Суммарная длительность перебоев в работе системы не должна превышать 4 часов в месяц.
3. Должна обеспечиваться поддержка юридически значимого электронного документооборота, а это значит – что должна поддерживаться сертифицированная усиленная квалифицированная электронная подпись.
4. Должны поддерживаться приём и передача сведений между информационной системой и ЕГИСЗ в объеме и сроках, предусмотренных постановлением правительства №555 от 05.05.2018 (подробно тут http://www.kmis.ru/blog/obsuzhdaem-proekt-polozheniia-o-egisz).
Функциональные возможности
Функциональные возможности региональных государственных информационных систем в сфере здравоохранения (ГИС СЗ) должны обеспечивать:
Поддержку принятия управленческих решений
- Управление потоками пациентов (привычно мы называем это «электронными регистратурами»)
- Управление скорой медицинской помощью
- Ведение интегрированной электронной медицинской карты
- Учет сведений о показателях работы здравоохранения региона, в том числе демографических показателей (рождаемость и смертность)
- Ведение специализированных регистров по отдельным нозологиям и категориям
- Сбор и обработку сведений об обеспеченности лекарственными препаратами, продуктами питания, медицинскими изделиями
- Проведение телемедицинских консультаций
- Организацию профилактики, включая диспансеризацию и профилактические осмотры
- Организацию имуннопрофилактики
- Ведение централизованной системы управления лабораторной диагностикой
- Ведение центрального архива медицинских изображений
- Автоматизацию процессов оказания медицинской помощи по отдельным нозологиям, самые важные из которых – онкология, сердечно-сосудистые заболевания, ведение беременных и пациенты, нуждающиеся в паллиативной помощи.
- Обращение медицинской документации (электронных листков нетрудоспособности, электронных рецептов и т.д.)
- Ведение единой региональной нормативно-справочной информации.
ГИС СЗ может включать иные информационные системы по решению Оператора.
Функциональные возможности медицинской информационной системы медицинской организации должны обеспечивать:
- Ведение электронной медицинской карты (ЭМК) пациента
- Мониторинг и управление потоками пациентов
- Поддержку принятия управленческих решений в МО
- Информационное взаимодействие с ГИС СЗ и ЕГИСЗ
- Оказание медицинской помощи с применением телемедицины
- Проведение профилактических осмотров и диспансеризации
- Проведение иммунопрофилактики
МИС МО может поддерживать иные функциональные возможности по решению Оператора.
Остановимся чуть подробнее на ключевых компонентах МИС МО. Системы должны поддерживать ведение юридически-значимой электронной медицинской карты (ЭМК) в следующем объеме:
- Протоколы врачебных осмотров, экспертиз, освидетельствований, сведений об оказанной медицинской помощи и т.д.
- Назначение диагностических исследований и результаты (протоколы) их проведения
- Назначение и получение результатов лабораторной диагностики, включая интеграцию с региональной ЛИС или ЛИС, входящей в состав МИС МО.
- Интеграцию с архивом медицинских изображений
- Выписка листков нетрудоспособности, включая электронные листки нетрудоспособности и интеграцию с ФГИСЗ ЕИИС «Соцстрах»
- Ведение индивидуальных программ абилитации и реабилитации
- Ведение и выдачи медицинских справок, заключений, выписок и т.д.
Подсистема мониторинга и управления потоками пациентов должна поддерживать:
- ведение расписаний приема врачей,
- ведение листов ожиданий,
- коечный фонд (для стационаров),
- учет прикрепленного населения,
- мониторинг сроков оказания медицинской помощи, предусмотренных программами госгарантий,
- интеграцию с региональной системой управления потоками пациентов (электронной регистратурой), а через нее – с сервисами личного кабинет пациента «Мое здоровье».
Подсистема поддержки принятия управленческих решений должна поддерживать:
- автоматизированное формирование статистики,
- интеграцию с ТФОМС,
- полностью автоматические взаиморасчеты по ОМС на основе данных из ЭМК, включая ФЛК и МЭК,
- информационную поддержку работы руководителя МО,
- автоматизацию учета лекарственных средств,
- автоматизацию службы питания и т.д.
Обратим внимание, что формирование реестров счетов на основании «заколачивалок» талонов амбулаторных пациентов и карт выбывшего из стационара не рассматривается регулятором, реестры должны формироваться именно на основании сведений, автоматически забираемых из ЭМК.
Требования к интеграциям
Обобщенный анализ технических и функциональных требований показывает, что применяемые в регионе информационные системы в сфере здравоохранения должны обеспечивать соблюдение ряда не всегда явно указанных, но тем не менее подразумеваемых требований по интеграционным возможностям, включая готовую интеграцию с:
- региональной системой бюро медико-социальной экспертизы (МСЭ) в части обмена сведениями о направлении на МСЭ;
- региональной информационной системой территориальных фондов ОМС в части автоматической актуализации сведений о застрахованном;
- федеральным сервисом нормативно-справочной информации в части автоматического двустороннего обновления онлайн сведений между региональной НСИ и федеральной НСИ, а также между МИС МО и региональной НСИ;
- федеральным регистром медицинских работников в части актуализации сведений обо всех медицинских работниках медицинской организации;
- федеральным реестром медицинских организаций в части актуализации сведений о медицинской организации и всех структурных подразделений;
- федеральной электронной регистратурой, к которой должны быть подключены все амбулаторно-поликлинические подразделения МО, осуществляющие первичный прием граждан;
- федеральной интегрированной электронной медицинской картой, к которой должны быть подключены все подразделения МО, участвующие в оказании медицинской помощи. Из МИС МО в ИЭМК должны передаваться структурированные сведения об оказанной гражданам медицинской помощи в формате, предусмотренном Минздравом;
- федеральным реестром электронных медицинских документов, к которому должны быть подключены все подразделения МО, участвующие в оказании медицинской помощи. В РЭМД должны передаваться сведения о медицинских документах в форме электронного документа, формирование и хранение которых осуществляется в медицинской организации;
- федеральной системой ЕГИСЗ «Соцстрах» в части ведения электронных листков нетрудоспособности
О проверке на соблюдение требований
В заключении хотелось бы напомнить, что федеральным проектом создания «Единого цифрового контура» предусмотрено, что регионы должны не просто внедрить МИС МО и ГИС СЗ – внедрённые системы должны официально соответствовать утвержденным требованиям Минздрава России, в том числе перечисленным требованиям к функциональным возможностям.
Очевидно, что для соблюдения этого положения должна быть окончательно выбрана и предложена определённая методика независимой оценки информационных систем на предмет соответствия вышедшему приказу. Диалог о такой процедуре и даже пилотные ее «обкатки» велись в последние несколько лет. Возможно, в ближайшее время мы выйдем на какую-то финально утверждённую процедуру независимой сертификации, т.к. разработчикам, утверждающим, что их продукт всем требованиям соответствует, на слово никто верить не станет. Особенно контролирующие органы и, пожалуй, общественные организации, у которых в силу колоссальной суммы, выделенной на информатизацию, интерес к реализации проекта думаю будет неподдельный и глубокий.
В каких случаях устанавливается суммированный учет рабочего времени и что это такое?
Трудовым кодексом РФ установлена нормальная продолжительность рабочего времени, которая, по общему правилу, не может превышать 40 часов в неделю. Для некоторых категорий работников установлена сокращенная продолжительность рабочего времени в неделю (например, для несовершеннолетних, инвалидов 1 и 2 группы, лиц, работающих с вредными условиями труда).
Также законодательством установлена максимальная продолжительность ежедневной работы (смены).
Но эта установленная продолжительной рабочего времени в неделю и(или) в день (смену) не всегда возможно соблюдать. Когда по условиям производства (работы) у индивидуального предпринимателя, в организации в целом или при выполнении отдельных видов работ не может быть соблюдена установленная ежедневная или еженедельная продолжительность рабочего времени, допускается введение суммированного учета рабочего времени.
При суммированном учете должна соблюдаться продолжительность рабочего времени за учетный период (месяц, квартал, полугодие, год; для работников на работах с вредными и/или опасными условиями труда учетный период не может превышать трех месяцев).
Нормальное число рабочих часов за учетный период определяется исходя из установленной для конкретной категории работников еженедельной продолжительности рабочего времени. Например, если нормальная продолжительность рабочего времени для работника по Трудовому кодексу составляет 40 часов в неделю, на предприятии введен суммированный учет рабочего времени с учетным периодом один месяц, то норма рабочего времени для этого работника, скажем, за март 2015 года составит 168 часов:
— 40 часов : 5 дней в неделю (для подсчета часовой нормы ежедневной работы принимается пятидневная рабочая неделя) = 8 часов в день,
— 8 часов х 21 день (в марте 2015 года 21 рабочий день) = 168 часов.
Если работник за учетный период отработает больше нормы рабочего времени (в примере — больше 168 часов в марте месяце), то будет иметь место сверхурочная работа, которая должна быть оплачена в повышенном размере.
Порядок введения суммированного учета рабочего времени устанавливается правилами внутреннего трудового распорядка.
Правовое обоснование:
Согласно статье 91 ТК РФ нормальная продолжительность рабочего времени не может превышать 40 часов в неделю.
Работодатель обязан вести учет времени, фактически отработанного каждым работником.
Статья 92 ТК РФ устанавливает сокращенную продолжительность рабочего времени для отдельных категорий работников:
для работников в возрасте до шестнадцати лет — не более 24 часов в неделю;
для работников в возрасте от шестнадцати до восемнадцати лет — не более 35 часов в неделю;
для работников, являющихся инвалидами I или II группы, — не более 35 часов в неделю;
для работников, условия труда на рабочих местах которых по результатам специальной оценки условий труда отнесены к вредным условиям труда 3 или 4 степени или опасным условиям труда, — не более 36 часов в неделю.
Статья 94 ТК РФ определяет продолжительность ежедневной работы (смены).
Согласно статье 104 ТК РФ когда по условиям производства (работы) у индивидуального предпринимателя, в организации в целом или при выполнении отдельных видов работ не может быть соблюдена установленная для данной категории работников (включая работников, занятых на работах с вредными и (или) опасными условиями труда) ежедневная или еженедельная продолжительность рабочего времени, допускается введение суммированного учета рабочего времени с тем, чтобы продолжительность рабочего времени за учетный период (месяц, квартал и другие периоды) не превышала нормального числа рабочих часов. Учетный период не может превышать один год, а для учета рабочего времени работников, занятых на работах с вредными и (или) опасными условиями труда, — три месяца.
Нормальное число рабочих часов за учетный период определяется исходя из установленной для данной категории работников еженедельной продолжительности рабочего времени. Для работников, работающих неполный рабочий день (смену) и (или) неполную рабочую неделю, нормальное число рабочих часов за учетный период соответственно уменьшается.
Порядок введения суммированного учета рабочего времени устанавливается правилами внутреннего трудового распорядка.
В соответствие с п.1. Порядка исчисления нормы рабочего времени на определенные календарные периоды времени (месяц, квартал, год) в зависимости от установленной продолжительности рабочего времени в неделю, утвержденного приказом Минздравсоцразвития РФ от 13.08.2009 N 588н, норма рабочего времени на определенные календарные периоды времени исчисляется по расчетному графику пятидневной рабочей недели с двумя выходными днями в субботу и воскресенье исходя из продолжительности ежедневной работы (смены):
при 40-часовой рабочей неделе — 8 часов;
при продолжительности рабочей недели менее 40 часов — количество часов, получаемое в результате деления установленной продолжительности рабочей недели на пять дней.
Продолжительность рабочего дня или смены, непосредственно предшествующих нерабочему праздничному дню, уменьшается на один час.
В соответствии с частью 2 статьи 112 Трудового кодекса Российской Федерации при совпадении выходного и нерабочего праздничного дней выходной день переносится на следующий после праздничного рабочий день.
В тех случаях, когда в соответствии с решением Правительства Российской Федерации выходной день переносится на рабочий день, продолжительность работы в этот день (бывший выходной) должна соответствовать продолжительности рабочего дня, на который перенесен выходной день.
Исчисленная в таком порядке норма рабочего времени распространяется на все режимы труда и отдыха.
Таким образом, норма рабочего времени конкретного месяца рассчитывается следующим образом: продолжительность рабочей недели (40, 39, 36, 30, 24 и т.д. часов) делится на 5, умножается на количество рабочих дней по календарю пятидневной рабочей недели конкретного месяца и из полученного количества часов вычитается количество часов в данном месяце, на которое производится сокращение рабочего времени накануне нерабочих праздничных дней.
В аналогичном порядке исчисляется норма рабочего времени в целом за год: продолжительность рабочей недели (40, 39, 36, 30, 24 и т.д. часов) делится на 5, умножается на количество рабочих дней по календарю пятидневной рабочей недели в году и из полученного количества часов вычитается количество часов в данном году, на которое производится сокращение рабочего времени накануне нерабочих праздничных дней.
1. Введение
Настоящие правила предназначены для обязательного ознакомления выделенному в организации сотруднику, отвечающему за информационную безопасность при использовании средств криптографической защиты информации и работе в защищенной телекоммуникационной системе.
2. Основные понятия
Система − автоматизированная информационная система передачи и приема информации в электронном виде по телекоммуникационным каналам связи в виде юридически значимых электронных документов с использованием средств электронной подписи.
Автоматизированное рабочее место (АРМ) – ПЭВМ, с помощью которой пользователь осуществляет подключение для работы в Системе.
Cредство криптографической защиты информации (СКЗИ) − средство вычислительной техники, осуществляющее криптографическое преобразование информации для обеспечения ее безопасности.
Электронная подпись (ЭП) − информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию. В Системе для подписания электронных документов электронной подписью используется технология электронно-цифровой подписи (ЭЦП) в инфраструктуре открытых ключей.
Ключ ЭП — уникальная последовательность символов, предназначенная для создания электронной подписи. Ключ ЭП хранится пользователем системы в тайне. В инфраструктуре открытых ключей соответствует закрытому ключу ЭЦП.
Ключ проверки ЭП — уникальная последовательность символов, однозначно связанная с ключом электронной подписи и предназначенная для проверки подлинности электронной подписи. Ключ проверки ЭП известен всем пользователям системы и позволяет определить автора подписи и достоверность электронного документа, но не позволяет вычислить ключ электронной подписи. Ключ проверки ЭП считается принадлежащим пользователю, если он был ему выдан установленным порядком. В инфраструктуре открытых ключей соответствует открытому ключу ЭЦП.
Сертификат ключа проверки ЭП — электронный документ или документ на бумажном носителе, выданные удостоверяющим центром либо доверенным лицом удостоверяющего центра и подтверждающие принадлежность ключа проверки электронной подписи владельцу сертификата ключа проверки электронной подписи.
Удостоверяющий центр — юридическое лицо или индивидуальный предприниматель, осуществляющие функции по созданию и выдаче сертификатов ключей проверки электронных подписей, а также иные функции, предусмотренные законодательством.
Владелец сертификата ключа проверки ЭП — лицо, которому в установленном порядке выдан сертификат ключа проверки электронной подписи.
Средства ЭП − шифровальные (криптографические) средства, используемые для реализации хотя бы одной из следующих функций — создание электронной подписи, проверка электронной подписи, создание ключа электронной подписи и ключа проверки электронной подписи.
Сертификат соответствия − документ, выданный по правилам системы сертификации для подтверждения соответствия сертифицированной продукции установленным требованиям.
Подтверждение подлинности электронной подписи в электронном документе − положительный результат проверки соответствующим средством ЭП принадлежности электронной подписи в электронном документе владельцу сертификата ключа проверки подписи и отсутствия искажений в подписанном данной электронной подписью электронном документе.
Компрометация ключа − утрата доверия к тому, что используемые ключи обеспечивают безопасность информации. К событиям, связанным с компрометацией ключей, относятся, включая, но не ограничиваясь, следующие:
- Потеря ключевых носителей.
- Потеря ключевых носителей с их последующим обнаружением.
- Увольнение сотрудников, имевших доступ к ключевой информации.
- Нарушение правил хранения и уничтожения (после окончания срока действия) закрытого ключа.
- Возникновение подозрений на утечку информации или ее искажение в системе конфиденциальной связи.
- Нарушение печати на сейфе с ключевыми носителями.
- Случаи, когда нельзя достоверно установить, что произошло с ключевыми носителями (в том числе случаи, когда ключевой носитель вышел из строя и доказательно не опровергнута возможность того, что, данный факт произошел в результате несанкционированных действий злоумышленника).
3. Риски использования электронной подписи
При использовании электронной подписи существуют определенные риски, основными из которых являются следующие:
- Риски, связанные с аутентификацией (подтверждением подлинности) пользователя. Лицо, на которого указывает подпись под документом, может заявить о том, что подпись сфальсифицирована и не принадлежит данному лицу.
- Риски, связанные с отрекаемостью (отказом от содержимого документа). Лицо, на которое указывает подпись под документом, может заявить о том, что документ был изменен и не соответствует документу, подписанному данным лицом.
- Риски, связанные с юридической значимостью электронной подписи. В случае судебного разбирательства одна из сторон может заявить о том, что документ с электронной подписью не может порождать юридически значимых последствий или считаться достаточным доказательством в суде.
- Риски, связанные с несоответствием условий использования электронной подписи установленному порядку. В случае использования электронной подписи в порядке, не соответствующем требованиям законодательства или соглашений между участниками электронного взаимодействия, юридическая сила подписанных в данном случае документов может быть поставлена под сомнение.
- Риски, связанные с несанкционированным доступом (использованием электронной подписи без ведома владельца). В случае компрометации ключа ЭП или несанкционированного доступа к средствам ЭП может быть получен документ, порождающий юридически значимые последствия и исходящий от имени пользователя, ключ которого был скомпрометирован.
Для снижения данных рисков или их избежания помимо определения порядка использования электронной подписи при электронном взаимодействии предусмотрен комплекс правовых и организационно-технических мер обеспечения информационной безопасности.
4. Общие принципы организации информационной безопасности в Системе
Криптографическая подсистема Системы опирается на отечественное законодательство в области электронной подписи, инфраструктуры открытых ключей и защиты информации, в том числе, на действующие ГОСТ и руководящие документы ФСБ и ФСТЭК, а также на международный стандарт X.509, определяющий принципы и протоколы, используемые при построении систем с открытыми ключами.
Инфраструктура открытых ключей − это система, в которой каждый пользователь имеет пару ключей − закрытый (секретный) и открытый. При этом по закрытому ключу можно построить соответствующий ему открытый ключ, а обратное преобразование неосуществимо или требует огромных временных затрат. Каждый пользователь Системы генерирует себе ключевую пару, и, сохраняя свой закрытый ключ в строгой тайне, делает открытый ключ общедоступным. С точки зрения инфраструктуры открытых ключей, шифрование представляет собой преобразование сообщения, осуществляемое с помощью открытого ключа получателя информации. Только получатель, зная свой собственный закрытый ключ, сможет провести обратное преобразование и прочитать сообщения, а больше никто сделать этого не сможет, в том числе − и сам отправитель шифрограммы. Электронная подпись в инфраструктуре открытых ключей − это преобразование сообщения с помощью закрытого ключа отправителя. Любой желающий может для проверки подписи провести обратное преобразование, применив общедоступный открытый ключ (ключ проверки ЭП) автора документа, но никто не сможет имитировать такой документ, не зная закрытого ключа (ключа ЭП) автора.
Обязательным участником любой инфраструктуры открытых ключей является Удостоверяющий центр, выполняющий функции центра доверия всей системы документооборота. При этом Удостоверяющий центр обеспечивает выполнение следующих основных функций:
- выпускает сертификаты ключей проверки электронных подписей и выдает их пользователям;
- выдает пользователям средства электронной подписи;
- создает по обращениям заявителей ключи электронных подписей и ключи проверки электронных подписей;
- получает и обрабатывает сообщения о компрометации ключей; аннулирует выданные этим удостоверяющим центром сертификаты ключей проверки электронных подписей, доверие к которым утрачено;
- ведет реестр выданных и аннулированных этим удостоверяющим центром сертификатов ключей проверки электронных подписей (далее — реестр сертификатов), в том числе включающий в себя информацию, содержащуюся в выданных этим удостоверяющим центром сертификатах ключей проверки электронных подписей, и информацию о датах прекращения действия или аннулирования сертификатов ключей проверки электронных подписей и об основаниях таких прекращения или аннулирования и обеспечивает доступ лиц к информации, содержащейся в реестре сертификатов;
- проверяет уникальность ключей проверки электронных подписей в реестре сертификатов;
- осуществляет по обращениям участников электронного взаимодействия проверку электронных подписей;
- определяет порядок разбора конфликтных ситуаций и доказательства авторства электронного документа.
Свою деятельность Удостоверяющий центр осуществляет в строгом соответствии с законодательством, собственным регламентом и соглашениями между участниками электронного взаимодействия. Благодаря соблюдению необходимых требований исключаются риски, связанные с юридической значимостью документов, подписанных электронной подписью, и снижаются риски несоответствия условий использования электронной подписи установленному порядку.
Сертификат ключа проверки ЭП заверяется электронной подписью Удостоверяющего центра и подтверждает факт владения того или иного участника документооборота тем или иным ключом проверки ЭП и соответствующим ему ключом ЭП. Благодаря сертификатам, пользователи Системы могут опознавать друг друга, а, кроме того, проверять принадлежность электронной подписи конкретному пользователю и целостность (неизменность) содержания подписанного электронного документа. Таким образом исключаются риски, связанные с подтверждением подлинности пользователя и отказом от содержимого документа.
Преобразования сообщений с использованием ключей достаточно сложны и производятся с помощью специальных средств электронной подписи. В Системе для этих целей используется СКЗИ, имеющее сертификат соответствия установленным требованиям как средство электронной подписи. Данное СКЗИ − это программное обеспечение, которое решает основные задачи защиты информации, а именно:
- обеспечение конфиденциальности информации − шифрование для защиты от несанкционированного доступа всех электронных документов, которые обращаются в Системе;
- подтверждение авторства документа — применение ЭП, которая ставится на все возникающие в Системе электронные документы; впоследствии она позволяет решать на законодательно закрепленной основе любые споры в отношении авторства документа;
- обеспечение неотрекаемости − применение ЭП и обязательное сохранение передаваемых документов на сервере Системы у отправителя и получателя; подписанный документ обладает юридической силой с момента подписания: ни его содержание, ни сам факт существования документа не могут быть оспорены никем, включая автора документа;
- обеспечение целостности документа − применение ЭП, которая содержит в себе хэш-значение (усложненный аналог контрольной суммы) подписываемого документа; при попытке изменить хотя бы один символ в документе или в его подписи после того, как документ был подписан, будет нарушена ЭП, что будет немедленно диагностировано;
- аутентификация участников взаимодействия в Системе − каждый раз при начале сеанса работы сервер Системы и пользователь предъявляют друг другу свои сертификаты и, таким образом, избегают опасности вступить в информационный обмен с анонимным лицом или с лицом, выдающим себя за другого.
Уровень защищенности Системы в целом равняется уровню защищенности в ее самом слабом месте. Поэтому, учитывая то, что система обеспечивает высокий уровень информационной безопасности на пути следования электронных документов между участниками документооборота, для снижения или избежания рисков необходимо так же тщательно соблюдать меры безопасности непосредственно на рабочих местах пользователей.
В следующем разделе содержатся требования и рекомендации по основным мерам информационной безопасности на рабочем месте пользователя.
5. Требования и рекомендации по обеспечению информационной безопасности на рабочем месте пользователя
Рабочее место пользователя Системы использует СКЗИ для обеспечения целостности, конфиденциальности и подтверждения авторства информации, передаваемой в рамках Системы. Порядок обеспечения информационной безопасности при работе в Системе определяется руководителем организации, подключающейся к Системе, на основе рекомендаций по организационно-техническим мерам защиты, изложенным в данном разделе, эксплуатационной документации на СКЗИ, а также действующего российского законодательства в области защиты информации.
5.1 Персонал
Должен быть определен и утвержден список лиц, имеющих доступ к ключевой информации.
К работе на АРМ с установленным СКЗИ допускаются только определенные для эксплуатации лица, прошедшие соответствующую подготовку и ознакомленные с пользовательской документацией на СКЗИ, а также другими нормативными документами по использованию электронной подписи.
К установке общесистемного и специального программного обеспечения, а также СКЗИ, допускаются доверенные лица, прошедшие соответствующую подготовку и изучившие документацию на соответствующее ПО и на СКЗИ.
Рекомендуется назначение в организации, эксплуатирующей СКЗИ, администратора безопасности, на которого возлагаются задачи организации работ по использованию СКЗИ, выработки соответствующих инструкций для пользователей, а также контролю за соблюдением требований по безопасности.
Должностные инструкции пользователей АРМ и администратора безопасности должны учитывать требования настоящих Правил.
В случае увольнения или перевода в другое подразделение (на другую должность), изменения функциональных обязанностей сотрудника, имевшего доступ к ключевым носителям (ЭП и шифрования), должна быть проведена смена ключей, к которым он имел доступ.
5.2 Размещение технических средств АРМ с установленным СКЗИ
Должно быть исключено бесконтрольное проникновение и пребывание в помещениях, в которых размещаются технические средства АРМ, посторонних лиц, по роду своей деятельности не являющихся персоналом, допущенным к работе в указанных помещениях. В случае необходимости присутствия таких лиц в указанных помещениях должен быть обеспечен контроль за их действиями.
Рекомендуется использовать АРМ с СКЗИ в однопользовательском режиме. В отдельных случаях, при необходимости использования АРМ несколькими лицами, эти лица должны обладать равными правами доступа к информации.
Не допускается оставлять без контроля АРМ при включенном питании и загруженном программном обеспечении СКЗИ после ввода ключевой информации. При уходе пользователя с рабочего места должно использоваться автоматическое включение экранной заставки, защищенной паролем. В отдельных случаях при невозможности использования парольной защиты, допускается загрузка ОС без запроса пароля, при этом должны быть реализованы дополнительные организационно-режимные меры, исключающие несанкционированный доступ к АРМ.
Рекомендуется предусмотреть меры, исключающие возможность несанкционированного изменения аппаратной части АРМ, например, опечатывание системного блока АРМ администратором. Также возможно в этих целях применение специальных средств защиты информации — аппаратных модулей доверенной загрузки.
Рекомендуется принять меры по исключению вхождения лиц, не ответственных за администрирование АРМ, в режим конфигурирования BIOS (например, с использованием парольной защиты).
Рекомендуется определить в BIOS установки, исключающие возможность загрузки операционной системы, отличной от установленной на жестком диске: отключается возможность загрузки с гибкого диска, привода CD-ROM, исключаются прочие нестандартные виды загрузки ОС, включая сетевую загрузку.
Средствами BIOS должна быть исключена возможность работы на ПЭВМ, если во время его начальной загрузки не проходят встроенные тесты.
5.3 Установка программного обеспечения на АРМ
На технических средствах АРМ с установленным СКЗИ необходимо использовать только лицензионное программное обеспечение фирм-изготовителей, полученное из доверенных источников.
На АРМ должна быть установлена только одна операционная система. При этом не допускается использовать нестандартные, измененные или отладочные версии операционной системы.
Не допускается установка на АРМ средств разработки и отладки программного обеспечения. Если средства отладки приложений необходимы для технологических потребностей пользователя, то их использование должно быть санкционировано администратором безопасности. В любом случае запрещается использовать эти средства для просмотра и редактирования кода и памяти приложений, использующих СКЗИ. Необходимо исключить попадание в систему средств, позволяющих осуществлять несанкционированный доступ к системным ресурсам, а также программ, позволяющих, пользуясь ошибками ОС, получать привилегии администратора.
Рекомендуется ограничить возможности пользователя запуском только тех приложений, которые разрешены администратором безопасности.
Рекомендуется установить и использовать на АРМ антивирусное программное обеспечение.
Необходимо регулярно отслеживать и устанавливать обновления безопасности для программного обеспечения АРМ (Service Packs, Hot fix и т п.), обновлять антивирусные базы.
5.4 Настройка операционной системы АРМ
Администратор безопасности должен сконфигурировать операционную систему, в среде которой планируется использовать СКЗИ, и осуществлять периодический контроль сделанных настроек в соответствии со следующими требованиями:
- Правом установки и настройки ОС и СКЗИ должен обладать только администратор безопасности.
- Всем пользователям и группам, зарегистрированным в ОС, необходимо назначить минимально возможные для нормальной работы права.
- У группы Everyone должны быть удалены все привилегии.
- Рекомендуется исключить использование режима автоматического входа пользователя в операционную систему при ее загрузке.
- Рекомендуется переименовать стандартную учетную запись Administrator.
- Должна быть отключена учетная запись для гостевого входа Guest.
- Исключить возможность удаленного управления, администрирования и модификации ОС и ее настроек, системного реестра, для всех, включая группу Administrators.
- Все неиспользуемые ресурсы системы необходимо отключить (протоколы, сервисы и т п.).
- Должно быть исключено или ограничено с учетом выбранной в организации политики безопасности использование пользователями сервиса Scheduler (планировщик задач). При использовании данного сервиса состав запускаемого программного обеспечения на АРМ согласовывается с администратором безопасности.
- Рекомендуется организовать затирание временных файлов и файлов подкачки, формируемых или модифицируемых в процессе работы СКЗИ. Если это невыполнимо, то ОС должна использоваться в однопользовательском режиме и на жесткий диск должны распространяться требования, предъявляемые к ключевым носителям.
- Должны быть установлены ограничения на доступ пользователей к системному реестру в соответствии с принятой в организации политикой безопасности, что реализуется при помощи ACL или установкой прав доступа при наличие NTFS.
- На все директории, содержащие системные файлы Windows и программы из комплекта СКЗИ, должны быть установлены права доступа, запрещающие запись всем пользователям, кроме Администратора (Administrator), Создателя/Владельца (Creator/Owner) и Системы (System).
- Должна быть исключена возможность создания аварийного дампа оперативной памяти, так как он может содержать криптографически опасную информацию.
- Рекомендуется обеспечить ведение журналов аудита в ОС, при этом она должна быть настроена на завершение работы при переполнении журналов.
- Рекомендуется произвести настройку параметров системного реестра в соответствии с эксплуатационной документацией на СКЗИ.
Рекомендуется разработать и применить политику назначения и смены паролей (для входа в ОС, BIOS, при шифровании на пароле и т д.), использовать фильтры паролей в соответствии со следующими правилами:
- длина пароля должна быть не менее 6 символов;
- в числе символов пароля обязательно должны присутствовать буквы в верхнем и нижнем регистрах, цифры и специальные символы (@, #, $, &, *, % и т.п.);
- пароль не должен включать в себя легко вычисляемые сочетания символов (имена, фамилии и т д.), а также общепринятые сокращения (USER, ADMIN, ALEX и т д.);
- при смене пароля новое значение должно отличаться от предыдущего не менее чем в 4-x позициях;
- личный пароль пользователь не имеет права сообщать никому;
- не допускается хранить записанные пароли в легкодоступных местах;
- периодичность смены пароля определяется принятой политикой безопасности, но не должна превышать 6 месяцев;
- указанная политика обязательна для всех учетных записей, зарегистрированных в ОС.
5.5 Установка и настройка СКЗИ
Установка и настройка СКЗИ на АРМ должна выполняться в присутствии администратора, ответственного за работоспособность АРМ.
Установка СКЗИ на АРМ должна производиться только с дистрибутива, полученного по доверенному каналу.
Установка СКЗИ и первичная инициализация ключевой информации осуществляется в соответствии с эксплуатационной документацией на СКЗИ.
При установке ПО СКЗИ на АРМ должен быть обеспечен контроль целостности и достоверность дистрибутива СКЗИ.
Рекомендуется перед установкой произвести проверку ОС на отсутствие вредоносных программ с помощью антивирусных средств.
По завершении инициализации осуществляются настройка и контроль работоспособности ПО.
Запрещается вносить какие-либо изменения, не предусмотренные эксплуатационной документацией, в программное обеспечение СКЗИ.
5.6 Подключение АРМ к сетям общего пользования
При использовании СКЗИ на АРМ, подключенных к сетям общего пользования, должны быть предприняты дополнительные меры, исключающие возможность несанкционированного доступа к системным ресурсам используемых операционных систем, к программному обеспечению, в окружении которого функционируют СКЗИ, и к компонентам СКЗИ со стороны указанных сетей. В качестве такой меры рекомендуется установка и использование на АРМ средств межсетевого экранирования. Должен быть закрыт доступ ко всем неиспользуемым сетевым портам.
В случае подключения АРМ с установленным СКЗИ к общедоступным сетям передачи данных необходимо ограничить возможность открытия и исполнения файлов и скриптовых объектов (JavaScript, VBScript, ActiveX и т д.), полученных из сетей общего пользования, без проведения соответствующих проверок на предмет содержания в них программных закладок и вредоносных программ.
5.7 Обращение с ключевыми носителями
В организации должен быть определен и утвержден порядок учета, хранения и использования носителей ключевой информации с ключами ЭП и шифрования, который должен исключать возможность несанкционированного доступа к ним.
Для хранения ключевых носителей в помещениях должны устанавливаться надежные металлические хранилища (сейфы), оборудованные надежными запирающими устройствами.
Запрещается:
- Снимать несанкционированные администратором безопасности копии с ключевых носителей.
- Знакомить с содержанием ключевых носителей или передавать ключевые носители лицам, к ним не допущенным, а также выводить ключевую информацию на дисплей (монитор) АРМ или принтер.
- Устанавливать ключевой носитель в считывающее устройство ПЭВМ АРМ в режимах, не предусмотренных функционированием системы, а также устанавливать носитель в другие ПЭВМ.
- Использовать бывшие в работе ключевые носители для записи новой информации без предварительного уничтожения на них ключевой информации средствами СКЗИ.
5.8 Обращение с ключевой информацией
Владелец сертификата ключа проверки ЭП обязан:
- Хранить в тайне ключ ЭП (закрытый ключ).
- Не использовать для электронной подписи и шифрования ключи, если ему известно, что эти ключи используются или использовались ранее.
- Немедленно требовать приостановления действия сертификата ключа проверки ЭП при наличии оснований полагать, что тайна ключа ЭП (закрытого ключа) нарушена (произошла компрометация ключа).
- Обновлять сертификат ключа проверки ЭП в соответствии с установленным регламентом.
5.9 Учет и контроль
Действия, связанные с эксплуатацией СКЗИ, должны фиксироваться в «Журнале пользователя сети», который ведет лицо, ответственное за обеспечение информационной безопасности на АРМ. В журнал кроме этого записываются факты компрометации ключевых документов, нештатные ситуации, происходящие в системе и связанные с использованием СКЗИ, проведение регламентных работ, данные о полученных у администратора безопасности организации ключевых носителях, нештатных ситуациях, произошедших на АРМ, с установленным ПО СКЗИ.
В журнале может отражаться следующая информация:
- дата, время;
- запись о компрометации ключа;
- запись об изготовлении личного ключевого носителя пользователя, идентификатор носителя;
- запись об изготовлении копий личного ключевого носителя пользователя, идентификатор носителя;
- запись об изготовлении резервного ключевого носителя пользователя, идентификатор носителя;
- запись о получении сертификата ключа проверки ЭП, полный номер ключевого носителя, соответствующий сертификату;
- записи, отражающие выдачу на руки пользователям (ответственным исполнителям) и сдачу ими на хранение личных ключевых носителей, включая резервные ключевые носители;
- события, происходившие на АРМ пользователя с установленным ПО СКЗИ, с указанием причин и предпринятых действий.
Пользователь (либо администратор безопасности) должен периодически (не реже одного раза в два месяца) проводить контроль целостности и легальности установленных копий ПО на всех АРМ со встроенной СКЗИ с помощью программ контроля целостности, просматривать сообщения о событиях в журнале EventViewer операционной системы, а также проводить периодическое тестирование технических и программных средств защиты.
В случае обнаружения «посторонних» (не зарегистрированных) программ, нарушения целостности программного обеспечения либо выявления факта повреждения печатей на системных блоках работа на АРМ должна быть прекращена. По данному факту должно быть проведено служебное расследование комиссией, назначенной руководителем организации, где произошло нарушение, и организованы работы по анализу и ликвидации негативных последствий данного нарушения.
Рекомендуется организовать на АРМ систему аудита в соответствии с политикой безопасности, принятой в организации, с регулярным анализом результатов аудита.
6. Заключение
Настоящие правила составлены на основе:
- Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи»;
- Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»;
- приказа ФАПСИ от 13.06.2001 № 152 «Об утверждении Инструкции об организации и обеспечении безопасности хранения, обработки и передачи по каналам связи с использованием средств криптографической защиты информации с ограниченным доступом, не содержащей сведений, составляющих государственную тайну»;
- приказа ФСБ от 09.02.2005 № 66 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации (Положение ПКЗ-2005)».
- эксплуатационной документации на СКЗИ, которое используется в Системе.
Рабочее время как правовая категория
Основополагающей юридической нормой, устанавливающей соотношение времени, затраченного на труд и на отдых, является ст. 37 Конституции РФ, указывающая, что работнику как участнику трудовых правоотношений гарантируется максимально обозначенное количество времени, которое он может использовать для труда. Оно регламентируется на уровне федерального законодательства и ограничивается правоустанавливающими положениями Трудового кодекса РФ.
Ст. 91 ТК определяет правовую категорию «рабочее время». Это время, которое работник должен использовать для выполнения трудовой функции, причем длительность этого времени, момент начала и окончания устанавливаются трудовым контрактом. Кодекс, федеральные и отраслевые НПА квалифицируют как рабочее время процесс фактического труда и «иные» промежутки времени. К категории иных временных интервалов относятся так называемые регламентированные перерывы:
- перерывы, связанные с организацией и технологией процесса труда: для обогрева и отдыха по ст. 109 ТК РФ при выполнении трудовой функции не в помещении или в неотапливаемом помещении, для отдыха авиадиспетчеров по п. 11 положения Минтранса, регламентирующего работу по управлению воздушным движением (утв. приказом Минтранса от 30.01.2004 № 10), для водителей автомобилей по пп. 15, 19 положения Минтранса, регламентирующего труд водителей автомобилей (утв. приказом Минтранса от 20.08.2004 № 15) и т. д.
- дополнительные перерывы для кормления детей трудящимся женщинам при возрасте детей до 1,5 лет по ст. 258 ТК РФ.
Перечисленные перерывы есть часть рабочего времени, они подлежат оплате.
Нормальная продолжительность рабочего времени составляет не более 40 часов
Нормальная продолжительность рабочего времени не может превышать обозначенного кодексом предела и определяется (1) количеством времени труда, выраженным в часах, и (2) календарным интервалом, в течение которого это количество часов должно быть отработано. Ст. 91 ТК РФ регламентирует первый критерий (не более 40 часов) и второй критерий — временной интервал, равный неделе. Норма устанавливается в общем случае, т. е. выполнение трудовой функции происходит в обычных, стандартных условиях, а исполнители трудовых обязанностей не требуют в силу, например, возраста, состояния здоровья или семейного статуса специальных мер охраны труда.
Необходимо отметить, что ст. 91 фиксирует максимальную границу времени труда: показатель нормальной продолжительности рабочего времени не может превышать 40 часов в неделю. Это положение общеприменимо:
- для всех работодателей вне зависимости от организационно-правовой структуры и формы собственности;
- для всех видов трудовых контрактов — бессрочных, срочных, сезонных, краткосрочных (исключением является только совместительство, где длительность труда по природе своей иная);
- для всех графиков занятости.
Особые нормативы рабочего времени для особых субъектов
Как уже отмечалось, количественное значение нормы рабочего времени находится в зависимости от свойств субъекта труда (работника) — его возраста, здоровья — и, конечно, от условий труда. В Трудовом кодексе приводится классификация видов рабочего времени по протяженности. Оно может быть:
- Нормальное, когда максимальная длительность для общей категории работников составляет не более 40 часов в трудовой неделе (ст. 91 ТК РФ).
- Сокращенное, когда максимальная продолжительность устанавливается для работников в зависимости от возраста, здоровья или имеющихся вредных либо опасных условий труда. Максимумы регламентируются ст. 92 ТК РФ, и для различных групп работников длительность недели устанавливается на уровнях не более 36, 35, 24 часов. Заметим, что существуют отраслевые нормативы, фиксирующие иную длительность рабочей недели для медицинских, педагогических и других кадров.
- Неполное, когда продолжительность устанавливается трудовым соглашением для работников с семейными обязанностями. Ст. 93 называет круг лиц, для которых наниматель должен по их просьбе определить неполный рабочий день. Это беременные женщины, родители детей до 14 лет и прочие категории. Подразумевается, что такие работники получают заработную плату в соответствии с отработанным временем.
Норма времени при графике, отличном от 5/2
Итак, время трудовой занятости работника ограничено законодателем. Период, определенный в качестве нормальной продолжительности рабочего времени, не может превышать 40-часовой недели. Соблюдение этого правового положения тесно связано с решением вопроса, как, по какому расписанию осуществляется работа.
Существующее соотношение времени труда и отдыха имеет следующие варианты: 5-дневная занятость с 2 днями отдыха, 6-дневная трудовая неделя с единственным выходным, скользящий график предоставления дней отдыха, неполная рабочая неделя. Отметим, что подавляющее большинство трудящихся работает в условиях пятидневки (5 восьмичасовых рабочих дней в неделю).
Необходимо остановиться на некоторых нюансах организации времени труда и отдыха при прочих видах трудовой занятости. Например, если установлена 6-дневная рабочая неделя, то протяженность рабочего дня накануне выходного не может превышать 5 часов (ст. 95 ТК РФ). В таких обстоятельствах законодатель говорит не о количественном уменьшении размера рабочей недели, а о перераспределении рабочего времени, с тем чтобы реализовать норму ст. 110 о протяженности непрерывного времени отдыха между рабочими неделями в 42 часа. Если установлен трудовой график со «скользящими» выходными, то необходимо выполнять норму ст. 111 об обязательном отдыхе в воскресенье.
Режим рабочего времени является существенным условием труда. По этой причине график трудовой занятости работника должен быть оформлен работодателем в виде отдельного НПА либо включен в состав правил внутреннего распорядка или коллективного договора. В случае когда режим занятости работника отличается от принятого в целом по организации, он должен быть отдельно зафиксирован в трудовом договоре.
Помимо того, что в графике должна быть отражена продолжительность рабочей недели и ежедневного труда, он должен содержать часовую разбивку рабочего дня. В итоге в графике следует указать время начала и окончания работы, установленные перерывы, число смен, порядок чередования смен, а также расписание рабочих и выходных дней.
Нормальная продолжительность рабочего времени в неделю и норма рабочего времени
Итак, ст. 91 ТК РФ гласит: «Нормальная продолжительность рабочего времени не может превышать 40 часов в неделю». Данный юридический постулат стал основополагающим в методике подсчета нормы рабочего времени.
Другим документом — приказом Минздравсоцразвития от 13.08.2009 № 588н — установлен регламент, согласно которому продолжительность рабочего времени рассчитывается в фиксированные календарные промежутки и базируется на графике 5-дневной рабочей недели. В день длительность работы должна составлять:
- 8 часов, если рабочая неделя 40-часовая;
- если рабочих часов в неделе меньше 40, то дневная длительность устанавливается путем деления числа часов рабочей недели на 5.
То есть установленную протяженность трудовой недели, которая, как уже отмечалось, может быть 40, 36, 35 или 24 часа, надо делить на 5 и умножать на число рабочих дней в определенном месяце по графику пятидневки. Полученный итог следует уменьшить на число часов, приходящихся на сокращение времени труда в преддверии праздничных нерабочих дней. Существует норматив, установленный ст. 95 ТК: в дни накануне нерабочих праздничных дней время работы должно быть сокращено на 1 час.
Описанный выше метод удобен тем, что с его помощью можно рассчитать норму рабочего времени, которая применима при любом режиме занятости.
В обязанности нанимателя входит персональное и ежедневное ведение учета времени труда каждого сотрудника.
Форму для учета рабочего времени и порядок ее заполнения см. в статье «Табель учета рабочего времени — форма Т-13 (бланк)».
Учет рабочего времени — выявляем норму и превышение
Контроль над тем, соответствует ли продолжительность времени труда существующим нормативам, ведется в процессе учета рабочего времени. Процесс организации труда на разных предприятиях может быть организован на отличных друг от друга принципах. В частности, учет времени труда может вестись за различные временные промежутки, и, как правило, предприятия выбирают из трех вариантов: день, неделя или суммированный учет.
Дневной учет рабочего времени целесообразен для тех нанимателей, у которых график работы предполагает: в любой день длительность работы одинакова. В обстоятельствах, когда реальное дневное рабочее время выйдет за пределы норматива, разница не компенсируется недоработкой в последующие дни, а квалифицируется как сверхурочный труд.
Недельный учет рабочего времени требуется в обстоятельствах, когда в нормальных границах длительности недельного труда продолжительность рабочих дней фактически может колебаться день ото дня. Недельный учет целесообразен, например, когда работа ведется по гибкому графику (ст. 102 ТК РФ).
Суммированный учет рабочего времени более всего необходим для таких режимов труда, как сменный (ст. 103 ТК РФ) или вахтовый (ст. 300 ТК РФ). Принцип данного вида учета таков: время трудовой деятельности считается не за неделю, а за другой промежуток (три недели, месяц, два месяца и т. п.). Использование иного по длительности промежутка для подсчета рабочего времени вызвано тем, что по объективным причинам, например в связи со спецификой предприятия, нет возможности строго придерживаться установленной, нормированной длительности недельного или дневного труда. Временной промежуток, взятый работодателем с целью нормирования для подсчета числа рабочих часов, называется учетным периодом. Общая продолжительность труда за это время не может быть больше нормальной недельной, умноженной на число недель. При всем этом для протяженности данного периода ст. 104 ТК РФ определен максимум — один год.
Подробнее о расчете нормы часов при сменном графике см. в материале «Норма часов при сменном графике работы по Трудовому кодексу».
В обязанности работодателя входит учет времени, отработанного наемными работниками. Причем учитывать требуется время как в рамках нормальной продолжительности, так и в случаях, когда нормы рабочего времени превышаются за счет сверхурочной работы или труда в режиме ненормированного рабочего дня. Эти два понятия характеризуют занятость работника сверх установленной нормы и, следовательно, требуют отдельного правового регулирования.
Превышение нормы: сверхурочная работа и ненормированное рабочее время
Ст. 99 ТК квалифицирует сверхурочную работу как труд, выполняемый по прямому указанию работодателя вне границ нормальной длительности рабочего времени. Если речь идет о дневном учете, то такой работой будет считаться труд после окончания трудового дня или смены. Если речь идет о суммированном учете, то такой работой считается труд, который за учетный период длится больше, чем нормативное количество часов.
Одним из обязательных условий является тот фактор, что указание нанимателя о работе сверхурочно должно быть оформлено в письменном виде. Привлекать к сверхурочной работе можно, соблюдая определенные ограничения. Дозволяемые рамки зависят от типа работ, которые необходимо исполнять сверхурочно, категорий привлекаемых работников, наконец, от продолжительности сверхурочного труда.
Согласие работников на сверхурочную работу требуется для решения следующих проблем:
- для окончания начатой работы, которая по объективным причинам не была окончена в течение трудового дня, при условии, что незавершение этой работы повлечет необратимый вред имуществу, создаст угрозу жизни и здоровью людей;
- для выполнения ремонтных работ, когда неисправность препятствует дальнейшему труду большого количества работников;
- для замены неявившегося сменяющего работника.
Существуют причины, по которым работники могут быть привлечены к сверхурочной работе без их согласия. Эти причины связаны с необходимостью действий по предотвращению катастроф или с проведением работ по нормализации функционирования систем жизнеобеспечения населения при ликвидации последствий чрезвычайных ситуаций.
В остальных случаях производство сверхурочных работ возможно с согласия работника с учетом мнения профсоюзной организации. Однако процедура учета мнения профсоюзной организации кодексом не разъяснена (ст. 371 ТК РФ), и на практике работодателю достаточно уведомить профсоюз (при его наличии) о своем решении, связанном с проведением сверхурочных работ.
Законодательство запрещает сверхурочную работу для беременных женщин и подростков до 18 лет. Если есть согласие и отсутствуют медицинские противопоказания, то разрешено привлекать к работе за рамками нормальной протяженности женщин с детьми до 3 лет и инвалидов. Однако в таких обстоятельствах действует особый разрешительный порядок: указанные работники в письменном виде подтверждают, что осведомлены о своем законном праве не работать сверхурочно.
Объем сверхурочной работы для ее исполнителя не должен превышать 4 часов на протяжении 2 дней подряд и за 120 часов в год. Оплачивать сверхурочный труд следует в увеличенном размере (ст. 152 ТК РФ).
Ненормированным рабочим днем считается такой режим работы, при котором длительность рабочего времени в большую сторону отличается от длительности труда, установленной законодательными актами. При таком графике работники могут иногда привлекаться к труду вне границ нормальной длительности работы. Наличие режима ненормированного рабочего дня есть существенное условие трудовой функции, и поэтому оно должно быть в обязательном порядке отражено в трудовом соглашении.
Итоги
Недельная продолжительность рабочего времени не должна быть больше максимума в 40 часов, определенного законодателем. Именно на основании данного показателя устанавливается норма рабочего времени для всех имеющихся режимов труда. Выполнение труда сверх норм есть предмет отдельного регулирования со стороны законодательства.
С этим файлом связано 18 файл(ов). Среди них: Б 1.3. Задание_Мухина_Виктория_Владимировна.docx, 1.2.docx, региональные проекты Ставропольского края.docx, Практическое задание «организация проектной и учебно-исследовате, Сам.ра 2.2.docx, Практическая 2.1.docx, Практическое задание 1.2.docx, доп.материал 2.3. (3).pdf, Самостоятельная работа 1.1.docx, Лабораторная.docx, практическая работа №4 «Проектирование учебного занятия на основ, практическая работа №3 «Анализ содержания и методического аппара, Практическая работа №1.docx, 3 четверть (1).docx, Doc1.docx, Методика физического воспитания.docx, _Теория и методика физического воспитания как учебная дисциплина, testovoe_zadanie_zemelnoe_pravo_2017 (1).pdf и ещё 8 файл(а).
Показать все связанные файлы
Подборка по базе: лб 4 Определение содержания воды в нефтях и нефтепродуктах.docx, ПР Определение метрологических характеристик средств измерений., Бланк отчета ПЗ 4.1.4. Определение класса защищенности ГИС — (1, Лабораторная работа 3 Определение скорости Некрасов К.Л О-5Б11.d, Фотометрическое определение железа в питьевой воде.rtf, Бланк отчета ПЗ 4.1.4. Определение класса защищенности ГИС — .do, Бланк отчета ПЗ 4.1.4. Определение класса защищенности ГИС — .do, Бланк отчета ПЗ 4.1.4. Определение класса защищенности ГИС — .do, Бланк отчета ПЗ 4.1.4. Определение класса защищенности ГИС — .do, Бланк отчета ПЗ 4.1.4. Определение класса защищенности ГИС — .do
Тема№11.Укажите наиболее полное определение медицинской информатики-наука,занимающаяся исследованием процессов получения,передачи,обработки… в медицине и здравоохранения .2.Предметом медицинской информатики являются:информационные процессы,сопряженные с медико-биологическими,клиническими и профилактическими проблемами3.На основе какой системы разрабатывается единый цифровой контур здравоохранения?—Единаягосударственная информационная система здравоохранения(ЕГИСЗ)4.ГИС СЗ это…государственные информационные системы в сфере здравоохранения5.Основными направлениями реализации федерального проекта «Создание единого цифрового контура в здравоохранении на основе единой государственной информационной системы здравоохранения (ЕГИСЗ)» являются:
-внедрение медицинских информационных
-Внедрение региональных сервисов и систем для управления здравоохранением;
-Функционирование федерального ЦОД и федеральных сервисов ЕГИСЗ ;
-Развитие сервисов личного кабинета пациента «Мое здоровье» ЕПГУ
6.Какие результаты должны быть достигнуты при реализации проекта в 2019-2024?
-Решены инфраструктурные проблемы,
-Врачи должны перейти на преимущественно
-Должна работать передача
-Все МО (включая ФАП и ФП подключенные к сети интернет)
7.Укажите сроки реализации национального проекта «создание единого цифрового контура здравоохранения»— 2019-2024 гг.8.Какие задачи решались на этапе «Развитие ЕГИСЗ» в 2013-2018 гг.?(ВСЕ повышение)9.В какие годы происходило развитие ЕГИСЗ?— 2013-2018 гг.10.Все МО ,оказывающие амбулаторно-поликлиническую помощь и осуществляющие первичный прием граждан, должны быть подключены к….Централизованной региональной системе «Управление потоками пациентов»
Тема №21.АРМ главного врача МО по предназначению-административное2.Что называют автоматизированным рабочим местом врача?-место работы специалиста, оснащенное вычислительной техникой и программным обеспечением,обеспечивающим сбор,хранение и обработку медицинской информации3.Согласно классификации АРМ по их принадлежности к определенному функциональному классу,АРМ второго уровня-реализует расчет параметров,характеризующихсостояние объекта управления4.Какие уровни автоматизации медицинской организации принято выделять?-начальнаяавтоматизация,
работа с электронной медицинской картой,
полная автоматизация
5.На какие подклассы делятся административные АРМ?
административно-управленческие,
медико-статические,
медико-экономические
6.АРМ клинического фармаколога в МО по предназначению-медико-технологическое7.Создание специальных средств адаптации АРМ к уровню подготовки пользователя и возможностью его обучения непосредственно на данном АРМ основывается на-принципе максимальной ориентации на конечного пользователя8.Специализация АРМ на решение определенного класса задач основывается на-принципе проблемной ориентации9.Согласно классификации АРМ по их принадлежности к определенному функциональному классу,АРМ первого уровня-осуществляет ввод информации,ее хранение,поиски выдачу по запросу10.В настоящее время АРМ в МО разработаны-для всех сотрудников,рабочие места которых требуют автоматизации11.На какие подклассы делятся организационно-технологические АРМ?
организационно-клинические;
телемедицинские
12.Согласно классификации АРМ по их принадлежности к определенному функциональному классу,АРМчетвертого уровня-включает функцию прогнозирования и выбора способа воздействия на объект управления13.АРМ клинического фармаколога в МО по предназначению-медико-технологическое14.На каких общих принципах основывается проектирование и внедрение АРМ?
•
Принцип постоянного взаимодействия разработчиков АРМ и их пользо
• Принцип максимальной ориентации на конечного пользователя
• Принцип проблемной ориентации
• Принцип соответствия информационных потребностей пользователей
15.Что называют автоматизированным рабочим местом?-аппаратно-программный комплекс,предназначенный для автоматизации технологических процессов в определенной области деятельности16.Согласно классификации АРМ по их принадлежности к определенному функциональному классу,АРМтретьего уровня-обеспечиваетдиагностику,дифференциальную диагностику17.В соответствии с предназначением АРМ в МО классифицируются на
медико-технологические,
организационно-технологические,
административные
Темы № 3,4,51.Обязательными функциями подсистемы «Приемное отделение» МИС МО являются (ВСЕ,кроме формирование статист .отчетности)
+регистрация медицинских данных обслуживаемых пациентов
+поиск гражданина по идентификатору
+внесение информации из документов, удостоверяющиъличность
+ создание ЭМК. Внесение полисов ОМС, ДМС
+ получение информированного согласия на обработку перс. Данных
2.Что может служить источником информации для МИС МО?
+медицинские записи, создаваемые в процессе оказания всех видов мед. Помощи
+ данные, получаемые от мед техники
+данные, передаваемые из других инф. Систем
3.
Какие уровни функциональных возможностей МИС МО принято выделять?
+Минимальный, базовый расширенный
4.Обязательными функциями подсистемы «Оказание скорой медицинской помощи» МИС МО являются
+учет медицинских услуг в рамках оказания скорой и неотложной медицинской помощи
5.Обязательными функциями подсистемы «Цифровые изображения (Радиология)» МИС МО являются
+формирование протокола исследования
+ ведение журнала диагностического кабинета
+формирование статистической отчетности
6Аппаратное обеспечение МИС МО должно обеспечивать(ВСЕ)
+совместимость и возможность изменения конфигурации технич средств
+надежность обработки информации , достаточн для эффект. Функционирования ..
+включение средств защиты информации от несанкц. Доступа
7.Модуль «Статистика» входит в состав МИС МО (ВСЕ, кроме службы скорой мед .помощи)
+стационара, роддома, санатория, поликлиники, стоматологической поликлиники
8.Модуль «Ведение электронных стационарных карт пациентов» входит в состав МИС МО
+стационара, роддома. Санатория
9.Модуль «Приемное отделение» входит в состав МИС МО
+стационара, роддома, санатория
10.Обязательными функциями подсистемы «Статистика» МИС МО
+подготовка утвержденной государственной статистической отчетности
+предварительный просмотр сформир. Отчета
11. Модуль «Клинико-диагностическая лаборатория» входит в состав МИС МО
+стационара, роддома, санатория, поликлиники
12.Обязательными функциями подсистемы «Статистика» МИС МО являются
+подготовка утвержденной государственной статистической отчетности
+предварительный просмотр сформированного отчета
13.Модуль «Оказание скорой и неотложной медицинской помощи» входит в состав МИС МО
+поликлиники, службы скорой помощи
14.Модуль «Инструментальная диагностика» входит в состав МИС МО
+стационара, роддома, санатория, поликлиники, стоматологии
15.Модуль «Регистратура полклиники» входит в состав МИС МО
+поликлиники, стоматологической поликлиники
16. обеспечение МИС МО включает
+ вычислительную технику, объединенную в вычислит сеть
+ технолог оборудование
17.медицинская информационная система медицинской организации предназначена для обеспечения
+инф. Поддержки процесса оказания мед помощи
+Инф поддержки процесса управления мед орг-цией
+инф поддержки процессов вз-вия с пациентами
+инф вз-вия между различными медицинскими орг-циями
+инф. Вз-вия с централизов рег-ными и федер инфресурсами
18.С какой целью создаются и внедряются МИС(ВСЕ)
+повышение качества и доступности мед помощи нас-ю
+повышение эффективности работы
+вовлечение граждан в заботу о собств здоров.
+обеспечение оперативности принятия управл решений
19.На каком уровне развития функционала МИС МО реализуется функция «Взаимодействие со средствами поддержки принятия решений»
+расширенный
20.Модуль «Ведение электронных амбулаторных карт пациентов» входит в состав МИС МО
+поликлиники, стоматологии
21.Модуль «Аптека МО» входит в состав Модуль «Аптека МО» входит в состав МИС МО
+стационара, роддома, санатория, поликлиники, стоматологии, службы скорой помощи
22.Какая информация содержится в разделе «Результаты исследований» ЭМК?
+данные обо всех проведенных исследованиях пациента
23.Какая информация содержится в разделе «Данные о владельце документа»
+сведения о мед организации, которая завела эл карту
24.Какими способами мед организация обеспечивает информационную безопасность ЭМК?
+внесение любых новых данных
+Использование максимального числа кодов для шифрования инф
+Установка спец криптографического ПО
25.Согласно Федеральному закону от 21 ноября 2011 «об основах охраны здоровья граждан в РФ» пациент либо его законный представитель
+имеет право непосредственно знакомиться с мед документацией, отражающей состояние его здоровья
26.Какая инф содержится в раделе «Вмешательства и процедуры» ЭМК(ВСЕ)
+данные о проведенных оперативн вмеш-вах
+данные о подготовит к оперативн вм-ву мероприятиях
+данные о реанимационных действиях
+сведения о применении специализир лекарственнсопровождения
27.Что такое электронная персональная медицинская запись
+медицинская запись,, сделанная а электронном носителе, кот отражает фактическое состояние пациента на момент обращения, а также перечень оказанных ему мед услуг
28.Какие стадии жизненного цикла ЭПМЗ принято выделять
+создание, ведение, подписание, хранение, уничтожение
29.Кем заполняется раздел «Врачебные осмотры» ЭМК
+специалистом, который проводит осмотр
30.Какая информация содержится в разделе «Временная нетрудоспособность пациента» ЭМК
+сведения о причине формирования больничного
+сведения о сроке действия больничного
+данные врача
31.Какая информация содержится в разделе «Данные о пациенте» ЭМК
+дата и место рождения, пол, паспортн данные, тип обращения по виду страхования
32.Какая информация содержится в разделе «Метрика пациента»
+сведения о проводимых метрических измерениях человека
33.Защита данных в ЭМК двусторонняя, так как осуществляется со стороны
+мед орг и пациентов
34.К недостаткам использования ЭМК относятся
+зависимость от исправной работы компьютера
+отсутствие интеграции с другими Мо
35.Структура персональной медицинской записи включает в себя
+все перечисленное
36.Что такое медицинская карта пациента
+совокупность электронных персональных мед записей, относящихся к одному пациенту
37.Кем заполняется раздел «Врачебные осмотры»
+ специалистом, который проводит осмотр
38.С какими данными, содержащиеся в ЭМК имеет право ознакомиться пациент
+результатами проведенных мед анализов
+протоколами осмотров у врачей
+данными о листках нетрудоспособности
39.Является ли ЭПМЗ юридически значимым документом
+да, после подписания эл подписью
Тема №61.По каким направлениям оценивается эффективность внедрения СППВР в МО?
-эффективность клиническая,
-эффективность организационная,
-эффективность экономическая
2.К какому классу СППВР относится автоматизация врачебных назначений ?-информационно-справочным3.Для решения каких задач предназначены система поддержки принятия врачебных решений?-интерпретация медицинских изображений,подачатревожных сигналов и напоминаний,контроль и планирование терапии,помощь при постановке диагноза4.СППВР, имитирующие или моделирующие рассуждения врача это…-интеллектуальные5.Что такое гибридные СППВР?-сочетающиеинформационно-справочные и интеллектуальные компоненты6.Что такое прецендентный подход к построению СППВР?-основан на поиске в базе данных случаев,похожихна текущий,и система формирует рекомендации по диагностике и лечению на основе найденных случаев7.К какому классу СППВР относят электронные медицинские карты?-информационно-справочным8.На какие классы можно разделить СППВР по выполняемым задачам и функциям?
-информационно-справочные,
интеллектуальные,
гибридные
9.Наиболее адекватным показателем организационной эффективности системы можно считать…уменьшение затрат рабочего времени медицинского персонала при подготовке отчетной документации10.Интеллектуальные СППВР делятся на системы…имитирующие рассуждения врача, моделирующие рассуждения врача11.Что такое система поддержки принятия врачебных решений?-програмное обеспечение,позволяющее путем сбора …оказываемой медицинской помощи12.Любая СППВР основывается на знаниях,которыемогут быть….явными и неявными13.Примерами отечественных СППВР являются…MeDiCase,Алгом14.В чем заключается принцип «клинических путей» в разработке СППВР?-использование моделей стандартных процедур,которые должны быть предприняты в конкретной клинической ситуации у данного пациента15.К какому классу СППВР относится автоматический контроль критериев качества медицинской помощи?— Информационно-справочнымТема №7 «Телемедицина»1.Телемедицинские технологии применяются при организации и оказании медицинской помощи:
•Врачу и пациенту
2.В какие сроки осуществляется консультация с применением телемедицинских технологий в неотложной форме (с момента поступления запроса на их проведение в консультирующую организацию)?
•От 3 до 24 часов
3.В какие сроки осуществляется консультация с применением телемедицинских технологий в экстренной форме (с момента поступления запроса на их проведение в консультирующую организацию)?
•От 30 минут до 2 часов
4.Какую информацию предоставляет пациенту консультирующая медицинская организация?
•Сведения о медицинской организации, участвующей в оказании консультации
•Сведения о консультанте
•Характер консультации
•Порядок получения медицинского заключения по результатам проведенной консультации
5.В какой форме проводятся консультации с применением телемедицинских технологий?
•В экстренной
•В неотложной
•В плановой
6.При оказании каких видов медицинской помощи используют телемедицинские технологии?
•Первичной медико-санитарной помощи
•Специализированной, в том числе высокотехнологичной медицинской помощи
•Скорой, в том числе скорой специализированной медицинской помощи
•Паллиативной медицинской помощи
7.Появление дистанционной медицины в России относят … к 60-70 годам8.Допускается ли использование мобильных средств связи для телемедициских консультаций?
•Да, врачами бригад скорой помощи, а также при оказании помощи малочисленным народам Севера
9.В каком режиме проводятся консультации с применением телемедицинских технологий?
•В режиме реального времени и (или) отложенных консультаций
10.Кем устанавливается необходимость проведения консультации с применением телемедицинскихтехнологий в экстренной и неотложной формах?
•Лечащим врачом
11.Какой срок хранения документации, полученной в результате телемедицинских консультаций?
•25 лет
12.Какое из определений телемедицины является наиболее полным?
•Прикладное направление медицинской науки …телекоммуникационных технологий
13. Какие преимущества имеет дистанционное обучение перед традиционным?
•Обучение или переподготовка без выезда в учебные учреждения
•Обеспечение постоянного доступа к новейшей информации
14.Какой срок хранения материалов, сопутствующих телемедицинской консультации (аудио – и видеозаписи, текстовые сообщения, изображения и т.д.)?
•1 год
15.Какие формы взаимодействия с пациентом допускаются при проведении телемедицинскойконсультации?
•Видеоконсультация
•Аудиосвязь
•Обмен текстовыми сообщениями и файлами
16.Может ли медицинское образование стать полностью дистанционным?
•Нет, из-за невозможности в полном объеме изучать практические навыки дистанционно
17.При дистанционном наблюдении за состоянием здоровья пациента осуществляется:
•Получение данных о состоянии здоровья пациента
•Обработка данных о состоянии здоровья пациента
•Контроль показателей состояния здоровья пациента
•Экстренное реагирование при критическом отклонении показателей состояния здоровья пациента от предельных значений
18.В каком году пришли первые видеоконсультациив РФ?
•1995 год
Тема №8 «Информационная безопасность»1.Что такое электронная подпись?
•Информация в электронной форме, которая присоединена к другой информации в электронной форме …подписывающего информацию
2.Какие функции защиты информации от несанкционированного доступа должны поддерживать МИС МО?
•Аутентификация и авторизация пользователя по логину и паролю условно-постоянного действия
•Изменение прав управления доступом пользователей к ресурсам МИС МО
•Регистрация неудачных попыток доступа и изменения системных объектов с сохранением даты и времени, регистрационного имени пользователя системы и типа события в журнале и возможность его анализа
3.Что понимают под защитой информации?
•Это комплекс мероприятий, направленных на обеспечение информационной безопасности
4.Какие виды угроз информации принято выделять?
•Уничтожение
•Несанкционированное или ошибочное использование информационных ресурсов системы
•Отказ в получении или отправке информации
•Несанкционированное получение и распространение конфиденциальной информации
•Создание ложных сообщений
•Блокирование доступа к информации
•Несанкционированная модификация информации
5.Какие виды усиленной электронной подписи принято выделять?
•Неквалифицированная и квалифицированная
6.Что такое информационная угроза?
•Это потенциальная возможность определенным образом нарушить информационную безопасность
7.Что такое санкционированный многоуровневый доступ?
•Предоставление каждому из обращающихся … осуществление различных действий
8.Какие уровни защиты информации принято выделять?
•Законодательный
•Административный
•Процедурный уровень
•Программно-технический уровень
9.Какие виды электронной подписи принято выделять?
•Простая и усиленная
10.Что такое конфиденциальная информация?
•Это документированная информация, правовой режим которой .. общественной деятельности
11.Информационная безопасность это …
•Защищенность информации и поддерживающей инфраструктуры от случайных или преднамеренных воздействий естественного или искусственного характера
12.Какая конфиденциальная информация используется в медицинских организациях? (ВСЕ, кроме данные о структуре и местонахождении мед.организации)
•Персональные данные, составляющие «личную тайну», а также врачебную тайну
•Технико-экономические данные (о взаиморасчетах между учреждениями здравоохранения), составляющие коммерческую тайну
•Данные о медико-демографической и эпидемиологической ситуации, составляющие служебную тайну
13.Является ли верным утверждение: информация в электронной форме, подписанная усиленной неквалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью и заверенному печатью?
•Да
14.Как обеспечивается технически в МИС МО вопрос конфиденциальности и защиты данных?
•Использованием иерархической системы паролей, присваиваемых пользователям и определяющих их право на просмотр и (или) внесение новых записей
15.Что такое аутентификация пользователей?
•Проверка подлинности путем сравнения введенного пароля с паролем, сохраненным в базе данных пользовательских логинов
Итоговые тесты (Даша)
1. Что такое аутентификация пользователей?
• Проверка подлинности путем сравнения путем введенного пароля с паролем, сохраненным в базе данных пользовательских логинов
2. На какие подклассы делятся административные АРМ?
• Административно-управленческие
• Медико-статистические
• Экономические
3. Какая информация содержится в разделе «Результаты исследований» ЭМК?
• Данные обо всех проведенных исследованиях пациента, а также о результатах таких исследований
4. Какая конфиденциальная информация используется в медицинских организациях?
• Персональные данные, составляющие «личную тайну», а также врачебную тайну
• Технико-экономические данные (о взаиморасчетах между учреждениями здравоохранения), составляющие коммерческую тайну
• Данные о медико-демографической и эпидемиологической ситуации, составляющие служебную тайну
5. Целью медицинской информатики является?
• Оптимизация информационных процессов в медицине
• Обучение медицинского персонала компьютерной грамотности и умению работать с современными медицинскими приборно-компьютерными системами
• Внедрение компьютерных технологий в медицину и здравоохранение для облегчения ведения медицинской документации
6. К недостаткам использования ЭМК относятся:
• Зависимость от исправной работы компьютерного оборудования и серверов
• Отсутствие интеграции с другими МО
7. Структура персональной медицинской записи включает в себя (ВСЕ)
• Идентификатор электронной записи, с помощью которого врач сможет ее найти в общем перечне записей
• Номер ЭМК, в которую вносится запись
• Дата и время создания электронной записи, а также того события (заболевания или консультации), которое стало причиной создания такой записи
• Тест самой записи
• Системные дата и время, которые обозначают подписание записи
• Обозначение идентификатора того специалиста, который данную запись создал
• Код использования электронной цифровой подписи врача, с помощью которой ПМЗ была подписана
8. Что может служить источником информации для МИС МО?
• медицинские записи, создаваемые в процессе оказания всех видов мед. Помощи
• данные, получаемые от медицинской техники
• данные, передаваемые из других информационных систем
9. Модуль «Оказание скорой и неотложной медицинской помощи» входит в состав МИС МО
• Поликлиники
• Службы скорой медицинской помощи
10. Что такое электронная медицинская карта пациента?
• Совокупность электронных персональных медицинских записей, относящихся и используемых к одному пациенту, собираемых, хранящихся и используемых в рамках одной МО
11. Создание специальных средств адаптации АРМ к уровню подготовки пользователя и возможностью его обучения непосредственно на данном АРМ основывается на:
• Принципе максимальной ориентации на конечного пользователя
• Что такое электронная персональная медицинская запись?
• Медицинская запись, сделанная на электронном носителе, кот отражает фактическое состояние пациента на момент обращения, а также перечень оказанных ему мед услуг
12. Какая информация содержится в разделе «Метрика пациента»
• Сведения о проводимых метрических измерениях человека
13. Для решения каких задач предназначены система поддержки принятия врачебных решений?
• Интерпретация медицинских изображений
• Подача тревожных сигналов и напоминаний
• Контроль и планирование терапии
• Помощь при постановке диагноза
14. К какому классу СППВР относится автоматизация врачебных назначений?
• Информационно-справочным
15. На решение каких задач ориентирован «Центр компетенций», созданный на базе ЦНИИОИЗ?
• Разработка требований к централизованным подсистемам ГИС СЗ, методики оценки уровня информатизации здравоохранения регионов, методических рекомендаций и контроль и управление ходом проекта
16. Какие виды информационных систем внедряются в регионах Российской Федерации?
• Государственные информационные системы в сфере здравоохранения (ГИС СЗ)
• Медицинские информационные системы медицинских организаций (МИС МО)
• Информационные системы фармацевтических организаций (ИС ФО)
17. Что такое прецендентный подход к построению СППВР?
• Основан на поиске в базе данных случаев, похожих на текущий, и система формирует рекомендации по диагностике и лечению на основе найденных случаев
18. Какими способами медицинская организация обеспечивает информационную безопасность ЭМК?
• Внесение любых новых данных
• Использование максимального числа кодов для шифрования инф
• Установка спец криптографического ПО
19. АРМ главного врача МО по предназначению
• Административное
20. Модуль «Инструментальная диагностика» входит в состав МИС МО
• Стационара, роддома, санатория, поликлиники, стоматологии
21. Суммарная длительность перебоев в работе информационной системы не должна превышать
• 4 часов в месяц
22. Модуль «Аптека МО» входит в состав Модуль «Аптека МО» входит в состав МИС МО
Стационара, роддома, санатория, поликлиники, стоматологии, службы скорой помощи
23. Куда должны передаваться сведения о медицинских документах в форме электронного документа, формирование и хранение которых осуществляется в медицинской организации?
• Федеральный реестр электронных медицинских документов
24. Согласно классификации АРМ по их принадлежности к определенному функциональному классу, АРМ третьего уровня
• Обеспечивает диагностику, диф диагностику
25. Важными технологическими требованиями к ГИС СЗ, МИС МО и ИС ФО является
• Обеспечение бесперебойного ведения базы данных и защиты от несанкционированного доступа
• Обеспечение защиты информации, содержащейся в соответствующей информационной системе, посредством применения организационных и технических мер защиты
• Обеспечение поддержки юридически значимого электронного документооборота
• Наличие действующих сертификатов, выданных ФСБ и ФСТЭК в отношении применяемых средств защиты информации
26. Кем заполняется раздел «Врачебные осмотры» ЭМК?
Специалистом, который проводит осмотр
27. С какой целью создавалась ЕГИСЗ?
• Обеспечение эффективной информационной поддержки процесса управления системой медицинской помощи, а также процесса оказания медицинской помощи
28. Какие задачи решались на этапе «Развитие ЕГИСЗ» в 2013-2018 г?
ВСЕ повышения
• Повышение эффективности управления
• Повышение информированности
• Повышение качества
29. Является ли верным утверждение: информация в электронной форме, подписанная усиленной неквалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью и заверенному печатью?
• Да
30. На основе какой системы разрабатывается единый цифровой контур здравоохранения?
• Единая государственная информационная система здравоохранения (ЕГИСЗ)
31. Возможность информационного взаимодействия программно-технические средств информационных систем МО между собой является
• Обязательным технологическим требованием
32. Обязательными функциями подсистемы «Цифровые изображения (Радиология)» МИС МО являются
• Формирование протокола исследования
• Ведение журнала диагностического кабинета
• Формирование статистической отчетности
33.
Какие уровни автоматизации медицинской организации принято выделять?
• Начальная автоматизация,
• Работа с электронной медицинской картой,
• Полная автоматизация
34
. Обязательными функциями подсистемы «Приемное отделение» МИС МО являются
• Регистрация медицинских данных обслуживаемых пациентов
• Поиск гражданина по идентификатору
• Внесение информации из документов, удостоверяющих личность
• Создание ЭМК. Внесение полисов ОМС, ДМС
• Получение информированного согласия на обработку перс. данных
35. Какая информация содержится в разделе «Вмешательства и процедуры» ЭМК
• Данные о проведенных оперативных вмешательствах
• Данные о подготовит к оперативному вмешательству мероприятиях
• Данные о реанимационных действиях
• Сведения о применении специализированного лекарственного сопровождения
36. Примерами отечественных СППВР являются
• MeDiCase
• Алгом
37.
Защита данных в ЭМК двусторонняя, так как осуществляется со стороны
• Медицинской организации и пациентов
38. По каким медицинским и фармацевтическим организациям региона должна содержать информацию ГИС СЗ?
• По государственным (муниципальным) и частным организациям
38. Основными направлениями реализации федерального проекта «Создание единого цифрового контура в здравоохранении на основе единой государственной информационной системы здравоохранения (ЕГИСЗ)» являются:
• Внедрение медицинских информационных систем в медицинских организациях (МИС МО), переход на юридически-значимую электронную медицинскую карту (ЭМК);
• Внедрение региональных сервисов и систем для управления здравоохранением;
• Функционирование федерального ЦОД и федеральных сервисов ЕГИСЗ ;
• Развитие сервисов личного кабинета пациента «Мое здоровье» ЕПГУ
39. Что такое конфиденциальная информация?
• Это документированная информация, правовой режим которой установлен специальными нормами действующего законодательства в области государственной, коммерческой, промышленной и другой общественной деятельности
40. Какой из сервисов содержит актуальные сведения обо всех медицинских работниках медицинской организации?
• Федеральный регистр медицинских работников
41. Укажите наиболее полное определение медицинской информатики
• Наука, занимающаяся исследованием процессов получения, передачи, обработки, хранения, распространения, представления информации с использованием информационной техники в медицине и здравоохранении
42. Государственные информационные системы в сфере здравоохранения субъектов Российской Федерации (ГИС СЗ) это
• Информационные системы, предназначенные для сбора, хранения, обработки и предоставления информации, необходимой для информационной поддержки управления деятельностью в сфере охраны здоровья, включая информацию о медицинских и фармацевтических организациях и об осуществлении ими медицинской и фармацевтической деятельности
43. Что такое санкционированный многоуровневый доступ?
• Предоставление каждому из обращающихся к информационной системе соответствующих прав ко всей базе данных или отдельным ее разделам, т.е. прав на ознакомление с различными данными пациентов и осуществление различных действий
44. На какие подклассы делятся организационно-технологические АРМ?
• Организационно-клинические
• Телемедицинские
45. Согласно Федеральному закону от 21 ноября 2011 «об основах охраны здоровья граждан в РФ» пациент либо его законный представитель
• Имеет право непосредственно знакомиться с мед документацией, отражающей состояние его здоровья, и получать на основании такой документации консультации у других специалистов
46. С какими данными, содержащиеся в ЭМК, имеет право ознакомиться пациент?
• Результатами проведенных медицинских анализов
• Протоколами осмотров врачей и специалистов
• Данными о листках нетрудоспособности
47. В какие годы происходило развитие ЕГИСЗ?
• 2013 – 2018
48. По каким направлениям оценивается эффективность внедрения СППВР в МО?
• Эффективность клиническая,
• Эффективность организационная,
• Эффективность экономическая
49. Какие уровни защиты информации принято выделять?
• Законодательный
• Административный
• Процедурный уровень
• Программно-технический уровень
50. На каких общих принципах основывается проектирование и внедрение АРМ?
• Принцип постоянного взаимодействия разработчиков АРМ и их пользователей
• Принцип максимальной ориентации на конечного пользователя
• Принцип проблемной ориентации
• Принцип соответствия информационных потребностей пользователей используемым техническим средствам
51. К какому классу СППВР относится автоматический контроль критериев качества медицинской помощи?
• Информационно-справочным
52. Какая информация содержится в разделе «Данные о владельце документа» ЭМК?
• Сведения о медицинской организации, которая завела электронную карту
53. Модуль «Статистика» входит в состав МИС МО
Стационара, роддома, санатория, стоматологической поликлиники, поликлиники
54. Является ли ЭПМЗ юридически значимым документом
• Да, после подписания эл подписью
55. В соответствии с предназначением АРМ в МО классифицируются на
• медико-технологические,
• организационно-технологические,
• административные
56.
Какая информация содержится в разделе «Данные о пациенте» ЭМК
Дата и место рождения, пол, паспортные данные, тип обращения по виду страхования (ОМС или ДМС)
57
. С какой целью создаются и внедряются МИС
• Повышение качества и доступности мед помощинаселению
• Повышение эффективности работы
• Вовлечение граждан в заботу о собственном здоровье
• Обеспечение оперативности принятия управленческихрешений
58. К преимуществам использования ЭМК относятся
• Оперативный доступ к информации о пациенте и имеющихся у него заболеваниях в любой МО, подключенной к единому цифровому контуру здравоохранения, независимо от региона
• Однократный ввод и многократное использование информации
• Возможность быстрого получения необходимых медицинских документов в электронном виде
+невозможность утери сведений о пациенте вместе с его картой
59. Применяемые в регионе информационные системы в сфере здравоохранения должны обеспечивать интеграцию с (ВСЕ)
60. Согласно требованиям постановления Правительства РФ от 16.11.2015 г №1236 «Об установлении запрета на доступ программного обеспечения, происходящего из иностранных государств» МИС МО, ГИС СЗ и ИС ФО, начиная с 1 июля 2019 года должны(ВСЕ)
61. Информационные системы фармацевтических организаций (ИС ФО) это
• Информационные системы, содержащие информацию, необходимую… об осуществлении ими фармацевтической деятельности
62. Аппаратное обеспечение МИС МО должно обеспечивать
• Совместимость и возможность изменения конфигурации технических средств
• Надежность обработки информации, достаточную для эффективного функционирования и получения требуемой достоверности результатов
• Включение средств защиты информации от несанкционированного доступа
63. В какой промежуток времени осуществляется этап «базовой информатизации»?
• 2011 – 2012
64. На какие классы делятся медико-технологические АРМ?
• Клинические
• Функциональные
• Радиологические
• Лабораторные
• Фармакологические
65.Информатизация это ?
+реализация комплекса мер , направленных на обеспечение полного и своевременного использования достоверных знаний
66.Какой из сервисов содержит актуальные сведения о мед.организации и всех структурных подразделений?
+федеральный реестр медицинских организаций
67.Медицинские информационные системы медицинских организаций (МИСМО)?
+Информационные системы , предназначенные для сбора , хранения ….и о медицинской деятельности медицинских организаций
68.Функциональные возможности региональных государственных информационных систем в сфере здравоохранения должны обеспечивать
+все , кроме автоматическую выгрузку данных в федеральные регистры
69.Задачами «базового этапа» создания ЕГИСЗ 2011-2012 г являлись :
+ВСЕ
70.Функциональные возможности медицинской информационной системы медицинской организации должны обеспечивать :
+ВСЕ
МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ
И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРИКАЗ
от 29 октября 2018 г. N 573
ОБ УТВЕРЖДЕНИИ ТРЕБОВАНИЙ
К ТЕХНИЧЕСКИМ И ПРОГРАММНЫМ СРЕДСТВАМ ИНФОРМАЦИОННЫХ
СИСТЕМ, СОДЕРЖАЩИХ БАЗЫ ДАННЫХ АБОНЕНТОВ ОПЕРАТОРА СВЯЗИ
И ПРЕДОСТАВЛЕННЫХ ИМ УСЛУГАХ СВЯЗИ, А ТАКЖЕ ИНФОРМАЦИЮ
О ПОЛЬЗОВАТЕЛЯХ УСЛУГАМИ СВЯЗИ И О ПРЕДОСТАВЛЕННЫХ
ИМ УСЛУГАХ СВЯЗИ, ОБЕСПЕЧИВАЮЩИХ ВЫПОЛНЕНИЕ УСТАНОВЛЕННЫХ
ДЕЙСТВИЙ ПРИ ПРОВЕДЕНИИ ОПЕРАТИВНО-РОЗЫСКНЫХ МЕРОПРИЯТИЙ
В соответствии со статьями 41 и 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи» (Собрание законодательства Российской Федерации, 2003, N 28, ст. 2895; 2004, N 45, ст. 4377; 2006, N 31, ст. 3452; 2011, N 45, ст. 6333; 2014, N 26, ст. 3366; 2016, N 28, ст. 4558; 2018, N 32, ст. 5135), пунктами 4 и 12 Правил взаимодействия операторов связи с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность, утвержденных постановлением Правительства Российской Федерации от 27 августа 2005 г. N 538 (Собрание законодательства Российской Федерации, 2005, N 36, ст. 3704; 2007, N 48, ст. 6010; 2008, N 42, ст. 4832; 2013, N 15, ст. 1804; 2018, N 3, ст. 556; 2018, N 40, ст. 6142), и пунктами 5 — 8 Правил хранения операторами связи текстовых сообщений пользователей услугами связи, голосовой информации, изображений, звуков, видео- и иных сообщений пользователей услугами связи, утвержденных постановлением Правительства Российской Федерации от 12 апреля 2018 г. N 445 (Собрание законодательства Российской Федерации, 2018, N 17, ст. 2489), пунктом 29 Перечня средств связи, подлежащих обязательной сертификации, утвержденного постановлением Правительства Российской Федерации от 25 июня 2009 г. N 532 (Собрание законодательства Российской Федерации, 2009, N 26, ст. 3206; 2015, N 6, ст. 954), приказываю:
1. Утвердить прилагаемые Требования к техническим и программным средствам информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий.
2. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.
Министр
К.Ю.НОСКОВ
1. Требования к техническим и программным средствам информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее соответственно — Требования, ОРМ), разработаны в целях обеспечения целостности, устойчивости функционирования и безопасности единой сети электросвязи Российской Федерации <1>, а также создания условий для выполнения уполномоченными государственными органами, осуществляющими оперативно-розыскную деятельность (далее — уполномоченные государственные органы), возложенных на них задач с использованием технических средств.
———————————
<1> Пункт 1 статьи 41 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
2. Требования обязательны для применения в отношении технических и программных средств информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении ОРМ (далее — технические и программные средства ИС ОРМ), подлежащих установке на сетях операторов связи, осуществляющих деятельность в рамках лицензий на оказание услуг связи <2>.
———————————
<2> Постановление Правительства Российской Федерации от 18 февраля 2005 г. N 87 «Об утверждении перечня наименований услуг связи, вносимых в лицензии, и перечней лицензионных условий» (Собрание законодательства Российской Федерации, 2005, N 9, ст. 719; 2006, N 2, ст. 202; 2007, N 38, ст. 4552; 2008, N 4, ст. 275; 2015, N 6, ст. 954; 2018, N 39, ст. 5978).
3. Технические и программные средства ИС ОРМ в соответствии с пунктом 29 Перечня средств связи, подлежащих обязательной сертификации, утвержденного постановлением Правительства Российской Федерации от 25 июня 2009 г. N 532, подлежат обязательной сертификации в порядке, установленном Правилами организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденными постановлением Правительства Российской Федерации от 13 апреля 2005 г. N 214 (Собрание законодательства Российской Федерации, 2005, N 16, ст. 1463; 2008, N 42, ст. 4832; 2012, N 6, ст. 687).
4. Посредством ИС ОРМ осуществляется сбор, накопление, хранение, поиск и предоставление уполномоченным государственным органам, осуществляющим в соответствии с Федеральным законом от 12 августа 1995 г. N 144-ФЗ «Об оперативно-розыскной деятельности» (Собрание законодательства Российской Федерации, 1995, N 33, ст. 3349; 1999, N 2, ст. 233; 2000, N 1, ст. 8; 2001, N 13, ст. 1140; 2003, N 2, ст. 167; N 27, ст. 2700; 2005, N 49, ст. 5128; 2007, N 31, ст. 4008; 2008, N 52, ст. 6235; 2013, N 51, ст. 6689; 2016, N 27, ст. 4238, N 28, ст. 4558) оперативно-розыскную деятельность, информации об абонентах и оказанных пользователям услугах связи, в том числе о фактах приема, передачи, доставки и (или) обработки голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений <3> пользователей услугами связи, содержании голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений пользователей услугами связи, а также иной информации <4>, необходимой для выполнения возложенных на уполномоченные государственные органы задач в порядке и случаях, установленных федеральными законами.
———————————
<3> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
<4> Пункт 1.1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
5. Посредством технических и программных средств ИС ОРМ по запросу, поступающему с оборудования уполномоченного государственного органа, осуществляющего взаимодействие с техническими и программными средствами ИС ОРМ в соответствии с Приложениями N 3 — 9 (далее соответственно — пульт управления уполномоченного государственного органа, ПУ), обеспечивается передача на ПУ данных о предоставленных абонентам и другим пользователям следующих услуг связи:
1) услуг местной телефонной связи, за исключением услуг местной телефонной связи с использованием таксофонов и средств коллективного доступа;
2) услуг междугородной и международной телефонной связи;
3) услуг телефонной связи в выделенной сети связи;
4) услуг внутризоновой телефонной связи;
5) услуг местной телефонной связи с использованием таксофонов;
6) услуг местной телефонной связи с использованием средств коллективного доступа;
7) услуг подвижной радиосвязи в сети связи общего пользования;
услуг подвижной радиосвязи в выделенной сети связи;
9) услуг подвижной радиотелефонной связи в сети связи общего пользования;
10) услуг подвижной спутниковой радиосвязи;
11) услуг связи по предоставлению каналов связи;
12) услуг связи в сети передачи данных, за исключением передачи голосовой информации;
13) услуг связи по передаче голосовой информации в сети передачи данных;
14) телематических услуг доступа к информационно-телекоммуникационной сети «Интернет» (далее — сеть «Интернет»).
6. Посредством технических и программных средств ИС ОРМ обеспечиваются сбор, накопление, хранение и предоставление на ПУ по запросу уполномоченного государственного органа <5> в автоматическом режиме:
———————————
<5> Пункт 5 постановления Правительства Российской Федерации от 27 августа 2005 г. N 538 «Об утверждении правил взаимодействия операторов связи с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность».
1) информации об абонентах;
2) информации о пользователях услугами связи;
3) информации о предоставленных абонентам и другим пользователям данной сети связи услугах связи, действиях абонентов и других пользователей при получении услуг связи, взаимодействии между средствами связи, позволяющем абонентам передавать и/или получать данные (далее — соединения), в том числе о регистрируемых сетью связи действиях, совершенных абонентами и другими пользователями при обращении к сети связи, которые не привели к установлению соединения (попытки установления соединения, несостоявшиеся соединения), а также о содержании сообщений (текстовых, голосовых и мультимедийных) как доставленных, так и не доставленных адресату и сохраненных на средствах связи данной сети для последующей доставки;
4) голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений <6> пользователей услугами связи (при наличии лицензий на услуги связи по предоставлению каналов связи, услуги связи в сети передачи данных, за исключением передачи голосовой информации, телематические услуги связи <7>);
———————————
<6> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
<7> Пункты 13, 14, 16 Перечня наименований услуг связи, вносимых в лицензии на осуществление деятельности в области оказания услуг связи, утвержденного постановлением Правительства Российской Федерации от 18 февраля 2005 г. N 87.
5) иной информации <8>, необходимой для выполнения возложенных на уполномоченные государственные органы задач для проведения ОРМ, в случаях, установленных федеральными законами.
———————————
<8> Пункт 1.1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
7. Взаимодействие технических и программных средств ИС ОРМ с ПУ должно осуществляться по пяти каналам передачи данных:
1) канал управления (кпд1);
2) канал данных (кпд2);
3) канал мониторинга (кпд3);
4) канал неформатированных данных (кпд4);
5) канал доставки сообщений пользователей услугами связи (кпд5).
8. Если оператор связи предоставляет пользователям дополнительные услуги <9> с использованием сети передачи данных, посредством ИС ОРМ обеспечиваются сбор, накопление и хранение информации для указанных услуг в форматах, приведенных в приложении N 13 к Требованиям.
———————————
<9> Пункт 9 Правил оказания услуг связи по передаче данных, утвержденных постановлением Правительства Российской Федерации от 23 января 2006 г. N 32 (Собрание законодательства Российской Федерации, 2006, N 5, ст. 553; 2008, N 8, ст. 749; 2014, N 32, ст. 4542, N 34, ст. 4662; 2016, N 6, ст. 852; 2017, N 44, ст. 6522).
9. Технические и программные средства ИС ОРМ должны размещаться на узлах связи операторов связи на территории Российской Федерации <10>.
———————————
<10> Пункт 15 постановления Правительства Российской Федерации от 27 августа 2005 г. N 538 «Об утверждении правил взаимодействия операторов связи с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность».
10. Состав накапливаемой в технических и программных средствах ИС ОРМ информации <11> приведен в приложении N 1 к Требованиям.
———————————
<11> Пункт 14 постановления Правительства Российской Федерации от 27 августа 2005 г. N 538 «Об утверждении правил взаимодействия операторов связи с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность».
11. Требования, предъявляемые к интерфейсу взаимодействия между ПУ и техническими и программными средствами ИС ОРМ, приведены в приложении N 2 к Требованиям.
12. Требования, предъявляемые к функционированию канала управления (кпд1), приведены в приложении N 3 к Требованиям.
13. Требования, предъявляемые к функционированию канала данных (кпд2), приведены в приложении N 4 к Требованиям.
14. Требования, предъявляемые к функционированию канала мониторинга (кпд3), приведены в приложении N 5 к Требования.
15. Требования, предъявляемые к функционированию канала неформатированных данных (кпд4), приведены в приложении N 6 к Требованиям.
16. Требования, предъявляемые к функционированию канала доставки сообщений пользователей услугами связи (кпд5), приведены в приложении N 7 к Требованиям.
17. Форматы сообщений технических и программных средств ИС ОРМ приведены в приложении N 8 к Требования.
18. Требования к параметрам кодирования протокола взаимодействия ASN.1 ПУ и технических и программных средств ИС ОРМ приведены в приложении N 9 к Требованиям.
19. Посредством технических и программных средств ИС ОРМ обеспечиваются:
1) сбор и обработка информации, из различных источников для наполнения и формирования баз данных (далее — первичная обработка информации), состав которой определяется настоящими Требованиями, для последующего ее накопления, хранения и предоставления по запросу ПУ;
2) накопление и хранение на срок до 6 месяцев голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений пользователей услугами связи (при наличии лицензий на услуги связи по предоставлению каналов связи, услуги связи в сети передачи данных, за исключением передачи голосовой информации, телематические услуги связи) с момента окончания их приема, передачи, доставки и (или) обработки;
3) автоматическое удаление сообщений электросвязи пользователей услугами связи в соответствии пунктом 8 Правил хранения операторами связи текстовых сообщений пользователей услугами связи, голосовой информации, изображений, звуков, видео- и иных сообщений <12> пользователей услугами связи, утвержденных постановлением Правительства Российской Федерации от 12 апреля 2018 г. N 445 (далее — Правила хранения);
———————————
<12> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
4) контроль времени поступления из сетей связи информации и информирование ПУ о превышении значений в соответствии с пунктом 34 настоящих Правил;
5) накопление, хранение и обработка информации об абонентах и других пользователях данной сети, о выделенных абонентам телефонных номерах и кодах идентификации, об оказанных абонентам услугах связи и иной информации <13>, необходимой для выполнения возложенных на уполномоченные государственные органы задач по проведению ОРМ в случаях, установленных федеральными законами <14>, в течение трех лет (данные об услугах связи, оказываемых абонентам и другими пользователями данной сети, должны накапливаться независимо от того, присутствует или нет в технических и программных средствах ИС ОРМ информация о выделении телефонных номеров и (или) кодов идентификации);
———————————
<13> Пункт 1.1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
<14> Федеральный закон от 12 августа 1995 г. N 144-ФЗ «Об оперативно-розыскной деятельности», Федеральный закон от 7 июля 2003 г. N 126-ФЗ «О связи».
6) поиск запрашиваемой с ПУ информации, хранимой в технических и программных средствах ИС ОРМ (далее — поисковые задачи);
7) защита от несанкционированного доступа со стороны производителей оборудования технических и программных средств ИС ОРМ; неавторизованных пользователей; технического персонала оператора связи; третьих лиц как к хранящимся в технических и программных средствах ИС ОРМ сообщениям абонентов и другими пользователями, так и информации, непосредственно связанной с проведением ОРМ (информации, поступающей в технические и программные средства ИС ОРМ с ПУ, и информации, подготовленной к передаче из технических и программных средств ИС ОРМ в ПУ) в соответствии пунктом 7 Правил хранения;
информирование ПУ о попытках:
доступа к данным, хранящимся в технических и программных средствах ИС ОРМ, связанным с проведением ОРМ, с использованием штатных команд или сервисных программ;
обращения к информации технических и программных средств ИС ОРМ, содержащей данные, связанные с проведением ОРМ;
резервного копирования данных, связанных с проведением ОРМ;
доступа к техническим и программным средствам ИС ОРМ через порты, не предусмотренные для доступа;
вскрытия корпуса технических средств, предназначенных для приема запросов от ПУ;
9) контроль работоспособности и загруженности технических и программных средств ИС ОРМ;
10) контроль за соблюдением предоставленных прав доступа к хранящейся в технических и программных средствах ИС ОРМ информации;
11) круглосуточный удаленный доступ со стороны операторов ПУ к хранящейся в технических и программных средствах ИС ОРМ информации в соответствии с пунктом 12 Правил взаимодействия операторов связи с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность, утвержденных постановлением Правительства Российской Федерации от 27 августа 2005 г. N 538, по протоколу взаимодействия ПУ и ИС ОРМ в соответствии с Требованиями к параметрам кодирования протокола взаимодействия ASN.1 ПУ и технических и программных средств ИС ОРМ, приведенных в приложении N 9 к Требованиям;
12) реализация протокола взаимодействия технических и программных средств ИС ОРМ и оборудования ПУ, приведенного в приложении N 9 к Требованиям;
13) прием от ПУ запросов об абонентах и других пользователях и предоставленных им услугах связи, предусмотренных настоящими Требованиями;
14) передача на ПУ от технических и программных средств ИС ОРМ данных в соответствии с поступившими с ПУ запросами;
15) взаимодействие с техническими средствами ОРМ в соответствии с протоколом взаимодействия, приведенным в приложении N 3 к Требованиям применения оборудования систем коммутации, включая программное обеспечение, обеспечивающего выполнение установленных действий при проведении оперативно-розыскных мероприятий. Часть IV. Правила применения оборудования систем коммутации, включая программное обеспечение и технические средства накопления голосовой информации, обеспечивающего выполнение установленных действий при проведении оперативно-розыскных мероприятий, утвержденным приказом Министерства связи и массовых коммуникаций Российской Федерации от 26.02.2018 N 86 (зарегистрирован Министерством юстиции Российской Федерации 28 марта 2018 г., регистрационный N 50536; Официальный интернет-портал правовой информации (http://www.pravo.gov.ru), 29.03.2018);
16) получение голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений <15> пользователей услугами связи (при наличии лицензий на услуги связи по предоставлению каналов связи, услуги связи в сети передачи данных, за исключением передачи голосовой информации, телематические услуги связи <16>), а также информации об оказанных абонентам услугах связи, в том числе о фактах приема, передачи, доставки и (или) обработки голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений пользователей услугами связи, по запросу с ПУ и передача результатов в соответствии с протоколом взаимодействия ПУ и ИС ОРМ;
———————————
<15> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
<16> Пункты 13, 14, 16 Перечня наименований услуг связи, вносимых в лицензии на осуществление деятельности в области оказания услуг связи, утвержденного постановлением Правительства Российской Федерации от 18 февраля 2005 г. N 87.
17) посредством технических и программных средств ИС ОРМ обеспечивается ведение в автоматическом режиме системных файлов, содержащих информацию о работе технических и программных средств ИС ОРМ за исключением данных, связанных с проведением ОРМ:
о поступлении данных из различных источников сети (сетей связи);
об установленных и не установленных авторизованных подключениях (сессиях) к ПУ;
о запросах на получение данных, за исключением данных самого запроса;
об ответах на запросы о получении данных;
об отчетах;
о текущей конфигурации технических и программных средств ИС ОРМ, системного и прикладного программного обеспечения (далее — ПО);
об изменениях в конфигурации технических и программных средств ИС ОРМ, системного и прикладного ПО;
о сбоях в технических и программных средствах ИС ОРМ, системном и прикладном ПО;
об обращении и доступе обслуживающего технического персонала оператора связи к техническим и программным средствам ИС ОРМ;
18) доступ технического персонала к системным файлам и ПО, в соответствии с правами, установленными парольной системой доступа; регистрация команд и сообщений, используемых техническим персоналом при обращении к техническим и программным средствам ИС ОРМ для выполнения регламентных и ремонтных работ;
19) сохранность и доступность для дальнейшего использования ранее накопленных данных при модернизации технических и программных средств ИС ОРМ;
20) выполнение функциональных требований, указанных в настоящем пункте, при вводе в эксплуатацию сетей и средств связи для оказания услуг связи в соответствии с лицензиями на осуществление деятельности в области оказания услуг связи <17>.
———————————
<17> Постановление Правительства Российской Федерации от 18 февраля 2005 г. N 87 «Об утверждении перечня наименований услуг связи, вносимых в лицензии, и перечней лицензионных условий».
20. Посредством технических и программных средств ИС ОРМ для проведения регламентных и ремонтных работ уполномоченному техническому персоналу должен предоставляться доступ к файлу ошибочных блоков переданных отчетов и возможность редактирования ошибочных записей соответствующих отчетов.
21. Посредством технических и программных средств ИС ОРМ обеспечивается сбор и накопление информации:
1) о фактах состоявшихся соединений абонентов (пользователей услугами связи);
2) о фактах несостоявшихся соединений, включая попытки установления соединения, абонентов (пользователей услугами связи);
3) о кратковременных соединениях, не подлежащих тарификации в системе учета сети связи;
4) об услугах связи, предоставленных в рамках действующих лицензий на оказание услуг связи, которая хранится в технических и программных средствах ИС ОРМ в соответствии с приложениями N 1 и 10 к Требованиям.
22. Посредством технических и программных средств ИС ОРМ обеспечивается сбор и накопление информации о соединениях, инициированных абонентами и другими пользователями и реализованных посредством услуг сети передачи данных (при наличии лицензий на услуги связи по предоставлению каналов связи, услуги связи в сети передачи данных, за исключением передачи голосовой информации, телематические услуги связи):
1) подключениях абонента к сети передачи данных и отключениях от сети передачи данных;
2) HTTP-соединениях с информационными ресурсами сети передачи данных (посещение страниц в сети «Интернет», мультиплексирование с использованием протокола HTTP);
3) соединениях для передачи почтовых сообщений;
4) передаче электронных сообщений между пользователями (служебных сообщениях, мгновенных сообщениях, коротких сообщениях, мультимедийных сообщениях, отправленных посредством сети передачи данных);
5) голосовой связи посредством сети передачи данных;
6) передаче файловых данных;
7) терминальном доступе к оборудованию для удаленного управления;
передаче прочих сообщений, принимаемых (получаемых) абонентом при помощи закрытых протоколов обмена;
9) изменении сетевых адресов пользователей, если такая замена (трансляция) сетевых адресов в процессе оказания услуг связи осуществляется на оборудовании связи сети передачи данных оператора связи;
10) о кодах идентификации, выделенных абонентам выделенной сети и адресации, используемой в выделенной сети.
Информация должна храниться в течение трех лет с момента окончания осуществления таких действий <18>.
———————————
<18> Подпункт 1 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
23. Посредством технических и программных средств ИС ОРМ обеспечиваются сбор, накопление и хранение информации о следующих соединениях и сеансах связи абонентов (пользователей услугами телефонной связи) реализованных посредством сетей телефонной связи:
1) телефонных соединениях;
2) входящих/исходящих текстовых коротких сообщениях, как доставленных, так и не доставленных абоненту;
3) служебных соединений;
4) иной информации о телефонных соединениях абонентов и других пользователей телефонной сети связи <19>.
———————————
<19> Пункт 1.1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
24. Посредством технических и программных средств ИС ОРМ обеспечивается сбор, накопление и хранение информации об изменении местоположения абонентов в соответствии с протоколом, приведенным в разделе «Locations.asn» приложения N 9 к Требованиям, доступную в сети связи, как при предоставлении услуги связи, так и в режиме ожидания вызова (при переключении его обслуживания разными устройствами сети связи, находящимися в разных географических зонах обслуживания, при включении и/или выключении абонентского устройства, при рассылке запросов от средств связи).
25. Посредством технических и программных средств ИС ОРМ при сборе информации о соединениях абонентов в сети передачи данных обеспечивается формирование единой записи о соединениях в сети передачи с суммированием количества принятой и переданной информации в течение пяти минут по одной и той же паре IP-адресов и TCP/UDP-портов для всех соединений.
Для HTTP-соединений абонентов в сети передачи данных с информационными ресурсами посредством ИС ОРМ фиксируются сведения согласно приложению N 1 к Требованиям. В качестве международного единого указателя ресурса в сети «Интернет» должен заполняться адрес страницы, запрошенной пользователем.
26. Информация по пунктам 23 — 24 настоящих Правил должна храниться в течение 3-х лет с момента окончания осуществления таких действий <20>.
———————————
<20> Подпункт 1 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
27. Посредством технических и программных средств ИС ОРМ выполняется сбор сообщений пользователей услугами связи следующими способами:
1) сбор сообщений пользователей услугами связи, исключая передачу информации в сеть связи, в том числе от технических средств ОРМ сети передачи данных, в соответствии с протоколом взаимодействия, приведенным в приложении N 2 к Правилам применения оборудования систем коммутации, включая программное обеспечение, обеспечивающего выполнение установленных действий при проведении оперативно-розыскных мероприятий. Часть III. Правила применения оборудования коммутации и маршрутизации пакетов информации сетей передачи данных, включая программное обеспечение, обеспечивающего выполнение установленных действий при проведении оперативно-розыскных мероприятий, утвержденным приказом Министерства связи и массовых коммуникаций Российской Федерации от 16.04.2014 N 83 (зарегистрирован Министерством юстиции Российской Федерации 4 июня 2014 г., регистрационный N 32560) <21>;
———————————
<21> «Российская газета», N 160, 18 июля 2014 г.
2) сбор сообщений пользователей услугами связи с интерфейсов точек консолидации, перечень которых приведен в приложении N 11 к Требованиям (требования к организации точек консолидации голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений <22> пользователей услугами связи, приведены в приложении N 12 к Требованиям).
———————————
<22> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
28. Сбор, накопление и хранение голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений пользователей услугами связи, в ИС ОРМ осуществляется в форматах, приведенных в приложении N 13 к Требованиям.
29. Посредством технических и программных средств ИС ОРМ выполняется накопление и хранение голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений пользователей услугами связи, в соответствии с пунктом 6 Правил хранения.
30. Функционирование технических и программных средств ИС ОРМ не должно оказывать влияние на работоспособность средств связи и собственные информационные системы оператора связи.
31. Посредством технических и программных средств ИС ОРМ, в случае, когда структура организации сети связи оператора связи обслуживает одновременно несколько структурных подразделений оператора связи в субъектах Российской Федерации, обеспечивается функционал предоставления информации по запросу ПУ соответствующих субъектов Российской Федерации.
32. Технические и программные средства ИС ОРМ других сетей связи, должны иметь функционал предоставления информации по запросу ПУ тех субъектов Российской Федерации, где предоставляются услуги связи.
33. Технические и программные средства ИС ОРМ, применяемые в распределенных сетях связи и (или) нескольких сетях связи, должны иметь функционал выполнения поисковых задач для тех сетей связи и структурных подразделений операторов связи, которые заданы с ПУ в запросе. При явном указании списка структурных подразделений операторов связи в параметрах поисковой задачи, запрос выполняется в соответствии с временными характеристиками, приведенными в главе IV Требований.
34. Время предварительной обработки информации с момента ее поступления в технические и программные средства ИС ОРМ до момента, когда она становится доступной для выполнения запросов с ПУ, не должно превышать следующих значений:
1) 5 секунд — для данных об абонентах сети связи и пользователях услугами связи, получивших телефонные номера и (или) коды идентификации для доступа к услугам сети связи;
2) 5 секунд — для данных о кодах идентификации для доступа к услугам сети связи, предоставленных пользователям услугами связи путем распространения карточек доступа;
3) 30 секунд — для данных о кодах идентификации для доступа к услугам сети связи, предоставленных пользователям услугами связи посредством SMS-сообщения;
4) 30 секунд — для данных о временных кодах идентификации, выделяемых пользователям услугами связи в ходе предоставления доступа к сети связи или услугам сети связи;
5) 30 секунд — для данных об изменениях в сети связи;
6) 5 минут с момента наступления события — для данных об оказанных услугах телефонной связи, о смене местоположения абонентов;
7) 10 минут с момента наступления события — для данных о соединениях, осуществленных посредством сети передачи данных.
35. Временной интервал между началом исполнения поисковой задачи техническими и программными средствами ИС ОРМ и завершением формирования результата техническими и программными средствами ИС ОРМ (время выполнения задачи) не должно превышать следующих значений:
1) 1 секунда — для данных о принадлежности идентификаторов абонентов сети оператора связи;
2) 1 секунда — для данных об использовании абонентом (пользователем услуг связи) карты оплаты услуг телефонной связи <23>;
———————————
<23> Пункты 2, 43, 111 Порядка оказания услуг телефонной связи, утвержденного постановлением Правительства Российской Федерации от 9 декабря 2014 г. N 1342 (Собрание законодательства Российской Федерации, 2014, N 51, ст. 7431; 2016, N 6, ст. 852; 2017, N 44, ст. 6522,2018, N 46, ст. 7053).
3) 3 секунды — для данных об идентификаторах абонентов, зарегистрированных на физическое или юридическое лицо;
4) 1 секунда — для данных о пополнении баланса личного счета абонента.
36. Время выполнения задач поиска информации о связях абонентов, накопленных в технических и программных средствах ИС ОРМ, не должно превышать значений, приведенных в таблице N 1 к Требованиям.
37. Посредством технических и программных средств ИС ОРМ должно обеспечиваться одновременное выполнение не менее 100 поисковых задач. При выполнении каждой из 100 одновременно выполняемых задач должны обеспечиваться временные характеристики, указанные в таблице N 1.
Таблица N 1.
N |
Критерии запроса |
Время выполнения запроса |
||||
до суток |
до 1 месяца |
до 6 месяцев |
до 1 года |
до 3 лет |
||
1 |
номер телефона абонента сети оператора; идентификатор подвижной станции абонента (IMEI, ESN/MIN); идентификатор подвижного абонента (IMSI); номер телефонной (таксофонной) карты; |
< 3 с |
< 5 с |
< 15 с |
< 25 с |
< 50 с |
2 |
идентификатор абонента сети передачи данных, в том числе другого оператора связи; идентификатор пользователя в сети передачи данных, в том числе другого оператора связи; идентификатор прикладного уровня при использовании услуг сети передачи данных |
< 1 мин |
< 10 мин |
< 15 мин |
< 1 часа |
< 1,5 часов |
3 |
номер базовой станции; номер группы каналов; номер коммутатора; идентификатор узла связи; идентификатор устройства сети передачи данных; |
< 7 мин |
||||
4 |
критерии идентификатора сообщений пользователей услугами связи |
< 10 с |
38. В ИС ОРМ необходимо наличие функции выполнения комбинированных запросов, являющихся поисковыми критериями, объединенными логическими операциями.
39. В ИС ОРМ необходима поддержка логических операций для объединения поисковых критериев: «И», «ИЛИ», операции группировки критериев «(«, «)» и «НЕ».
40. Применение операции «НЕ» допускается только в случае, если к ее результату или результату включающей его операции объединения применяется операция «И» с допустимым поисковым критерием.
41. К временным параметрам поиска информации в базе данных ИС ОРМ при выполнении комбинированных поисковых запросов предъявляются следующие требования:
1) для операции «И» время выполнения поискового запроса по двум и более критериям должно быть меньше суммарного времени выполнения поисковых запросов по каждому из критериев;
2) для операции «ИЛИ» время выполнения поискового запроса по двум и более критериям должно быть не больше суммарного времени выполнения поисковых запросов по каждому из критериев;
3) для операции «НЕ» время выполнения поискового запроса, в котором один из критериев задан с операцией «НЕ», не должно превышать времени выполнения аналогичного запроса, в котором используется соответствующий критерий без операции «НЕ».
Если один из поисковых критериев является составным критерием с использованием операций группировки, время выполнения исходного запроса должно соответствовать требованиям подпунктов 1 — 3 настоящего пункта.
1. Идентификатор абонента в сетях персонального радиовызова, сети фиксированной телефонной связи, подвижной сети связи состоит из:
1) Идентификатора фиксированной телефонной сети связи общего пользования (далее — ТФоП-идентификатор), включающего:
телефонный номер в международном формате;
внутренний номер (при наличии);
2) GSM-идентификатора, включающего:
телефонный номер в международном формате;
идентификатор мобильного абонента (IMSI);
идентификатор мобильной станции (IMEI);
идентификатор SIM-карты абонента (ICC);
3) Идентификатора мобильной сети связи общего пользования (далее — CDMA-идентификатор), включающего:
телефонный номер в международном формате;
идентификатор мобильного абонента;
идентификатор мобильной станции;
идентификатор мобильного абонента (CDMA);
идентификатор SIM-карты абонента (ICC);
4) идентификатора сети передачи данных, включающего:
идентификатор пользовательского оборудования;
имя пользователя — login;
IP-адрес пользователя;
адрес его электронной почты;
PIN-код;
телефонный номер абонента сети передачи голосовой информации при передаче голоса посредством сети передачи данных;
пользовательский домен;
5) идентификатора сети персонального радиовызова;
6) идентификатора в сети передачи голосовой информации при передаче голоса посредством сети передачи данных, включающего:
IP-адрес абонента;
общедоступное имя инициатора связи;
телефонный номер абонента или уникальный код идентификации в сети передачи голосовой информации при передаче голоса посредством сети передачи данных.
2. Технические и программные средства ИС ОРМ должны накапливать следующую информацию о соединениях абонентов в сети персонального радиовызова:
1) дату и время соединения;
2) тип соединения;
3) идентификаторы абонента;
4) объем переданных данных;
5) причину завершения соединения;
6) идентификатор оператора связи или структурного подразделения
3. Технические и программные средства ИС ОРМ должны накапливать следующую информацию о соединениях абонентов при оказании услуг фиксированной телефонной связи:
1) дату и время начала соединения;
2) длительность соединения, секунд;
3) тип соединения;
4) тип вызывающего абонента;
5) коммутатор, обслуживший соединение;
6) тип вызываемого абонента;
7) входящий группа соединительных линий;
исходящий группа соединительных линий;
9) код пограничного коммутатора;
10) причину завершения соединения;
11) идентификатор оператора связи или его структурного подразделения;
12) оказанные услуги связи при соединении;
13) номер телефонной карты;
14) идентификаторы вызывающего абонента;
15) набранный номер вызываемого абонента;
16) идентификаторы вызываемого абонента;
17) телефонный номер при переадресации;
18) код сигнальной точки отправления (OPC) для транзитного узла связи;
19) код сигнальной точки назначения (DPC) для транзитного узла связи;
20) текстовое сообщение пользователей услугами связи;
21) идентификатор сообщений пользователей услугами связи.
4. Технические и программные средства ИС ОРМ должны накапливать следующую информацию о соединениях абонентов при предоставлении услуг подвижной телефонной связи:
1) дату и время начала соединения;
2) длительность соединения, выраженную в секундах;
3) тип соединения;
4) оказанные услуги связи при соединении;
5) тип вызывающего абонента;
6) коммутатор, обслуживший соединение;
7) тип вызываемого абонента;
входящая группа соединительных линий;
9) исходящая группа соединительных линий;
10) код пограничного коммутатора;
11) код роумингового партнера;
12) причину завершения соединения;
13) идентификатор оператора связи или структурного подразделения;
14) идентификаторы вызывающего абонента;
15) местоположение вызывающего абонента на начало вызова;
16) местоположение вызывающего абонента на конец вызова;
17) идентификаторы вызываемого абонента;
18) местоположение вызываемого абонента на начало вызова;
19) местоположение вызываемого абонента на конец вызова.
20) телефонный номер при переадресации;
21) текстовое сообщение;
22) идентификатор сообщений пользователей услугами связи.
5. Технические и программные средства ИС ОРМ должны накапливать следующую информацию о соединениях абонентов в сети передачи данных:
1) информацию о подключении (отключении) абонента к сети передачи данных (AAA-имя пользователя login), включающую:
дату и время подключения (отключения) к сети передачи данных;
тип соединения (подключение к сети передачи данных, отключение от сети передачи данных, смена местоположения);
идентификатор сессии;
выделенный динамический IP-адрес;
имя пользователя (login);
код протокола в соответствии с RFC 1700, либо номер порта для TCP/UDP;
вызывающий номер;
вызываемый номер;
IP-адрес/порт сетевого накопителя данных (далее — NAS-сервер);
объем принятых данных, байт;
объем переданных данных, байт;
идентификатор оператора связи или структурного подразделения;
идентификатор пользовательского оборудования;
наименование GPRS точки доступа (APN);
IP-адрес GPRS SGSN;
IP-адрес GPRS GGSN;
код зоны обслуживания (SAC) GRPS;
базовую станцию, через которую установлено соединение (передача данных посредством подвижной сети связи);
базовую станцию, через которую завершено соединение (передача данных посредством подвижной сети связи);
номер телефонной карты;
международный идентификатор мобильного абонента (далее — IMSI мобильного абонента);
идентификатор мобильной станции абонента;
номер модемного пула;
2) общую информацию для всех записей об использовании абонентами услуг связи и ресурсов сети передачи данных (за исключением соединений подключения/отключения к сети связи, трансляции сетевых адресов):
идентификатор оператора связи или структурного подразделения;
дату и время начала соединения;
дату и время завершения соединения;
информацию о клиенте (IP/порт);
информацию о сервере (IP/порт);
информацию о трансляции (IP/порт) <24>;
———————————
<24> Допускается накопление информации о трансляции в составе общей информации об использовании абонентами услуг и ресурсов сети передачи данных.
код протокола в соответствии с RFC 1700 либо номер порта для TCP/UDP;
идентификатор точки подключения к сети передачи данных, с которой получена запись о соединении;
3) информацию о HTTP-соединениях с информационными ресурсами сети передачи данных (посещение страниц в сети «Интернет»), включающую:
адрес в сети Интернет, наименование информационного ресурса;
объем принятых и переданных данных в соединении (информация должна включать как соединения управления, так и передачи данных), байт;
причину завершения соединения;
уникальный идентификатор абонента, формируемый путем аутентификации, авторизации и учета действий абонента (AAA-имя пользователя login);
идентификатор сообщений пользователей услугами связи;
4) информацию о соединениях передачи почтовых сообщений, включающую:
отправителя почтового сообщения;
список получателей почтового сообщения;
список получателей копии почтового сообщения;
адрес, куда следует отправлять ответ на письмо;
тему почтового сообщения;
размер почтового сообщения, включая прикрепленные файлы, байт;
наличие прикрепленных файлов в письме;
список текстовых наименований почтовых серверов, через которые отправлено письмо (в том числе почтового сервера);
причину завершения соединения;
протокол, при помощи которого отправлено сообщение;
тип пользовательской операции;
AAA-имя пользователя login;
текстовое сообщение;
идентификатор сообщений пользователей услугами связи;
5) информацию о соединениях передачи электронных сообщений между пользователями (служебных сообщениях, мгновенных сообщениях, коротких сообщениях, мультимедийных сообщениях, отправленные посредством сети передачи данных), включающую:
наименование учетной записи пользователя при подключении;
общедоступное имя отправителя;
пользовательский идентификатор отправителя (в том числе для сервера, предназначенного для отправки мгновенных сообщений);
список получателей, включающий для каждого получателя сообщения: общедоступное имя получателя, пользовательский идентификатор получателя (в том числе для сервера, предназначенного для отправки мгновенных сообщений);
размер данных сессии, байт;
причину завершения соединения;
протокол, при помощи которого отправлены сообщения;
тип пользовательской операции;
AAA-имя пользователя login;
текстовое сообщение;
идентификатор сообщений пользователей услугами связи;
6) информацию о соединениях голосовой связи посредством сети передачи данных, включающую:
идентификатор сессии;
идентификатор конференции;
длительность разговора, выраженная в секундах;
общедоступное имя инициатора связи;
способ подключения;
номер вызывающего абонента;
номер вызываемого абонента;
объем переданных данных (включает как соединения управления, так и передачи данных), байт;
объем принятых данных (включает как соединения управления, так и передачи данных), байт;
наличие переданной в соединении факсовой информации;
причину завершения соединения;
входящая группа (идентификатор направления/оконечного оборудования вызывающей стороны);
исходящая группа (идентификатор направления/оконечного оборудования вызываемой стороны);
идентификаторы медиашлюзов, обслуживших соединение;
протокол передачи;
услуги связи при соединении;
AAA-имя пользователя login;
идентификатор сообщений пользователей услугами связи;
7) информацию о соединениях передачи файловых данных, включающую:
название сервера;
имя пользователя, наименование учетной записи;
режим работы файлового сервера;
объем переданных данных (включает как соединения управления, так и передачи данных), байт;
объем принятых данных (включает как соединения управления, так и передачи данных), байт;
причину завершения соединения;
AAA-имя пользователя login;
идентификатор сообщений пользователей услугами связи;
информацию о соединениях терминального доступа к оборудованию для удаленного управления, включающую:
объем переданных данных (включает как соединения управления, так и передачи данных), байт;
объем принятых данных (включает как соединения управления, так и передачи данных), байт;
протокол удаленного доступа к оборудованию;
AAA-имя пользователя login;
идентификатор сообщений пользователей услугами связи;
9) информацию о соединениях передачи прочих данных принимаемых, получаемых абонентом при помощи закрытых протоколов обмена, включающую:
объем переданных данных (включает как соединения управления, так и передачи данных), байт;
объем принятых данных (включает как соединения управления, так и передачи данных), байт;
протокол передачи данных;
AAA-имя пользователя login;
идентификатор сообщений пользователей услугами связи;
10) информацию о трансляции сетевых адресов пользователей, накапливаемую отдельными техническими и программными средствами ИС ОРМ по согласованию с ПУ, включающую:
дату и время трансляции;
тип записи (начало (окончание трансляции);
внутренний сетевой адрес и порт;
внешний сетевой адрес и порт;
сетевой адрес назначения и порт;
тип трансляции сетевых адресов.
6. Технические и программные средства ИС ОРМ должны накапливать следующую информацию об изменении местоположения абонентов:
1) дату и время определения местоположения;
2) идентификатор абонента;
3) информацию о местоположении для услуг телефонной связи в сетях подвижной радиосвязи:
код зоны;
номер сектора базовой станции;
компенсацию задержки прохождения сигнала от мобильной станции;
4) информацию о местоположении для услуг передачи данных в сети подвижной связи: код зоны/контроллера доступа, номер сектора базовой станции, либо MAC-адрес сетевого оборудования базовой станции и идентификатор сектора; информацию о широте/долготе местоположения абонента с указанием типа проекции координат (в случае технической возможности накопления).
7. Технические и программные средства ИС ОРМ должны накапливать информацию о пользователях услугами связи в соответствии с приложением N 9 к Требованиям (раздел ReportsAbonents.asn).
8. Технические и программные средства ИС ОРМ должны накапливать информацию о платежах, совершенных абонентами в соответствии с приложением N 9 к Требованиям (раздел ReportsPayments.asn).
9. Технические и программные средства ИС ОРМ должны накапливать справочную информацию в соответствии с приложением N 9 к Требованиям (раздел Dictionaries.asn) о:
1) группа соединительных линий (идентификатор направления и оконечного оборудования вызываемой/вызывающей стороны);
2) базовых станциях;
3) роуминговых партнерах;
4) коммутаторах;
5) IP-шлюзах, в том числе: узлах обслуживания абонентов GPRS (далее — SGSN), узлах маршрутизации данных между сетями GPRS и другими IP-сетями (далее — GGSN), узлах для сервисов коротких сообщений (далее — SMSC), шлюзах для передачи голосовой информации поверх IP (далее — VOIP-шлюз), серверов аутентификации, авторизации и учета действий абонента (пользователя) (далее — AAA-сервер), коммутаторов вызовов из внешних сетей (далее — GMSC), шлюзах для коммутации с ТФоП (далее — PSTN);
6) типах вызовов;
7) списках услуг связи;
способах оплаты (пополнения баланса);
9) причинах завершения соединения;
10) справочниках с планами IP-адресации;
11) планах телефонной номерной емкости;
12) типах документов, удостоверяющих личность;
13) операторах связи, обслуживаемые ИС ОРМ;
14) идентификаторах точек подключения к сети передачи данных, с которых получены записи о соединениях;
15) специальных номерах оператора связи:
короткие номера;
номера технических служб;
групповые номера;
пул маршрутных номеров подвижной станции (далее — номера MSRN-пулов);
16) собственных телематических серверах операторов связи;
17) ином оборудовании сети передачи данных, предоставляющим доступ абонентов к собственным информационным ресурсам оператора;
18) картах связей группы соединительных линий;
19) планах нумерации идентификаторов мобильных телефонных абонентов;
20) справочниках кодов сигнальных точек отправления и назначения.
Справочная информация должна накапливаться в объеме, достаточном для декодирования идентификаторов услуг, местоположения, а также иной информации об абонентах, подключенных услугах, соединениях, трафике, накапливаемой техническими и программными средствами ИС ОРМ информации.
1. Технические и программные средства информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ) подключаются к ПУ в точках подключения выделенными каналами связи.
2. В качестве набора протоколов передачи данных следует использовать набор протоколов TCP/IP.
Сетевой интерфейс первого уровня необходимо использовать для первичного подключения аппаратуры передачи данных.
Для каждой ИС ОРМ внутри сетевого интерфейса первого уровня должна предусматриваться возможность создания виртуальной сети VPN (Virtual Private Network), по протоколу туннелирования второго уровня L2TP (IPSec VPN) для туннелирования всего рабочего TCP/IP трафика между техническими и программными средствами ИС ОРМ и ПУ.
3. Пропускная способность каналов передачи данных для доставки информации об оказанных абонентам услугах связи, в том числе о фактах приема, передачи, доставки и (или) обработки голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений <25> пользователей услугами связи между техническими и программными средствами ИС ОРМ и ПУ в точках подключения должна соответствовать данным, приведенным в таблице N 1.
———————————
<25> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
Таблица N 1. Пропускная способность каналов передачи данных для доставки информации об оказанных абонентам услугах связи, в том числе о фактах приема, передачи, доставки и (или) обработки голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений <26>
———————————
<26> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
Емкость абонентской базы, тысяч абонентов |
не более 1 |
не более 10 |
не более 100 |
не более 1000 |
более 1000 |
Скорость передачи данных, килобит в секунду, не менее |
2048 |
4096 |
10000 |
10000 |
100000 |
Пропускная способность каналов передачи данных между техническими и программными средствами ИС ОРМ и ПУ для доставки голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений пользователей услугами связи:
для сетей подвижной радиосвязи в сети связи общего пользования, подвижной радиосвязи в выделенной сети связи, подвижной радиотелефонной связи в сети связи общего пользования, подвижной радиотелефонной связи, подвижной спутниковой радиосвязи в соответствии с таблицей N 2;
Таблица N 2. Пропускная способность каналов передачи данных между техническими и программными средствами ИС ОРМ и ПУ для услуг подвижной телефонной связи
Емкость абонентской базы, тысяч абонентов |
Не более 10 |
Не более 100 |
Не более 1000 |
Не более 10000 |
Более 10000 |
Скорость передачи данных, мегабит в секунду, не менее |
4 |
10 |
100 |
300 |
500 |
для сетей междугородной и международной телефонной связи, телефонной связи в выделенной сети связи, внутризоновой телефонной связи, местной телефонной связи, голосовой связи посредством сети передачи данных в соответствии с таблицей N 3;
Таблица N 3. Пропускная способность каналов передачи данных между техническими и программными средствами ИС ОРМ и ПУ для услуг фиксированной телефонной связи
Емкость абонентской базы, тысяч абонентов, не более |
Не более 10 |
Не более 100 |
Более 100 |
Количество групп каналов |
1 |
10 |
100 и более |
Скорость передачи данных, мегабит в секунду, не менее |
4 |
10 |
100 |
для услуг связи по предоставлению каналов связи, услуг связи в сети передачи данных, за исключением передачи голосовой информации, телематических услуг связи в соответствии с таблицей N 4;
Таблица N 4. Пропускная способность каналов доставки сообщений пользователей услугами передачи данных между техническими и программными средствами средствами ИС ОРМ и ПУ
Скорость потока информации сетевого трафика, обрабатываемого ИС ОРМ, мегабит в секунду |
Суммарная скорость передачи данных на выходе ИС ОРМ, предназначенном для связи с ПУ, мегабит в секунду, не менее |
Не более 1000 |
5% от скорости потока информации обрабатываемого ИС ОРМ |
Не более 10000 |
100 |
Не более 20000 |
1000 |
Более 20000 |
10000 |
Суммарная скорость выгрузки из ИС ОРМ по всем запросам должна составлять не менее 70% от пропускной способности канала доставки сообщений пользователей услугами передачи данных.
4. Взаимодействие технических и программных средств ИС ОРМ с оборудованием ПУ на транспортном уровне следует осуществлять по схеме «клиент — сервер»:
1) в качестве «сервера» выступает ИС ОРМ;
2) в качестве «клиента» выступает оборудование ПУ.
5. Для взаимодействия технических и программных средств ИС ОРМ с ПУ необходимо организовать пять каналов передачи данных (далее — кпд):
1) канал управления (кпд1);
2) канал данных (кпд2);
3) канал мониторинга (кпд3);
4) канал неформатированных данных (кпд4);
5) канал доставки сообщений пользователей услугами связи (кпд5).
6. Канал управления (кпд1) служит для передачи:
1) от ПУ в ИС ОРМ запросов (команд);
2) от ИС ОРМ на ПУ ответов и «сигналов».
7. Канал данных (кпд2) служит для передачи:
1) от ИС ОРМ на ПУ блоков данных отчетов, генерируемых и направляемых ИС ОРМ по запросам от ПУ, «сигнала» HeartBeat;
2) от ПУ в ИС ОРМ подтверждений о принятии блоков данных отчетов.
8. Канал мониторинга (кпд3) служит для передачи:
1) от ПУ в ИС ОРМ запросов о текущей конфигурации оборудования, системного и прикладного ПО ИС ОРМ и запросов на модификацию конфигурации;
2) от ИС ОРМ на ПУ ответов на запросы ПУ, «сигналов».
9. Канал неформатированных данных (кпд4) служит для передачи:
1) от ПУ в ИС ОРМ команд на виды передаваемых неформатированных данных;
2) от ИС ОРМ на ПУ неформатированных данных, «сигналов».
10. Канал доставки сообщений пользователей услугами связи (кпд5) служит для передачи:
1) от ИС ОРМ на ПУ блоков сообщений пользователей услугами связи, запрошенных ПУ, сигналов;
2) от ПУ в ИС ОРМ подтверждений о принятии блоков сообщений пользователей услугами связи.
11. Каналы передачи данных (кпд1, кпд2, кпд3, кпд4, кпд5) создаются для подключения к ИС ОРМ в виде TCP-соединений. Номера портов должны передаваться на ПУ на внешних носителях. Посредством ИС ОРМ выполняется мониторинг данных портов для создания TCP-соединений с ПУ.
12. ПУ должны осуществлять попытки установления подключения к ИС ОРМ в соответствии с задаваемым интервалом по предоставленным ИС ОРМ TCP-портам.
13. Установление соединений ПУ с ИС ОРМ по кпд1, кпд2 необходимо осуществлять в следующей последовательности:
1) установление ПУ TCP-соединения к ИС ОРМ по порту канала кпд1;
2) выполнение процедуры взаимной SSL/TLS аутентификации в соответствии с пунктом 15 приложения N 2 к Требованиям;
3) установление ПУ TCP-соединения к ИС ОРМ по порту канала кпд2;
4) выполнение процедуры взаимной SSL/TLS аутентификации в соответствии с пунктом 15 приложения N 2;
5) после успешной аутентификации создание ПУ сессии к ИС ОРМ;
6) ожидание ПУ данных и сигналов по кпд2 только после того, как была создана сессия по кпд1. При приеме данных и сигналов по кпд2 при отсутствии установленной сессии по кпд1 ПУ должен разорвать соединение по кпд2.
14. Установление ПУ соединений к ИС ОРМ по каналам кпд3, кпд4 и кпд5 необходимо осуществлять независимо друг от друга и от наличия установленных соединений по кпд1 и кпд2:
1) установление ПУ TCP-соединения к ИС ОРМ по TCP-порту кпд3/кпд4/кпд5;
2) выполнение процедуры взаимной SSL/TLS аутентификации в соответствии с пунктом 15 настоящего приложения;
3) после успешной аутентификации создание ПУ сессии к ИС ОРМ;
4) после успешной аутентификации посылка ПУ на ИС ОРМ команды в соответствии с приложением N 9 к Требованиям.
15. ПУ должен разорвать соединения к ИС ОРМ, если в течение трех периодов приема сигнала HeartBeat в каналах не было сетевой активности. При отсутствии подтверждения посланного сигнала HeartBeat в течение времени «максимальный размер задержки подтверждения запроса или сигнала» ИС ОРМ должна разорвать соединения с ПУ по соответствующему каналу.
16. ИС ОРМ должна обеспечивать одновременное подключение нескольких ПУ и предоставление ПУ доступа к информации ИС ОРМ по территориям оказания услуг данным узлом связи. Максимальное количество одновременно подключенных ПУ для одной ИС ОРМ — 100. ИС ОРМ должна обслуживать подключенные ПУ независимо друг от друга.
17. Каждому идентифицированному на ИС ОРМ ПУ должен быть назначен приоритет выполнения задач. В случае поступления на ИС ОРМ задач от различных ПУ, вероятность постановки на выполнение задачи конкретного ПУ зависит от назначенного приоритета данного ПУ и приоритетов других подключенных ПУ. Распределение вероятности запуска задач от различных ПУ задается приоритетом каждого конкретного ПУ. Конфигурация «по умолчанию» должна обеспечивать равномерное распределение вероятности запуска задач от каждого ПУ. ИС ОРМ должна обеспечивать возможность конфигурирования приоритетов ПУ, а также одновременное выполнение задач по каждому идентифицированному ПУ:
1) по соединениям абонентов, по совершенным платежам, по пополнению справочников, по принадлежности абонентов — не менее 100
2) по запросам сообщений пользователей услугами связи — не менее 10.
18. Обмен данных в кпд1, кпд2, кпд3, кпд4 и кпд5 должен осуществляться при помощи сообщений (Message) в соответствии с форматом сообщений, представленным в приложении N 8 к параметрам кодирования протокола взаимодействия ASN.1 ПУ и технических и программных средств ИС ОРМ ГОСТ Р ИСО/МЭК 8824-1-2001 «Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации», введенного в действие постановлением Государственного комитета Российской Федерации по стандартизации и метрологии от 06.09.2001 N 375-ст <27>. Способ кодирования сообщений соответствует отличительным правилам кодирования (DER) по ГОСТ Р ИСО/МЭК 8825-1-2003 «Информационная технология. Правила кодирования. Часть 1. Спецификация базовых (BER), канонических (CER) и отличительных (DER) правил кодирования», введенному в действие постановлением Государственного комитета Российской Федерации по стандартизации и метрологии от 13.05.2003 N 140-ст <28>.
———————————
<27> Источник официального опубликования: Издательско-полиграфический комплекс Издательство стандартов, 2001.
<28> Источник официального опубликования: Издательско-полиграфический комплекс Издательство стандартов, 2003.
19. Интерфейс взаимодействия между ПУ и ИС ОРМ по кпд1 и кпд2 должен предусматривать наличие следующих видов сообщений:
1) «запросы» — передаются от ПУ в ИС ОРМ по кпд1;
2) «ответы» — передаются из ИС ОРМ на ПУ по кпд1;
3) «сигналы» — передаются из ИС ОРМ на ПУ по кпд1 и кпд2 (для кпд2 только «сигнал» HeartBeat);
4) «отчеты» — формируются ИС ОРМ в качестве ответов на запросы от ПУ, передаются на ПУ по кпд2;
5) «подтверждения» о принятии «отчетов» — передаются из ПУ в ИС ОРМ по кпд2;
6) «подтверждения» о принятии «сигналов» — передаются от ПУ в ИС ОРМ по кпд1 и кпд2 (по кдп2 только для «сигнала» HeartBeat).
20. Интерфейс взаимодействия между ПУ и ИС ОРМ по кпд3 должен предусматривать наличие следующих видов «Сообщений»:
1) запросы;
2) ответы;
3) сигнал HeartBeat;
4) подтверждения о принятии сигнала HeartBeat и ответов.
21. Интерфейс взаимодействия между ПУ и ИС ОРМ по кпд4 должен предусматривать наличие следующих видов «Сообщений»:
1) «запросы» — передаются от ПУ в ИС ОРМ;
2) «ответы» — передаются из ИС ОРМ на ПУ;
3) «сигналы» — передаются из ИС ОРМ на ПУ;
4) «отчеты» — формируются ИС ОРМ в качестве ответов на запросы от ПУ;
5) «подтверждения» о принятии «отчетов» — передаются от ПУ в ИС ОРМ;
6) «подтверждения» о принятии «сигналов» — передаются от ПУ в ИС ОРМ.
22. Интерфейс взаимодействия между ПУ и ИС ОРМ по кпд5 должен предусматривать наличие следующих видов «Сообщений»:
1) «запросы» — передаются от ПУ в ИС ОРМ, используются только запросы создания сессии;
2) «ответы» — передаются из ИС ОРМ на ПУ;
3) «сигналы» — передаются из ИС ОРМ на ПУ;
4) «отчеты» — формируются ИС ОРМ в качестве ответов на запросы от ПУ;
5) «подтверждения» о принятии «отчетов» — передаются от ПУ в ИС ОРМ;
6) «подтверждения» о принятии «сигналов» — передаются от ПУ в ИС ОРМ.
23. Посредством ИС ОРМ выполняются любые действия, связанные с выдачей информации о пользователях услугами связи и предоставленных им услугах связи, управлением и мониторингом технических средств и ПО ИС ОРМ, только по «запросам» с ПУ.
24. Посредством ИС ОРМ обеспечивается прием и обработка следующих сообщений, передаваемых с ПУ:
1) «Запрос на открытие сессии» (ConnectRequest);
2) «Запрос на закрытие сессии» (DisconnectRequest);
3) «Запрос готовности данных» (DataReadyRequest);
4) «Запрос загрузки данных» (DataLoadRequest);
5) «Запрос удаления данных» (DataDropRequest);
6) «Запрос прерывания загрузки данных» (DataInterruptRequest);
7) «Запрос на создание задачи по обработке информации» (CreateTaskRequest) — предназначен для создания запросов по информации:
«Задачи пополнения справочников» (DictionaryTask);
«Задача поисков по принадлежности абонентов» (AbonentsTask);
«Задача поисков по соединениям абонентов» (ConnectionsTask);
«Задача получения данных местоположения абонентов» (LocationTask);
«Задача поисков по совершенным платежам» (PaymentsTask);
«Задача предоставления сведений о наличии данных» (PresenseTask);
«Задача получения сообщений пользователей услугами связи» (DataContentTask);
«Запрос на создание задачи по обработке неформализованных данных» (NonFormalizedTaskRequest) — предназначен для получения иной информации, не определенной в подпункте 7 настоящего пункта и предоставляемой при технической возможности ИС ОРМ.
25. В зависимости от типа завершенной поисковой задачи передача блоков данных должна осуществляться по кпд2 или кпд5:
1) в случае, если запрошенная задача является задачей получения сообщений пользователей услугами связи, используется кпд5;
2) во всех остальных случаях используется кпд2.
26. ИС ОРМ должна обеспечивать одновременную передачу блоков данных отчетов для нескольких завершенных поисковых задач по кпд2 — кпд5. ИС ОРМ должна обеспечивать возможность многократной передачи отчетов выполненных задач на ПУ.
27. По запросу ПУ «Запрос загрузки данных» кпд1 ИС ОРМ должна обеспечивать передачу блоков отчетов по кпд2 — кпд5 по запрошенной задаче без внесения дополнительных временных задержек между операциями по получению записей результата задачи и преобразования их в блоки.
28. На каждый «запрос» по кпд1 ИС ОРМ на ПУ должна посылать «ответ» о принятии к обработке этого запроса. ИС ОРМ должна обеспечивать посылку по кпд1 на ПУ следующих «ответов»:
1) «Ответ на запрос открытия сессии» (ConnectResponse);
2) «Ответ на запрос закрытия сессии» (DisconnectResponse);
3) «Ответ на запрос готовности данных» (DataReadyResponse);
4) «Ответ на запрос загрузки данных» (DataLoadResponse);
5) «Ответ на запрос удаления данных» (DataDropResponse);
6) «Ответ на запрос прерывания загрузки данных» (DataInterruptResponse);
7) «Ответ на запрос создания задачи» (TaskResponse);
«Ответ на запрос создания задачи по обработке неформализованных данных» (NonFormalizedTaskResponse).
29. По запросу ПУ «Запрос на создание задачи по обработке информации» ИС ОРМ должна обеспечивать подготовку и выдачу информации из ИС ОРМ для следующих групп задач:
1) «Задачи пополнения справочников» (DictionaryTask);
2) «Задачи поисков по принадлежности абонентов» (AbonentsTask);
3) «Задачи поисков по соединениям абонентов» (ConnectionsTask);
4) «Задачи получения данных местоположения абонентов» (LocationTask);
5) «Задачи поисков по совершенным платежам» (PaymentsTask);
6) «Задачи предоставления сведений о наличии данных» (PresenseTask);
7) «Задача получения сообщений пользователей услугами связи» (DataContentTask).
30. В группу «Задачи пополнения справочников» входят запросы на получение информации справочников:
группы соединительных линий (идентификатор направления/оконечного оборудования вызываемой/вызывающей стороны);
базовые станции;
роуминговые партнеры;
коммутаторы;
IP-шлюзы;
типы вызовов;
список услуг связи;
способы оплаты (пополнения баланса);
причины завершения соединения;
справочник с планами IP-адресации;
план телефонной номерной емкости;
типы документов, удостоверяющих личность;
операторы связи, обслуживаемые ИС ОРМ;
идентификаторы точек подключения к сети передачи данных, с которых получены записи о соединениях;
специальные номера оператора связи;
карта связей группы соединительных линий;
план нумерации идентификаторов мобильных телефонных абонентов;
коды сигнальных точек отправления и назначения.
31. В группу «Задачи поисков по принадлежности абонентов» входят:
«Задача на поиск информации о принадлежности идентификаторов абонентов сети оператора связи» (ValidateAbonentsTask);
«Задача на поиск информации об идентификаторах абонентов сети оператора связи, зарегистрированных на физическое или юридическое лицо» (ValidateIdentifiersTask);
«Задача на поиск информации о доступных абоненту видах услуг связи» (ValidateServicesTask).
По «Задаче на поиск информации о принадлежности идентификаторов абонентов сети оператора связи» и «Задаче на поиск информации об идентификаторах абонентов сети оператора связи, зарегистрированных на физическое или юридическое лицо» ИС ОРМ вместе с информацией об абоненте и зарегистрированных идентификаторах должна предоставлять сведения о текущих подключенных абонентом услугах связи.
По запросу «Задача на поиск информации о доступных абоненту видах услуг связи» ИС ОРМ должна формировать отчет, содержащий список с историей подключенных абонентом услуг связи за весь период накопления данных. Поисковым критерием задачи является идентификатор абонента, не содержащий символов маскирования.
32. В группу «Задачи поисков по соединениям абонентов» входит «Задача на поиск по соединениям абонентов» (ValidateCallsTask), в том числе:
«Задача на поиск соединений абонентов» (ValidateConnectionsTask);
«Задача на поиск соединений между абонентами сети передачи данных» (ValidateDataTask);
«Задача на поиск информации о появлении абонента в сети связи (выхода на связь)» (ValidateEntranceTask);
«Задача получения сообщений пользователей услугами связи» (DataContentTask).
Если в качестве параметров «Задача на поиск соединений абонентов» указаны только диапазон времени и (опционально) структурное подразделение оператора связи, ИС ОРМ должно формировать результат выполнения поисковой задачи, содержащий все соединения всех абонентов за указанный диапазон времени.
33. В группу «Задачи поисков по совершенным платежам» входят:
«Задача на поиск пополнения баланса через банковский перевод» (bankTransactionTask);
«Задача на поиск пополнения баланса через карты экспресс-оплаты» (expressCardTask);
«Задача на поиск пополнения баланса через терминалы моментальных платежей» (publicTerminalTask);
«Задача на поиск пополнения баланса через центры обслуживания клиентов (ЦОК)» (serviceCenterTask);
«Задача на поиск пополнения баланса посредством снятия денег со счета другого абонента» (crossAccountTask);
«Задача на поиск пополнения баланса через телефонные карты» (telephoneCardTask);
«Задача на поиск перевода средств со счета абонента для их снятия в отделении банка» (bankDivisionTransferTask);
«Задача на поиск перевода средств со счета абонента на банковскую карту» (bankCardTransferTask);
«Задача на поиск перевода средств со счета абонента на счет в банке» (bankAccountTransferTask);
«Общая задача на поиск пополнения баланса личного счета абонента» (balanceFillupTask).
По «Задаче получения данных местоположения абонентов» ИС ОРМ за запрошенный период времени должна предоставить накопленную в базе данных информацию об изменении местоположения абонентского устройства (историю) по запрошенному идентификатору.
34. В группу «Задачи предоставления сведений о наличии данных» (PresenseTask) входят:
«Запрос наличия информации по абонентам и их идентификаторам»;
«Запрос наличия информации по соединениям»;
«Запрос наличия имеющейся информации по платежам»;
«Запрос наличия справочников»;
«Запрос наличия информации по местоположениям абонентов».
35. По «Задаче получения сообщений пользователей услугами связи» ИС ОРМ должна передать по кпд5 соответствующие сообщения пользователей услугами связи по запрошенному идентификатору.
36. По запросу ПУ «Запрос на создание задачи по обработке неформализованных данных» ИС ОРМ должна обеспечить подготовку и выдачу информации по следующим видам запросов:
1) «Запрос получения списка типов сущностей неформализованных данных ИС ОРМ» (GetEntities);
2) «Запрос получения списка атрибутов сущности» (GetEntityAttibutes);
3) «Задача поиска неформализованных данных» (ValidateNonFormalizedTask);
4) «Задача предоставления сведений о наличии неформализованных данных» (NonFormalizedPresenseTask).
37. По «Задаче поиска неформализованных данных» ИС ОРМ должна предоставить доступ ПУ к системным файлам ИС ОРМ.
38. ИС ОРМ должна обеспечивать выполнение поисковых задач по строковым критериям, содержащим символы маскирования, включающие:
«*» — обозначает любую комбинацию символов;
«?» — обозначает любой один возможный символ.
39. ИС ОРМ должна обеспечивать выполнение поисковых задач по критериям, содержащим последовательность цифр с символом маскирования пробел (» «), означающим одну любую цифру.
Результат выполнения поисковой задачи с критерием, содержащим символы маскирования, содержит все записи, соответствующие заданной маске.
40. В случае возникновения в ИС ОРМ исключительных ситуаций на ПУ передаются следующие «Сообщения» типа «Сигналы», содержащие информацию об уровне важности исключительной ситуации, ее влиянии на сохранность данных и выполнение задач:
1) «Перезапуск ПО» (RestartDB);
2) «Попытка несанкционированного доступа» (UnauthorizedAccess);
3) «Критическая ошибка ПО, потеря данных, дальнейшая работа невозможна» (CriticalError);
4) «Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна» (MajorError);
5) «Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна» (MinorError);
6) «Тестовый пакет» (Heartbeat). Единственный, из «сигналов», передающийся по кпд1, кпд2, кпд3, кпд4 в отсутствие иной сетевой активности.
В ответ на «Сигналы», поступившие от ИС ОРМ, ПУ передает «подтверждения сигнала» об их приеме.
41. ИС ОРМ должна обеспечивать запись сообщений пользователей услугами передачи данных, при этом:
1) в случае обнаружения соответствия соединению присваивается уникальный идентификатор в рамках данной ИС ОРМ;
2) сообщения пользователей услугами связи записываются в ИС ОРМ;
3) идентификатор используется в «Задаче получения сообщений пользователей услугами связи»;
4) статистическая информация о соединении по его завершению записывается в ИС ОРМ вместе с идентификатором соединения.
42. ИС ОРМ по запросу ПУ «Запрос удаления данных» (DataDropRequest) должна осуществлять:
1) прерывание задачи, находящейся на выполнении;
2) удаление данных отчета по завершившейся задаче.
43. При установлении соединения ПУ и ИС ОРМ должны взаимно аутентифицироваться. Аутентификация выполняется установлением SSL/TLS-соединения поверх установленного TCP-соединения между ПУ и ИС ОРМ. Для взаимной аутентификации ПУ и ИС ОРМ предварительно создаются X.509-сертификаты, которые должны сообщаться ПУ и ИС ОРМ. В случае невозможности аутентифицировать одну из сторон TCP-соединение разрывается. Созданный для ПУ сертификат используется для аутентификации только одного данного ПУ на одной ИС ОРМ по всем каналам передачи данных — кпд1, кпд2, кпд3, кпд4, кпд5. ПУ и ИС ОРМ используют TLS версии 1.2. Требования к сертификатам (длины ключей, иные параметры) должны быть согласованы для каждой пары ИС ОРМ и ПУ отдельно.
44. Открытие сессии должно осуществляться выполнением процедуры аутентификации согласно пункту 15 настоящего приложения перед началом выполнения всех запросов. Открытие сессии осуществляется посылкой по каналу управления от ПУ к ИС ОРМ запроса ПУ «Запрос на открытие сессии» (ConnectRequest).
45. При «Запросе на открытие сессии» должны устанавливаться следующие параметры сессии:
1) «максимальное время отсутствия активности сессии» (session-timeout) — интервал времени, по истечении которого сессия принудительно прерывается от ИС ОРМ;
2) «максимальный размер блока данных отчетов» (max-data-length) в строках записей ИС ОРМ;
3) «размер окна для канала передачи данных» (data-packet-window-size);
4) «максимальная длительность задержки начала передачи блоков отчетов» (data-load-timeout);
5) «максимальный размер задержки подтверждения о получении данных» (data-packet-response-timeout);
6) «максимальный размер задержки подтверждения запроса или сигнала» (request-response-timeout).
Любое сообщение в соответствии с протоколом взаимодействия ASN.1 ПУ и технических и программных средств ИС ОРМ, согласно приложению N 9 к Требованиям, считается сетевой активностью.
46. ИС ОРМ при получении запрос «Запрос на открытие сессии» должна проанализировать параметр «размер окна для канала передачи данных», определить максимально возможный размер окна, не превышающий полученного от ПУ. ИС ОРМ должна определить минимальные значения таймаутов из параметров сессии, выбирая их не меньше, чем переданные в сообщении «Запрос на открытие сессии» (ConnectRequest). Рассчитанные значения размеров окна и таймаутов ИС ОРМ должна передать на ПУ в сообщении «Ответ на открытие сессии» (ConnectResponse). Полученные ПУ значения в сообщении «Ответ на открытие сессии» являются параметрами сессии между ПУ и ИС ОРМ.
47. Закрытие сессии должно осуществляться посылкой по каналу управления, каналу мониторинга, каналу неформатированных данных или каналу доставки сообщений пользователей услугами связи от ПУ к ИС ОРМ «Запроса на закрытие сессии» или, по истечении допустимого времени отсутствия активности ИС ОРМ, посылкой сигнала «Прерывание текущей сессии по таймауту». При этом ИС ОРМ и ПУ должны осуществить разрыв текущих TCP соединений канала управления и канала данных, канала мониторинга, канала неформатированных данных или канала доставки сообщений пользователей услугами связи.
48. ПУ должен посылать в ИС ОРМ «запросы» независимо от получения от ИС ОРМ «ответа» о приеме предыдущего «запроса».
49. «Запрос на создание задачи по обработке информации» должен привести к созданию в ИС ОРМ задачи по обработке данных в базе данных ИС ОРМ, которой присваивается номер (идентификатор) задачи, передаваемый в «Ответе на запрос создания задачи» (TaskResponse). Идентификаторы задач должны генерироваться ИС ОРМ независимо от сессий и являться уникальными в данной ИС ОРМ. ИС ОРМ должна присвоить идентификаторы задачам и выполнить обработку задач независимо для различных ПУ.
50. ПУ для получения информации о ходе выполнения и завершения обработки задач в ИС ОРМ должен послать в ПУ «Запрос готовности данных». После завершения выполнения задачи, данные, сформированные в результате выполнения задачи, становятся доступными для загрузки в ПУ или для удаления.
51. ИС ОРМ при получении от ПУ «Запроса загрузки данных» по кпд1 должна сформировать сообщения типа — «отчет», состоящие из блоков данных обработанной задачи.
52. При передаче блоков данных по задаче получения сообщений пользователей услугами связи следует использовать кпд5.
53. При передаче блоков данных по всем остальным задачам следует использовать кпд2.
54. При получении от ПУ «Запроса загрузки данных» для задачи получения сообщений пользователей услугами связи при отсутствии установленной сессии по кпд5, в ИС ОРМ формируется и автоматически направляется ответ ПУ на «Запрос загрузки данных» с установленным флагом ошибки. При этом в случае установления сессии по кпд5 передача ранее запрошенных отчетов не производится.
55. Количество строк в каждом блоке при передаче по кпд2 не должно превышать параметр «максимальный размер блока данных отчетов», заданный при открытии сессии.
56. Количество байт в каждом блоке при передаче по кпд5 следует устанавливать при конфигурации ИС ОРМ.
57. В каждом последовательном блоке данных из серии должен указываться идентификатор задачи, сгенерировавшей данный отчет, общее количество блоков в отчете, порядковый номер каждого блока.
58. Данные задачи, полученные в одной сессии, могут быть считаны и (или) удалены в другой сессии ПУ, инициировавшим данную задачу. Данные по завершенной задаче должны быть доступными между сессиями по тому же идентификатору задачи. При получении сообщения ПУ «Запрос загрузки данных» (DataLoadRequest) от ПУ, не являющегося инициатором данной задачи, ИС ОРМ необходимо послать на ПУ ответ на «Запрос загрузки данных», в котором должно быть указано на отсутствие результата исполнения задачи (data-exists), а в поле «краткое описание ошибки» (error-description) должна быть записана расшифровка отказа в доступе к данным задачи, а также ИС ОРМ на ПУ, сформировавший «Запрос загрузки данных», должна отправить «сигнал» попытки несанкционированного доступа (unauthorized-access) и ожидать его подтверждения.
59. В ИС ОРМ уничтожаются данные, сформированные в результате выполнения задачи и самой выполненной задачи после поступления с ПУ запроса на удаление данных.
60. В случае возникновения в ИС ОРМ или каналах передачи данных исключительных ситуаций на ПУ должны передаваться сообщения типа «Сигнал».
1. Посредством технических и программных средств информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ), обеспечивается подключение пульта управления (далее — ПУ) и обработка поступающих запросов по кпд1 в соответствии с приведенными схемами состояний переходов. Состояние переходов ИС ОРМ по кпд1 приведено на схеме 1:
1) ИС ОРМ по TCP-порту кпд1 находится в ожидании входящих соединений; после установления соединения с ПУ должна выполняться взаимная SSL/TLS-аутентификация;
2) если SSL/TLS-соединения по каналам управления и данных установлены, а сессия не открыта, ИС ОРМ следует реагировать только на сообщение «Запрос на открытие сессии»; при попытке посылок каких-либо других сообщений со стороны ПУ ИС ОРМ должна разорвать TCP-соединения по каналу управления и каналу данных и перевести канальный уровень подключения в исходное состояние;
3) при получении сообщения «Запрос на открытие сессии» ИС ОРМ должна создать список поддерживаемых ИС ОРМ типов запросов, отчетов и сигналов (в том числе и предыдущих версий) и отослать его на ПУ;
4) после отсылки списка поддерживаемых типов ИС ОРМ должна ожидать от ПУ списка поддерживаемых им запросов, отчетов и сигналов; список поддерживаемых ПУ типов является подмножеством списка типов в ИС ОРМ;
5) при получении от ПУ списка поддерживаемых ПУ запросов ИС ОРМ должна послать сообщение «Ответ на согласование списка поддерживаемых типов» и создать сессию;
6) после создания сессии кпд1 ИС ОРМ должна быть переведена в режим ожидания команд от ПУ; при поступлении команды со стороны ПУ ИС ОРМ должна ее выполнить и сформировать результат, который в виде сообщения «ответа» отправляется на ПУ;
Рисунок (не приводится)
Схема 1
7) в случае возникновения сбоя в работе ИС ОРМ, вызванного причинами, не предусмотренными режимом нормального функционирования системы, по каналу управления должен передаваться «сигнал» — «Критическая ошибка ПО, потеря данных, дальнейшая работа невозможна» с соответствующим описанием проблемы; все задачи, которые были в процессе выполнения, когда произошел сбой, а также данные выполненных задач, поврежденные в результате произошедшего сбоя, имеют «признак результата выполнения задачи» (TaskResult), равный значению «ошибка» (error), с соответствующим описанием проблемы; в случае, если для восстановления работоспособности ИС ОРМ требуется ее перезагрузка, то по каналу управления следует выдать прерывание «Перезапуск ПО»; в этом случае ИС ОРМ и ПУ должны закрыть все открытые на текущий момент сессии;
в случае наличия признаков сбоя или ошибки выполнения конкретной задачи ИС ОРМ в режиме нормального функционирования по каналу управления в автоматическом режиме передает прерывание «Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна» с соответствующим описанием проблемы; результат выполнения данной задачи имеет «признак результата выполнения задачи» (TaskResult), равный значению «ошибка» (error), с соответствующим описанием проблемы;
9) на каждый «сигнал», переданный ИС ОРМ, ПУ в автоматическом режиме направляет сообщение «подтверждение сигнала» по кпд1; отсутствие подтверждения в течение времени RequestResponseTimeout, которое задается при открытии сессии, свидетельствует о прерывании соединения и вызывает действия, согласно пункту 18 приложения N 2 к Требованиям;
10) при отсутствии команд ПУ в течение «максимального времени неактивности» (session-timeout, задается в ConnectRequest) ИС ОРМ в автоматическом режиме направляет на ПУ «сигнал» Heartbeat и ожидает его подтверждения аналогично описанному в подпункте 9 пункта 1 настоящего приложения.
2. ПУ с задаваемым интервалом выполняет попытки установления TCP-соединения с ИС ОРМ по заданному порту кпд1 (состояние переходов ПУ по кпд1 приведено на схеме 2):
1) ПУ ожидает установления соединения по кпд1; после установления соединения выполняется взаимная SSL/TLS-аутентификация;
2) после установления TCP-соединения по кпд1 и прохождения по нему взаимной аутентификации ИС ОРМ и ПУ по кпд1 посылают команду создания сессии (ConnectRequest);
3) ПУ ожидает сообщения «ответ» от ИС ОРМ на отправленную команду в течение времени «таймаут ответа на запрос» (request-response-timeout);
4) если сообщение не получено в течение времени «таймаут ответа на запрос», ПУ автоматически разрывает соединения к ИС ОРМ по кпд1 и кпд2 и переводит их в начальное состояние согласно подпункту 1 пункта 2 настоящего приложения. Время ожидания сообщения «ответ» не зависит от приема сообщений «сигналов», поступающих в этот интервал времени;
5) при получении сообщения «Ответ на запрос создания сессии» пунктом управления ОРМ автоматически создается список поддерживаемых ПУ типов запросов, отчетов и сигналов, который направляется в ИС ОРМ. Список поддерживаемых ПУ типов является подмножеством списка типов ИС ОРМ согласно подпункту 3 пункта 2 настоящего приложения;
6) после отправки сообщения «Согласование поддерживаемых типов со стороны ПУ» ПУ ожидает ответа на сообщение от ИС ОРМ. Поведение ПУ при ожидании ответа должно соответствовать подпункту 4 пункта 2 настоящего приложения;
7) во время ожидания сообщения «ответ» ИС ОРМ автоматически посылается на ПУ сообщение «сигнал» (в том числе HeartBeat), а ПУ «подтверждение» о принятии «сигнала» (в том числе HeartBeat) и ожидается сообщение «ответ» на отосланную команду;
после создания сессии ПУ посылает поступающие команды на ИС ОРМ и ожидает сообщения «ответов» на них согласно подпунктам 3, 4 и 7 пункта 2 настоящего приложения;
Рисунок (не приводится)
Схема 2
9) если при ожидании поступления в ПУ команд ИС ОРМ не посылала «сигнал» (HeartBeat) в течение трех интервалов «максимального времени неактивности» (session-timeout, задается в ConnectRequest), ПУ должен разорвать соединения к ИС ОРМ по кпд1 и кпд2 и перевести их в начальное состояние согласно подпункту 1 пункта 2 настоящего приложения;
10) при поступлении сообщения «Запрос на закрытие сессии» (DisconnectRequest) ПУ должен отослать его на ИС ОРМ, ожидать сообщения «ответ» согласно подпунктам 3, 4, 7 пункта 2 настоящего приложения, после чего разорвать соединение по кпд2 и кпд1 и перевести их в начальное состояние согласно подпункту 1 пункта 2 настоящего приложения.
1. Посредством технических и программных средств информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ), обеспечиваются подключение пульта управления (далее — ПУ) и обработка поступающих запросов по кпд2 в соответствии с приведенными схемами состояний переходов.
2. Состояние переходов ИС ОРМ по кпд2 приведено на схеме 1.
Рисунок (не приводится)
Схема 1
ИС ОРМ по TCP-порту кпд2 ожидает входящих соединений. После установления соединения выполняется взаимная SSL/TLS-аутентификация.
Если на ИС ОРМ был передан запрос ПУ «Запрос загрузки данных» (DataLoadRequest), ИС ОРМ направляет «ответ на запрос загрузки данных» (DataLoadResponse) по кпд1 и данные блоков отчетов по кпд2 при их наличии. ПУ получает блоки отчетов по кпд2 до получения «ответа на запрос загрузки данных» (DataLoadResponse) по кпд1.
Если количество переданных без получения сообщения «подтверждения» о принятии серии блоков сообщений «отчетов» по всем задачам, по которым выполняется загрузка на ПУ данных, меньше «окна канала передачи данных» (параметр data-packet-window-size в запросе ПУ «Запрос на открытие сессии» ConnectRequest), то ИС ОРМ выполняет подготовку новых блоков отчетов по загружаемым задачам и направляет их на ПУ. Количество подготовленных и переданных без получения «подтверждения» блоков не должно превышать размера окна канала передачи данных.
Максимальная задержка подтверждения приема блока данных со стороны ПУ не должна превышать параметр «таймаут подтверждения приема блока данных отчета» (data-packet-response-timeout), указываемый при создании сессии. Если задержка подтверждения превысила заданное значение, то оставшиеся для передачи блоки данных не должны отправляться и по каналу управления направляется «сигнал» «Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна» с соответствующим описанием проблемы, при этом в поле «reference-message» сообщения «сигнал» указывается идентификатор сообщения блока отчета, по которому не поступило подтверждение приема.
При получении «подтверждения» блока «отчета» ИС ОРМ регистрирует информацию об ошибочно принятом ПУ блоке и ошибочных записях в блоке в файл, передача последующих блоков по задаче на ПУ не должна прерываться. ИС ОРМ иметь функционал, позволяющий техническому персоналу оператора связи осуществлять доступ к файлу с записями об ошибочно принятых на ПУ блоках отчетов и средства исправления ошибочных данных в отчетах. Подтвержденные блоки исключаются из «окна канала передачи данных» (в «окне канала передачи данных» должны остаться только неподтвержденные блоки).
В случае разрыва TCP/IP соединения кпд2, при существующем соединении кпд1, по кпд1 должно быть передано сообщение «Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна» с соответствующим описанием проблемы, работа в данном случае не должна прекращаться, должно выполняться установление соединения по кпд2 согласно пункту 15 приложения N 2 к Требованиям.
Передача блоков данных должна прерываться в случае получения ИС ОРМ запроса ПУ «Запрос прерывания загрузки данных».
Если по кпд2 не производится передача блоков отчетов в течение «максимального времени неактивности» (session-timeout при создании сессии ConnectRequest), ИС ОРМ должна послать на ПУ «сигнал» (HeartBeat) и ожидать его подтверждения согласно подпункту 9 пункта 1 приложения N 3 к Требованиям.
3. Состояние переходов ПУ по кпд2 приведено на схеме 2.
Рисунок (не приводится)
Схема 2
ПУ с задаваемым интервалом должен выполнять попытки установления TCP-соединения к ИС ОРМ по заданному порту кпд2. После установления соединения должна выполняться взаимная SSL/TLS-аутентификация.
При поступлении запроса ПУ «Запрос загрузки данных» (DataLoadRequest) ПУ должен ожидать начала передачи данных в течение времени «таймаут начала передачи блоков отчетов» (data-load-timeout в ConnectRequest). Если данные не поступают в течение указанного «таймаута начала передачи блоков отчетов», то ПУ должен разорвать соединения по кпд1 и кпд2 и перевести соединения в изначальное состояние согласно подпункту 1 пункта 1 приложения N 3 к Требованиям и предыдущему абзацу пункта 2 настоящего приложения.
При поступлении блока отчета ПУ должен произвести декодирование полученного блока и сохранение декодированных данных.
В ответ на переданный блок данных ПУ должен послать сообщение «подтверждение» получения блока отчета. Количество последовательно переданных ИС ОРМ блоков данных без подтверждения со стороны ПУ определяется параметром «размер окна канала передачи данных», который согласовывается при создании сессии. При подтверждении блока отчета ПУ должен сигнализировать об ошибке декодирования блока. В этом случае в сообщении «подтверждение» приема для ошибочно декодированного блока ПУ, в случае возможности, должно указать номер записи в блоке, начиная с которой декодирование не удалось.
Если при ожидании поступления в ПУ блоков отчетов ИС ОРМ не посылала «сигнал» HeartBeat в течение трех интервалов «максимального времени неактивности» (session-timeout, задается в ConnectRequest), ПУ должен разорвать соединения к ИС ОРМ по кпд1 и кпд2 и перевести их в начальное состояние согласно подпункту 1 пункта 1 приложения N 3 к Требованиям и абзацу второму пункта 2 настоящего приложения.
1. Посредством технических и программных средств информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ), обеспечиваются подключение пульта управления (далее — ПУ) и обработка следующих поступающих от него запросов по кпд3:
1) запрос на получение структуры ИС ОРМ и списка модулей прикладного программного обеспечения (далее — ПО) ИС ОРМ («GetStructureRequest»);
2) запрос на получение конфигурации модуля ПО ИС ОРМ («GetModuleConfigRequest»);
3) запрос на изменение конфигурации модуля ПО ИС ОРМ («SetModuleConfigRequest»);
4) запрос на получение состояния модуля ПО ИС ОРМ («CheckModuleRequest»).
2. На каждый запрос по кпд3 ИС ОРМ должна послать ответ, содержащий результат обработки соответствующего запроса — «ManagementResponse».
3. Схемы состояний перехода ИС ОРМ и ПУ по кпд3 соответствуют схемам для кпд1 (схема 1 и схема 2 приложения N 3 к Требованиям).
ИС ОРМ по TCP-порту кпд3 должна находиться в состоянии ожидания входящих соединений. После установления соединения с ПУ должна выполняться взаимная SSL/TLS-аутентификация.
Если SSL/TLS-соединение по кпд3 установлено, а сессия не открыта, ИС ОРМ обеспечивает принятие только сообщения «Запрос на открытие сессии».
Создание сессии аналогично представленному в подпунктах 3 — 5 пункта 1 приложения N 3 к Требованиям. При попытке посылок каких-либо других сообщений со стороны ПУ ИС ОРМ должна разорвать TCP-соединение по кпд3 и перевести канальный уровень подключения в исходное состояние.
После создания сессии ИС ОРМ автоматически переключается в режим ожидания команд от ПУ. Обработка поступающих команд и посылка сигналов производится аналогично, представленному в подпунктах 6 — 10 пункта 1 приложения N 3 к Требованиям.
ПУ с заданным интервалом должен попытаться установить TCP-соединения с ИС ОРМ по заданному порту. После установления соединения должна выполняться взаимная SSL/TLS-аутентификация.
ПУ по кпд3 должен послать команду создания сессии (ConnectRequest).
Ожидание подтверждения создания сессии, согласование списка поддерживаемых типов, отправка команд, ожидание ответов и обработка полученных от ИС ОРМ сигналов по кпд3 должно производиться ПУ согласно подпунктам 3 — 9 пункта 2 приложения N 3 к Требованиям.
4. Посредством ИС ОРМ обеспечивается получение следующих видов информации о структуре и функционировании ИС ОРМ по запросу ПУ:
1) о структуре и составе оборудования ИС ОРМ, составе и состоянии интерфейсов взаимодействия ИС ОРМ с ПУ;
2) об установленном в оборудовании ИС ОРМ программном обеспечении, перечне и состоянии программных модулей в составе ПО ИС ОРМ;
3) о точках подключения ИС ОРМ к сети оператора связи и интерфейсах ввода информации в ИС ОРМ.
5. В части структуры и состава оборудования ИС ОРМ, состава и состоянии интерфейсов взаимодействия оборудования ИС ОРМ с ПУ по запросу ПУ должна предоставить следующую информацию:
1) перечень телекоммуникационного и серверного оборудования хранения данных, с его идентификацией;
2) идентификацию интерфейсов подключения оборудования ИС ОРМ;
3) параметры для серверного оборудования (на момент формирования ПУ запроса):
общий и занятый объем оперативной памяти;
количество сетевых интерфейсов с их идентификацией, текущую нагрузку;
общее количество процессоров, текущую загрузку;
общий объем дискового пространства, объем свободного пространства;
4) параметры технических средств хранения данных:
перечень модулей, составляющих средства хранения данных с их идентификацией;
для каждого входящего в состав средств хранения данных модуля — общий объем дискового пространства, объем свободного дискового пространства и текущее состояние модуля (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя.
6. В части точек подключения ИС ОРМ к сети оператора связи, интерфейсов ввода информации в ИС ОРМ ИС ОРМ по запросу ПУ должна предоставить текущую информацию на момент формирования запроса, содержащую:
1) перечень точек подключения к сети связи и точек ввода информации в ИС ОРМ с их идентификацией;
2) для каждой точки подключения предоставляет информацию о:
виде поступающих в ИС ОРМ сообщений (о соединениях абонентов, о платежах, об абонентах, иные сведения);
состоянии точки подключения (ввода информации) (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя;
объеме информации, поступающей в секунду, в том числе количестве записей, объеме (байт);
периоде, в течение которого на точку подключения и/или ввода информации в ИС ОРМ не поступала информация.
7. В части состава общесистемного ПО ИС ОРМ, его текущего состояния ИС ОРМ по запросу ПУ должна предоставить следующую информацию:
1) перечень установленного общесистемного ПО с его идентификацией;
2) предоставление для общесистемного ПО информации:
идентификатора оборудования ИС ОРМ, на котором установлено ПО;
наименование общесистемного ПО;
текущее состояние ПО (функционирование в нормальном режиме, сбой, не функционирует), текстовую расшифровку сбоя;
3) перечень установленного ПО ИС ОРМ с его идентификацией;
4) предоставление для ПО ИС ОРМ информации:
идентификатора оборудования ИС ОРМ, на котором установлено ПО;
назначение оборудования ИС ОРМ (определяется разработчиком ИС ОРМ);
текущее состояние (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя;
список контролируемых параметров (определяется разработчиком ИС ОРМ).
8. Посредством ИС ОРМ обеспечивается возможность изменения отдельных параметров функционирования оборудования ИС ОРМ, общесистемного ПО по запросу с ПУ посредством кпд3. Перечень доступных ПУ для изменения параметров должен быть определен разработчиком оборудования ИС ОРМ.
1. Посредством технических и программных средств информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ), обеспечиваются подключение ПУ и обработка поступающих запросов по кпд4.
2. Посредством ИС ОРМ должны обеспечиваться прием и обработка следующих видов запросов от ПУ по кпд4:
1) «запрос проверки наличия вида неформатированных данных в ИС ОРМ» (DataTypesRequest);
2) «запрос на начало передачи неформатированных данных» (DataStartRequest);
3) «запрос на остановку передачи неформатированных данных» (DataStopRequest).
3. На каждый запрос по кпд4 в ИС ОРМ должен формироваться ответ на ПУ, содержащий результат обработки соответствующего запроса.
4. В ИС ОРМ должна накапливаться информация с неформатированными данными в буфере, которые упорядочиваются согласно времени их поступления.
Для телефонных соединений абонентов в соответствии с лицензиями на оказание услуг связи <29> длительность временного хранения неформатированных данных в буфере — до 6 месяцев с момента окончания их приема, передачи, доставки и (или) обработки.
———————————
<29> Постановление Правительства Российской Федерации от 18 февраля 2005 г. N 87 «Об утверждении перечня наименований услуг связи, вносимых в лицензии, и перечней лицензионных условий».
5. Посредством ИС ОРМ обеспечивается запись в буфер информации о телефонных соединений абонентов — файлы, формируемые коммутационным оборудованием, содержащие только записи о соединениях абонентов в недекодированном виде.
6. Посредством ИС ОРМ обеспечивается запись информации в буфер циклически; при переполнении буфера старая информация в нем стирается, освобождая емкость буфера для вновь поступающей информации.
7. Состояние переходов ИС ОРМ по кпд4 приведено на схеме 1.
Рисунок (не приводится)
Схема 1
Посредством ИС ОРМ устанавливается соединение согласно абзацам второму и третьему пункта 3 приложения N 5 к Требованиям.
После создания сессии ИС ОРМ автоматически переключается в режим ожидания команд. Обработка команд и посылка «сигналов» должна осуществляться согласно подпунктам 6 — 10 пункта 1 приложения N 3 к Требованиям, за исключением команды «запрос на начало, остановку передачи неформатированных данных» (DataStartRequest/DataStopRequest).
Если в режиме ожидания команд в ИС ОРМ поступило сообщение «запрос на начало передачи неформатированных данных», ИС ОРМ обеспечивает отсылку «ответа на запрос» и переводит кпд4 в «режим передачи данных» (при этом должна производиться передача данных того типа, который указан в команде запроса).
Если в режиме ожидания команд в ИС ОРМ поступило сообщение «запрос на остановку передачи неформатированных данных», ИС ОРМ обеспечивает выполнение «ответа на запрос остановки передачи неформатированных данных» с отрицательным результатом.
В режиме передачи данных посылка блоков отчетов и их подтверждение должна производиться согласно абзацам четвертому, шестому и девятому пункта 2 приложения N 4 к Требованиям.
Максимальная задержка подтверждения приема блока данных со стороны ПУ не должна превышать параметр «таймаут подтверждения приема блока данных отчета» (data-packet-response-timeout), указываемый при создании сессии. Если задержка подтверждения превысит заданное значение, то оставшиеся для передачи блоки данных не должна отправляться, ИС ОРМ должна разорвать соединение по кпд4 и перевести кпд4 в изначальное состояние.
Передача неформатированных данных соответствующего типа должна производиться из буфера кпд4 согласно пункту 4 настоящего приложения.
Если в режиме передачи данных в ИС ОРМ поступило сообщение «запрос на остановку передачи неформатированных данных» ИС ОРМ обеспечивает отправку «ответа на запрос остановки передачи неформатированных данных», завершает посылку блоков данных и автоматически переключается в режим ожидания команд.
Если в режиме передачи данных в ИС ОРМ поступило сообщение «запрос на начало передачи неформатированных данных» ИС ОРМ обеспечивает отправку «ответа на запрос начала передачи неформатированных данных» с отрицательным результатом, при этом передача неформатированных данных не должна прекратиться.
Исходные данные о соединениях в виде неформатированных данных должны записываться в буфер, независимо от текущего режима работы кпд4 ИС ОРМ.
Если сообщение «запрос на остановку передачи неформатированных данных» поступило в момент передачи из буфера файловых данных, передаваемый файл должен сохраниться в буфере и быть доступным для передачи после посылки сообщения «запрос на начало передачи неформатированных данных» с учетом ограничений по длительности хранения, согласно подпункту 2 пункта 3 настоящего приложения.
8. Состояние переходов ПУ по кпд4 представлено на схеме 2.
Рисунок (не приводится)
Схема 2
Посредством ПУ с задаваемым интервалом обеспечивается выполнение попытки установления TCP-соединения с ИС ОРМ по заданному порту. После установления соединения должна выполняться взаимная SSL/TLS-аутентификация.
ПУ по кпд4 должен послать сообщение о создании сессии (ConnectRequest).
Ожидание подтверждения создания сессии, согласование списка поддерживаемых типов, отправка команд, ожидание ответов и обработка полученных от ИС ОРМ сигналов по кпд4 должны осуществляться ПУ согласно подпунктам 4 — 10 пункта 1 приложения N 3 к Требованиям, за исключением сообщения «запрос на начало, остановку передачи неформатированных данных» (DataStartRequest/DataStopRequest).
9. При посылке сообщения «запрос на начало/остановку передачи неформатированных данных» ПУ должен дождаться результата (DataStartResponse) согласно подпунктам 4 и 5 пункта 1 приложения N 3 к Требованиям, после чего перевести кпд4 в режим передачи данных.
В режиме передачи данных ПУ должен осуществить прием, декодирование и подтверждение приема данных согласно абзацам четвертому — шестому пункта 2 приложения N 4 к Требованиям.
При приеме сообщения «запрос на остановку передачи неформатированных данных» (DataStopRequest) ПУ, находясь в режиме передачи данных, посредством ПУ обеспечивается прием блоков данных и перейти в режим передачи команд.
1. Посредством технических и программных средств информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ), обеспечиваются подключение ПУ и обработка поступающих запросов по кпд5 в соответствии с приведенных состоянием переходов на схеме 1.
Рисунок (не приводится)
Схема 1
2. ИС ОРМ по TCP-порту кпд5 ожидаются входящие соединения. После установления соединения с ПУ выполняется взаимная SSL/TLS-аутентификация.
3. Если SSL/TLS-соединение по кпд5 установлено, а сессия не открыта, ИС ОРМ должна реагировать только на сообщения «Запрос на открытие сессии». Создание сессии аналогично представленному в подпунктах 3 — 5 пункта 1 приложения N 3 к Требованиям. При попытке посылок каких-либо других сообщений со стороны ПУ, ИС ОРМ обеспечивается разрыв TCP-соединения по кпд3 и перевод канального уровня подключения в исходное состояние.
4. После создания сессии кпд5 автоматически переключается в режим ожидания. При поступлении сообщения «Запрос на открытие сессии» или «Согласование списка поддерживаемых типов» в режиме ожидания, ИС ОРМ автоматически производит закрытие текущей сессии и разрывает TCP-соединение.
5. Если на ИС ОРМ от ПУ был передан «Запрос загрузки данных» (DataLoadRequest) с указанием идентификатора задачи получения сообщений пользователей услугами связи, в случае отсутствия соединения по кпд5 ИС ОРМ автоматически обеспечивается отправка «ответа на запрос загрузки данных» (DataLoadResponse) с пометкой «признака существования результата». При наличии открытой сессии по кпд5 ИС ОРМ автоматически обеспечивается передача данных блоков отчетов. ПУ получает блоки отчетов по кпд5 до получения «ответа на запрос загрузки данных» (DataLoadResponse) по кпд1.
6. Если количество переданных без получения «подтверждения» о принятии серии блоков «отчетов» по всем задачам, по которым выполняется загрузка на ПУ данных, меньше «окна канала передачи данных» (параметр data-packet-window-size в запросе создания сессии ConnectRequest), то ИС ОРМ автоматически обеспечивается выполнение подготовки новых блоков отчетов по загружаемым задачам и их отправка на ПУ. Количество подготовленных и переданных без получения «подтверждения» блоков не должно превышать размера окна канала передачи данных.
7. Максимальная задержка подтверждения приема блока данных со стороны ПУ не должна превышать значения параметра «таймаут подтверждения приема блока данных отчета» (data-packet-response-timeout). Если задержка подтверждения превысила данное значение, то оставшиеся для передачи блоки данных не должны отправляться и должен быть передан «сигнал» — «незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна» с соответствующим описанием проблемы, при этом в поле «reference-message» сообщения «сигнал» должен указываться идентификатор сообщения блока отчета, по которому не поступило подтверждение приема.
8. При получении негативного «подтверждения» блока «отчета» ИС ОРМ автоматически записывает информацию об ошибочно принятом ПУ блоке и ошибочных записях в блоке в файл с записями об ошибочно принятых на ПУ блоках отчетов, передача последующих блоков на ПУ не должна прерываться. Посредством ИС ОРМ техническому персоналу оператора связи обеспечивается доступ к файлу с записями об ошибочно принятых на ПУ блоках отчетов. Подтвержденные блоки должны быть исключены из «окна канала передачи данных» (в «окне канала передачи данных» должны остаться только неподтвержденные блоки).
9. Передача блоков данных должна быть прервана в случае поступления в ИС ОРМ «запроса прерывания загрузки данных».
10. Если по кпд5 не производится передача блоков отчетов в течение «максимального времени неактивности» (session-timeout при создании сессии ConnectRequest), ИС ОРМ посылает на ПУ «сигнал» HeartBeat ожидать его подтверждения согласно подпункту 9 пункта 1 приложения N 3 к Требованиям.
11. Состояние переходов ПУ по кпд5 приведено на схеме 2.
Рисунок (не приводится)
Схема 2
12. ПУ с задаваемым интервалом выполняет попытки установления TCP-соединения с ИС ОРМ по заданному порту кпд5. После установления соединения с ИС ОРМ выполняется взаимная SSL/TLS-аутентификация.
13. После выполнения SSL/TLS-аутентификации ПУ автоматически посылает команду создания сессии (ConnectRequest).
14. ПУ ожидает сообщения «ответ» от ИС ОРМ на отправленную команду в течение времени «таймаут ответа на запрос» (request-response-timeout).
15. Если сообщение не получено в течение времени «таймаут ответа на запрос», ПУ автоматически разрывает соединение с ИС ОРМ и переключается в состояние установления TCP-соединения с ИС ОРМ по заданному порту кпд5 согласно пункту 12 настоящего приложения. Время ожидания сообщения «ответ» не зависит от приема сообщений «сигналов», поступающих в этот интервал времени.
16. При получении сообщения «Ответ на запрос создания сессии» ПУ создается список поддерживаемых ПУ типов запросов, отчетов и сигналов и отправляется ИС ОРМ.
17. При поступлении запроса ПУ «Запрос загрузки данных» (DataLoadRequest) ПУ ожидает начала передачи данных в течение времени «таймаут начала передачи блоков отчетов» (data-load-timeout в ConnectRequest). Если данные не поступают в течение вышеописанного периода, ПУ автоматически разрывает соединение по кпд5 и переводит его в состояние согласно пункту 12 настоящего приложения.
18. При поступлении блока отчета в ПУ декодируется и сохраняется полученный блок.
19. В ответ на переданный блок отчета с ПУ отправляется сообщение «подтверждение» получения блока отчета. Количество последовательно переданных ИС ОРМ блоков отчета без подтверждения со стороны ПУ определяется параметром «размер окна канала передачи данных», который согласовывается при создании сессии. При подтверждении блока отчета ПУ сигнализирует об ошибке декодирования блока отчета (при ее наличии). В этом случае в сообщении «подтверждение» приема для ошибочно декодированного блока ПУ при сигнализации одновременно указывается номер записи в блоке, начиная с которой декодирование не удалось.
20. Если при ожидании поступления в ПУ блоков отчетов ИС ОРМ не посылала «сигнал» HeartBeat в течение трех интервалов «максимального времени неактивности» (session-timeout, задается в ConnectRequest), ПУ автоматически разрывает соединение по кпд5 и перевести его в состояние согласно пункту 12 настоящего приложения.
1. Структура модулей протокола взаимодействия ПУ и информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ) приведена на схеме 1.
sorm |
||||||||||
message |
||||||||||
session |
trap |
task |
report |
management |
unformatted |
Схема 1
2. Структура разделения поисковых критериев кпд1 представлена на схеме 2.
sorm |
|||||||||||||||
request |
|||||||||||||||
identifier |
connection |
abonent |
location |
payments |
dictionary |
presense |
|||||||||
pager |
pager |
person |
bank-transaction |
||||||||||||
pstn |
pstn |
organization |
express-pays |
||||||||||||
gsm |
mobile |
terminal-pays |
|||||||||||||
cmda |
network-equipment |
service-center |
|||||||||||||
data-network |
aaa-login |
cross-account |
|||||||||||||
resource |
telefone-card |
||||||||||||||
|
balance-fileups |
||||||||||||||
im |
bank-division-transfer |
||||||||||||||
voip |
bank-card-transfer |
||||||||||||||
file-transfer |
bank-account-transfer |
||||||||||||||
term-access |
|||||||||||||||
raw-flouws |
|||||||||||||||
entrance |
|||||||||||||||
Схема 2
3. Структура разделения видов отчетов кпд2 представлена на схеме 3.
sorm |
|||||||||||||||||||||
report |
|||||||||||||||||||||
identifiers |
abonent |
location |
connection |
payments |
dictionary |
presense |
|||||||||||||||
pager |
person |
mobile |
pager |
bank-transaction |
bunches |
abonents |
|||||||||||||||
pstn |
organization |
wireless |
pstn |
express-pays |
basic-stations |
connections |
|||||||||||||||
gsm |
service |
geo |
mobile |
terminal-pays |
roaming-parners |
payments |
|||||||||||||||
cmda |
aaa-login |
service-center |
swiches |
dictionaries |
|||||||||||||||||
data-network |
resource |
cross-account |
gates |
locations |
|||||||||||||||||
voip |
|
telephone-card |
call-types |
||||||||||||||||||
im |
balance-fileups |
suppeement-services |
|||||||||||||||||||
voip |
bank-division-transfer |
pay-types |
|||||||||||||||||||
file-transfer |
bank-card-transfer |
termination-causes |
|||||||||||||||||||
term-access |
bank-account-transfer |
ip-numbering-plan |
|||||||||||||||||||
raw-flows |
phone-number-plan |
||||||||||||||||||||
ipdr-header |
doc-types |
||||||||||||||||||||
telcos |
|||||||||||||||||||||
ip-data-points |
|||||||||||||||||||||
special-numbers |
|||||||||||||||||||||
bunches-map |
|||||||||||||||||||||
mobile-subscriber-identity-plan |
|||||||||||||||||||||
Схема 3
4. Структура разделения модулей протокола взаимодействия ПУ и ИС ОРМ приведена на схеме 4.
Sorm.asn |
||||||||||||||||||||||
Session.asn |
Traps.asn |
Task.asn |
Management.asn |
Informatte.asn |
Report.asn |
|||||||||||||||||
Dictionaries.asn |
||||||||||||||||||||||
TaskAbonents.asn |
TaskConnections.asn |
TaskLocation.asn |
TaskPresense.asn |
TaskPayments.asn |
DataContentTask.asn |
TaskNonFormalized.asn |
||||||||||||||||
RequestedAbonents.asn |
RequestedConnections.asn |
|||||||||||||||||||||
Совместно используемые модули |
||||||||||||||||||||||
————————————————————————————————————————— |
||||||||||||||||||||||
| | |
Classification.asn |
Adress.asn |
Location.asn |
NetworkIdentifers.asn |
ReportedIdentifiers.asn |
RequestedIdentifiers.asn |
| | |
|||||||||||||||
————————————————————————————————————————— |
||||||||||||||||||||||
ReportsConnections.asn |
ReportsLocations.asn |
ReportsPayments.asn |
ReportsDataContent.asn |
ReportsPresensea.asn |
ReportsNonFormalized.asn |
ReportsAbonents.asn |
Схема 4
5. Посредством модуля Classification.asn устанавливаются правила, в соответствии с которыми:
1) выполняется расширение:
списка типов запросов к ИС ОРМ;
списка видов поисковых критериев к ИС ОРМ;
списка типов отчетов, формируемых ИС ОРМ;
2) выполняется ввод новых версий сообщений протокола.
6. Модуль протокола взаимодействия ПУ и ИС ОРМ Classification.asn содержит кодированные в иерархическом виде идентификаторы:
1) видов сообщений верхнего уровня интерфейса взаимодействия ПУ и ИС ОРМ, составляющих кпд1, кпд2, кпд3, кпд4;
2) видов поисковых критериев для формирования задач к ИС ОРМ;
3) видов форматов отчетов, формируемых ИС ОРМ.
7. Соответствующие идентификаторы используются в других модулях протокола взаимодействия ПУ и ИС ОРМ (схема 4 с модулями), при этом идентификатор определяет конкретную версию и расширения формата соответствующего элемента (поисковых критериев, отчетов, справочников сообщений — в соответствии со схемами 2 и 3).
8. Предоставленный ИС ОРМ при создании сессии перечень идентификаторов и согласованное из него ПУ подмножество определяют конкретные возможности взаимодействия ПУ и ИС ОРМ в соответствии с выбранными идентификаторами.
9. Расширение интерфейса взаимодействия ПУ и ИС ОРМ обеспечивается введением новых идентификаторов, определяющих соответствующие расширенные элементы (поисковые критерии, отчеты, справочники, сообщения). Кодирование новых вводимых идентификаторов элементов осуществляется в соответствии со структурами, приведенными на схемах 2 и 3 и стандартным модулем протокола взаимодействия ПУ и ИС ОРМ Classification.asn.
___________________________________________________________________________ Classification.asn Classification DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS TAGGED, sorm-message-session, sorm-message-trap, sorm-message-task, sorm-message-report, sorm-message-management, sorm-message-unformatted, sorm-message-filter, sorm-request-identifier-pager, sorm-request-identifier-pstn, sorm-request-identifier-gsm, sorm-request-identifier-cdma, sorm-request-identifier-data-network, sorm-request-identifier-voip, sorm-report-identifier-pager, sorm-report-identifier-pstn, sorm-report-identifier-gsm, sorm-report-identifier-cdma, sorm-report-identifier-data-network, sorm-report-identifier-voip, sorm-request-payment-bank-transaction, sorm-request-payment-express-pays, sorm-request-payment-terminal-pays, sorm-request-payment-service-center, sorm-request-payment-cross-account, sorm-request-payment-telephone-card, sorm-request-payment-balance-fillups, sorm-request-payment-bank-division-transfer, sorm-request-payment-bank-card-transfer, sorm-request-payment-bank-account-transfer, sorm-report-payment-bank-transaction, sorm-report-payment-express-pays, sorm-report-payment-terminal-pays, sorm-report-payment-service-center, sorm-report-payment-cross-account, sorm-report-payment-telephone-card, sorm-report-payment-balance-fillups, sorm-report-payment-bank-division-transfer, sorm-report-payment-bank-card-transfer, sorm-report-payment-bank-account-transfer, sorm-request-connection-pager, sorm-request-connection-pstn, sorm-request-connection-mobile, sorm-request-connection-aaa-login, sorm-request-connection-resource, sorm-request-connection-email, sorm-request-connection-im, sorm-request-connection-voip, sorm-request-connection-file-transfer, sorm-request-connection-term-access, sorm-request-connection-raw-flows, sorm-request-connection-entrance, sorm-request-connection-address-translations, sorm-report-connection-pager, sorm-report-connection-pstn, sorm-report-connection-mobile, sorm-report-connection-ipdr-header, sorm-report-connection-aaa-login, sorm-report-connection-resource, sorm-report-connection-email, sorm-report-connection-im, sorm-report-connection-voip, sorm-report-connection-file-transfer, sorm-report-connection-term-access, sorm-report-connection-raw-flows, sorm-report-connection-address-translations, sorm-request-dictionaries, sorm-report-dictionary-bunches, sorm-report-dictionary-basic-stations, sorm-report-dictionary-roaming-partners, sorm-report-dictionary-switches, sorm-report-dictionary-gates, sorm-report-dictionary-call-types, sorm-report-dictionary-supplement-services, sorm-report-dictionary-pay-types, sorm-report-dictionary-termination-causes, sorm-report-dictionary-ip-numbering-plan, sorm-report-dictionary-phone-numbering-plan, sorm-report-dictionary-doc-types, sorm-report-dictionary-telcos, sorm-report-dictionary-ip-data-points, sorm-report-dictionary-special-numbers, sorm-report-dictionary-bunches-map, sorm-report-dictionary-mobile-subscriber-identity-plan sorm-report-dictionary-signal-point-codes sorm-request-presense, sorm-report-presense-abonents, sorm-report-presense-connections, sorm-report-presense-payments, sorm-report-presense-dictionaries, sorm-report-presense-locations, sorm-request-abonent-person, sorm-request-abonent-organization, sorm-report-abonent-abonent, sorm-report-abonent-service, sorm-report-abonent-person, sorm-report-abonent-organization, sorm-report-data-content-raw; TAGGED ::= CLASS{ &id ObjectDescriptor UNIQUE, &Data } WITH SYNTAX{ OID &id DATA &Data } --- Классификация OID ::= ObjectDescriptor -- Подструктура сообщений sorm-message-session OID ::= "280" sorm-message-trap OID ::= "281" sorm-message-task OID ::= "282" sorm-message-report OID ::= "283" sorm-message-management OID ::= "284" sorm-message-unformatted OID ::= "285" sorm-message-filter OID ::= "286" -- Идентификаторы sorm-request-identifier-pager OID ::= "140" sorm-request-identifier-pstn OID ::= "141" sorm-request-identifier-gsm OID ::= "142" sorm-request-identifier-cdma OID ::= "143" sorm-request-identifier-data-network OID ::= "144" sorm-request-identifier-voip OID ::= "145" sorm-report-identifier-pager OID ::= "1" sorm-report-identifier-pstn OID ::= "2" sorm-report-identifier-gsm OID ::= "3" sorm-report-identifier-cdma OID ::= "4" sorm-report-identifier-data-network OID ::= "5" sorm-report-identifier-voip OID ::= "6" -- Параметры соединений sorm-request-connection-pager OID ::= "160" sorm-request-connection-pstn OID ::= "161" sorm-request-connection-mobile OID ::= "162" sorm-request-connection-aaa-login OID ::= "164" sorm-request-connection-resource OID ::= "165" sorm-request-connection-email OID ::= "166" sorm-request-connection-im OID ::= "167" sorm-request-connection-voip OID ::= "168" sorm-request-connection-file-transfer OID ::= "169" sorm-request-connection-term-access OID ::= "170" sorm-request-connection-raw-flows OID ::= "171" sorm-request-connection-entrance OID ::= "172" sorm-request-connection-address-translations OID ::= "173" sorm-report-connection-pager OID ::= "20" sorm-report-connection-pstn OID ::= "21" sorm-report-connection-mobile OID ::= "22" sorm-report-connection-ipdr-header OID ::= "23" sorm-report-connection-aaa-login OID ::= "24" sorm-report-connection-resource OID ::= "25" sorm-report-connection-email OID ::= "26" sorm-report-connection-im OID ::= "27" sorm-report-connection-voip OID ::= "28" sorm-report-connection-file-transfer OID ::= "29" sorm-report-connection-term-access OID ::= "30" sorm-report-connection-raw-flows OID ::= "31" sorm-report-connection-address-translations OID ::= "32" -- Абоненты sorm-request-abonent-person OID ::= "180" sorm-request-abonent-organization OID ::= "181" sorm-report-abonent-abonent OID ::= "40" sorm-report-abonent-service OID ::= "41" sorm-report-abonent-person OID ::= "42" sorm-report-abonent-organization OID ::= "43" -- Местоположение sorm-request-location OID ::= "200" sorm-report-location-mobile OID ::= "60" sorm-report-location-wireless OID ::= "61" sorm-report-location-geo OID ::= "62" -- Платежи sorm-request-payment-bank-transaction OID ::= "220" sorm-request-payment-express-pays OID ::= "221" sorm-request-payment-terminal-pays OID ::= "222" sorm-request-payment-service-center OID ::= "223" sorm-request-payment-cross-account OID ::= "224" sorm-request-payment-telephone-card OID ::= "225" sorm-request-payment-balance-fillups OID ::= "226" sorm-request-payment-bank-division-transfer OID ::= "227" sorm-request-payment-bank-card-transfer OID ::= "228" sorm-request-payment-bank-account-transfer OID ::= "229" sorm-report-payment-bank-transaction OID ::= "80" sorm-report-payment-express-pays OID ::= "81" sorm-report-payment-terminal-pays OID ::= "82" sorm-report-payment-service-center OID ::= "83" sorm-report-payment-cross-account OID ::= "84" sorm-report-payment-telephone-card OID ::= "85" sorm-report-payment-balance-fillups OID ::= "86" sorm-report-payment-bank-division-transfer OID ::= "87" sorm-report-payment-bank-card-transfer OID ::= "88" sorm-report-payment-bank-account-transfer OID ::= "89" -- Справочники sorm-request-dictionaries OID ::= "240" sorm-report-dictionary-bunches OID ::= "100" sorm-report-dictionary-basic-stations OID ::= "101" sorm-report-dictionary-roaming-partners OID ::= "102" sorm-report-dictionary-switches OID ::= "103" sorm-report-dictionary-gates OID ::= "104" sorm-report-dictionary-call-types OID ::= "105" sorm-report-dictionary-supplement-services OID ::= "106" sorm-report-dictionary-pay-types OID ::= "107" sorm-report-dictionary-termination-causes OID ::= "108" sorm-report-dictionary-ip-numbering-plan OID ::= "109" sorm-report-dictionary-phone-numbering-plan OID ::= "110" sorm-report-dictionary-doc-types OID ::= "111" sorm-report-dictionary-telcos OID ::= "112" sorm-report-dictionary-ip-data-points OID ::= "113" sorm-report-dictionary-special-numbers OID ::= "114" sorm-report-dictionary-bunches-map OID ::= "115" sorm-report-dictionary-mobile-subscriber-identity-plan OID ::= "116" sorm-report-dictionary-signal-point-codes OID::= "132" -- Запрос о наличии данных sorm-request-presense OID ::= "260" sorm-report-presense-abonents OID ::= "120" sorm-report-presense-connections OID ::= "121" sorm-report-presense-payments OID ::= "122" sorm-report-presense-dictionaries OID ::= "123" sorm-report-presense-locations OID ::= "124" -- Запрос о содержимом потоков sorm-report-data-content-raw OID ::= "50" END ___________________________________________________________________________ Addresses.asn Addresses DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS AddressType, ReportedAddresses, ReportedAddress, RequestedAddress; AddressType ::= ENUMERATED{ registered (0), --- Адрес регистрации (обязателен для юридических и физических лиц) postal (1), --- Почтовый адрес (дополнительный адрес для юридических лиц) invoice (2), --- Адрес доставки счета (дополнительный адрес для юридических лиц) device-location (3), --- Адрес установки пользовательского устройства (телефонного аппарата) reserved (4) --- Резерв } ReportedAddresses ::= SEQUENCE OF ReportedAddress ReportedAddress ::= SEQUENCE { title AddressType, --- тип адреса address-info AddressInfoReport --- адрес } AddressInfoReport ::= CHOICE{ struct-info[1] AddressStructInfoReport, --- структурированный адрес unstruct-info[2] UTF8String(SIZE (1 .. 1024)) --- неструктурированный адрес } AddressStructInfoReport ::= SEQUENCE { zip [0] UTF8String (SIZE (1 .. 32)) OPTIONAL, --- почтовый индекс, zip-код country [1] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- страна region [2] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- область zone [3] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- район, муниципальный округ city [4] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- город, поселок, деревня street [5] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- улица building [6] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- дом, строение build-sect [7] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- корпус apartment [8] UTF8String (SIZE (1 .. 128)) OPTIONAL --- квартира, офис } -- поля адресных данных RequestedAddress ::= SEQUENCE { zip [0] UTF8String (SIZE (1 .. 32)) OPTIONAL, --- почтовый индекс, zip-код country [1] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- страна region [2] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- область zone [3] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- район, муниципальный округ city [4] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- город, поселок, деревня, населенный пункт street [5] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- улица building [6] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- дом, строение build-sect [7] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- корпус apartment [8] UTF8String (SIZE (1 .. 128)) OPTIONAL --- квартира, офис } END ___________________________________________________________________________ Dictionaries.asn Dictionaries DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS TelcoID, TelcoList, DictionaryTask, DictionaryReport, PhoneAbonentType; IMPORTS DateAndTime FROM Sorm TAGGED, sorm-request-dictionaries, sorm-report-dictionary-telcos, sorm-report-dictionary-bunches, sorm-report-dictionary-basic-stations, sorm-report-dictionary-roaming-partners, sorm-report-dictionary-switches, sorm-report-dictionary-gates, sorm-report-dictionary-call-types, sorm-report-dictionary-supplement-services, sorm-report-dictionary-pay-types, sorm-report-dictionary-termination-causes, sorm-report-dictionary-ip-numbering-plan, sorm-report-dictionary-phone-numbering-plan, sorm-report-dictionary-doc-types, sorm-report-dictionary-ip-data-points, sorm-report-dictionary-special-numbers, sorm-report-dictionary-bunches-map, sorm-report-dictionary-mobile-subscriber-identity-plan sorm-report-dictionary-signal-point-codes FROM Classification ReportedAddress FROM Addresses Bunch, DataNetworkEquipment, IPAddress, IPPort, IPMask, NetworkPeerInfo, NetworkType FROM NetworkIdentifiers GeoLocation FROM Locations; -- Идентификатор оператора связи или структурного подразделения TelcoID ::= INTEGER (0.. 65535) --- список идентификаторов операторов связи или структурного подразделения TelcoList ::= SEQUENCE OF TelcoID -- Запрос DictionaryTask ::= SEQUENCE { id TAGGED.&id({DictionaryTaskVariants}), data TAGGED.&Data({DictionaryTaskVariants}{@id}) } DictionaryTaskVariants TAGGED ::= { dictionaryTask } dictionaryTask TAGGED ::= { OID{ sorm-request-dictionaries } DATA ObjectDescriptor -- тип запрашиваемого справочника (идентификатор отчета) } -- ObjectDescriptor принимает значение одно из: -- sorm-report-dictionary-telcos -- sorm-report-dictionary-bunches -- sorm-report-dictionary-basic-stations -- sorm-report-dictionary-roaming-partners -- sorm-report-dictionary-switches -- sorm-report-dictionary-gates -- sorm-report-dictionary-call-types -- sorm-report-dictionary-supplement-services -- sorm-report-dictionary-pay-types -- sorm-report-dictionary-termination-causes -- sorm-report-dictionary-ip-numbering-plan -- sorm-report-dictionary-phone-numbering-plan -- sorm-report-dictionary-doc-types -- sorm-report-dictionary-ip-data-points -- sorm-report-dictionary-special-numbers -- sorm-report-dictionary-bunches-map, -- sorm-report-dictionary-mobile-subscriber-identity-plan -- sorm-report-dictionary-signal-point-codes -- Отчет DictionaryReport ::= SEQUENCE { id TAGGED.&id({DictionaryRecordsVariants}), --- идентификтор записи справочника data TAGGED.&Data({DictionaryRecordsVariants}{@id}) --- данные записи справочника } DictionaryRecordsVariants TAGGED ::= { telcosRecords --- операторы связи, обслуживаемые ИС СОРМ |bunchesRecords --- пучки соединительных линий |basicStationsSectorRecords --- базовые станции |roamingPartnersRecords --- роуминговые партнеры |switchesRecords --- коммутаторы |gatesRecords --- IP шлюзы |callTypesRecords --- типы вызовов |supplementServicesRecords --- список дополнительных видов обслуживания (далее - ДВО) |payTypesRecords --- способы оплаты (пополнения баланса) |terminationCausesRecords --- причины завершения соединения |ipNumberingPlanRecords --- IP-план адресации |telephoneNumberingPlanRecords --- план телефонной номерной емкости |docTypesRecords --- типы документов, удостоверяющих личность |ipDataPointsRecords --- идентификаторы точек подключения к сети передачи данных, с которых получены записи о соединениях |specialNumbersRecords --- специальные номера оператора (SMS-центры, ТМС, сервисы) |bunchesMapRecords --- карта связей пучков соединительных линий |mobileSubscriberIdenityPlanRecords --- план нумерации идентификаторов мобильных телефонных абонентов |signalPointCodes --- коды сигнальных точек OPC/DPC } --- операторы связи, обслуживаемые ИС СОРМ telcosRecords TAGGED ::= { OID{ sorm-report-dictionary-telcos } DATA SEQUENCE OF TelcosRecord } TelcosRecord ::= SEQUENCE { telco-id TelcoID, --- номер структурного подразделения или оператора связи begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL, --- время конца действия description UTF8String (SIZE (1 .. 256)), --- описание (наименование) оператора связи или структурного подразделения mcc[0] NumericString (SIZE(3)) OPTIONAL, --- код страны mnc[1] NumericString (SIZE(3)) OPTIONAL --- код оператора связи } --- пучки соединительных линий bunchesRecords TAGGED ::= { OID ( sorm-report-dictionary-bunches } DATA SEQUENCE OF BunchRecord } BunchRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения bunch-id Bunch, --- идентификатор пучка switch-id UTF8String (SIZE (1 .. 128)), --- идентификатор коммутатора bunch-type ENUMERATED{ --- тип - входящий/исходящий inbound(0), outbound(1), bidirectional(3) }, begin-time DateAndTime, --- время начала назначения пучка end-time DateAndTime OPTIONAL, --- время конца назначения пучка description UTF8String (SIZE(1 .. 256)) --- расшифровка пучка } --- базовые станции basicStationsSectorRecords TAGGED ::= { OID{ sorm-report-dictionary-basic-stations } DATA SEQUENCE OF BasicStationSectorRecord } BasicStationSectorRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения begin-time DateAndTime, --- время начала действия базовой станции end-time DateAndTime, --- время конца действия базовой станции address UTF8String (SIZE (1 .. 256)), --- произвольное текстовое описание адреса или места расположения sector-identifiers BasicStationIdentifiers, --- идентификаторы сектора antenna-configuration BasicStationAntenna, --- параметры антенной системы station-type BasicStationType, --- тип сети базовой станции structured-address[0] ReportedAddress OPTIONAL, --- адрес места установки базовой станции location[1] GeoLocation OPTIONAL --- географическое местоположение } --- идентификаторы сектора BasicStationIdentifiers ::= CHOICE ( telepone[0] TelephoneIdentifiers, --- идентификаторы сектора для телефонной сети wireless[1] SEQUENCE OF WirelessIdentifiers --- идентификаторы сектора для сети передачи данных } --- идентификаторы сектора для телефонной сети TelephoneIdentifiers ::= SEQUENCE { lac INTEGER (0 .. 65535), --- код зоны cell INTEGER (0 .. 4294967295), --- идентификатор сектора базовой станции (идентификатор базовой станции и сектор) cell-sign UTF8String(SIZE (1 .. 18)) OPTIONAL --- телефонный идентификатор соты } --- идентификаторы сектора для сети передачи данных WirelessIdentifiers ::= SEQUENCE { cell UTF8String (SIZE (1 .. 64)), --- идентификатор сектора ip-list IPList OPTIONAL, --- перечень назначенных сектору IP-адресов/портов mac OCTET STRING (SIZE (6)) OPTIONAL --- MAC-адрес сетевого оборудования сектора } IPList ::= SEQUENCE OF NetworkPeerInfo --- параметры антенной системы GsmAntenna ::= SEQUENCE { azimut INTEGER (-1 .. 359), --- азимут относительно направления на север, в градусах, если -1, то нет направленности width INTEGER (0 .. 359), --- ширина растра в градусах horizon-angle INTEGER (0 .. 359), --- угол наклона сектора к горизонту power [0] INTEGER (0 .. 25000) OPTIONAL, --- мощность в ваттах (сектор) frequency [1] INTEGER (0 .. 10000000000) OPTIONAL, --- частота излучения (сектор) vertical-lift [2] INTEGER (0 .. 100) OPTIONAL, --- высота подвеса сектора gain-factor [3] INTEGER (-100 .. 100) OPTIONAL, --- коэффициент усиления антенны (Дб) polarization [4] INTEGER (-45 .. 45) OPTIONAL, --- поляризация антенной системы setting [5] BsSetting OPTIONAL, --- тип расположения БС thickness [6] INTEGER (0 .. 359) OPTIONAL, --- ширина диаграммы направленности основного лепестка сектора БС по вертикали (в градусах) generation [7] BsGeneration OPTIONAL, --- поколение controller-num [8] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- номер контроллера БС bcc-ncc [9] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- код идентификации базовой станции (BCC + NCC) cell-type [10] BsCellType OPTIONAL, --- тип БС соты (макро-, микро-, пико-, фемто-) radiation-class [11] UTF8String (SIZE (1 .. 32)) OPTIONAL, --- класс излучения (например: 200KG7D) name [12] UTF8String (SIZE (1 .. 32)) OPTIONAL, --- наименование базовой станции (номер БС в базах оператора) channel [13] UTF8String (SIZE (1 .. 32)) OPTIONAL --- десятичный номер канала (в соответствии со стандартом) } -- тип БС соты (макро-, микро-, пико-, фемто-) BsCellType ::= ENUMERATED{ macro (0), micro (1), pico (2), femto (3) } -- поколение БС BsGeneration ::= ENUMERATED{ g2 (0), g3 (1), g4 (2), g5 (3) } -- тип расположения БС BsSetting ::= ENUMERATED{ indoor (0), outdoor (1), underground (2) } CdmaAntenna ::= BroadbandWirelessParameters --- параметры антенной системы CDMA-сектора WirelessAntenna ::= BroadbandWirelessParameters --- параметры антенной системы WiFi/WiMAX-сектора BroadbandWirelessParameters ::= SEQUENCE { azimuth INTEGER (-1 .. 359), --- азимут относительно направления на север в градусах, если -1, то нет направленности width INTEGER (0 .. 359), --- ширина растра в градусах horizon-angle INTEGER (0 .. 359), --- угол наклона сектора к горизонту power[0] INTEGER (0 .. 25000) OPTIONAL, --- мощность в ваттах (сектор) frequency-start[1] INTEGER (0 .. 10000000000) OPTIONAL, --- нижняя частота излучения диапазона (сектор) frequency-stop[2] INTEGER (0 .. 10000000000) OPTIONAL, --- верхняя частота излучения диапазона (сектор) leaf-level [3] INTEGER (-45 .. 45) OPTIONAL, --- уровень боковых лепестков vertical-lift [4] INTEGER (0 .. 100) OPTIONAL, --- высота подвеса сектора gain-factor [5] INTEGER (-100 .. 100) OPTIONAL, --- коэффициент усиления антенны (Дб) polarization [6] INTEGER (-45 .. 45) OPTIONAL --- поляризация антенной системы } --- виды базовых станций BasicStationType ::= ENUMERATED { gsm (0), cdma (1), umts (2), wifi (3), wimax (4) } roamingPartnersRecords TAGGED ::= { OID ( sorm-report-dictionary-roaming-partners } DATA SEQUENCE OF RoamingPartnerRecord } RoamingPartnerRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения roaming-id INTEGER (0 .. 4294967295), --- идентификатор роумингового партнера begin-time DateAndTime, --- время начала действия роуминга end-time DateAndTime OPTIONAL, --- время конца действия роуминга description UTF8String (SIZE (1 .. 256)) --- описание } switchesRecords TAGGED ::= { OID ( sorm-report-dictionary-switches } DATA SEQUENCE OF SwitchesRecord } SwitchesRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения switch-id UTF8String (SIZE (1 .. 128)), --- идентификатор коммутатора begin-time DateAndTime, --- время начала действия коммутатора end-time DateAndTime OPTIONAL, --- время конца действия коммутатора description UTF8String (SIZE (1 .. 256)), --- описание network-type NetworkType, --- тип сети связи address ReportedAddress, --- адрес места установки коммутатора switch-sign NumericString (SIZE (1 .. 18)) OPTIONAL, --- телефонный идентификатор коммутатора switch-type ENUMERATED{ internal(0), --- внутренний border(1) --- пограничный } } gatesRecords TAGGED ::= { OID { sorm-report-dictionary-gates } DATA SEQUENCE OF GatesRecord } GatesRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения gate-id INTEGER (0 .. 4294967295), --- идентификатор шлюза ip-list IPList, --- IP адрес шлюза begin-time DateAndTime, --- время начала действия шлюза end-time DateAndTime OPTIONAL, --- время конца действия шлюза description UTF8String (SIZE (1 .. 256)), --- описание address ReportedAddress, --- адрес места установки шлюза gate-type ENUMERATED{ --- тип IP-шлюза sgsn(0), ggsn(1), smsc(2), gmsc(3), hss(4), pstn(5), voip-gw(6), aaa(7), nat(8) } } callTypesRecords TAGGED ::= { OID{ sorm-report-dictionary-call-types } DATA SEQUENCE OF CallsTypesRecord } CallsTypesRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения call-type-id INTEGER (0 .. 4294967295), --- идентификатор типа вызова begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL, --- время конца действия description UTF8String (SIZE (1 .. 256)) --- описание } supplementServicesRecords TAGGED ::= { OID { sorm-report-dictionary-supplement-services } DATA SEQUENCE OF SupplementServicesRecord } SupplementServicesRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения service-id INTEGER (0 .. 4294967295), --- идентификатор сервиса mnemonic UTF8String (SIZE (1..64)), --- мнемоническое обозначение begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL, --- время конца действия description UTF8String (SIZE (1 .. 256)) --- описание } payTypesRecords TAGGED ::= { OID { sorm-report-dictionary-pay-types } DATA SEQUENCE OF PayTypesRecord } PayTypesRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения pay-type-id INTEGER (0 .. 4294967295), --- идентификатор типа оплаты begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL, --- время конца действия description UTF8String (SIZE (1 .. 256)) --- описание } terminationCausesRecords TAGGED ::= { OID { sorm-report-dictionary-termination-causes } DATA SEQUENCE OF TerminationCausesRecord } TerminationCausesRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения termination-cause-id INTEGER (0 .. 16384), --- код причины begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL, --- время конца действия description UTF8String (SIZE (1 .. 256)), --- описание network-type NetworkType --- тип сети связи } ipNumberingPlanRecords TAGGED ::= { OID { sorm-report-dictionary-ip-numbering-plan } DATA SEQUENCE OF IpNumberingPlanRecord } IpNumberingPlanRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или филиала description UTF8String (SIZE (1 .. 256)), --- описание назначения диапазона network-address IPAddress, --- подсеть network-mask IPMask, --- маска подсети begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL --- время конца действия } telephoneNumberingPlanRecords TAGGED ::= { OID { sorm-report-dictionary-phone-numbering-plan } DATA SEQUENCE OF TelephoneNumberingPlanRecord } TelephoneNumberingPlanRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения iso-3166-alpha-2 UTF8String (SIZE (2)), --- 2-х символьная аббревиатура страны iso-3166-alpha-3 UTF8String (SIZE (3)), --- 3-х символьная аббревиатура страны country-code UTF8String (SIZE (3)), --- международный код страны national-significant-number UTF8String (SIZE (14)), --- номерной телефонный префикс оператора связи, включая код зоны area-code-length INTEGER (0 .. 6), --- длина кода зоны в телефонном префиксе оператора связи min-subscr-nr-length INTEGER (1 .. 15), --- минимальная длина абонентского номера, символов (national-significant-number + min-subscr) max-subscr-nr-length INTEGER (1 .. 15), --- максимальная длина абонентского номера, символов (national-significant-number + max-subscr) utc-min INTEGER (-12 .. 12), --- минимальный часовой пояс utc-max INTEGER (-12 .. 12), --- максимальный часовой пояс destination UTF8String (SIZE (2 .. 256)), --- страна operator-type-id NetworkType, --- тип сети связи оператора capacity-from NumericString (SIZE (1 .. 15)), --- нижняя граница диапазона выданных номеров (от) capacity-to NumericString (SIZE (1 .. 15)), --- верхняя граница диапазона выданных номеров (до) capacity-size INTEGER (1 .. 1000000), --- количество выделенных номеров в диапазоне (емкость) location UTF8String (SIZE (0 .. 256)), --- текстовое описание местоположения оператора связи registrar UTF8String (SIZE (0 .. 256)), --- наименование оператора связи range-activation DateAndTime, --- дата и время начала действия номерной емкости mobile-country-code NumericString (SIZE(3)), --- MCC mobile-network-code NumericString (SIZE(3)), --- MNC range-deactivation [0] DateAndTime OPTIONAL, --- дата и время завершения действия номерной емкости range-status [1] UTF8String (SIZE (2 .. 128)) OPTIONAL, --- текущее состояние номерной емкости description [2] UTF8String (SIZE (2 .. 256)) OPTIONAL, --- расшифровка оказываемых услуг связи по номерной емкости operating-company-number [3] UTF8String (SIZE (0 .. 4)) OPTIONAL --- международный идентификатор оператора связи } docTypesRecords TAGGED ::= { OID {sorm-report-dictionary-doc-types} DATA SEQUENCE OF DocTypesRecord } DocTypesRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения doc-type-id INTEGER (0 .. 65535), --- идентификатор типа документа begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL, --- время конца действия description UTF8String (SIZE (1 .. 256)) --- описание (наименование) } ipDataPointsRecords TAGGED ::= { OID { sorm-report-dictionary-ip-data-points } DATA SEQUENCE OF IpDataPointRecord } IpDataPointRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения point-id INTEGER (0 .. 1000), --- идентификатор точки подключения description UTF8String (SIZE (1 .. 256)), --- описание (наименование) точки подключения begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL --- время конца действия } specialNumbersRecords TAGGED ::= { OID { sorm-report-dictionary-special-numbers } DATA SEQUENCE OF SpecialNumberRecord } SpecialNumberRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения directory-number UTF8String (SIZE (2 .. 32)), --- специальный номер description UTF8String (SIZE (1 .. 256)), --- описание (наименование, назначение) специального номера begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL, --- время конца действия network-address IPAddress OPTIONAL --- адрес в сети передачи данных } bunchesMapRecords TAGGED ::= { OID { sorm-report-dictionary-bunches-map } DATA SEQUENCE OF BunchesMapRecord } BunchesMapRecord ::= SEQUENCE { a-bunch BunchMapPoint, --- пара коммутатор/пучок в связи b-bunch BunchMapPoint, --- пара коммутатор/пучок в связи begin-time DateAndTime, --- время начала действия связи end-time DateAndTime OPTIONAL --- время конца действия связи } BunchMapPoint ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или филиала switch-id UTF8String (SIZE (1 .. 128)), --- идентификатор коммутатора bunch-id Bunch --- идентификатор пучка коммутатора } mobileSubscriberIdenityPlanRecords TAGGED ::= { OID { sorm-report-dictionary-mobile-subscriber-identity-plan } DATA SEQUENCE OF MobileSubscriberIdenityPlanRecord } MobileSubscriberIdenityPlanRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения mcc NumericString (SIZE(3)), --- код страны mnc NumericString (SIZE(3)), --- код оператора связи area-code NumericString (SIZE(3 .. 10)), --- код зоны/региона capacity-from NumericString (SIZE (0 .. 7)), --- нижняя граница диапазона (от) capacity-to NumericString (SIZE (0 .. 7 )), --- верхняя граница диапазона (до) capacity-size INTEGER (1 .. 1000000), --- количество выделенных в диапазоне (емкость) description UTF8String (SIZE (2 .. 255)), --- описание, назначение region UTF8String (SIZE (1 .. 128)), --- область city UTF8String (SIZE (1 .. 128)), --- город, поселок, деревня range-activation DateAndTime, --- дата и время начала действия номерной емкости range-deactivation [0] DateAndTime OPTIONAL, --- дата и время завершения действия номерной емкости range-status [1] UTF8String (SIZE (2 .. 128)) OPTIONAL --- текущее состояние номерной емкости } -- Тип абонента PhoneAbonentType ::= ENUMERATED { local (0), -- абонент данного коммутатора network (1), -- абонент сети связи roamer (2), -- Абонент сети подвижной радиосвязи, получающий услуги связи за пределами региона регистрации (роумер) undefined (3) } --- коды сигнальных точек OPC/DPC signalPointCodes TAGGED ::= { OID {sorm-report-dictionary-signal-point-codes} DATA SEQUENCE OF SignalPointCodesRecord } SignalPointCodesRecord ::= SEQUENCE { ss7-point-code UTF8String (SIZE (1 .. 32)), --- идентификатор сигнальной точки (OPC/DPC) switch-id UTF8String (SIZE (1 .. 128)), --- идентификатор коммутатора begin-time DateAndTime, --- время начала назначения пучка end-time DateAndTime OPTIONAL, --- время конца назначения пучка description UTF8String (SIZE (1 .. 256)) --- расшифровка пучка } END ___________________________________________________________________________ Locations.asn Locations DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS Location, GeoLocation; Location ::= CHOICE { mobile-location [0] MobileLocation, --- местоположение мобильного абонента wireless-location [1] WirelessLocation, --- местоположение абонента мобильной сети передачи данных geo-location [2] GeoLocation --- географическое местоположение } MobileLocation ::= SEQUENCE { lac INTEGER (0 .. 65535), --- код зоны cell INTEGER (0 .. 4294967295), --- идентификатор базовой станции ta [0] INTEGER (0 .. 63) OPTIONAL --- Timing Advance (временная компенсация) } WirelessLocation ::= SEQUENCE { cell UTF8String (SIZE (1 .. 64)), --- идентификатор сектора mac OCTET STRING (SIZE (6)) --- MAC-адрес сетевого оборудования сектора } GeoLocation ::= SEQUENCE { latitude-grade REAL, --- широта в формате [целое_число_градусов].[стотысячные_доли_градуса] longitude-grade REAL, --- долгота в формате [целое_число_градусов].[стотысячные_доли_градуса] projection-type ENUMERATED { --- тип проекции координат wgs84 (0), utm (1), sgs85 (2) } } END ___________________________________________________________________________ Management.asn Management DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS managementMessage; IMPORTS TAGGED, sorm-message-management FROM Classification; managementMessage TAGGED ::= { OID { sorm-message-management } DATA CHOICE { request [0] ManagementRequest, response [1] ManagementResponse } } --- тип сообщения "команда управления ИС СОРМ" ManagementRequest ::= CHOICE { get-structure [0] GetStructureRequest, --- запрос на получение структуры ИС СОРМ - КТС и модулей СПО get-module-config [1] GetModuleConfigRequest, --- запрос на получение конфигурации КТС/модуля СПО set-module-config [2] SetModuleConfigRequest, --- запрос на изменение конфигурации КТС/модуля СПО check-module [3] CheckModuleRequest, --- запрос на получение состояния модуля get-module-types [4] GetModuleTypesRequest --- запрос на получение типов модулей КТС и СПО } --- запрос на получение структуры ИС СОРМ - КТС и модулей СПО GetStructureRequest ::= NULL --- запрос на получение конфигурации КТС/модуля СПО GetModuleConfigRequest::= CHOICE { hw-modules-list [0] RequestedHardwareModules, --- перечень идентификаторов узлов КТС ИС СОРМ sw-modules-list [1] RequestedSoftwareModules --- перечень идентификаторов модулей СПО ИС СОРМ } RequestedHardwareModules ::= SEQUENCE OF ModuleId --- перечень идентификаторов узлов КТС ИС СОРМ RequestedSoftwareModules ::= SEQUENCE OF ModuleId --- перечень идентификаторов модулей СПО ИС СОРМ --- запрос на изменение конфигурации КТС/модуля СПО SetModuleConfigRequest::= SEQUENCE { module-id ModuleId, --- идентификатор конфигурируемого модуля module-config ConfiguratedModule --- устанавливаемая в модуль конфигурация } ConfiguratedModule ::= CHOICE { sw-module [0] SormSoftwareModule, --- для узла КТС hw-module [1] SormHardwareModule --- для узла СПО } --- запрос на получение состояния модуля CheckModuleRequest::= RequestedModulesList RequestedModulesList ::= CHOICE { hw-modules [0] RequestedHardwareModules, --- идентификаторы узлов КТС, для которых запрашивается состояние sw-modules [1] RequestedSoftwareModules --- идентификаторы модулей ИС СОРМ, для которых запрашивается состояние } --- запрос на получение типов модулей КТС и СПО GetModuleTypesRequest ::= NULL --- уникальный идентификатор КТС/модуля СПО ИС СОРМ ModuleId ::= OCTET STRING (SIZE (8)) --- параметр модуля ModuleParameter ::= SEQUENCE { parameter-name UTF8String (SIZE (1 .. 256)), --- наименование параметра read-only BOOLEAN, --- контролируемый или измеряемый параметр parameter-value ParameterValue --- значение параметра } --- варианты значений параметров ParameterValue ::= CHOICE { string [0] UTF8String (SIZE (1 .. 256)), integer [1] INTEGER (0 .. 999999999), boolean [2] BOOLEAN } ModuleParameters ::= SEQUENCE OF ModuleParameter SormSoftwareModule ::= SEQUENCE { module-id ModuleId, --- уникальный идентификатор данного модуля hardware-module-id ModuleId, --- идентификатор КТС, на котором работает данный блок модуля СПО block-name INTEGER (0 .. 1024), --- номер блока СПО модуля module-name UTF8String (SIZE (1 .. 512)), --- наименование модуля module-type INTEGER (1 .. 512), --- идентификатор типа модуля module-parameters ModuleParameters, --- список параметров модуля sub-modules-list SubmodulesList OPTIONAL --- субмодули } SubmodulesList ::= SEQUENCE OF SormSoftwareModule SormHardwareModule ::= SEQUENCE { module-id ModuleId, --- уникальный идентификатор данного модуля block-name INTEGER (0 .. 1024), --- номер блока КТС module-name UTF8String (SIZE (1 .. 512)), --- наименование модуля module-parameters HwParameterGroups --- значение группы параметров КТС } HwParameterGroup ::= SEQUENCE { group-name UTF8String (SIZE (1 .. 512)), --- наименование группы параметров для КТС module-parameters ModuleParameters --- перечень параметров для КТС } HwParameterGroups ::= SEQUENCE OF HwParameterGroup SormSoftwareModules ::= SEQUENCE OF SormSoftwareModule SormHardwareModules ::= SEQUENCE OF SormHardwareModule --- тип сообщения "ответ на команду управления ИС СОРМ" ManagementResponse ::= CHOICE { get-structure [0] GetStructureResponse, --- ответ на запрос получения структуры ИС СОРМ - КТС и модулей СПО get-module-config [1] GetModuleConfigResponse, --- ответ на запрос получения конфигурации КТС/модуля СПО set-module-config [2] SetModuleConfigResponse, --- ответ на запрос изменения конфигурации КТС/модуля СПО check-module [3] CheckModuleResponse, --- ответ на запрос получения состояния модуля get-module-types [4] GetModuleTypesResponse --- ответ на запрос получения типов модулей КТС и СПО } --- ответ на запрос получения структуры ИС СОРМ - КТС и модулей СПО GetStructureResponse ::= SEQUENCE { sw-modules SormHardwareModules, --- перечень всех узлов КТС hw-modules SormSoftwareModules --- перечень всех модулей СПО ИС СОРМ } --- ответ на запрос получения конфигурации КТС/модуля СПО GetModuleConfigResponse ::= SEQUENCE { hw-modules SormHardwareModules, --- конфигурации запрошенных узлов КТС sw-modules SormSoftwareModules --- конфигурации запрошенных модулей СПО ИС СОРМ } --- отчет на запрос изменения конфигурации КТС/модуля СПО SetModuleConfigResponse::= ConfiguratedModule --- установленная в модуль конфигурация --- ответ на запрос получения состояния модуля CheckModuleResponse ::= CHOICE { hw-modules [0] SormHardwareModules, --- текущее состояние запрошенных модулей СПО ИС СОРМ sw-modules [1] SormSoftwareModules --- текущее состояние запрошенных узлов КТС } --- ответ на запрос получения типов модулей КТС и СПО GetModuleTypesResponse ::= SEQUENCE OF ModuleType ModuleType ::= SEQUENCE { module-type INTEGER (1 .. 512), --- идентификатор типа модуля type-description UTF8String ( SIZE (1 .. 128)) --- расшифровка типа модуля } END ___________________________________________________________________________ NetworkIdentifiers.asn NetworkIdentifiers DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS Bunch, DataNetworkEquipment, IPAddress, IPPort, IPMask, NetworkPeerInfo, PortRange, NetworkType, DataVoipNumber, IMProtocol, VoipProtocol, HttpMethod; --- идентификаторы пучка Bunch ::= CHOICE { gsm [0] INTEGER (0 .. 4294967295), --- идентификатор пучка для GSM-Сети cdma-umts [1] DataNetworkEquipment --- идентификатор пучка для W/CDMA, UMTS-сети } -- идентификатор оборудования сети передачи данных DataNetworkEquipment ::= CHOICE { mac [0] OCTET STRING (SIZE (6)), --- MAC-адрес оконечного сетевого оборудования atm [1] DataNetworkATM } --- АТМ адрес (SDH/PDH сети) DataNetworkATM ::= SEQUENCE { vpi OCTET STRING (SIZE (1)), --- номер виртуального пути сети АТМ (VPI) vci OCTET STRING (SIZE (2)) OPTIONAL --- номер виртуального канала сети АТМ (VCI) } --- тип сети связи (стандарт) NetworkType ::= ENUMERATED { not-specified(0), --- неконкретизированный стандарт mob-gsm(1), --- сеть мобильной связи стандарта GSM mob-cdma(2), --- сеть мобильной связи стандарта CDMA fix-pstn(3), --- ТФоП-сеть data-ip(4), --- стационарные сети передачи данных data-srv(5), --- ТМС-службы data-ip-mob(6), --- мобильная сеть передачи данных data-ip-wifi (7), --- беспроводная сеть передачи данных стандарта WiFi data-ip-max (8), --- беспроводная сеть передачи данных стандарта WiMAX paging(9), --- персональный радиовызов voip(10) --- сеть передачи голосовой информации посредством сети передачи данных } --- IP-адрес IPAddress ::= CHOICE { ipv4 [0] IPV4Address, --- IPv4-адрес ipv6 [1] IPV6Address --- IPv6-адрес } -- IPv4-адрес IPV4Address ::= OCTET STRING (SIZE (4)) -- IP адрес (4 байта) -- IPv6-адрес IPV6Address ::= OCTET STRING (SIZE (16)) -- IP адрес (16 байт) --- IP/UDP/TCP-порт IPPort ::= OCTET STRING (SIZE (2)) -- порт --- маска IP-подсети IPMask ::= CHOICE { ipv4-mask [0] IPV4Mask, --- IPv4-маска ipv6-mask [1] IPV6Mask --- IPv6-маска } --- информация об участнике соединения передачи данных NetworkPeerInfo ::= SEQUENCE { ip-address IPAddress, --- IP-адрес ip-port IPPort OPTIONAL --- IP-порт } PortRange ::= SEQUENCE { port-from [0] IPPort, port-to [1] IPPort } --- IPv4-маска IPV4Mask ::= OCTET STRING (SIZE (4)) --- IPv6-маска IPV6Mask ::= OCTET STRING (SIZE (16)) -- Номер телефона VoIP-абонента DataVoipNumber ::= SEQUENCE { original-number UTF8String (SIZE (1 .. 512)), --- исходный номер абонента translated-number [0] UTF8String (SIZE (1 .. 32)) OPTIONAL, --- номер абонента после преобразования e164-number [1] UTF8String (SIZE (1 .. 15)) OPTIONAL --- номер абонента в E164-сети } VoipProtocol ::= ENUMERATED { sip(0), h323(1), iax(2), skype(100) } IMProtocol ::= ENUMERATED { --- протокол, при помощи которого отправлены сообщения icq(0), aol(1), msn(2), yahoo(3), web-mail(4), --- передача сообщения пользователем посредством почтового веб-сервера mms(98), sms(99), } --- http метод HttpMethod ::= ENUMERATED { get(0), post(1), put(2), delete (3) } END ___________________________________________________________________________ ReportedIdentifiers.asn ReportedIdentifiers DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ReportedIdentifier ; IMPORTS TAGGED, sorm-report-identifier-pager, sorm-report-identifier-pstn, sorm-report-identifier-gsm, sorm-report-identifier-cdma, sorm-report-identifier-data-network, sorm-report-identifier-voip FROM Classification IPAddress, DataNetworkEquipment, IPMask FROM NetworkIdentifiers; ReportedIdentifier ::= SEQUENCE { id TAGGED.&id ({ReportedIdentifierVariants}), data TAGGED.&Data ({ReportedIdentifierVariants}{@id}) } --- варианты идентификаторов отчета ReportedIdentifierVariants TAGGED ::= { reportedPagerIdentifier --- идентификатор сети персонального радиовызова | reportedPstnIdentifier --- идентификатор ТФОП | reportedGsmIdentifier --- идентификатор GSM | reportedCdmaIdentifier --- идентификатор CDMA | reportedDataNetworkIdentifier --- идентификатор сети передачи данных | reportedVoipIdentifier } --- идентификатор сети персонального радиовызова reportedPagerIdentifier TAGGED ::= { OID { sorm-report-identifier-pager } DATA ReportedPagerIdentifier } ReportedPagerIdentifier ::= NumericString (SIZE (2 .. 18)) --- идентификатор телефонной сети общего пользования reportedPstnIdentifier TAGGED ::= { OID { sorm-report-identifier-pstn } DATA ReportedPstnIdentifier } ReportedPstnIdentifier ::= SEQUENCE { directory-number UTF8String (SIZE (2 .. 32)), --- телефонный номер в международном формате internal-number NumericString (SIZE (1 .. 32)) OPTIONAL --- дополнительный внутренний номер, если есть } -- идентификатор абонента GSM reportedGsmIdentifier TAGGED ::= { OID { sorm-report-identifier-gsm } DATA ReportedGsmIdentifier } ReportedGsmIdentifier ::= SEQUENCE { directory-number UTF8String (SIZE (2 .. 32)), --- телефонный номер в международном формате imsi NumericString (SIZE (2 .. 18)), --- идентификатор мобильного абонента imei [0] NumericString (SIZE (2 .. 18)) OPTIONAL, --- идентификатор мобильной станции icc [1] NumericString (SIZE (10 .. 20)) OPTIONAL --- идентификатор SIM-карты абонента } -- идентификатор абонента CDMA reportedCdmaIdentifier TAGGED ::= { OID { sorm-report-identifier-cdma } DATA ReportedCdmaIdentifier } ReportedCdmaIdentifier ::= SEQUENCE { directory-number UTF8String (SIZE (2 .. 32)), --- телефонный номер в международном формате imsi NumericString (SIZE (2 .. 18)), --- идентификатор мобильного абонента esn [0] NumericString (SIZE (2 .. 18)) OPTIONAL, --- идентификатор мобильной станции min [1] NumericString (SIZE (2 .. 18)) OPTIONAL, --- идентификатор мобильного абонента (CDMA) icc [2] NumericString (SIZE (10 .. 20)) OPTIONAL --- идентификатор SIM-карты абонента } reportedDataNetworkIdentifier TAGGED ::= { OID { sorm-report-identifier-data-network } DATA ReportedDataNetworkIdentifier } ReportedDataNetworkIdentifier ::= SEQUENCE { user-equipment [0] DataNetworkEquipment OPTIONAL, --- идентификатор пользовательского оборудования login [1] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- имя пользователя - login ip-address [2] IPAddress OPTIONAL, --- IP адрес e-mail [3] UTF8String (SIZE (1 .. 256)) OPTIONAL, --- адрес электронной почты pin [4] NumericString (SIZE (2 .. 20)) OPTIONAL, --- PIN phone-number [5] UTF8String (SIZE (2 .. 32)) OPTIONAL, --- номер телефона user-domain [6] UTF8String (SIZE (2 .. 256)) OPTIONAL, --- пользовательский домен reserved [7] UTF8String (SIZE (1 .. 256)) OPTIONAL, --- резерв ip-mask [8] IPMask OPTIONAL } reportedVoipIdentifier TAGGED ::= { OID { sorm-report-identifier-voip } DATA ReportedVoipIdentifier } ReportedVoipIdentifier ::= SEQUENCE { ip-address [0] IPAddress OPTIONAL, --- IP-адрес абонента originator-name [1] UTF8String (SIZE (1 .. 512)) OPTIONAL, --- общедоступное имя инициатора связи calling-number [2] UTF8String (SIZE (1 .. 32)) OPTIONAL --- номер вызывающего абонента } END ___________________________________________________________________________ ReportsAbonents.asn ReportsAbonents DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS AbonentsReport; IMPORTS TAGGED, sorm-report-abonent-abonent, sorm-report-abonent-service, sorm-report-abonent-person, sorm-report-abonent-organization FROM Classification DateAndTime FROM Sorm TelcoID FROM Dictionaries ReportedIdentifier FROM ReportedIdentifiers NetworkType FROM NetworkIdentifiers AddressType, ReportedAddresses, ReportedAddress FROM Addresses Location FROM Locations; AbonentsReport ::= SEQUENCE { id TAGGED.&id({AbonentsReportVariants}), data TAGGED.&Data({AbonentsReportVariants}{@id}) } AbonentsReportVariants TAGGED ::= { reportAbonent| --- информация об абоненте reportService --- информация о сервисах } reportAbonent TAGGED ::= { OID sorm-report-abonent-abonent DATA SEQUENCE OF AbonentsRecord } AbonentsRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения idents ReportedIdentifier, --- идентификаторы абонента contract-date DateAndTime, --- дата и время заключения договора contract UTF8String (SIZE (1 .. 64)), --- номер договора actual-from DateAndTime, --- дата и время начала интервала времени, на котором актуальная информация actual-to DateAndTime, --- дата и время окончания интервала времени, на котором актуальна информация abonent AbonentInfo, --- информация об абоненте (клиенте оператора связи) status ActiveStatus, --- текущий статус абонента (подключен/отключен) attach [0] DateAndTime OPTIONAL, --- дата и время подключения основной услуги (если подключение производилось на интервале актуальности) detach [1] DateAndTime OPTIONAL, --- дата и время отключения основной услуги (если отключение производилось на интервале актуальности) last-location [2] Location OPTIONAL, --- последнее зафиксированное местоположение для мобильных абонентов services [3] ActiveServices OPTIONAL, --- активированные услуги line-data [4] LineData OPTIONAL, --- линейные данные (кросс, рамка, пара и т.д.) standard [5] Standard OPTIONAL, --- стандарт связи addresses [6] ReportedAddresses OPTIONAL --- адреса абонента } ActiveServices ::= SEQUENCE OF AbonentService --- набор подключенных ДВО ActiveStatus ::= ENUMERATED { active (0), --- активный not-active (1) --- не активный } LineData ::= SEQUENCE { object [0] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- описание объекта связи cross [1] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- описание кросса block [2] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- описние блока pair [3] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- описание пары reserved [4] UTF8String (SIZE (1 .. 128)) OPTIONAL --- резерв } AbonentInfo ::= SEQUENCE { id TAGGED.&id ({AbonentsInfoVariants}), data TAGGED.&Data({AbonentsInfoVariants}{@id}) } AbonentsInfoVariants TAGGED ::= { abonentPerson| --- информация об абоненте - физическом лице abonentOrganization --- информация об абоненте - юридическом лице } --- Физическое лицо abonentPerson TAGGED ::= { OID { sorm-report-abonent-person } DATA AbonentPerson } AbonentPerson ::= SEQUENCE { name-info PersonNameInfoReport, --- ФИО birth-date GeneralizedTime OPTIONAL, --- дата рождения passport-info PassportInfoReport, --- паспортные данные bank [1] UTF8String (SIZE(1 .. 256)) OPTIONAL, --- банк абонента (используемый при расчетах с оператором связи) bank-account [2] UTF8String (SIZE(1 .. 30)) OPTIONAL --- счет абонента в банке (используемый при расчетах с оператором связи) } PersonNameInfoReport ::= CHOICE { struct-name[0] PersonStructNameInfoReport, --- структурированное ФИО unstruct-name[1] UTF8String(SIZE(1 .. 1024)) --- неструктурированное ФИО } PersonStructNameInfoReport ::= SEQUENCE { given-name UTF8String (SIZE (1 .. 256)), --- имя initial UTF8String (SIZE (1 .. 256)), --- отчество family-name UTF8String (SIZE (1 .. 256)) --- фамилия } PassportInfoReport::= SEQUENCE { ident-card-info IdentCardInfoReport, --- описание удостоверения личности doc-type-id INTEGER (0 .. 65535) --- идентификатор типа документа, удостоверяющего личность } IdentCardInfoReport ::= CHOICE { struct-info [0] IdentCardStructInfoReport, --- структурированная информация unstruct-info [1] UTF8String (SIZE (1 .. 1024)) --- неструктурированная информация } IdentCardStructInfoReport ::= SEQUENCE { ident-card-serial UTF8String (SIZE (1..16)), --- серия удостоверения личности ident-card-number NumericString (SIZE (1..16)), --- номер удостоверения личности ident-card-description UTF8String (SIZE (1 .. 512)) --- когда и кем выдано } abonentOrganization TAGGED ::= { OID { sorm-report-abonent-organization } DATA AbonentOrganization } AbonentOrganization ::= SEQUENCE { full-name UTF8String (SIZE (1 .. 256)), --- полное наименование inn UTF8String (SIZE(1 .. 64)), --- ИНН contact [0] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- контактное лицо phone-fax [1] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- контактные телефоны, факс internal-users [2] InternalUsers OPTIONAL, --- список внутренних пользователей, выдается только при --- заполнении аналогичного поля в запросе формирования --- задачи на поиск идентификаторов абонентов или при заполнении --- поля internal-number в запросе на принадлежность идентификаторов --- операторам связи bank [3] UTF8String (SIZE(1 .. 256)) OPTIONAL, --- банк абонента (используемый при расчетах с оператором связи) bank-account [4] UTF8String (SIZE(1 .. 30)) OPTIONAL --- счет абонента в банке (используемый при расчетах с оператором связи) } InternalUsers ::= SEQUENCE OF InternalUsersRecord -- набор записей, описывающих внутренних пользователей абонента - -- юридического лица InternalUsersRecord ::= SEQUENCE { user-name UTF8String (SIZE (1 .. 64)), --- строка - описатель внутреннего пользователя internal-number NumericString (SIZE (1 .. 64)) --- внутренний номер } Standard ::= NetworkType --- перечень стандартов связи reportService TAGGED ::= { OID sorm-report-abonent-service DATA SEQUENCE OF AbonentService } AbonentService ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения service-id INTEGER (0 .. 4294967295), --- идентификатор услуги idents ReportedIdentifier OPTIONAL, --- идентификаторы абонента contract UTF8String (SIZE (1 .. 64)), --- номер договора begin-time DateAndTime, --- дата и время начала оказания услуги end-time DateAndTime, --- дата и время окончания оказания услуги parameter UTF8String (SIZE(1..256)) OPTIONAL --- индивидуальные параметры настройки услуги абонента --- номер на который осуществляется преадресация } END ___________________________________________________________________________ Reports.asn Reports DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS reportMessage, Acknowledgement; IMPORTS TAGGED, sorm-message-report FROM Classification Message, MessageID, DateAndTime FROM Sorm TaskID FROM Tasks DictionaryReport FROM Dictionaries ConnectionsReport FROM ReportsConnections LocationReport FROM ReportsLocations PaymentsReport FROM ReportsPayments PresenseReport FROM ReportsPresense NonFormalizedReport FROM ReportsNonFormalized AbonentsReport FROM ReportsAbonents DataContentReport FROM ReportsDataContent; reportMessage TAGGED ::= { OID { sorm-message-report } DATA CHOICE { report [0] Report, --- тип сообщения "отчет" ack [1] Acknowledgement --- тип сообщения "подтверждение" } } -- Блок данных сообщения типа "отчет" Report ::= SEQUENCE { request-id MessageID, --- идентификатор запроса, запросивший отчет task-id TaskID, --- идентификатор задачи, сгенерировавшей данный отчет total-blocks-number INTEGER --- общее количество блоков в отчете block-number INTEGER --- порядковый номер текущего блока report-block ReportDataBlock --- блок данных отчета } -- Подтверждение приема блока, передается с номером соощения соответствующему номеру сообщения блока отчета Acknowledgement ::= SEQUENCE { successful BOOLEAN, --- признак успешного приема блока broken-record INTEGER OPTIONAL, --- номер записи в отчете, обработанной на ПУ с ошибкой error-description UTF8String (SIZE(1..1024)) OPTIONAL --- описание ошибки приема блока в произвольной форме } ReportDataBlock ::= CHOICE { dictionary [0] DictionaryReport, --- отчеты задач пополнения справочников (нормативно- справочная информация) abonents [1] AbonentsReport, --- отчеты задач поисков по принадлежности абонентов connections [2] ConnectionsReport, --- отчеты задач поисков по соединениям абонентов locations [3] LocationReport, --- отчет задачи получения данных местоположения абонентов payments [4] PaymentsReport, --- отчеты задач поисков по совершенным платежам presense [6] PresenseReport, --- отчеты задач по запросу наличия в ИС СОРМ информации nonFormalized [7] NonFormalizedReport, --- отчеты задач по обработке неформализованных данных data-content [10] DataContentReport --- отчеты задач по получению содержимого потоков } END ___________________________________________________________________________ ReportsConnections.asn ReportsConnections DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ConnectionsReport, CallsRecords; IMPORTS DateAndTime FROM Sorm DataContentID FROM Tasks Location FROM Locations ReportedIdentifier FROM ReportedIdentifiers Bunch, NetworkPeerInfo, DataNetworkEquipment, DataVoipNumber, IPAddress, IPMask, VoipProtocol, IMProtocol, HttpMethod FROM NetworkIdentifiers PhoneAbonentType, TelcoID FROM Dictionaries TAGGED, sorm-report-connection-pager, sorm-report-connection-pstn, sorm-report-connection-mobile, sorm-report-connection-ipdr-header, sorm-report-connection-aaa-login, sorm-report-connection-resource, sorm-report-connection-email, sorm-report-connection-im, sorm-report-connection-voip, sorm-report-connection-file-transfer, sorm-report-connection-term-access, sorm-report-connection-raw-flows, sorm-report-connection-address-translations FROM Classification; ConnectionsReport ::= CallsRecords CallsRecords ::= SEQUENCE { id TAGGED.&id ({ReportedCallsVariants}), data TAGGED.&Data ({ReportedCallsVariants}{@id}) } ReportedCallsVariants TAGGED ::= { pagerRecord |pstnRecord |mobileRecord |dataAAARecord |dataEmailRecord |dataImRecord |dataFileTransferRecord |dataTermAccessRecord |dataRawFlowsRecord |dataResourceRecord |dataVoipRecord |dataAddressTranslationRecord } -- Детализированные записи отправки пэйджинг-сообщений pagerRecord TAGGED ::= { OID { sorm-report-connection-pager } DATA SEQUENCE OF PagerRecordContent } PagerRecordContent ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения call-type-id INTEGER (0 .. 4294967295), --- тип соединения connection-time DateAndTime, --- дата и время передачи сообщения info ReportedIdentifier, --- идентификаторы абонента in-bytes-count INTEGER (0 .. 1024), --- объем переданных данных term-cause INTEGER (0 .. 16384) --- причина завершения соединения } -- Детализированные записи звонков абонентов ТФОП, в т.ч. и неудавшиеся попытки соединений pstnRecord TAGGED ::= { OID { sorm-report-connection-pstn } DATA SEQUENCE OF PstnRecordContent } PstnRecordContent ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения begin-connection-time DateAndTime, --- дата и время начала соединения duration INTEGER (0 .. 86399), --- время соединения call-type-id INTEGER (0 .. 4294967295), --- тип соединения supplement-service-id INTEGER (0 .. 4294967295), --- ДВО при соединении in-abonent-type PhoneAbonentType, --- тип вызывающего абонента out-abonent-type PhoneAbonentType, --- тип вызываемого абонента switch-id UTF8String (SIZE (1 .. 128)), --- код коммутатора обслужившего соединение inbound-bunch INTEGER (0 .. 4294967295), --- входящий пучок outbound-bunch INTEGER (0 .. 4294967295), --- исходящий пучок term-cause INTEGER (0 .. 16384), --- причина завершения соединения phone-card-number [0] NumericString (SIZE (1.. 20)) OPTIONAL, --- номер телефонной карты in-info [1] ReportedIdentifier OPTIONAL, --- идентификаторы вызывающего абонента dialed-digits [2] UTF8String (SIZE (1 .. 128)), --- набранный номер вызываемого абонента out-info [3] ReportedIdentifier OPTIONAL, --- идентификаторы вызываемого абонента forwarding-identifier [4] UTF8String (SIZE (2 .. 32)) OPTIONAL, --- телефонный номер при переадресации border-switch-id [5] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- код пограничного коммутатора message [10] UTF8String OPTIONAL, --- текстовое содержание сообщения абонента ss7-opc [11] UTF8String (SIZE (1 .. 32)) OPTIONAL, --- SS7 код точки отправления ss7-dpc [12] UTF8String (SIZE (1 .. 32)) OPTIONAL, --- SS7 код точки назначения data-content-id [13] DataContentID OPTIONAL --- идентификатор потока } -- Детализированные записи звонков мобильных абонентов, в т.ч. и неудавшиеся попытки соединений -- Должны содержать также записи об SMS, в т.ч. и неудавшиеся попытки отправки mobileRecord TAGGED ::= { OID { sorm-report-connection-mobile } DATA SEQUENCE OF MobileRecordContent } MobileRecordContent ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения begin-connection-time DateAndTime, --- дата и время начала соединения duration INTEGER (0 .. 86399), --- время соединения call-type-id INTEGER (0 .. 4294967295), --- тип соединения supplement-service-id INTEGER (0 .. 4294967295), --- ДВО при соединении in-abonent-type PhoneAbonentType, --- тип вызывающего абонента out-abonent-type PhoneAbonentType, --- тип вызываемого абонента switch-id UTF8String (SIZE (1 .. 128)), --- код коммутатора обслужившего соединении term-cause INTEGER (0 .. 16384), --- причина завершения соединения inbound-bunch [0] Bunch OPTIONAL, --- входящий пучок outbound-bunch [1] Bunch OPTIONAL, --- исходящий пучок in-info [2] ReportedIdentifier OPTIONAL, --- идентификаторы вызывающего абонента in-end-location [3] Location OPTIONAL, --- местоположение вызывающего абонента на конец вызова in-begin-location [4] Location OPTIONAL, --- местоположение вызывающего абонента на начало вызова out-info [5] ReportedIdentifier OPTIONAL, --- идентификаторы вызываемого абонента out-begin-location [6] Location OPTIONAL, --- местоположение вызываемого абонента на начало вызова out-end-location [7] Location OPTIONAL, --- местоположение вызываемого абонента на конец вызова forwarding-identifier [8] UTF8String (SIZE (2 .. 32)) OPTIONAL, --- телефонный номер при переадресации roaming-partner-id [9] INTEGER (0 .. 4294967295) OPTIONAL, --- код роумингового партнера border-switch-id [10] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- код пограничного коммутатора message [40] UTF8String OPTIONAL, --- текстовое содержание сообщения абонента data-content-id [41] DataContentID OPTIONAL --- идентификатор потока } --- запись IPDR подключения/отключения абонента к сети связи dataAAARecord TAGGED ::= { OID { sorm-report-connection-aaa-login } DATA SEQUENCE OF DataAAARecordContent } DataAAARecordContent ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения point-id INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получена запись о соединении aaa-connection-time DateAndTime, --- дата и время подключения/отключения к сети передачи данных aaa-login-type ENUMERATED { --- тип соединения connect (0), --- подключение к сети передачи данных disconnect (1), --- отключение от сети передачи данных lac-update (2) }, aaa-session-id UTF8String (SIZE (1 .. 64)), --- идентификатор сессии aaa-allocated-ip IPAddress, --- выделенный динамический IP-адрес aaa-user-name UTF8String (SIZE (1 .. 128)), --- имя пользователя (логин) aaa-connect-type INTEGER (0 .. 65535), --- код протокола в соответствии с RFC1700 либо номер порта для TCP/UDP aaa-calling-number UTF8String (SIZE (2 .. 32)), --- вызывающий номер aaa-called-number UTF8String (SIZE (2 .. 32)), --- вызываемый номер aaa-nas NetworkPeerInfo, --- IP-адрес/порт NAS-сервера aaa-in-bytes-count INTEGER (0 .. 18446744073709551615), --- объем принятых данных aaa-out-bytes-count INTEGER (0 .. 18446744073709551615), --- объем переданных данных aaa-user-password [0] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- пользовательский пароль aaa-user-equipment [1] DataNetworkEquipment OPTIONAL, --- идентификатор пользовательского оборудования aaa-apn [2] UTF8String (SIZE (1 .. 128)) OPTIONAL, --- наименование точки доступа (Access Point Name) aaa-sgsn-ip [3] IPAddress OPTIONAL, --- IP-адрес GPRS/EDGE SGSN aaa-ggsn-ip [4] IPAddress OPTIONAL, --- IP-адрес GPRS/EDGE GGSN aaa-service-area-code [5] INTEGER (0 .. 65535) OPTIONAL, --- код зоны обслуживания (SAC) GPRS/EDGE aaa-location-start [6] Location OPTIONAL, --- базовая станция, через которую установлено соединение (передача данных посредством подвижной сети связи) aaa-location-end [7] Location OPTIONAL, --- базовая станция, через которую завершено соединение (передача данных посредством подвижной сети связи) phone-card-number [8] NumericString (SIZE (20)) OPTIONAL, --- номер телефонной карты aaa-imsi [9] NumericString (SIZE (2 .. 18)) OPTIONAL, --- IMSI мобильного абонента aaa-imei [10] NumericString (SIZE (2 .. 18)) OPTIONAL, --- идентификатор мобильной станции абонента aaa-esn [11] NumericString (SIZE (10 .. 18)) OPTIONAL, --- идентификатор мобильной станции абонента aaa-pool-number [12] UTF8String (SIZE (1 .. 64)) OPTIONAL, --- номер модемного пула aaa-mcc [13] UTF8String OPTIONAL, aaa-mnc [14] UTF8String OPTIONAL, aaa-allocated-ip-mask [15] IPMask OPTIONAL } --- запись IPDR передачи почтового сообщения dataEmailRecord TAGGED ::= { OID { sorm-report-connection-email } DATA SEQUENCE OF DataEmailRecordContent } DataEmailRecordContent ::= CHOICE { mail-aaa [0] DataEmailRecordContentAAA, mail-ipdr [1] DataEmailRecordContentIPDR } DataEmailRecordContentIPDR ::= SEQUENCE { mail-cdr-header DataNetworkCdrHeader, --- заголовок IPDR-соединения mail-event EmailEvent, --- тип события mail-sender UTF8String (SIZE (1 .. 512)), --- отправитель почтового сообщения mail-receiver EmailReceivers, --- получатель почтового сообщения mail-cc EmailReceivers, --- получатель-копия почтового сообщения mail-subject UTF8String (SIZE (0 .. 2048)), --- тема почтового сообщения mail-size INTEGER (0 .. 4294967295), --- размер почтового сообщения, включая прикрепленные файлы, байт attachements INTEGER (0 ..1), --- наличие прикрепленных файлов в письме (да/нет) mail-servers EmailServers, --- список текстовых наименований почтовых серверов, через которые отправлено письмо (в т.ч. сервера веб-почты) mail-term-cause INTEGER (0 .. 16384), --- причина завершения соединения mail-reply-to UTF8String (SIZE (1 .. 256)) OPTIONAL, --- имя и адрес, куда следует адресовать ответы на письмо mail-protocol ENUMERATED { --- протокол, при помощи которого отправлено сообщение smtp(0), pop3(1), imap(2), web-mail(3) } OPTIONAL, mail-abonent-id [0] UTF8String (SIZE (0 .. 64)) OPTIONAL, --- идентификатор абонента mail-message [10] UTF8String OPTIONAL, --- текстовое содержание сообщения абонента mail-nat-info [11] SEQUENCE OF NetworkPeerInfo OPTIONAL, --- транслированные NAT IP/порт mail-location [12] Location OPTIONAL, --- местоположение абонента mail-data-content-id [13] DataContentID OPTIONAL --- идентификатор потока } DataEmailRecordContentAAA ::= SEQUENCE { mail-cdr-header DataNetworkCdrHeader, --- заголовок IPDR-соединения mail-event EmailEvent, --- тип события mail-aaa-info IP-AAAInformation, --- пользовательские реквизиты входа mail-message [10] UTF8String OPTIONAL, --- текстовое содержание сообщения абонента mail-nat-info [11] SEQUENCE OF NetworkPeerInfo OPTIONAL, --- транслированные NAT IP/порт mail-location [12] Location OPTIONAL, --- местоположение абонента mail-data-content-id [13] DataContentID OPTIONAL --- идентификатор потока } EmailEvent ::= ENUMERATED { email-send(1), email-receive(2), email-download(3), email-logon-attempt(4), email-logon(5), email-logon-failure(6), email-logoff(7), email-partial-download(8) } EmailReceivers ::= SEQUENCE { data SEQUENCE OF UTF8String (SIZE (1 .. 512)) } EmailServers ::= SEQUENCE { data SEQUENCE OF UTF8String (SIZE (1 .. 512)) } --- запись IPDR передачи мгновенных электронных сообщений между пользователями dataImRecord TAGGED ::= { OID { sorm-report-connection-im } DATA SEQUENCE OF DataImRecordContent } DataImRecordContent ::= SEQUENCE { im-cdr-header DataNetworkCdrHeader, --- заголовок IPDR-соединения im-user-login UTF8String (SIZE (1 .. 128)), --- учетная запись пользователя при подключении im-user-password UTF8String (SIZE (1 .. 128)), --- пользовательский пароль при подключении im-sender-screen-name UTF8String (SIZE (1 .. 256)), --- общедоступное имя отправителя im-sender-uin UTF8String (SIZE (1 .. 256)), --- пользовательский идентификатор отправителя (в т.ч. для чата сервера, предназначенного для отправки мгновенных сообщений) im-receivers ImReceivers, --- список получателей сообщения im-size INTEGER (0 .. 4294967295), --- размер данных сессии, байт im-term-cause INTEGER (0 .. 16384), --- причина завершения соединения im-protocol [0] IMProtocol OPTIONAL, im-abonent-id [1] UTF8String (SIZE (0 .. 64)) OPTIONAL, --- идентификатор абонента im-event [5] ImEvent OPTIONAL, im-message [10] UTF8String OPTIONAL, --- текстовое содержание сообщения абонента im-nat-info [11] SEQUENCE OF NetworkPeerInfo OPTIONAL, --- транслированные NAT IP/порт im-location [12] Location OPTIONAL, --- местоположение абонента im-data-content-id [13] DataContentID OPTIONAL --- идентификатор потока } ImReceivers ::= SEQUENCE OF ImReceiver ImReceiver ::= SEQUENCE { im-receiver-screen-name UTF8String (SIZE (1 .. 256)), --- общедоступное имя получателя im-receiver-uin UTF8String (SIZE (1 .. 256)) --- пользовательский идентификатор получателя (в т.ч. для сервера, предназначенного для отправки мгновенных сообщений) } ImEvent ::= ENUMERATED { im-undefined(0), im-send(1), im-receive(2) } --- запись IPDR передачи файловых данных dataFileTransferRecord TAGGED ::= { OID { sorm-report-connection-file-transfer } DATA SEQUENCE OF DataFileTransferRecordContent } DataFileTransferRecordContent ::= SEQUENCE { file-cdr-header DataNetworkCdrHeader, --- заголовок IPDR-соединения file-server-name UTF8String (SIZE (1 .. 256)), --- название сервера file-user-name UTF8String (SIZE (0 .. 128)), --- имя пользователя, наименование учетной записи file-user-password UTF8String (SIZE (0 .. 256)), --- пользовательский пароль file-server-type BOOLEAN OPTIONAL, --- режим работы файлового сервера (ACTIVE/PASSIVE) file-in-bytes-count INTEGER (0 .. 18446744073709551615), --- объем переданных данных (включает как соединения управления так и передачи данных), байт file-out-bytes-count INTEGER (0 .. 18446744073709551615), --- объем принятых данных (включает как соединения управления так и передачи данных), байт file-term-cause INTEGER (0 .. 16384), --- причина завершения соединения file-abonent-id [0] UTF8String (SIZE (0 .. 64)) OPTIONAL, --- идентификатор абонента file-nat-info [10] SEQUENCE OF NetworkPeerInfo OPTIONAL, --- транслированные NAT IP/порт file-location [11] Location OPTIONAL, --- местоположение абонента file-data-content-id [12] DataContentID OPTIONAL --- идентификатор потока } --- запись IPDR терминального доступа к оборудованию dataTermAccessRecord TAGGED ::= { OID { sorm-report-connection-term-access } DATA SEQUENCE OF DataTermAccessRecordContent } DataTermAccessRecordContent ::= SEQUENCE { term-cdr-header DataNetworkCdrHeader, --- заголовок IPDR-соединения term-in-bytes-count INTEGER (0 .. 18446744073709551615), --- объем переданных данных (включает как соединения управления так и передачи данных), байт term-out-bytes-count INTEGER (0 .. 18446744073709551615), --- объем принятых данных (включает как соединения управления так и передачи данных), байт term-protocol ENUMERATED { --- протокол удаленного доступа к оборудованию telnet(0), ssh(1), scp(2) } OPTIONAL, term-abonent-id [0] UTF8String (SIZE (0 .. 64)) OPTIONAL, --- идентификатор абонента term-nat-info [10] SEQUENCE OF NetworkPeerInfo OPTIONAL, --- транслированные NAT IP/порт term-location [11] Location OPTIONAL, --- местоположение абонента term-data-content-id [12] DataContentID OPTIONAL --- идентификатор потока sni[13] UTF8String (SIZE (0 .. 128)) OPTIONAL ---SNI/CN } --- запись IPDR прочих данных, принимаемых, получаемых пользователем при помощи закрытых протоколов обмена dataRawFlowsRecord TAGGED ::= { OID { sorm-report-connection-raw-flows } DATA SEQUENCE OF DataRawFlowsRecordContent } DataRawFlowsRecordContent ::= SEQUENCE { flow-cdr-header DataNetworkCdrHeader, --- заголовок IPDR-соединения flow-in-bytes-count INTEGER (0 .. 18446744073709551615), --- объем переданных данных (включает как соединения управления так и передачи данных), байт flow-out-bytes-count INTEGER (0 .. 18446744073709551615), --- объем принятых данных (включает как соединения управления так и передачи данных), байт flow-protocol ENUMERATED { --- протокол передачи данных ip(0), udp(1), tcp(2) } OPTIONAL, flow-abonent-id [0] UTF8String (SIZE (0 .. 64)) OPTIONAL, --- идентификатор абонента flow-nat-info [10] SEQUENCE OF NetworkPeerInfo OPTIONAL, --- транслированные NAT IP/порт flow-location [11] Location OPTIONAL, --- местоположение абонента flow-data-content-id [12] DataContentID OPTIONAL --- идентификатор потока sni[13] UTF8String (SIZE (0 .. 128)) OPTIONAL ---SNI/CN } --- запись IPDR HTTP-обращения к информационному ресурсу сети связи (сайт, портал) dataResourceRecord TAGGED ::= { OID { sorm-report-connection-resource } DATA SEQUENCE OF DataResourceRecordContent } DataResourceRecordContent ::= SEQUENCE { res-cdr-header DataNetworkCdrHeader, --- заголовок IPDR-соединения res-url UTF8String (SIZE (1 .. 8192)), --- Наименование информационного ресурса res-bytes-count INTEGER (0 .. 18446744073709551615), --- объем принятых и переданных данных в соединении (включает как соединения управления так и передачи данных), байт res-term-cause INTEGER (0 .. 16384), --- причина завершения соединения res-aaa-info [0] IP-AAAInformation OPTIONAL, --- пользовательские реквизиты входа в информационный ресурс res-http-method [1] HttpMethod OPTIONAL, --- http метод res-abonent-id [2] UTF8String (SIZE (0 .. 64)) OPTIONAL, --- идентификатор абонента res-nat-info [10] SEQUENCE OF NetworkPeerInfo OPTIONAL, --- транслированные NAT IP/порт res-location [11] Location OPTIONAL, --- местоположение абонента res-data-content-id [12] DataContentID OPTIONAL --- идентификатор потока } --- запись IPDR голосовой связи посредством сети передачи данных dataVoipRecord TAGGED ::= { OID { sorm-report-connection-voip } DATA SEQUENCE OF DataVoipRecordContent } DataVoipRecordContent ::= SEQUENCE { voip-cdr-header DataNetworkCdrHeader, --- заголовок CDR-соединения voip-session-id UTF8String (SIZE (0..64)), --- идентификатор сессии/call-id voip-conference-id UTF8String (SIZE (1..64)), --- идентификатор конференции voip-duration INTEGER (0 .. 864000), --- длительность разговора, сек. voip-originator-name UTF8String (SIZE (1 .. 512)), --- общедоступное имя инициатора связи voip-call-type-id INTEGER (0 .. 4294967295), --- способ подключения voip-calling-number DataVoipNumber, --- номер вызывающего абонента voip-called-number DataVoipNumber, --- номер вызываемого абонента voip-in-bytes-count INTEGER (0 .. 18446744073709551615), --- объем переданных данных (включает как соединения управления так и передачи данных), байт voip-out-bytes-count INTEGER (0 .. 18446744073709551615), --- объем принятых данных (включает как соединения управления так и передачи данных), байт voip-fax BOOLEAN, --- была попытка передачи факсовой информации (T.38) voip-term-cause INTEGER (0 .. 16384), --- причина завершения соединения inbound-bunch [0] Bunch OPTIONAL, --- входящий пучок outbound-bunch [1] Bunch OPTIONAL, --- исходящий пучок voip-gateways [2] SEQUENCE OF IPAddress OPTIONAL, --- идентификаторы медиашлюзов, обслуживших соединение voip-protocol [3] VoipProtocol OPTIONAL, supplement-service-id [4] INTEGER (0 .. 4294967295) OPTIONAL, --- ДВО при соединении voip-abonent-id [5] UTF8String (SIZE (0 .. 64)) OPTIONAL, --- идентификатор абонента voip-nat-info [10] SEQUENCE OF NetworkPeerInfo OPTIONAL, --- транслированные NAT IP/порт voip-location [11] Location OPTIONAL, --- местоположение абонента voip-event [12] VoIPEvent OPTIONAL, --- тип события voip-data-content-id [13] DataContentID OPTIONAL --- идентификатор потока } VoIPEvent ::= ENUMERATED { outgoing (0), --- исходящее incoming (1), --- входящее unknown (2) --- направление неизвестно } --- запись IPDR трансляции сетевых адресов dataAddressTranslationRecord TAGGED ::= { OID { sorm-report-connection-address-translations } DATA SEQUENCE OF DataAddressTranslationRecordContent } DataAddressTranslationRecordContent ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения point-id INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получена запись о соединении translation-time DateAndTime, --- дата и время трансляции record-type ENUMERATED { --- тип записи о трансляции сетевого адреса session-start (0), --- начало сессии трансляции session-end (1) --- окончание сессии трансляции }, private-ip NetworkPeerInfo, --- внутренний адрес public-ip NetworkPeerInfo, --- внешний адрес destination-ip NetworkPeerInfo, --- адрес назначения translation-type ENUMERATED { --- тип трансляции сетевых адресов static-nat (0), --- статическая dynamic-nat (1), --- динамическая source-nat (2), --- источника destination-nat (3), --- получателя pat (4) --- адрес-порт --- Data network header DataNetworkCdrHeader ::= SEQUENCE { id TAGGED.&id ({DataNetworkHeaderVariants}), data TAGGED.&Data ({DataNetworkHeaderVariants}{@id}) } DataNetworkHeaderVariants TAGGED ::= { dataNetworkCdrHeader } dataNetworkCdrHeader TAGGED ::= { OID { sorm-report-connection-ipdr-header } DATA DataNetworkCdrHeaderData } DataNetworkCdrHeaderData ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения begin-connection-time DateAndTime, --- дата и время начала соединения end-connection-time DateAndTime, --- дата и время завершения соединения client-info NetworkPeerInfo, --- информация о клиенте (IP/порт) server-info NetworkPeerInfo, --- информация о сервере (IP/порт) protocol-code INTEGER (0.. 65535), --- код протокола в соответствии с RFC1700 либо номер порта для TCP/UDP point-id INTEGER (0 .. 1000) OPTIONAL --- идентификатор точки подключения к сети передачи данных, с которой получена запись о соединении } --- информация о входе в ресурс IP-AAAInformation ::= SEQUENCE { username UTF8String (SIZE (0..64)), --- пользоватеьлский login aaaResult IP-AAAResult OPTIONAL --- результат операции входа } --- результат операции входа в ресурс IP-AAAResult ::= ENUMERATED { aaaUnknown(1), --- результат неизвестен aaaFailed(2), --- неудачная попытка входа aaaSucceeded(3) --- успешный вход } END ___________________________________________________________________________ ReportsLocations.asn ReportsLocations DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS LocationReport; IMPORTS DateAndTime FROM Sorm TelcoID FROM Dictionaries Location FROM Locations ReportedIdentifier FROM ReportedIdentifiers; LocationReport ::= SEQUENCE OF ValidateLocationRecord ValidateLocationRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи структурного подразделения connection-time DateAndTime, --- время определения местоположения ident ReportedIdentifier, --- идентификатор мобильного абонента connection-location Location --- местоположение мобильного абонента } END ___________________________________________________________________________ ReportsNonFormalized.asn ReportsNonFormalized DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS NonFormalizedReport; IMPORTS EntityId, NonFormalizedEntityAttributeData FROM TasksNonFormalized StandardInterval FROM ReportsPresense; --- отчет задачи по обработке неформализованных данных NonFormalizedReport ::= CHOICE { nonformalized-report [0] NonFormalizedRecords, --- отчет по задаче обработки неформализованных данных nonformalized-presense [1] NonFormalizedPresenseInfo --- отчет по наличию неформализованных данных заданного вида } NonFormalizedRecords ::= SEQUENCE OF NonFormalizedRecord NonFormalizedPresenseInfo ::= SEQUENCE OF StandardInterval --- диапазоны времени за которые есть неформализованные данные --- запись неформализованных данных NonFormalizedRecord ::= SEQUENCE OF NonFormalizedEntityAttributeData END ___________________________________________________________________________ ReportsPayments.asn ReportsPayments DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS PaymentsReport; IMPORTS TAGGED, sorm-report-payment-bank-transaction, sorm-report-payment-express-pays, sorm-report-payment-terminal-pays, sorm-report-payment-service-center, sorm-report-payment-cross-account, sorm-report-payment-telephone-card, sorm-report-payment-balance-fillups, sorm-report-payment-bank-division-transfer, sorm-report-payment-bank-card-transfer, sorm-report-payment-bank-account-transfer FROM Classification DateAndTime FROM Sorm TelcoID FROM Dictionaries Location FROM Locations ReportedIdentifier FROM ReportedIdentifiers ReportedAddress FROM Addresses; PaymentsReport ::= SEQUENCE { id TAGGED.&id ({ReportedPaymentsVariants}), data TAGGED.&Data ({ReportedPaymentsVariants}{@id}) } --- варианты запрашиваемых параметров связей ReportedPaymentsVariants TAGGED ::= { bankTransactionReport |expressCardReport |publicTerminalReport |serviceCenterReport |crossAccountReport |telephoneCardReport |balanceFillupReport |bankDivisionTransferReport |bankCardTransferReport |bankAccountTransferReport } --- отчет задачи на поиск пополнения баланса через банковский перевод bankTransactionReport TAGGED ::= { OID { sorm-report-payment-bank-transaction } DATA SEQUENCE OF BankTransactionRecord } BankTransactionRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения device-id ReportedIdentifier, --- идентификатор абонента date-time-fillup DateAndTime, --- время и дата пополнения баланса bank-account UTF8String (SIZE (1 .. 64)), --- номер банковского счета, с которого совершен платеж bank-name UTF8String (SIZE (1 .. 512)), --- наименование банка, со счета которого совершен перевод bank-address ReportedAddress, --- адрес банка, со счета которого совершен перевод amount UTF8String (SIZE (1 .. 64)) --- сумма перевода } --- отчет задачи на поиск пополнения баланса через карты экспресс-оплаты expressCardReport TAGGED ::= { OID { sorm-report-payment-express-pays } DATA SEQUENCE OF ExpressPaysRecord } ExpressPaysRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения device-id ReportedIdentifier, --- идентификатор абонента date-time-fillup DateAndTime, --- время и дата пополнения баланса card-number UTF8String (SIZE (1 .. 64)), --- номер карты amount UTF8String (SIZE (1 .. 64)) --- сумма перевода } --- отчет задачи на поиск пополнения баланса через терминалы моментальных платежей publicTerminalReport TAGGED ::= { OID { sorm-report-payment-terminal-pays } DATA SEQUENCE OF PublicTerminalRecord } PublicTerminalRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения device-id ReportedIdentifier, --- идентификатор абонента date-time-fillup DateAndTime, --- время и дата пополнения баланса terminal-id UTF8String (SIZE (1 .. 64)), --- идентификатор терминала terminal-number NumericString (SIZE (2 .. 20)), --- номер терминала terminal-address ReportedAddress, --- адрес терминала amount UTF8String (SIZE (1 .. 64)), --- сумма перевода location Location OPTIONAL --- адрес совершения платежа } --- отчет задачи на поиск пополнения баланса через центры обслуживания клиентов serviceCenterReport TAGGED ::= { OID { sorm-report-payment-service-center } DATA SEQUENCE OF ServiceCenterRecord } ServiceCenterRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения device-id ReportedIdentifier, --- идентификатор абонента date-time-fillup DateAndTime, --- время и дата пополнения баланса center-id UTF8String (SIZE (1 .. 64)), --- идентификатор центра обслуживания клиентов center-address ReportedAddress, --- адрес центра обслуживания клиентов amount UTF8String (SIZE (1 .. 64)) --- сумма перевода } --- отчет задачи на поиск пополнения баланса посредством снятия денег со счета другого абонента crossAccountReport TAGGED ::= { OID { sorm-report-payment-cross-account } DATA SEQUENCE OF CrossAccountRecord } CrossAccountRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения device-id ReportedIdentifier, --- идентификатор абонента-получателя платежа date-time-fillup DateAndTime, --- время и дата пополнения баланса donanted-id ReportedIdentifier, --- идентификатор абонента-отправителя платежа amountUTF8String (SIZE (1 .. 64)) --- сумма перевода } --- отчет задачи на поиск пополнения баланса через телефонные карты telephoneCardReport TAGGED ::= { OID { sorm-report-payment-telephone-card } DATA SEQUENCE OF ValidateTelephoneCardRecord } ValidateTelephoneCardRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения activator-device-id ReportedIdentifier, --- идентификатор абонента, активировавшего карту date-time-fillup DateAndTime, --- время и дата пополнения баланса card-number NumericString (SIZE (2 .. 20)), --- номер телефонной карты amount UTF8String (SIZE (1 .. 64)) --- сумма перевода } --- отчет задачи на поиск пополнения баланса личного счета абонента balanceFillupReport TAGGED ::= { OID { sorm-report-payment-balance-fillups } DATA SEQUENCE OF ValidateBalanceFillupRecord } ValidateBalanceFillupRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения pay-type-id INTEGER (0 .. 4294967295), --- тип платежа (способ оплаты) device-id ReportedIdentifier, --- идентификатор абонента date-time-fillup DateAndTime, --- время и дата пополнения баланса amount UTF8String (SIZE (1 .. 64)), --- сумма перевода pay-parameters UTF8String (SIZE (1 .. 512)) OPTIONAL --- "неструктурированная" информация } --- отчет задачи по переводу средств со счета абонента для их снятия в отделении банка bankDivisionTransferReport TAGGED ::= { OID { sorm-report-payment-bank-division-transfer } DATA SEQUENCE OF ValidateBankDivisonTransferRecord } ValidateBankDivisonTransferRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения donanted-id ReportedIdentifier, --- идентификатор инициатора перевода средств date-time-fillup DateAndTime, --- время и дата перевода средств person-recieved UTF8String(SIZE (1 .. 512)), --- получатель платежа (ФИО и прочая неструктурированная информация) bank-name UTF8String (SIZE (1 .. 256)), --- наименование банка получателя bank-division-name UTF8String (SIZE (1 .. 512)), --- наименование отделения банка получателя bank-division-address ReportedAddress, --- адрес отделения банка получателя amount UTF8String (SIZE (1 .. 64)) --- сумма перевода } --- отчет задачи по переводу средств со счета абонента на банковскую карту bankCardTransferReport TAGGED ::= { OID { sorm-report-payment-bank-card-transfer } DATA SEQUENCE OF ValidateBankCardTransferRecord } ValidateBankCardTransferRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения donanted-id ReportedIdentifier, --- идентификатор инициатора перевода средств bank-card-id NumericString (SIZE (1 .. 12)), --- номер банковской карты получателя перевода date-time-fillup DateAndTime, --- время и дата перевода средств amount UTF8String (SIZE (1 .. 64)) --- сумма перевода } --- отчет задачи по переводу средств со счета абонента на счет в банке bankAccountTransferReport TAGGED ::= { OID { sorm-report-payment-bank-account-transfer } DATA SEQUENCE OF ValidateBankAccountTransferRecord } ValidateBankAccountTransferRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения donated-id ReportedIdentifier, --- идентификатор инициатора перевода средств bank-name UTF8String (SIZE (1 .. 256)), --- наименование банка получателя bank-account UTF8String (SIZE (1 .. 64)), --- номер банковского счета получателя date-time-fillup DateAndTime, --- время и дата перевода средств amount UTF8String (SIZE (1 .. 64)) --- сумма перевода } END ___________________________________________________________________________ ReportsPresense.asn ReportsPresense DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS PresenseReport, StandardInterval; IMPORTS FindRange, DateAndTime FROM Sorm TelcoID FROM Dictionaries Location FROM Locations ReportedIdentifier FROM ReportedIdentifiers NetworkType FROM NetworkIdentifiers TAGGED, sorm-report-presense-abonents, sorm-report-presense-connections, sorm-report-presense-payments, sorm-report-presense-dictionaries, sorm-report-presense-locations FROM Classification; ---отчет по запросу наличия информации PresenseReport ::= SEQUENCE { id TAGGED.&id ({ReportedPresensesVariants}), data TAGGED.&Data ({ReportedPresensesVariants}{@id}) } ReportedPresensesVariants TAGGED ::= { subsPresence |connectionsPresence |paymentsPresense |dictionariesPresence |locationPresence } --- отчет по наличию информации по абонентам и их идентификаторам. --- Для каждого стандарта может быть указано более одного, либо ни --- одногоинтервала (фактические периоды наличия информации); subsPresence TAGGED ::= { OID { sorm-report-presense-abonents } DATA SEQUENCE OF StandardInterval } -- отчет по наличию информации по соединениям. Для каждого стандарта может быть указано более одного, либо ни одного, интервала (фактические периоды наличия информации); connectionsPresence TAGGED ::= { OID { sorm-report-presense-connections } DATA SEQUENCE OF ConnectionsPresenseRecord } ConnectionsPresenseRecord ::= SEQUENCE { standard-interval StandardInterval, data-type ENUMERATED { --- вид соединений передачи данных, информация по которым есть в ИС СОРМ telephone-pstn (0), --- телефонные ТФоП-соединения telephone-mobile (1), --- телефонные соединения мобильной связи pager (2), --- соединения сети персонального радиовызова data-aaa (3), --- подключения/отключения абонента к сети связи data-resource (4), --- HTTP-обращения к информационному ресурсу сети связи (сайт, портал) data-email (5), --- передача почтовых сообщений data-im (6), --- передача мгновенных электронных сообщений между пользователями data-voip (7), --- голосовая связь посредством сети передачи данных data-file (8), --- передача файловых данных data-term (9), --- терминальный доступ к оборудованию data-raw (10), --- иные данные, принимаемые, получаемые пользователем при помощи закрытых протоколов обмена data-address-translations (11) --- трансляции сетевых адресов } } paymentsPresense TAGGED ::= { OID { sorm-report-presense-payments } DATA SEQUENCE OF StandardInterval --- описание имеющейся информации по пополнениям балансов абонентов } --- отчет о наличии информации справочников в ИС. Если какой-либо из справочников не публикуется ИС СОРМ, запись о нем отсутствует dictionariesPresence TAGGED ::= { OID { sorm-report-presense-dictionaries } DATA SEQUENCE OF DictionaryInfo } --- запись отчета о наличии информации справочников DictionaryInfo ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения dict ObjectDescriptor, --- тип справочника, по которому есть информация --- (идентификатор запроса справочника) (Requested...) count INTEGER (1 .. 4294967295), --- количество записей в справочнике change-dates FindRange --- минимальное и максимальное дата/время изменения записей в справочнике } --- отчет по наличию информации по местоположению абонентов locationPresence TAGGED ::= { OID { sorm-report-presense-locations } DATA SEQUENCE OF StandardInterval } --- интервал времени, на котором имеются данные по абонентам, соединениям и платежам, в рамках стандарта связи StandardInterval ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или структурного подразделения standard NetworkType, --- стандарт связи, информация по которому имеется в ИС range FindRange, --- интервал времени, на который имеются данные в ИС count INTEGER OPTIONAL --- количество записей } END ___________________________________________________________________________ RequestedAbonents.asn RequestedAbonents DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RequestedAbonent; IMPORTS TAGGED, sorm-request-abonent-person, sorm-request-abonent-organization FROM Classification RequestedAddress FROM Addresses; RequestedAbonent ::= SEQUENCE { id TAGGED.&id ({RequestedAbonentVariants}), data TAGGED.&Data ({RequestedAbonentVariants}{@id}) } --- варианты запрашиваемых идентификаторов RequestedAbonentVariants TAGGED ::= { requestedPerson | --- физическое лицо requestedOrganization --- юридическое лицо - организация } --- поля параметра запроса на физическое лицо requestedPerson TAGGED ::= { OID { sorm-request-abonent-person } DATA RequestedPerson } RequestedPerson ::= SEQUENCE { given-name [0] UTF8String (SIZE (1 .. 256)) OPTIONAL, --- имя initial [1] UTF8String (SIZE (1 .. 256)) OPTIONAL, --- отчество family-name [2] UTF8String (SIZE (1 .. 256)) OPTIONAL, --- фамилия passport-info [3] RequestedPassport OPTIONAL, --- паспортные данные address [4] RequestedAddress OPTIONAL, --- адресные данные icc [5] NumericString (SIZE (10 .. 20)) OPTIONAL, --- идентификатор SIM-карты абонента contract [6] UTF8String (SIZE (1 .. 64)) OPTIONAL --- номер договора } --- поля паспортных данных RequestedPassport ::= SEQUENCE { doc-type-id [0] INTEGER (0 .. 65535) OPTIONAL, --- идентификатор типа документа, удостоверяющего личность passport-serial [1] UTF8String (SIZE (1..16)) OPTIONAL, --- серия паспорта passport-number [2] NumericString (SIZE (1..16)) OPTIONAL --- номер паспорта } -- поля параметра запроса на юридическое лицо requestedOrganization TAGGED ::= { OID { sorm-request-abonent-organization } DATA RequestedOrganization } RequestedOrganization ::= SEQUENCE { full-name [0] UTF8String (SIZE (1 .. 256)) OPTIONAL, --- полное наименование организации address [1] RequestedAddress OPTIONAL, --- юридический адрес организации inn [2] NumericString (SIZE (1 .. 64)) OPTIONAL, --- ИНН internal-user [3] UTF8String (SIZE (1 .. 64)) OPTIONAL, --- внутренний пользователь contract [4] UTF8String (SIZE (1 .. 64)) OPTIONAL --- номер договора } END ___________________________________________________________________________ RequestedConnections.asn RequestedConnections DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RequestedConnection; IMPORTS TAGGED, sorm-request-connection-pstn, sorm-request-connection-mobile, sorm-request-connection-entrance, sorm-request-connection-aaa-login, sorm-request-connection-resource, sorm-request-connection-email, sorm-request-connection-im, sorm-request-connection-voip, sorm-request-connection-file-transfer, sorm-request-connection-term-access, sorm-request-connection-raw-flows, sorm-request-connection-address-translations FROM Classification requestedPagerIdentifier, requestedPstnIdentifier, requestedGsmIdentifier, requestedCdmaIdentifier FROM RequestedIdentifiers PhoneAbonentType FROM Dictionaries Bunch, DataNetworkEquipment, IPAddress, NetworkPeerInfo, DataVoipNumber, VoipProtocol, IMProtocol, HttpMethod FROM NetworkIdentifiers Location FROM Locations; RequestedConnection ::= SEQUENCE { id TAGGED.&id ({RequestedConnectionVariants}), data TAGGED.&Data ({RequestedConnectionVariants}{@id}) } --- варианты запрашиваемых параметров связей RequestedConnectionVariants TAGGED ::= { requestedPagerIdentifier |requestedConnectionPstn --- параметры соединений абонента ТФОП |requestedConnectionMobile --- параметры соединений абонента сети мобильной связи |requestedConnectionEntrance --- параметры соединений подключения к сети связи |requestedAAALogin |requestedResource |requestedEmail |requestedIm |requestedVoip |requestedFileTransfer |requestedTermAccess |requestedRawFlows |requestedAddressTranslations } requestedConnectionEntrance TAGGED ::= { OID { sorm-request-connection-entrance } DATA CHOICE { directory-number [0] UTF8String (SIZE (2 .. 32)), --- телефонный номер в международном формате imsi [1] NumericString (SIZE (2 .. 18)), --- идентификатор мобильного абонента ip-address [2] IPAddress, --- IP-адрес абонента mac [3] OCTET STRING (SIZE (6)) --- MAC-адрес устройства абонента } } --- параметры соединений абонента ТФОП requestedConnectionPstn TAGGED ::= { OID { sorm-request-connection-pstn } DATA CHOICE { duration [0] INTEGER (0 .. 86399), --- время соединения call-type-id [1] INTEGER (0 .. 4294967295), --- тип соединения in-abonent-type [2] PhoneAbonentType, --- тип вызывающего абонента out-abonent-type [3] PhoneAbonentType, --- тип вызываемого абонента switch-id [4] UTF8String (SIZE (1 .. 128)), --- код коммутатора обслужившего вызов inbound-bunch [5] INTEGER (0 .. 4294967295), --- входящий пучок outbound-bunch [6] INTEGER (0 .. 4294967295), --- исходящий пучок border-switch-id [7] UTF8String (SIZE (1 .. 128)), --- код пограничного коммутатора term-cause [8] INTEGER (0 .. 16384), --- причина завершения соединения supplement-service-id [9] INTEGER (0 .. 4294967295), --- ДВО при соединении phone-card-number [10] NumericString (SIZE (1.. 20)), --- номер телефонной карты in-info [11] RequestedConnectionPstnIdentifier, --- идентификаторы вызывающего абонента out-info [12] RequestedConnectionPstnIdentifier, --- идентификаторы вызываемого абонента forwarding-identifier [13] UTF8String (SIZE (2 .. 32)), --- телефонный номер при переадресации message [20] UTF8String --- текстовое содержание сообщения абонента } } -- Идентификаторы PSTN RequestedConnectionPstnIdentifier ::= SEQUENCE { id TAGGED.&id ({RequestedConnectionPstnIdentifierVariants}), data TAGGED.&Data ({RequestedConnectionPstnIdentifierVariants}{@id}) } RequestedConnectionPstnIdentifierVariants TAGGED ::= { requestedPstnIdentifier } requestedConnectionMobile TAGGED ::= { OID { sorm-request-connection-mobile } DATA CHOICE { duration [0] INTEGER (0 .. 86399), --- время соединения call-type-id [1] INTEGER (0 .. 4294967295), --- тип соединения supplement-service-id [2] INTEGER (0 .. 4294967295), --- ДВО при соединении in-abonent-type [3] PhoneAbonentType, --- тип вызывающего абонента out-abonent-type [4] PhoneAbonentType, --- тип вызываемого абонента switch-id [5] UTF8String (SIZE (1 .. 128)), --- код коммутатора обслужившего соединения --- или номер SMS центра если SMS inbound-bunch [6] Bunch, --- входящий пучок outbound-bunch [7] Bunch, --- исходящий пучок border-switch-id [8] UTF8String (SIZE (1 .. 128)), --- код пограничного коммутатора roaming-partner-id [9] INTEGER (0 .. 4294967295), --- код роумингового партнера term-cause [10] INTEGER (0 .. 16384), --- причина завершения соединения in-info [11] RequestedConnectionMobileIdentifier, --- идентификаторы вызывающего абонента in-end-location [12] Location, --- местоположение вызывающего абонента на конец вызова in-begin-location [13] Location, --- местоположение вызывающего абонента на начало вызова dialed-digits [14] UTF8String (SIZE (1 .. 128)), --- набранный номер вызываемого абонента out-info [15] RequestedConnectionMobileIdentifier, --- идентификаторы вызываемого абонента out-begin-location [16] Location, --- местоположение вызываемого абонента на начало вызова out-end-location [17] Location, --- местоположение вызываемого абонента на конец вызова forwarding-identifier [18] UTF8String (SIZE (2 .. 32)), --- телефонный номер при переадресации message [40] UTF8String --- текстовое содержание сообщения абонента } } -- Идентификаторы мобильных абонентов RequestedConnectionMobileIdentifier ::= SEQUENCE { id TAGGED.&id ({RequestedConnectionMobileIdentifierVariants}), data TAGGED.&Data ({RequestedConnectionMobileIdentifierVariants}{@id}) } RequestedConnectionMobileIdentifierVariants TAGGED ::= { requestedGsmIdentifier | requestedCdmaIdentifier } requestedAAALogin TAGGED ::= { OID { sorm-request-connection-aaa-login } DATA CHOICE { point-id [0] INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получены записи login-type [1] ENUMERATED { --- тип соединения connect (0), --- подключение к сети передачи данных disconnect (1), --- отключение от сети передачи данных update (2) }, user-equipment [2] DataNetworkEquipment, --- идентификатор пользовательского оборудования allocated-ip [3] IPAddress, --- выделенный динамический IP-адрес user-name [4] UTF8String (SIZE (1 .. 128)), --- имя пользователя (login) user-password [5] UTF8String (SIZE (1 .. 128)), --- пользовательский пароль connect-type [6] INTEGER (1 .. 65535), --- код протокола в соответствии с RFC1700 либо номер порта для TCP/UDP calling-number [7] UTF8String (SIZE (2 .. 32)), --- вызывающий номер called-number [8] UTF8String (SIZE (2 .. 32)), --- вызываемый номер nas [9] NetworkPeerInfo, --- IP-адрес/порт NAS-сервера apn [10] UTF8String (SIZE (1 .. 128)), --- наименование точки доступа (Access Point Name) sgsn-ip [11] IPAddress, --- IP-адрес GPRS/EDGE SGSN ggsn-ip [12] IPAddress, --- IP-адрес GPRS/EDGE GGSN service-area-code [13] INTEGER (0 .. 65535), --- код зоны обслуживания (SAC) GPRS/EDGE location-start [14] Location, --- базовая станция, через которую установлено соединение (передача данных посредством подвижной сети связи) location-end [15] Location, --- базовая станция, через которую завершено соединение (передача данных посредством подвижной сети связи) phone-card-number [16] NumericString (SIZE (20)), --- номер телефонной карты imsi [17] NumericString (SIZE (2 .. 18)), --- IMSI мобильного абонента imei [18] NumericString (SIZE (2 .. 18)), --- идентификатор мобильной станции абонента esn [19] NumericString (SIZE (2 .. 18)), --- идентификатор мобильной станции абонента pool-number [20] UTF8String(SIZE (1 .. 64)), --- номер модемного пула mcc [21] UTF8String, mnc [22] UTF8String } } requestedResource TAGGED ::= { OID { sorm-request-connection-resource } DATA CHOICE { point-id [0] INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получены записи client-info [1] NetworkPeerInfo, --- идентификатор абонента сети передачи данных server-info [2] NetworkPeerInfo, --- идентификатор сервера сети передачи данных url [3] UTF8String (SIZE (1 .. 8192)), --- Наименование информационного ресурса term-cause [4] INTEGER (0 .. 16384), --- причина завершения соединения http-method [5] HttpMethod, abonent-id [6] UTF8String (SIZE (0 .. 64)), nat-info [10] NetworkPeerInfo, --- транслированные NAT IP/порт location [11] Location --- местоположение абонента } } requestedEmail TAGGED ::= { OID { sorm-request-connection-email } DATA CHOICE { point-id [0] INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получены записи client-info [1] NetworkPeerInfo, --- идентификатор абонента сети передачи данных server-info [2] NetworkPeerInfo, --- идентификатор сервера сети передачи данных sender [3] UTF8String (SIZE (1 .. 512)), --- отправитель почтового сообщения receiver [4] UTF8String (SIZE (1 .. 512)), --- получатель почтового сообщения cc [5] UTF8String (SIZE (1 .. 512)), --- получатель-копия почтового сообщения subject [6] UTF8String (SIZE (1 .. 2048)), --- тема почтового сообщения attachements [7] BOOLEAN, --- наличие прикрепленных файлов в письме (да/нет) mail-server [8] UTF8String (SIZE (1 .. 512)), --- текстовое наименование сервера, через который отправлено письмо (в т.ч. сервер веб-почты) term-cause [9] INTEGER (0 .. 16384), --- причина завершения соединения abonent-id [10] UTF8String (SIZE (0 .. 64)), message [20] UTF8String, --- текстовое содержание сообщения абонента nat-info [21] NetworkPeerInfo, --- транслированные NAT IP/порт location [22] Location --- местоположение абонента } } requestedIm TAGGED ::= { OID { sorm-request-connection-im } DATA CHOICE { point-id [0] INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получены записи client-info [1] NetworkPeerInfo, --- идентификатор абонента сети передачи данных server-info [2] NetworkPeerInfo, --- идентификатор сервера сети передачи данных user-login [3] UTF8String (SIZE (1 .. 128)), --- учетная запись пользователя при подключении user-password [4] UTF8String (SIZE (1 .. 128)), --- пользовательский пароль при подключении sender-screen-name [5] UTF8String (SIZE (1 .. 256)), --- общедоступное имя отправителя sender-uin [6] UTF8String (SIZE (1 .. 256)), --- пользовательский идентификатор отправителя (в т.ч. для сервера, предназначенного для отправки мнгновенных сообщений) receiver-screen-name [7] UTF8String (SIZE (1 .. 256)), --- общедоступное имя получателя receiver-uin [8] UTF8String (SIZE (1 .. 256)), --- пользовательский идентификатор получателя (в т.ч. для сервера, предназначенного для отправки мнгновенных сообщений) protocol [9] IMProtocol, term-cause [10] INTEGER (0 .. 16384), --- причина завершения соединения abonent-id [11] UTF8String (SIZE (0 .. 64)), message [20] UTF8String, --- текстовое содержание сообщения абонента nat-info [21] NetworkPeerInfo, --- транслированные NAT IP/порт location [22] Location --- местоположение абонента } } requestedVoip TAGGED ::= { OID { sorm-request-connection-voip } DATA CHOICE { point-id [0] INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получены записи client-info [1] NetworkPeerInfo, --- идентификатор абонента сети передачи данных server-info [2] NetworkPeerInfo, --- идентификатор сервера сети передачи данных duration [3] INTEGER (0 .. 864000), --- длительность разговора, сек. originator-name [4] UTF8String (SIZE (1 .. 512)), --- общедоступное имя инициатора связи call-type-id [5] INTEGER (0 .. 4294967295), --- способ подключения voip-calling-number [6] DataVoipNumber, --- номер вызывающего абонента voip-called-number [7] DataVoipNumber, --- номер вызываемого абонента inbound-bunch [8] Bunch, --- входящий пучок outbound-bunch [9] Bunch, --- исходящий пучок conference-id [10] UTF8String (SIZE (1 .. 64)), --- идентификатор конференции protocol [11] VoipProtocol, term-cause [12] INTEGER (0 .. 16384), --- причина завершения соединения abonent-id [13] UTF8String (SIZE (0 .. 64)), nat-info [20] NetworkPeerInfo, --- транслированные NAT IP/порт location [21] Location --- местоположение абонента } } requestedFileTransfer TAGGED ::= { OID { sorm-request-connection-file-transfer } DATA CHOICE { point-id [0] INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получены записи client-info [1] NetworkPeerInfo, --- идентификатор абонента сети передачи данных server-info [2] NetworkPeerInfo, --- идентификатор сервера сети передачи данных server-name [3] UTF8String (SIZE (1 .. 256)), --- название сервера user-name [4] UTF8String (SIZE (1 .. 128)), --- имя пользователя, наименование учетной записи user-password [5] UTF8String (SIZE (1 .. 256)), --- пользовательский пароль term-cause [6] INTEGER (1 .. 16384), --- причина завершения соединения abonent-id [7] UTF8String (SIZE (0 .. 64)), nat-info [20] NetworkPeerInfo, --- транслированные NAT IP/порт location [21] Location --- местоположение абонента } } requestedTermAccess TAGGED ::= { OID { sorm-request-connection-term-access } DATA CHOICE { point-id [0] INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получены записи client-info [1] NetworkPeerInfo, --- идентификатор абонента сети передачи данных server-info [2] NetworkPeerInfo, --- идентификатор сервера сети передачи данных abonent-id [3] UTF8String (SIZE (0 .. 64)), nat-info [10] NetworkPeerInfo, --- транслированные NAT IP/порт location [11] Location --- местоположение абонента sni [13] UTF8String (SIZE (0 .. 128)), --- Поле Server Name Indication/Common Name } } --- идентификаторы для соединений передачи данных (закрытые протоколы обмена) requestedRawFlows TAGGED::= { OID { sorm-request-connection-raw-flows } DATA CHOICE { point-id [0] INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получены записи protocol-code [1] INTEGER (0 .. 65535), --- код протокола в соответствии с RFC1700 client-info [2] NetworkPeerInfo, --- идентификатор абонента сети передачи данных server-info [3] NetworkPeerInfo, --- идентификатор сервера сети передачи данных abonent-id [4] UTF8String (SIZE (0 .. 64)), nat-info [10] NetworkPeerInfo, --- транслированные NAT IP/порт location [11] Location --- местоположение абонента sni [13] UTF8String (SIZE (0 .. 128)), --- SNI/CN } } --- идентификаторы для соединений передачи данных (закрытые протоколы обмена) requestedAddressTranslations TAGGED::= { OID { sorm-request-connection-address-translations } DATA CHOICE { point-id [0] INTEGER (0 .. 1000), --- идентификатор точки подключения к сети передачи данных, с которой получена запись о соединении record-type [2] ENUMERATED { --- тип записи о трансляции сетевого адреса session-start (0), --- начало сессии трансляции session-end (1) --- окончание сессии трансляции }, private-ip [3] NetworkPeerInfo, --- внутренний адрес public-ip [4] NetworkPeerInfo, --- внешний адрес destination-ip [5] NetworkPeerInfo, --- адрес назначения translation-type [6] ENUMERATED { --- тип трансляции сетевых адресов static-nat (0), --- статическая dynamic-nat (1), --- динамическая source-nat (2), --- источника destination-nat (3), --- получателя pat (4) --- адрес-порт } } } END ___________________________________________________________________________ RequestedIdentifiers.asn RequestedIdentifiers DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RequestedIdentifier, requestedPagerIdentifier, requestedPstnIdentifier, requestedGsmIdentifier, requestedCdmaIdentifier ; IMPORTS TAGGED, sorm-request-identifier-pager, sorm-request-identifier-pstn, sorm-request-identifier-gsm, sorm-request-identifier-cdma, sorm-request-identifier-data-network, sorm-request-identifier-voip FROM Classification DataNetworkEquipment, IPAddress FROM NetworkIdentifiers ; RequestedIdentifier ::= SEQUENCE { id TAGGED.&id ({RequestedIdentifierVariants}), data TAGGED.&Data ({RequestedIdentifierVariants}{@id}) } --- варианты запрашиваемых идентификаторов RequestedIdentifierVariants TAGGED ::= { requestedPagerIdentifier | --- идентификатор сети персонального радиовызова requestedPstnIdentifier | --- идентификатор ТФОП requestedGsmIdentifier | --- идентификатор GSM requestedCdmaIdentifier | --- идентификатор CDMA requestedDataNetworkIdentifier | --- идентификатор сети передачи данных requestedVoipIdentifier --- идентификатор voip } --- идентификатор сети персонального радиовызова requestedPagerIdentifier TAGGED ::= { OID { sorm-request-identifier-pager } DATA RequestedPagerIdentifier } RequestedPagerIdentifier ::= NumericString (SIZE (2 .. 18)) --- идентификатор телефонной сети общего пользования requestedPstnIdentifier TAGGED ::= { OID { sorm-request-identifier-pstn } DATA RequestedPstnIdentifier } RequestedPstnIdentifier ::= SEQUENCE { directory-number UTF8String (SIZE (2 .. 32)), --- телефонный номер в международном формате internal-number NumericString (SIZE (1 .. 32)) OPTIONAL --- дополнительный внутренний номер, если есть } -- идентификатор абонента GSM requestedGsmIdentifier TAGGED ::= { OID { sorm-request-identifier-gsm } DATA RequestedGsmIdentifier } RequestedGsmIdentifier ::= CHOICE { directory-number [0] UTF8String (SIZE (2 .. 32)), --- телефонный номер в международном формате imsi [1] NumericString (SIZE (2 .. 18)), --- идентификатор мобильного абонента imei [2] NumericString (SIZE (2 .. 18)) --- идентификатор мобильной станции } -- идентификатор абонента CDMA requestedCdmaIdentifier TAGGED ::= { OID { sorm-request-identifier-cdma } DATA RequestedCdmaIdentifier } RequestedCdmaIdentifier ::= CHOICE { directory-number [0] UTF8String (SIZE (2 .. 32)), --- телефонный номер в международном формате imsi [1] NumericString (SIZE (2 .. 18)), --- идентификатор мобильного абонента esn [2] NumericString (SIZE (2 .. 18)), --- идентификатор мобильной станции min [3] NumericString (SIZE (2 .. 18)) --- идентификатор мобильного абонента (CDMA) } -- Идентификатор сети передачи данных requestedDataNetworkIdentifier TAGGED ::= { OID { sorm-request-identifier-data-network } DATA RequestedDataNetworkIdentifier } RequestedDataNetworkIdentifier ::= CHOICE { user-equipment [0] DataNetworkEquipment, --- идентификатор пользовательского оборудования login [1] UTF8String (SIZE (1 .. 128)), --- имя пользоавателя - login ip-address [2] IPAddress, --- IP адрес e-mail [3] UTF8String (SIZE (1 .. 128)), --- адрес электронной почты phone-number [5] UTF8String (SIZE (2 .. 32)) --- номер телефона } -- Идентификатор voip requestedVoipIdentifier TAGGED ::= { OID { sorm-request-identifier-voip } DATA RequestedVoipIdentifier } RequestedVoipIdentifier ::= CHOICE { ip-address [0] IPAddress, --- IP-адрес абонента originator-name [1] UTF8String (SIZE (1 .. 512)), --- общедоступное имя инициатора связи calling-number [2] UTF8String (SIZE (1 .. 32)) --- номер вызывающего абонента } END ___________________________________________________________________________ Sessions.asn Sessions DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS sessionMessage; IMPORTS TAGGED ,sorm-message-session FROM Classification; sessionMessage TAGGED ::= { OID { sorm-message-session } DATA CHOICE { connect [0] ConnectRequest, --- запрос на открытие сессии connect-response [1] ConnectResponse, --- ответ на запрос открытия сессии adjustment [2] AdjustmentRequest, --- согласование поддерживаемых типов со стороны ПУ adjustment-response [3] AdjustmentResponse, --- ответ на запрос согласования данных disconnect [4] DisconnectRequest, --- запрос на закрытие сессии disconnect-response [5] DisconnectResponse --- ответ на запрос закрытия сессии } } --- запрос создания сессии ConnectRequest ::= SEQUENCE { session-timeout INTEGER (60 .. 2592000), --- максимальное время неактивности max-data-length INTEGER (10 .. 100000), --- максимальная длина блока отчета (в строках) data-packet-window-size INTEGER (4 .. 256), --- окно канала передачи данных --- максимальное число блоков данных, которое может быть --- отправлено без подтверждения приема data-load-timeout INTEGER (1 .. 60), --- таймаут начала передачи блоков отчетов request-response-timeout INTEGER (1 .. 60), --- таймаут ответа на запрос data-packet-response-timeout INTEGER (1 .. 60) --- таймаут подтверждения приема блока данных отчета } -- ответ на запрос создания сессии ConnectResponse ::= SEQUENCE { confirmed-data-packet-window-size INTEGER (4 .. 256), --- подтвержденное окно передачи данных --- то окно, которое может обеспечить ИС СОРМ --- должно быть меньше или равно окну, переданному --- в ConnectRequest confirmed-session-timeout INTEGER (60 .. 2592000), --- подтвержденное максимальное время неактивности --- должно быть больше или равно значению, переданному --- в ConnectRequest confirmed-data-load-timeout INTEGER (1 .. 60), --- подтвержденный таймаут начала передачи блоков отчетов --- должен быть больше или равен значению, переданному --- в ConnectRequest confirmed-request-response-timeout INTEGER (1 .. 60), --- подтвержденный таймаут ответа на запрос --- должен быть больше или равен значению, переданному --- в ConnectRequest supports SEQUENCE OF ObjectDescriptor --- весь список поддерживаемых СОРМ типов запросов, типов отчетов } --- согласование поддерживаемых типов со стороны ПУ AdjustmentRequest ::= SEQUENCE { supports SEQUENCE OF ObjectDescriptor --- список поддерживаемых ПУ типов запросов, типов отчетов --- данный список должен быть меньшим либо равным списку в --- сообщении ConnectRequest } -- ответ на согласование списка поддерживаемых типов AdjustmentResponse ::= NULL --- ответ на запрос согласования данных --- запрос завершения сессии DisconnectRequest ::= NULL --- ответ на запрос завершения сессии DisconnectResponse ::= NULL END ___________________________________________________________________________ Sorm.asn Sorm DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS DateAndTime, FindRange, MessageID, Message; IMPORTS TAGGED FROM Classification sessionMessage FROM Sessions trapMessage FROM Traps taskMessage FROM Tasks reportMessage FROM Reports managementMessage FROM Management unformattedMessage FROM Unformatted filterMessage FROM Filters; Version ::= PrintableString vers Version ::= "3.0.0" --- текущая версия протокола -- Оболочка сообщения СОРМ -- Message ::= SEQUENCE { version Version DEFAULT vers, --- версия протокола message-id MessageID, --- номер запроса message-time DateAndTime, --- время и дата запроса operator-name PrintableString (SIZE (1 .. 128)) OPTIONAL, --- наименование оператора связи id TAGGED.&id ({SormPDUs}), --- идентификтор блока данных data TAGGED.&Data({SormPDUs}{@id}) --- данные блока данных } -- Блок данных сообщения SormPDUs TAGGED ::= { sessionMessage --- сообщения организации сессии | trapMessage --- сообщения сигналов | taskMessage --- сообщения работы с задачами | reportMessage --- сообщения работы с отчетами | managementMessage --- сообщения канала передачи мониторинга (КПМ) | unformattedMessage --- сообщения канала передачи неформатированных данных (КПНФ) | filterMessage --- сообщения установки/снятия фильтров записываемого содержимого соединений сети передачи данных } --- Общие данные -- Номер сообщения MessageID ::= INTEGER (0 .. 4294967295) -- Дата и время DateAndTime ::= UTCTime -- Диапазон поиска FindRange ::= SEQUENCE { begin-find [0] DateAndTime OPTIONAL, --- время и дата начала поиска информации end-find [1] DateAndTime OPTIONAL --- время и дата окончания поиска информации } END ___________________________________________________________________________ TasksAbonents.asn TasksAbonents DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS AbonentsTask; IMPORTS LogicalOperation FROM Tasks RequestedIdentifier FROM RequestedIdentifiers RequestedAbonent FROM RequestedAbonents; AbonentsTask ::= CHOICE { validate-abonents-task [0] ValidateAbonentsTask, --- задача на поиск информации о принадлежности --- идентификаторов абонентов сети оператора связи validate-identifiers [1] ValidateIdentifiersTask, --- задача на поиск информации об идентификаторах --- абонентов сети оператора связи зарегистрированных --- на физическое или юридическое лицо validate-services [2] ValidateServicesTask -- задача на поиск информации о доступных абоненту видам услуг связи } --- задача на поиск информации о принадлежности идентификаторов абонентов сети оператора связи ValidateAbonentsTask ::= RequestedIdentifiers --- запрашиваемые идентификаторы RequestedIdentifiers ::= SEQUENCE OF RequestedIdentifierParameters -- последовательность из идентификаторов и логических операций RequestedIdentifierParameters ::= CHOICE { separator [0] LogicalOperation, --- логическая операция или скобка find-mask [1] RequestedIdentifier --- параметр - идентификатор } --- задача на поиск информации об идентификаторах абонентов сети оператора связи зарегистрированных на физическое или юридическое лицо ValidateIdentifiersTask ::= RequestedAbonents --- запрашиваемые абоненты RequestedAbonents ::= SEQUENCE OF RequestedAbonentsParameters --- последовательность логических операций и параметров RequestedAbonentsParameters ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки find-mask [1] RequestedAbonent --- информация запроса об абоненте } --- задача на поиск истории услуг связи абонента --- запрос по маске запрещен, идентификатор должен быть указан полностью ValidateServicesTask ::= SEQUENCE OF ValidateServicesParameters ValidateServicesParameters ::= CHOICE { separator [0] LogicalOperation, --- логическая операция или скобка find-mask [1] ValidateServicesParameter --- параметр - идентификатор } ValidateServicesParameter ::= CHOICE { contract [0] UTF8String (SIZE (1 .. 64)), --- номер договора identifier [1] RequestedIdentifier } END ___________________________________________________________________________ Tasks.asn Tasks DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS taskMessage, TaskID, LogicalOperation, CreateTaskResponse, DataContentID; IMPORTS TAGGED, sorm-message-task FROM Classification FindRange, MessageID FROM Sorm TelcoList, DictionaryTask FROM Dictionaries AbonentsTask FROM TasksAbonents ConnectionsTask FROM TasksConnections LocationTask FROM TasksLocation PaymentsTask FROM TasksPayments PresenseTask FROM TasksPresense DataContentTask FROM TasksContentTask NonFormalizedTaskRequest, NonFormalizedTaskResponse FROM TasksNonFormalized; taskMessage TAGGED ::= { OID {sorm-message-task} DATA CHOICE { data-ready-request [0] DataReadyRequest, --- запрос готовности данных data-ready-response [1] DataReadyResponse, --- ответ на запрос готовности данных data-load-request [2] DataLoadRequest, --- запрос загрузки данных data-load-response [3] DataLoadResponse, --- ответ на запрос загрузки данных data-drop-request [4] DataDropRequest, --- запрос удаления данных data-drop-response [5] DataDropResponse, --- ответ на запрос удаления данных data-interrupt-request [6] DataInterruptRequest, --- запрос прерывания загрузки данных data-interrupt-response [7] DataInterruptResponse, --- ответ на запрос прерывания загрузки данных create-task-request [8] CreateTaskRequest, --- запрос на создание задачи по обработке информации create-task-response [9] CreateTaskResponse, --- ответ на запрос создания задачи non-formalized-task-request [10] NonFormalizedTaskRequest, --- запрос на создание задачи по обработке неформализованных данных non-formalized-task-response [11] NonFormalizedTaskResponse --- ответ на запрос создания задачи по обработке неформализованных данных } } --- в этом запросе не параметров DataReadyRequest ::= NULL --- запрос загрузки данных конкретной задачи DataLoadRequest ::= TaskID --- запрос удаления данных конкретной задачи DataDropRequest ::= TaskID --- запрос прерывания загрузки данных DataInterruptRequest ::= TaskID --- запрос на создание задачи поиска CreateTaskRequest ::= SEQUENCE { telcos [0] TelcoList OPTIONAL, --- список операторов связи range [1] FindRange OPTIONAL, --- временной диапазон поиска report-limit [2] INTEGER (1 .. 10000000) OPTIONAL, --- ограничение на максимальное количество возвращаемых записей task [3] CHOICE { dictionary [0] DictionaryTask, --- задачи пополнения справочников (нормативно-справочная информация) abonents [1] AbonentsTask, --- задачи поисков по принадлежности абонентов connections [2] ConnectionsTask, --- задачи поисков по соединениям абонентов location [3] LocationTask, --- задача получения данных местоположения абонентов payments [4] PaymentsTask, --- задачи поисков по совершенным платежам presense [6] PresenseTask, --- задачи предоставления сведений о наличии данных data-content [9] DataContentTask --- задачи получения содержимого потоков } } -------------------------------------------------------------------------- -- последовательность записей о готовности данных задач DataReadyResponse ::= SEQUENCE OF DataReadyTaskRecord DataReadyTaskRecord ::= SEQUENCE { task-id TaskID, --- идентификатор задачи result TaskResult --- результат выполнения задачи } TaskResult ::= SEQUENCE { result ENUMERATED { data-not-ready (0), --- данные не готовы, задача еще выполняется data-ready (1), --- данные есть, задача выполнена data-not-found (2), --- данных нет, задача выполнена error (3) --- в процессе выполнения задачи произошла ошибка }, report-records-number [0] INTEGER (0 .. 999999999999) OPTIONAL, --- для выполненной задачи - количество --- записей в отчете report-limit-exeeded [1] BOOLEAN OPTIONAL, --- количество записей превысило лимит, заданный при создании задачи error-description [2] UTF8String (SIZE (1 .. 256)) OPTIONAL --- краткое описание произошедшей ошибки, --- если обнаружена } DataLoadResponse ::= SEQUENCE { task-id TaskID, --- идентификатор задачи, сгенерировавшей данный отчет data-exists BOOLEAN, --- признак существования результатов исполнения задачи --- (есть данные или нет) data-blocks-number INTEGER (0 .. 999999999999) OPTIONAL, --- количество блоков в отчете error-description UTF8String (SIZE (1 .. 256)) OPTIONAL --- краткое описание ошибки, если обнаружена } DataDropResponse ::= SEQUENCE { task-id TaskID, --- идентификатор задачи, данные которой будут удалены successful BOOLEAN, --- признак успешного выполнения запроса error-description UTF8String (SIZE (1 .. 256)) OPTIONAL --- краткое описание ошибки, если обнаружена } DataInterruptResponse ::= SEQUENCE { request-id MessageID, --- идентификатор прерванного запроса загрузки данных successful BOOLEAN, --- признак успешного выполнения запроса data-blocks-available INTEGER (0 .. 999999999999) OPTIONAL, --- количество оставшихся непереданными блоков error-description UTF8String (SIZE (1 .. 256)) OPTIONAL --- краткое описание ошибки, если обнаружена } CreateTaskResponse ::= SEQUENCE { task-id TaskID OPTIONAL, --- идентификатор задачи successful BOOLEAN, --- признак успешного выполнения запроса error-description UTF8String (SIZE (1 .. 256)) OPTIONAL --- краткое описание ошибки, если обнаружена } --------------------------------------------------------------------------- -- идентификатор задачи TaskID ::= INTEGER (0 .. 4294967295) -- идентификатор потока DataContentID ::= UTF8String (SIZE (1 .. 512)) LogicalOperation ::= ENUMERATED { operation-open-bracket (0), -- открывающая скобка - "(" operation-close-bracket (1), -- закрывающая скобка - ")" operation-or (2), -- логическое "или" operation-and (3), -- логическое "и" operation-not (4) -- логическое "не" } END ___________________________________________________________________________ TasksConnections.asn TasksConnections DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ConnectionsTask; IMPORTS LogicalOperation FROM Tasks RequestedConnection FROM RequestedConnections ; ConnectionsTask ::= CHOICE { validate-connections [0] ValidateConnectionsTask, --- задача на поиск телефонных соединений между абонентами validate-data [1] ValidateDataTask, --- задача на поиск соединений между абонентами сети передачи данных validate-entrance [2] ValidateEntranceTask --- задача на поиск информации о появлении абонента в сети связь (выхода на связь) } -- Зачем разделение ValidateConnectionsTask ValidateDataTask --- задача на поиск по соединениям абонентов ValidateConnectionsTask ::= RequestedConnectionIdentifiers --- запрашиваемые идентификаторы, указываются все, кроме --- RequestedDataNetworkIdentifier ValidateDataTask ::= RequestedConnectionIdentifiers --- запрашиваемые идентификаторы, указываются --- RequestedDataNetworkIdentifier ValidateEntranceTask ::= RequestedConnectionIdentifiers --- задача на поиск информации о появлении абонента в сети связь (выхода на связь) RequestedConnectionIdentifiers ::= SEQUENCE OF RequestedConnectionParameter RequestedConnectionParameter ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки find-mask [1] RequestedConnection --- параметр запроса } END ___________________________________________________________________________ TasksLocation.asn TasksLocation DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS LocationTask; IMPORTS LogicalOperation FROM Tasks RequestedConnection FROM RequestedConnections IPAddress FROM NetworkIdentifiers; --- задача получения данных местоположения абонентов LocationTask ::= RequestedLocationIdentifier --- запрашиваемые единтификаторы для определения местоположения RequestedLocationIdentifier ::= CHOICE { directory-number [0] UTF8String (SIZE (2 .. 32)), --- телефонный номер в международном формате imsi [1] NumericString (SIZE (2 .. 18)), --- идентификатор мобильного абонента ip-address [2] IPAddress, --- IP-адрес абонента imei [3] NumericString (SIZE (2 .. 18)) --- идентификатор мобильной станции } END ___________________________________________________________________________ TasksNonFormalized.asn TasksNonFormalized DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS EntityId, NonFormalizedTaskRequest, NonFormalizedTaskResponse, NonFormalizedEntityAttributeData; IMPORTS TelcoList FROM Dictionaries FindRange, MessageID, DateAndTime FROM Sorm Location FROM Locations LogicalOperation, CreateTaskResponse FROM Tasks ; -- TaskID, -- LogicalOperation; NonFormalizedTaskRequest ::= CHOICE { get-entities [0] GetEntities, --- тип сообщения "запрос получения списка типов сущностей" get-attributes [1] GetEntityAtttibutes, --- тип сообщения "запрос получения списка атрибутов сущности" validate-task [2] ValidateNonFormalizedTask, --- тип сообщения "задача поиска неформализованных данных" validate-presense [3] NonFormalizedPresenseTask --- тип сообщения "задача предоставления сведений о наличии неформализованных данных" } NonFormalizedTaskResponse ::= CHOICE { entities [0] GetEntitiesResponse, --- ответ на запрос получения списка типов сущностей entity-attributes [1] GetEntityAtttibutesResponse, --- ответ на запрос получения списка атрибутов сущности validate-task [2] ValidateNonFormalizedTaskResponse, --- ответ на запрос задачи поиска неформализованных данных validate-presense [3] NonFormalizedPresenseTaskResponse --- ответ на запрос задач предоставления сведений о наличии неформализованных данных } --- тип сообщения "запрос получения списка типов сущностей" GetEntities ::= NULL --- тип сообщения "запрос получения списка атрибутов сущности" GetEntityAtttibutes ::= EntityId --- тип сообщения "задача поиск неформализованных данных" ValidateNonFormalizedTask ::= SEQUENCE { entity-id EntityId, --- сущность для поиска по неформализованным данным parameters NonFormalizedParameters, --- критерии поиска по неформализованным данным range FindRange OPTIONAL, --- временной диапазон поиска report-limit INTEGER (1 .. 10000000) OPTIONAL --- ограничение на максимальное количество возвращаемых записей } --- тип сообщения "задача предоставления сведений о наличии неформализованных данных" NonFormalizedPresenseTask ::= EntityId NonFormalizedParameters ::= SEQUENCE OF NonFormalizedParameter NonFormalizedParameter ::= CHOICE { separator [0] LogicalOperation, --- логическая операция find-mask [1] NonFormalizedEntityCondition --- условие } NonFormalizedEntityCondition ::= SEQUENCE { attribute NonFormalizedEntityAttribute, --- атрибут сущности operation MathOperation, --- операция attribute-value NonFormalizedEntityAttributeData --- значение атрибута } NonFormalizedEntityAttribute ::= SEQUENCE { attribute-name UTF8String (SIZE (1 .. 256)), --- текстовое наименование атрибута сущности attribute-type AttributeType --- тип данных атрибута } NonFormalizedEntityAttributeData ::= CHOICE { datetime [0] DateAndTime, --- дата и время с точностью до секунд integer [1] INTEGER, --- целочисленный string [2] UTF8String, --- строковый boolean [3] BOOLEAN, --- булевый float [4] REAL, --- с плавающей запятой location [5] Location, --- местоположение empty [6] NULL --- пустое значение (null) } --- математические операции сравнения MathOperation ::= ENUMERATED { equal (0), --- равно less (1), --- меньше greater (2), --- больше not-equal (3), --- не равно less-or-equal (4), --- меньше или равно greater-or-equal (5) --- больше или равно } ----------------------------------------------------------- GetEntitiesResponse ::= SEQUENCE OF NonFormalizedEntity NonFormalizedEntity ::= SEQUENCE { entity-id EntityId, --- уникальный идентификатор сущности entity-name UTF8String (SIZE (1 .. 256)) --- текстовое наименование сущности } GetEntityAttributesResponse ::= SEQUENCE { entity-id EntityId, --- уникальный идентификатор сущности entity-attributes SEQUENCE OF NonFormalizedEntityAttribute --- атрибуты сущности } ValidateNonFormalizedTaskResponse ::= CreateTaskResponse NonFormalizedPresenseTaskResponse ::= CreateTaskResponse ----------------------------------------------------------- --- типы данных атрибутов AttributeType ::= ENUMERATED { date-time (0), --- дата и время с точностью до секунд integer (1), --- целочисленный string (2), --- строковый boolean (3), --- булевый float (4), --- с плавающей запятой location (5), --- местоположение empty (6) --- пустое значение } --- Идентификатор сущности EntityId ::= INTEGER (0 .. 4294967296) END ___________________________________________________________________________ TasksPayments.asn TasksPayments DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS PaymentsTask; IMPORTS LogicalOperation FROM Tasks RequestedConnection FROM RequestedConnections RequestedIdentifier FROM RequestedIdentifiers RequestedAddress FROM Addresses TAGGED, sorm-request-payment-bank-transaction, sorm-request-payment-express-pays, sorm-request-payment-terminal-pays, sorm-request-payment-service-center, sorm-request-payment-cross-account, sorm-request-payment-telephone-card, sorm-request-payment-balance-fillups, sorm-request-payment-bank-division-transfer, sorm-request-payment-bank-card-transfer, sorm-request-payment-bank-account-transfer FROM Classification; PaymentsTask ::= SEQUENCE { id TAGGED.&id ({RequestedPaymentsVariants}), data TAGGED.&Data ({RequestedPaymentsVariants}{@id}) } --- варианты запрашиваемых параметров связей RequestedPaymentsVariants TAGGED ::= { bankTransactionTask | expressCardTask | publicTerminalTask | serviceCenterTask | crossAccountTask | telephoneCardTask | balanceFillupTask | bankDivisionTransferTask | bankCardTransferTask | bankAccountTransferTask } --- задача на поиск пополнения баланса через банковский перевод bankTransactionTask TAGGED ::= { OID { sorm-request-payment-bank-transaction } DATA RequestedBankTransactionPays } RequestedBankTransactionPays ::= SEQUENCE OF RequestedBankTransactionPaysParameters --- последовательность логических операций и параметров RequestedBankTransactionPaysParameters ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки bank-account [1] UTF8String (SIZE (1 .. 64)), --- номер банковского счета, с которого совершен платеж bank-name [2] UTF8String (SIZE (1 .. 512)) --- наименование банка, со счета которого совершен перевод } --- задача на поиск пополнения баланса через карты экспресс-оплаты expressCardTask TAGGED ::= { OID { sorm-request-payment-express-pays } DATA RequestedExpressPays } RequestedExpressPays ::= SEQUENCE OF RequestedExpressPaysParameters --- последовательность логических операций и параметров RequestedExpressPaysParameters ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки express-card [1] NumericString (SIZE (2 .. 20)) --- номер карты экспресс-оплаты } --- задача на поиск пополнения баланса через терминалы моментальных платежей publicTerminalTask TAGGED ::= { OID { sorm-request-payment-terminal-pays } DATA RequestedTerminalPays } RequestedTerminalPays ::= SEQUENCE OF RequestedTerminalPaysParameters --- последовательность логических операций и параметров RequestedTerminalPaysParameters ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки terminal-id [1] UTF8String (SIZE (1..64)), --- идентификатор терминала terminal-number [2] NumericString (SIZE (2..20)), --- номер терминала terminal-address [3] RequestedAddress --- адрес терминала } --- задача на поиск пополнения баланса через центры обслуживания клиентов (ЦОК) serviceCenterTask TAGGED ::= { OID { sorm-request-payment-service-center } DATA RequestedServiceCenterPays } RequestedServiceCenterPays ::= SEQUENCE OF RequestedServiceCenterPaysParameters --- последовательность логических операций и параметров RequestedServiceCenterPaysParameters ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки center-id [1] UTF8String (SIZE (1 .. 64)), --- идентификатор центра обслуживания клиентов center-address [2] RequestedAddress --- адрес центра обслуживания клиентов } --- задача на поиск пополнения баланса посредством снятия денег со счета другого абонента crossAccountTask TAGGED ::= { OID { sorm-request-payment-cross-account } DATA RequestedCrossAccountPays } RequestedCrossAccountPays ::= SEQUENCE OF RequestedCrossAccountPaysParameters --- последовательность логических операций и параметров RequestedCrossAccountPaysParameters ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки source-identifier [1] RequestedIdentifier, --- идентификатор абонента, со счета которого переводятся средства dest-identifier [2] RequestedIdentifier --- идентификатор абонента, на счет которого переводятся средства } --- задача на поиск пополнения баланса через телефонные карты telephoneCardTask TAGGED ::= { OID { sorm-request-payment-telephone-card } DATA RequestedTelephoneCardPays } RequestedTelephoneCardPays ::= SEQUENCE OF RequestedTelephoneCardPaysParameters --- последовательность логических операций и параметров RequestedTelephoneCardPaysParameters ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки card-number [1] NumericString (SIZE (2..20)) --- номер телефонной карты } --- общая задача на поиск пополнения баланса личного счета абонента balanceFillupTask TAGGED ::= { OID { sorm-request-payment-balance-fillups } DATA RequestedBalanceFillups --- параметры запроса } RequestedBalanceFillups ::= SEQUENCE OF RequestedBalanceFillupsParameters --- последовательность логических операций и параметров RequestedBalanceFillupsParameters ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки identifier [1] RequestedIdentifier --- идентификатор абонента } --- задача на поиск перевода средств со счета абонента для их снятия в отделении банка bankDivisionTransferTask TAGGED ::= { OID { sorm-request-payment-bank-division-transfer } DATA RequestedBankDivisionTranferPays --- параметры запроса } RequestedBankDivisionTranferPays ::= SEQUENCE OF RequestedTranferParameters --- последовательность логических операций и параметров --- задача на поиск перевода средств со счета абонента на банковскую карту bankCardTransferTask TAGGED ::= { OID { sorm-request-payment-bank-card-transfer } DATA RequestedBankCardTranferPays --- параметры запроса } RequestedBankCardTranferPays ::= SEQUENCE OF RequestedTranferParameters --- последовательность логических операций и параметров --- задача на поиск перевода средств со счета абонента на счет в банке bankAccountTransferTask TAGGED ::= { OID { sorm-request-payment-bank-account-transfer } DATA RequestedBankAccountTranferPays --- параметры запроса } RequestedBankAccountTranferPays ::= SEQUENCE OF RequestedTranferParameters --- последовательность логических операций и параметров RequestedTranferParameters ::= CHOICE { separator [0] LogicalOperation, --- логический оператор связки source-identifier [1] RequestedIdentifier --- идентификатор абонента инициатора перевода средств } END ___________________________________________________________________________ TasksPresense.asn TasksPresense DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS PresenseTask; IMPORTS TAGGED, sorm-request-presense FROM Classification; PresenseTask ::= SEQUENCE { id TAGGED.&id ({PresenseListVariants}), data TAGGED.&Data ({PresenseListVariants}{@id}) } PresenseListVariants TAGGED ::= { presenseInfo } presenseInfo TAGGED ::= { OID { sorm-request-presense } DATA ENUMERATED { subscribers (0), --- запрос наличия информации по абонентам и их идентификаторам connections (1), --- запрос наличия информации по соединениям payments (2), --- запрос наличия имеющейся информации по платежам dictionaries (3), --- запрос наличия справочников locations (4) --- запрос наличия информации по местоположениям абонентов } } END ___________________________________________________________________________ Traps.asn Traps DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS trapMessage; IMPORTS TAGGED, sorm-message-trap FROM Classification MessageID FROM Sorm ; trapMessage TAGGED ::= { OID { sorm-message-trap } DATA CHOICE { trap [0] Trap, --- тип сообщения "сигнал" trap-ack [1] TrapAck --- тип сообщения "подтверждение сигнала" } } -- Блок данных сообщения типа "сигнал" Trap ::= SEQUENCE { trap-type TrapType, -- тип сообщения trap-message UTF8String (SIZE (1..256)) OPTIONAL, -- описание сообщения reference-message MessageID OPTIONAL -- номер сообщение к которому относится данный сигнал -- (например номер сообщения запросившего отчет при прерывании передачи) } TrapType ::= ENUMERATED { heartbeat (0), -- тестовый пакет restart-software (1), -- перезапуск ПО unauthorized-access (2), -- попытка несанкционированного доступа critical-error (3), -- критическая ошибка ПО, потеря данных, дальнейшая работа невозможна major-error (4), -- серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна minor-error (5) -- незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна } -- Блок данных сообщения типа "подтверждение сигнала" -- Номер сообщения TrapAck должен соответствовать номеру сообщения Trap TrapAck ::= NULL END ___________________________________________________________________________ Unformatted.asn Unformatted DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS unformattedMessage; IMPORTS TAGGED, sorm-message-unformatted FROM Classification TelcoList FROM Dictionaries Acknowledgement FROM Reports CallsRecords FROM ReportsConnections DateAndTime, MessageID FROM Sorm; unformattedMessage TAGGED ::= { OID { sorm-message-unformatted } DATA CHOICE { request [0] RawRequest, response [1] RawResponse, report [2] RawReport, report-ack [3] RawAcknowledgement } } RawRequest ::= SEQUENCE { telcos TelcoList, --- список операторов связи raw-task RawRequestTask --- запрос получения неформатированных данных } RawRequestTask ::= CHOICE { data-types-request [0] DataTypesRequest, --- запрос проверки наличия вида неформатированных данных в ИС СОРМ data-start-request [1] DataStartRequest, --- запрос на начало передачи неформатированных данных data-stop-request [2] DataStopRequest --- запрос на остановку передачи неформатированных данных } --- типы данных, передаваемых ИС СОРМ RawDataType ::= ENUMERATED { data-reports (0), --- записи о соединениях в формате сообщений кпд2 raw-cdr (1), --- "сырые" CDR-файлы } ControlCommandType ::= ENUMERATED { start (0), --- команда начала передачи ИС СОРМ данных stop (1) --- команда прерывания передачи ИС СОРМ данных } DataTypesRequest ::= RawDataType DataStartRequest ::= SEQUENCE { time-from DateAndTime, --- начало временного периода в буфере, с которого необходимо получить данные time-to DateAndTime, --- конец временного периода в буфере, с которого необходимо получить данные raw-type RawDataType --- тип неформатированных данных передачи } DataStopRequest ::= NULL RawResponse ::= CHOICE { data-types-response [0] DataTypesResponse, --- ответ на запрос проверки наличия неформатированных вида данных в ИС СОРМ data-start-response [1] DataStartResponse, --- ответ на запрос начала передачи неформатированных данных data-stop-response [2] DataStopResponse --- ответ на запрос остановки передачи неформатированных данных } DataTypesResponse ::= SEQUENCE { successful BOOLEAN, --- признак наличия в ИС СОРМ запрошенного вида неформатированных данных selected-type RawDataType, --- выбранный вид данных для передачи time-from DateAndTime, --- начало временного периода в буфере, начиная с которого накоплены данные time-to DateAndTime --- конец временного периода в буфере, по которому накоплены данные } DataStartResponse::= BOOLEAN --- признак успешности выполнения команды DataStopResponse ::= BOOLEAN --- признак успешности выполнения команды RawReport ::= SEQUENCE { request-id MessageID, --- идентификатор запроса stream-id UTF8String (SIZE (1..256)), --- идентификатор потока в сессии total-blocks-number INTEGER (0..999999999999), --- общее количество блоков в отчете block-number INTEGER (1..1000000000000), --- порядковый номер текущего блока report-block RawDataBlock --- блок данных отчета } RawDataBlock ::= CHOICE { reports [0] CallsRecords, --- записи отчетов о соединениях в формате КПД raw-cdr [1] RawBytesBlock } RawBytesBlock::= SEQUENCE OF RawBytes RawBytes ::= OCTET STRING (SIZE (1..4096)) RawAcknowledgement ::= Acknowledgement END ___________________________________________________________________________ ReportsDataContent.asn ReportsDataContent DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS DataContentReport; IMPORTS TAGGED, sorm-report-data-content-raw FROM Classification; DataContentReport ::= SEQUENCE { id TAGGED.&id ({ReportedDataContentVariants}), data TAGGED.&Data ({ReportedDataContentVariants}{@id}) } ReportedDataContentVariants TAGGED ::= { reportDataContentRaw } reportDataContentRaw TAGGED ::= { OID { sorm-report-data-content-raw } DATA SEQUENCE OF RawRecordContent } RawRecordContent ::= SEQUENCE { successful BOOLEAN, --- признак успешного формирования блока данных data [0] OCTET STRING (SIZE (1..1048576)) OPTIONAL, --- содержимое блока (в случае если блок успешно сформирован) error [1] UTF8String (SIZE (1..4096)) OPTIONAL, --- описание ошибки (в случае если не удалось сформировать блок) codec-info [2] UTF8String (SIZE (1..4096)) OPTIONAL, --- описание способа кодирования в формате SDP в соответствии RFC 2327 direction [3] DataContentRawDirection OPTIONAL, --- направление передачи channel [4] INTEGER OPTIONAL --- канал } DataContentRawDirection ::= ENUMERATED { client-server (0), server-client (1) } END ___________________________________________________________________________ TasksContentTask.asn TasksContentTask DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS DataContentTask; IMPORTS DataContentID FROM Tasks; DataContentTask ::= DataContentID END
Информация о соединениях, оказанных услугах связи и справочная информация, собираемая и накапливаемая техническими и программными средствами информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ):
N |
Наименование лицензии на оказание услуг связи |
Накапливаемая информация |
Накапливаемая справочная информация |
1 |
Услуги местной телефонной связи, за исключением услуг местной телефонной связи с использованием таксофонов и средств коллективного доступа |
Информация о соединениях в сети фиксированной телефонной связи. |
Справочная информация об: операторах связи, к сетям которых подключены ИС ОРМ; группах соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий |
2 |
Услуги междугородной и международной телефонной связи |
Информация о соединениях в сети фиксированной телефонной связи. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; пучках соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий. |
3 |
Услуги телефонной связи в выделенной сети связи |
Информация о соединениях в сети фиксированной телефонной связи. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; пучках соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий. |
4 |
Услуги внутризоновой телефонной связи |
Информация о соединениях в сети фиксированной телефонной связи. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; пучках соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий. |
5 |
Услуги местной телефонной связи с использованием таксофонов |
Информация о соединениях в сети фиксированной телефонной связи. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; пучках соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий. |
6 |
Услуги местной телефонной связи с использованием средств коллективного доступа |
Информация о соединениях в сети фиксированной телефонной связи. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; пучках соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий. |
7 |
Услуги подвижной радиосвязи в сети связи общего пользования |
Информация о соединениях в сети подвижной телефонной связи; при изменении местоположения. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; пучках соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий; базовых станциях; планах нумерации идентификаторов мобильных телефонных абонентов; роуминговых партнерах. |
8 |
Услуги подвижной радиосвязи в выделенной сети связи |
Информация о соединениях в сети подвижной телефонной связи; при изменении местоположения. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; пучках соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий; базовых станциях; планах нумерации идентификаторов мобильных телефонных абонентов; роуминговых партнерах. |
9 |
Услуги подвижной радиотелефонной связи |
Информация о соединениях в сети подвижной телефонной связи; при изменении местоположения. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; пучках соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий; базовых станциях; планах нумерации идентификаторов мобильных телефонных абонентов; роуминговых партнерах. |
10 |
Услуги подвижной спутниковой радиосвязи |
Информация о соединениях в сети подвижной телефонной связи; при изменении местоположения. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; пучках соединительных линий; коммутаторах; типах вызовов; списках услуг связи; способах оплаты (пополнения баланса); причинах завершения соединения; планах телефонной номерной емкости; специальных номерах оператора связи; типах документов, удостоверяющих личность; картах связей пучков соединительных линий; базовых станциях; планах нумерации идентификаторов мобильных телефонных абонентов; роуминговых партнерах. |
11 |
Услуги связи по предоставлению каналов связи |
Информация о соединениях: подключения/отключения абонента к сети передачи данных (AAA); HTTP-соединениях с информационными ресурсами сети передачи данных; при передаче почтовых сообщений; при передаче электронных сообщений между пользователями; при передаче голосовой информация посредством сети передачи данных; при передаче файловых данных; при терминальном доступе к оборудованию; при передаче иных данных; при трансляции сетевых адресов. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; справочниках с планами IP-адресации; идентификаторах точек подключения к сети передачи данных; IP шлюзах; специальных номерах оператора связи; типах документов, удостоверяющих личность; способах оплаты (пополнения баланса); причинах завершения соединения; списках услуг связи. |
12 |
Услуги связи по передаче данных, за исключением услуг связи по передаче данных для целей передачи голосовой информации |
Информация о соединениях: подключения/отключения абонента к сети передачи данных (AAA); HTTP-соединениях с информационными ресурсами сети передачи данных; при передаче почтовых сообщений; при передаче электронных сообщений между пользователями; при передаче файловых данных; при терминальном доступе к оборудованию; при передаче иных данных; при трансляции сетевых адресов; при изменении местоположения. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; справочниках с планами IP-адресации; идентификаторах точек подключения к сети передачи данных; IP шлюзах; специальных номерах оператора связи; типах документов, удостоверяющих личность; способах оплаты (пополнения баланса); причинах завершения соединения; списках услуг связи. |
13 |
Услуги связи по передаче данных для целей передачи голосовой информации |
Информация о соединениях: подключения/отключения абонента к сети передачи данных (AAA); HTTP-соединениях с информационными ресурсами сети передачи данных; при передаче почтовых сообщений; при передаче электронных сообщений между пользователями; при передаче голосовой информация посредством сети передачи данных; при передаче файловых данных; при терминальном доступе к оборудованию; при передаче иных данных; при трансляции сетевых адресов; при изменении местоположения. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; справочниках с планами IP-адресации; идентификаторах точек подключения к сети передачи данных; IP шлюзах; специальных номерах оператора связи; типах документов, удостоверяющих личность; способах оплаты (пополнения баланса); причинах завершения соединения; списках услуг связи. |
14 |
Телематические услуги связи |
Информация о соединениях: подключения/отключения абонента к сети передачи данных (AAA); HTTP-соединениях с информационными ресурсами сети передачи данных; при передаче почтовых сообщений; при передаче электронных сообщений между пользователями; при передаче файловых данных; при терминальном доступе к оборудованию; при передаче иных данных; при трансляции сетевых адресов. |
Справочная информация об: операторах связи, обслуживаемых ИС ОРМ; справочниках с планами IP-адресации; идентификаторах точек подключения к сети передачи данных; IP шлюзах; специальных номерах оператора связи; типах документов, удостоверяющих личность; способах оплаты (пополнения баланса); причинах завершения соединения; списках услуг связи. |
В перечень интерфейсов точек консолидации информации, передаваемой в телефонных сетях и сетях передачи данных для сбора текстовых сообщений, голосовой информации, изображений, звуков, иных сообщений пользователей услугами связи <30>, входят следующие интерфейсы:
———————————
<30> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
1. Интерфейсы с использованием контроля несущей и обнаружением коллизий, включая:
оптические интерфейсы 10GBASE-S;
оптические интерфейсы 10GBASE-L;
оптические интерфейсы 10GBASE-E;
оптические интерфейсы 10GBASE-LX4;
электрические интерфейсы 10GBASE-CX4;
оптические интерфейсы 1000 BASE-X;
электрический интерфейс GBE;
оптические интерфейсы 100BASE-X;
электрические интерфейсы 100BASE-T;
оптические интерфейсы 10BASE-F;
электрические интерфейсы EtherNet.
2. Оптические интерфейсы оборудования синхронной цифровой иерархии (SDH):
интерфейс 1-го уровня SDH (STM-1);
интерфейс 4-го уровня SDH (STM-4);
интерфейс 16-го уровня SDH (STM-16);
интерфейс 64-го уровня SDH (STM-64).
3. Оптические интерфейсы оборудования плезиохронной цифровой иерархии (PDH):
интерфейс 34 Мбит/с (E3);
интерфейс 140 Мбит/с (E4).
4. Электрические интерфейсы оборудования плезиохронной (PDH) и синхронной (SDH) цифровых иерархий:
интерфейс 2 Мбит/с (E1);
интерфейс 34 Мбит/с (E3);
интерфейс 140 Мбит/с (E4);
интерфейс 155 Мбит/с (STM-1).
1. Посредством информационных систем, содержащих базы данных абонентов оператора связи и предоставленных им услугах связи, а также информацию о пользователях услугами связи и о предоставленных им услугах связи, обеспечивающих выполнение установленных действий при проведении оперативно-розыскных мероприятий (далее — ИС ОРМ), выполняется сбор голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных сообщений <31> пользователей услугами связи (при наличии лицензий на услуги связи по предоставлению каналов связи, услуги связи в сети передачи данных, за исключением передачи голосовой информации, телематические услуги связи) из точек консолидации в соответствии с Таблицей N 1 настоящего приложения к Требованиям.
———————————
<31> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
Таблица N 1.
N |
Наименование услуг связи |
Точки консолидации информации |
1 |
Услуги связи по предоставлению каналов связи |
Интерфейсы оборудования связи точек пропуска входящего и исходящего трафика с предоставленных каналов связи |
2 |
Услуги связи по передаче данных, за исключением услуг связи по передаче данных для целей передачи голосовой информации |
Интерфейсы оборудования связи, включающие полный объем входящего и исходящего сетевого трафика с абонентских устройств, в т.ч. межабонентский трафик до выполнения преобразования (трансляции) сетевых адресов абонентов |
3 |
Телематические услуги связи |
Интерфейсы оборудования связи с сетевым трафиком, содержащим полный объем принимаемой и доставляемой на телематический сервис информации от пользователей, а также сетевой трафик обмена информацией с другими телематическими сервисами |
1. Для текстовых сообщений пользователей — информация записывается в кодировке UTF-8 (RFC 3629). Если в процессе передачи по сети связи сообщение было разбито на несколько фрагментов, текстовое сообщение записывается и хранится в виде целого сообщения.
2. Для голосовой информации — информация записывается в соответствии с фактически использованным сетью связи кодированием (кодеком) при доставке/приеме абонентом голосовой информации без внесения изменений и ухудшения качества голосовой информации в виде RTP потока (RFC 3550). При использовании протоколов сигнализации SIP, MGCP или других, использующих сообщения SDP для описания параметров передачи медиаданных, передаются атрибуты «m» и «a» из сообщения с типом application/sdp (описание сессии) согласно RFC 2327. Для остальных протоколов сигнализации также передаются атрибуты описания сессии «m» и «a» в формате, описанном RFC 2327, но сформированные на стороне ИС ОРМ.
Пример значения поля Value (кавычки не включаются):
«m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtnmap:98 L16/11025/2″
3. Для изображений, звуков и иных сообщений <32> пользователей услугами связи: в случае использования протокола TCP (RFC 793) — информация записывается в виде потока информации прикладного уровня, в случае использования протокола UDP (RFC 768) — в виде последовательности датаграмм UDP.
———————————
<32> Подпункт 2 пункта 1 статьи 64 Федерального закона от 7 июля 2003 г. N 126-ФЗ «О связи».
ДВО |
Дополнительные виды обслуживания |
КТС |
Комплекс технических средств |
ПО |
Программное обеспечение |
ПУ |
Пульт управления |
Сеть связи |
Сеть связи, оператором которой оказываются услуги связи, перечисленные в пункте 5 настоящих Требований |
Сеть передачи данных |
Сеть связи, оператором которой оказываются услуги связи, перечисленные в подпунктах 11 — 14 пункта 5 настоящих Требований |
ТФоП |
Телефонная сеть общего пользования |
AAA |
(Authentication, Authorization, Accounting), процедуры предоставления доступа пользователя к сети передачи данных |
APN |
(Access Point Name), точка доступа конфигурируемая и доступная из GGSN |
DPC |
(Destination Point Code), код точки назначения системы сигнализации N 7 (ОКС7) |
GMSC |
(Gate MSC), пограничный коммутатор |
GGSN |
(GPRS Gateway Support Node), узел обеспечивающий маршрутизацию данных между сетями GPRS и внешними IP сетями |
HTTP |
(HyperText Transfer Protocol), протокол прикладного уровня передачи данных |
ICC |
(Integrated circuit card identifier), уникальный серийный номер SIM-карты |
IMEI |
(International Mobile Equipment Identity), международный идентификатор мобильного оборудования стандарта GSM или аналогичный идентификатор, используемый в сетях подвижной радиотелефонной связи иных стандартов |
IP |
(Internet Protocol), межсетевой протокол |
IP-адрес |
Уникальный сетевой адрес узла в компьютерной сети, построенной по протоколу IP |
IMSI |
(International Mobile Subscriber Identity), международный идентификатор абонента сети подвижной связи стандарта GSM или аналогичный идентификатор, используемый в сетях подвижной радиотелефонной связи иных стандартов |
MAC-адрес |
(Media Access Control), уникальный идентификатор, присваиваемый каждой единице оборудования сетей передачи данных |
OPC |
(Origination Point Code), код точки отправления системы сигнализации N 7 (ОКС7) |
PIN |
(Personal Identification Number), персональный идентификационный номер |
PSTN |
(Public Switched Telephone Network), телефонная сеть общего пользования |
RFC 1700 |
Стандарт, определяющий коды протоколов передаваемых посредством протокола IP |
SMS |
(Short Message Service), короткое текстовое сообщение. |
SMSC |
(Short Message Service Centre), центр службы коротких сообщений. |
SGSN |
(Serving GPRS Support Node), узел обслуживания абонентов GPRS |
T.38 |
Стандарт ITU-T (Международного Союза Электросвязи), определяющий передачу факсимильных сообщений в реальном времени посредством протокола IP |
URL |
(Uniform Resource Locator), адрес местонахождения ресурса сети |
VAS |
(Value Added Services), услуги, приносящие дополнительный доход) |
VoIP |
(Voice over Internet Protocol), передача голосовой информации посредством сети передачи данных |