ИССЛЕДОВАНИЕ АЛГОРИТМОВ ВЗАИМОДЕЙСТВИЯ OSS И EMS СИСТЕМ ПРИ УСТРАНЕНИИ ОТКАЗОВ. - Студенческий научный форум

IX Международная студенческая научная конференция Студенческий научный форум - 2017

ИССЛЕДОВАНИЕ АЛГОРИТМОВ ВЗАИМОДЕЙСТВИЯ OSS И EMS СИСТЕМ ПРИ УСТРАНЕНИИ ОТКАЗОВ.

Кудряшов В.В. 1
1Московский технический университет связи и информатики
 Комментарии
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF
Рассмотрен комплекс систем, предназначенный для автоматизации и управления инфраструктурой, относящейся к предоставлению услуг связи. Подробно разобраны рассматриваемые системы и функции, которые описаны в стандартах. Рекомендованные стандартами, процессы были распределены по системам. Описаны сценарии взаимодействия систем и критерии эффективности алгоритма. Проведен анализ «процессов – исключений».

Описание комплекса систем управления сетью оператора связи

Системы класса OSS (Operation Support System) и EMS (Element Management System) включены в единый комплекс систем управления сетью связи. Задачей данного комплекса является управление совокупностью организационных, технических и программных процессов для поддержки работы сети оператора связи. Работа комплекса регламентируется стандартами и рекомендациями TMN (Telecommunication Management Network).

Рекомендации [1] описывают структуру и способы взаимодействия входящих в комплекс, систем. Комплекс взаимодействует со всеми объектами сети связи относящиеся к инфраструктуре, обслуживаемой оператором связи – «Сетевыми элементами» NE (Network element’s) (рис.1). Сетевыми элементами являются: базовые станции, маршрутизаторы, коммутаторы, мультиплексоры, модуляторы, демодуляторы, аналоговые и цифровые телефонные станции и др.

Рисунок 1. Сетевые элементы в структуре сети связи.

Рекомендациями [3] определены основные функции комплекса – управление отказами (Fault Management), управление конфигурации (Configuration Management), управление учетом (Accounting Management), управление производительностью (Performance Management), управление безопасностью (Security Management).

Особенности задачи управления предполагают управление разнородными частями сети связи и составляющими их элементами (NE). Результатом работы комплекса является бесперебойное обеспечение клиентов оператора связи «услугами» и «сервисами».

Описание систем комплекса

Учитывая условия, рекомендации [2] описывают структуру комплекса из четырех систем, которые выделяются благодаря специализированным функциям (рис.2):

Система BSS (Business Support System) – Обеспечивает подготовку новых услуг связи, аналитику, и действия по подержанию уровня прибыли компании.

Система OSS (Operation Support System) – Обеспечивает связь с клиентами и техническую поддержку, выполняет расчет и формирование счетов за оказанные услуги, автоматизирует часть документооборота.

Система NMS (Network Management System) – Обеспечивает мониторинг сети, регламентирует взаимодействия между элементами сети, обеспечивает взаимодействия разнородных сетей и взаимосвязь с сетями других операторов.

Система EMS (Element Management System) – Обрабатывает сигналы от отдельных элементов сети или группы элементов однородной сети, оказывает информационную поддержку при работе с элементами сети.

Рисунок 2. Концептуальная модель комплекса.

Анализ и разработка алгоритма взаимодействия

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

Функцию «управления отказами» подразделяют на несколько последовательно выполняемых, этапов: выявление ошибок, локализация ошибок, исправление отказов. Согласно рекомендациям, каждому этапу соответствует группа процессов. Распределение процессов между системами не регламентируются стандартами и рекомендациями. Целью является оптимальное распределение процессов в комплексе.

Учитывая особенности и отведенные стандартами, функции систем, следует распределить выполнение процессов на каждом этапе отдельно.

Стандарт [3] предлагает для реализации этапа «выявления ошибок» набор процессов:

  • Сигнализация и оповещение ошибок.

  • Анализ поступивших заявок.

  • Информирование клиентов о статусе проблемы.

  • Предоставление доступа к ведению и анализу статистики ошибок.

  • Оповещение службы поддержки об отключении сервисов в результате сбоя.

Результат распределения процессов по системам на данном этапе отражено в таблице 1. Процесс «Оповещение службы поддержки об отключении сервисов в результате сбоя» предоставляет возможность клиенту сообщить о неисправности в работе предоставляемого ему «сервиса» или «услуги». Процесс «Информирование клиентов о статусе проблемы» осуществляет обратную связь. Учитывая специализацию систем, процессы следует отнести к OSS системе. Процесс «Анализ поступивших заявок» может инициировать предшествующие процесс заново. Связь с клиентом занимает больше времени чем повторная отправка сигнала от сигнализации сетевого элемента. Для экономии времени, отнесем алгоритм к OSS системе. NMS система напрямую взаимодействует с множеством EMS систем и собирает статистику работы. Следовательно, «Предоставление доступа к ведению и анализу статистики ошибок» целесообразно отнести к NMS системе.

Таблица 1.

Распределение процессов, выполняемых системами на этапе «выявления ошибок».

OSS Системы

NMS Системы

EMS Системы

Оповещение службы поддержки об отключении сервисов в результате сбоя.

Предоставление доступа к ведению и анализу статистики ошибок.

Сигнализация и оповещение об ошибках.

Анализ поступивших заявок.

   

Информирование клиентов о статусе проблемы.

   

При выявлении отказов, после работы процесса «Сигнализации и оповещения об ошибках» в EMS системе, данные передается в виде сообщений протокола SNMP или сообщения проприетарного протокола, используемого комплексом управления, к OSS системе, где полученное сообщение анализируется. На основании полученного и проанализированного сообщения открывается заявка. Информирование клиентов о статусе проблемы после инициации обновляется каждый раз как приходит новое сообщение к OSS системе, связанное с ошибкой. Алгоритм последовательного выполнения процессов на данном этапе отражен на рис. 3.

Рисунок 3. Алгоритм выполнения этапа «выявления ошибок».

Стандарт [3] предлагает для реализации этапа «локализации ошибок» набор процессов:

  • Запуск и проведение диагностики

  • Локализация неисправности сетевых элементов

  • Локализация неисправности на уровне сети

  • Проверка параметров подключения

  • Поведение систем при локализации ошибки

Результат распределения процессов по системам на данном этапе отражено в таблице 2. Для оперативного сбора и анализа данных отнесем процесс «Мониторинг и управление поведением системами при локализации ошибки» к OSS системе. Процесс «Проверка параметров подключения» не используется. Его функции дублируются процессом «Локализация неисправности на уровне сети».

Таблица 2.

Распределение процессов, выполняемых системами на этапе «локализации ошибок».

OSS Системы

NMS Системы

EMS Системы

Мониторинг и управление поведением системами при локализации ошибки

Запуск и проведение диагностики.

Локализация неисправности сетевых элементов

 

Локализация неисправности на уровне сети

 

Локализация ошибок заключается в том, что OSS система, на основании заявки, формирует план анализа для остальных систем комплекса. Во-первых, сообщение передается к NMS системе где проходит анализ состояния сети. После выявления ошибки, либо проверяется параметры использования протоколов на сетевом и транспортном уровне, либо формируется сообщение к EMS системе, отвечающей за неисправную часть сети. По окончанию процесса OSS система собирает данные. Алгоритм последовательного выполнения процессов на данном этапе отражен на рис. 4.

Рисунок 4. Алгоритм выполнения этапа «локализации ошибок».

Стандарт [3] предлагает для реализации этапа «исправление отказов» набор процессов:

  • Управление функцией восстановления процесса.

  • Организация ремонта с набором функций клиента.

  • Планирование и диспетчеризация процесса восстановления

  • Функция коррекции неисправности сетевого элемента.

  • Функция автоматического восстановления.

Результат распределения процессов по системам на данном этапе отражено в таблице 3. Процесс «Управление функцией восстановления процесса» подготавливает решение, либо через инструкции для клиента, либо через внутренние сервисы, реализованные в другой системе. Предполагается частичное, временное и полное восстановление системы. Таким образом процессы «Функция коррекции неисправности сетевого элемента» и «Функция автоматического восстановления» при параллельном выполнении улучшаю временные и вероятностные характеристики алгоритма.

Таблица 3.

Распределение процессов, выполняемых системами этапе «исправления отказов».

OSS Системы

NMS Системы

EMS Системы

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

Планирование и диспетчеризация процесса восстановления.

Функция коррекции неисправности сетевого элемента.

Организация ремонта с набором функций клиента

 

Функция автоматического восстановления

Восстановление отказов инициируется OSS системой сразу после получения сигнала о неисправности. После того как собрана информация о неисправности формируется решение на использование различных средств восстановления. В зависимости от ситуации, OSS система составит заявку для решения с использованием возможностей клиента, или формирует сообщение к NMS системе. NMS система планирует мероприятия по восстановлению элементов сети. Формируются задания для отдельных EMS систем, где уже предусмотрены мероприятия по автоматическому восстановлению корректной работы. Если подобные мероприятия не имеют эффекта EMS система формирует подробный отчет о проводимых мероприятиях и состоянии системы для дальнейшего исправления ошибок и передает данное сообщение OSS и NMS системе. Алгоритм последовательного выполнения процессов на данном этапе отражен на рис. 5.

Рисунок 5. Алгоритм выполнения этапа «восстановления отказов».

Оптимальные параметры алгоритмов

Эффективность составленных алгоритмов следует оценивать по времени выполнения всех этапов (. Длительность выполнения алгоритмов зависит от вероятности получения верного результата (Р). Если результат выполнения алгоритма оказался неверным, то алгоритм выполнится заново, тем самым увеличив общее время, затрачиваемое на устранения неисправности.

Из рассмотренных процессов следует выделить те, чья длительность сопоставима с выполнением всех действий по устранению отказов или те, что требуют постоянной пересылки сообщений между системами. Такими являются: «планирование и диспетчеризация процесса восстановления», «управление функцией восстановления процесса», «запуск и проведение диагностики» и «Информирование клиентов о статусе проблемы».

К повторному запуску процесса «запуск и проведение диагностики» могут привести результаты алгоритма «локализация неисправности на уровне сети» или «локализация неисправности сетевых элементов». Процессы «управление функцией восстановления процесса» и «планирование и диспетчеризация процесса восстановления» могут выполнятся повторно, если последующие процессы не дали положительного результата.

Следовательно, вероятностный коэффициент неудачи следует применять не к самому процессу с несколькими последующими процессами, а, к сумме времени выполнения, исполняемого и выбираемого процессов.

Процесс «функция коррекции неисправности сетевого элемента» и «Функция автоматического восстановления» инициируется предыдущем процессом параллельно. При этом время считается одним коэффициентом на два процесса как максимальное время работы одного из двух процессов. Вероятностный коэффициент считается как вероятность отказа зарезервированного элемента.

Время, затраченное на процесс «Информирование клиентов о статусе проблемы» не включается в общее время решения проблемы, поскольку, является вспомогательным процессом.

Списоклитературы

  1. Рекомендация МСЭ-Т М.3100. Общая информационная модель сети. - 2005.

  2. ITU-T Recommendation M.3200. TMN management services and telecommunications managed areas: overview. - 1997.

  3. ITU-T Recommendation M.3400 TMN management functions. – 2000.

Просмотров работы: 375