Интеграция телекоммуникационных сетей в системе мониторинга с использованием доменных онтологий

Значительная часть современных систем мониторинга телекоммуникационных сетей (ТС) применяется для решения следующих типовых задач мониторинга [1]: производительности сети; аварийных ситуаций и учётных записей пользователей и их действий.

Современные ТС включают в свой состав многие подсистемы и имеют динамическую структуру. В этих условиях системы мониторинга при решении практических задач должны быть способны использовать одновременно данные различных подсистем (например, данные о топологии сети, правах доступа, данные биллинговой подсистемы), а также - к перенастройке при изменении структуры сети. Существует множество доступных инструментов мониторинга как с открытым исходным кодом, так и коммерческих [2]. Операторы ТС заинтересованы в получении данных от систем мониторинга всех сегментов своей сети независимо от применяемых в них решений и технологий. Для этого необходима унификация моделей сегментов сетей и их параметров с последующей интеграцией этих моделей в рамках единой системы мониторинга, которая позволит получать данные мониторинга от всех сегментов сети.

В случае реализации сервисно-ориентированного подхода построения системы мониторинга, возможна реализация облачной платформы мониторинга, позволяющей подключить к ней сети различных операторов ТС и интегрировать в неё ТС без построения собственных систем мониторинга, что снизит их операционные издержки. Поэтому эффективное подключение сетей операторов к облачной платформе является актуальной задачей. Для решения задачи построения облачной платформы мониторинга в качестве основного архитектурного решения предложены системы мониторинга ТС на основе графов знаний (ГЗ) [3]. В статье [4] в рамках разработки архитектуры системы мониторинга на основе ГЗ проработаны вопросы использования доменных онтологий для интеграции различных сегментов сетей одного оператора [5], а также интеграция сетей различных операторов в рамках единой облачной платформы мониторинга [6], когда сети или их сегменты построены на основе доменных онтологий ТС. Используемые для облачной платформы мониторинга онтологии могут относиться к трём уровням [7-11]: онтологии верхнего уровня (или базовые онтологии), онтологии среднего уровня (или онтологии предметной области, ПрО) и онтологии нижнего уровня – онтологии приложений. Онтология верхнего уровня должна быть достаточно компактной, поскольку онтологии ПрО наследуют её классы и свойства [12, 13]. Наиболее общие классы онтологии конкретной ПрО могут быть помещены в онтологию верхнего уровня. Онтологии верхнего уровня способствуют ликвидации логического разрыва между разными ПрО. Онтологию среднего уровня можно рассматривать как предметно-ориентированную часть словаря. Как правило, онтологии нижнего уровня являются публичными, потому что они содержат общую информацию о ПрО. Дополнительные сведения о ПрО помещаются в онтологию уровня приложения. Онтология приложения не является онтологией в строгом смысле, поскольку онтологии этого типа не являются общими, а представляют собой словарь для конкретного приложения или системы [14, 15]. Однако часто сети оператора спроектированы без использования онтологий и представляют собой сеть из связанных объектов различных типов, данные о которых представлены в том или ином формате.

В статье поставлена задача и построен алгоритм автоматизированного сопоставления классов доменных онтологий с элементами моделей сети оператора ТС, дано описание предлагаемого алгоритма и рассмотрен пример его использования при интеграции нового сегмента в сеть оператора кабельного телевидения.

1    Онтологии для телекоммуникационных сетей

Онтологии используются как словарь, в котором представлен набор классов и отношения между этими классами в определённой ПрО. Такое представление имеет формально определённую и общепринятую структуру [16-19]. Доменная онтология может быть представлена как база знаний ПрО. Для домена ТС онтология описывает набор сетевых узлов, таких как коммутаторы, маршрутизаторы, устройства хранения и связи между ними. Существует ряд онтологий, разработанных для ТС.

• ■    Онтология NDL (от англ. Network Description Language - язык описания сети) используется для описания субонтологий. Существуют субонтологии: топологии сети , которая описывает взаимосвязи между сетевыми устройствами; слоёв , описывающая применяемые технологии; функций сети - описывает функциональные возможности сети; ПрО - создаёт абстрактные представления ТС; физического уровня сети - описывает физические представления элементов ТС [20].

• ■    Онтология TSDO (от англ. Telecommunications Service Domain Ontology - доменная онтология телекоммуникационных сервисов) [21] определяет концепции и отношения для описания знаний о домене телекоммуникационных услуг и поддерживает описания

свойств ТС. TSDO основана на подходе семантического описания ( TelecomOWL-S ) и построена для услуг сети электросвязи [22]. Это даёт возможность точного описания и сопоставления услуг ТС с аннотированной семантической информацией в случае открытой интегрированной сети [23].

• ■    Онтология беспроводной сети 3G [24] разработана для конфигурации транспорта беспроводной сети и включает две субонтологии: онтологию ПрО и онтологию решаемых задач.

• ■    Мобильная онтология [25] предоставляет возможность реструктурировать онтологии. Это масштабируемое решение с несколькими подключаемыми субонтологиями: сервисы, профили, контент, сущности, контекст, субонтология коммуникационных ресурсов.

• ■    Онтология OOTN (от англ. Ontology for Optical Transport Networks - онтология для оптических транспортных сетей) [12] - это онтология нижнего уровня.

• ■    Онтология, принятая в « OpenMobileNetwork » [26], - связанный открытый набор данных о мобильных сетях и устройствах разработан на платформе с открытым исходным кодом.

• ■    Онтология ToCo (от англ. TOUCAN Ontology ) [27] - одна из современных структурированных онтологий домена ТС.

• ■    Онтология TNMO (от англ. Telecommunication Networks Monitoring Ontology - онтология мониторинга ТС) [5] - онтология уровня приложения, предложенная как расширение доменных онтологий ТС ( TSDO и ToCo ) для целей проектирования систем мониторинга ТС на основе ГЗ. Онтологии для ГЗ определяют словарь, используемый ГЗ. Использование онтологий для ГЗ позволяет описывать разнородные статические и динамические данные о ТС с помощью классов, отношений и атрибутов. Использование онтологий также позволяет интегрировать информационные системы на базе ГЗ. Онтологию можно легко расширить, добавляя новые классы, отношения и атрибуты. Структура ГЗ на основе онтологии позволяет использовать стандартный набор инструментов Semantic Web и RDF , включая SPARQL [28], для извлечения данных.

Для построения моделей сегментов сети обычно используются доменные онтологии для ПрО ТС, например, такие как TSDO или ToCo . При построении системы мониторинга для описания ПрО мониторинга ТС может использоваться онтология TNMO , которая описывает отслеживаемые в процессе мониторинга события ТС и перечни типов элементов, включая их параметры. На уровне онтологии TNMO происходит интеграция классов онтологии мониторинга с классами доменной онтологии путём определения связей эквивалентности классов tnmo:sameAs [6]. Такая интеграция позволяет использовать разработанные модели данных для систем мониторинга, содержащиеся в TNMO с разнообразными сегментами сетей операторов, построенных на основе доменных онтологий.

Когда оператор одновременно эксплуатирует сегменты сети, построенные на оборудовании и программном обеспечении разных поколений, часто более старые по времени создания сегменты не поддерживают онтологические модели. В этом случае требуется интеграция таких сегментов с онтологической моделью платформы мониторинга. Для такой интеграции возможно использовать метод обогащения онтологии, описанный в работе [29].

2    Постановка задачи

В качестве типового случая интеграции сети оператора в облачную систему мониторинга рассматривается интеграция сети или сегмента сети оператора, построенных без использования онтологических моделей. Архитектура облачной системы мониторинга построена на основе онтологии TNMO, поэтому при интеграции сегмента сети, модель которого не использует какую-то доменную онтологию, требуется применить алгоритм сопоставления эле- ментов сегмента сети с классами онтологии TNMO. Для формулирования требований к такому алгоритму необходимо учитывать следующие особенности функционирующих ТС:

• ■    ТС имеют сложную динамическую структуру, основным источником информации о них являются оперативные данные, полученные из сети;

• ■   бизнес-процессы операторов ТС имеют высокую сложность, их выполнение требует тес

ного взаимодействия между несколькими информационными системами, в том числе системами сторонних производителей;

• ■    особенности, определяемые целевыми группами абонентов, техническими ресурсами и т.д..

Сформулированы требования к алгоритму сопоставления данных. Алгоритм должен:

• ■    обеспечивать возможность сопоставления с доменной онтологией разнородных статических и динамических данных о ТС без потери информации;

• ■    учитывать возможность использования различных доменных онтологий сторонними производителями систем, эксплуатируемых в ТС;

• ■    учитывать случаи, когда число параметров мониторинга изменяется на стороне подключаемой сети оператора;

• ■    обеспечивать расширение онтологии TNMO на уровне приложения.

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

3    Интеграция сети оператора

Логическая схема интеграции сети оператора, построенной без использования онтологической модели ТС, в облачную платформу мониторинга представлена на рисунке 1.

Рисунок 1 - Логическая схема интеграция сети оператора, построенной без использования онтологической модели ТС, в облачную платформу мониторинга

Онтологии ТС уровня ПрО (доменные онтологии ТС) содержат описания типов элементов ТС. Для элементов сетей операторов связи определяются соответствующие им элементы в доменных онтологиях, элементы связаны через tnmo:sameAs. Типы событий мониторинга связываются с уже описанными типами событий в онтологии TNMO также через tnmo:sameAs. В случаях, когда тип события не определён в онтологии TNMO, онтология расширяется путём добавления нового типа события (связь ‘imported’ на рисунке 1). При построении онтологии TNMO были использованы базовые и доменные онтологии [5].

TNMO является многоуровневой онтологией со следующими уровнями: уровнем базовой онтологии, уровнем онтологии ПрО и уровнем онтологии приложения. На уровне онтологии ПрО используется онтология TSDO или ToCo . Онтологии ПрО используются без модификаций. Онтологии базового уровня импортируются в онтологию ПрО.

TNMO связана с доменными онтологиями, используя следующие общие классы:

• ■    Device - любое устройство ТС;

• ■    Link - проводное или беспроводное соединение ТС;

• ■    Interface - любой интерфейс ТС;

• ■    Service - любая услуга ТС;

• ■    Data - любой элемент данных в ТС (может быть описан в базовой онтологии).

Обобщённая информационная модель элемента сети оператора, построенной без онтологической модели, представлена на рисунке 2.

Рисунок 2 - Обобщённая информационная модель элемента сети оператора, построенной без онтологической модели

Предполагается, что каждый элемент сети относится к определённой сети оператора (ID Сети Оператора), к опреде- лённому типу (Тип Элемента Сети) и имеет ряд атрибутов

(Атрибуты Элемента Сети).

При интеграции подобной сети типы элементов сети добавляются в онтологию приложения TNMO, и её элементы далее связываются с элементами онтологии доменного уровня.

На рисунке 3 показан пример, когда в онтологию TNMO добавляется новый тип элемента сети – «Тип Элемента Сети», для него находится общий класс в доменной онтологии –

“net:Device” , для атрибута, характеризующего исходящий трафик в онтологии TNMO, находится общий атрибут “tnmo:OctetsSent” . Элемент “tnmo:Parameter_M” описывает параметр сетевого устройства для мониторинга.

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

4 Алгоритм сопоставления классов онтологии с типами элементов ТС

Модели сети операторов, даже в условиях, когда они не строились на основе доменных онтологий, содержат большой объём метаданных о каждом элементе. Наличие метаданных позволяет сопоставлять типы элементов и их атрибуты с классами и свойствами доменной онтологии или TNMO . Сопоставление для части элементов выявляется в автоматическом режиме, для остальных элементов - выполняется с привлечением экспертов. Алгоритм сопоставления классов онтологии с элементами ТС представлен на рисунке 4.

Перед выполнением алгоритма необходимо составить список типов элементов, входящих в сеть оператора. Количество элементов сети – I (i = 1, 2, … , I) . Для каждого типа элемента составляются перечни атрибутов. Количество атрибутов для i -го элемента - J i (j = 1, 2, … , J i ).

Рисунок 3 - Интеграция элемента сети оператора на уровне онтологии для случая с событием мониторинга – мониторинг параметра элемента сети

Входные данные:

список типов элементов сети оператора;

списки атрибутов для каждого типа элемента сети оператора.

Выходные данные:

расширенная онтология TNMO ;

список типов элементов сети оператора для ручной обработки экспертом.

Алгоритм включает в себя следующие шаги:

• 1)    устанавливается начальное значение счётчика типов элементов сети оператора i = 1 ;

• 2)    производится поиск соответствия метаданных элемента сети i и метаданных классов доменной онтологии;

• 3)    если соответствующий элемент найден в доменной онтологии, то переход на Шаг 4, если нет, то переход на Шаг 5;

• 4)    формирование связи tnmo:sameAs между элементом сети i и соответствующим классом доменной онтологии на уровне онтологии TNMO , переход на Шаг 6;

• 5)    элемент сети i помечается для поиска соответствия с классом доменной онтологии с привлечением эксперта в ручном режиме;

• 6)    установка счётчика атрибутов для элемента сети оператора i: j=1 ;

• 7)    поиск соответствия метаданных атрибута j элемента сети i и атрибутов классов в онтологии TNMO ;

• 8)    если соответствующий атрибут найден в онтологии TNMO , то переход на Шаг 9, если нет, то переход на Шаг 10;

Рисунок 4 - Алгоритм сопоставления классов онтологии с элементами ТС

• 9)    формирование связи tnmo:sameAs между атрибутом j элемента сети i и соответствующим атрибутом класса онтологии TNMO , переход на Шаг 11;

• 10)    расширение онтологии TNMO новым атрибутом j для класса, описывающего элемент сети i ;

• 11)    увеличение счётчика атрибутов для элемента сети i: j = j + 1 ;

• 12)    если рассмотрены не все атрибуты для i -го элемента (j <= J i ) , то переход на Шаг 7;

• 13)    увеличение счётчика типов элементов сети i = i + 1 ;

• 14)    если рассмотрены не все типы элементов сети (i <= I) , то переход на Шаг 2;

• 15)    конец.

• 5.1    Описание задачи

• 5.2    OWL представление расширенной онтологии TNMO

Представленный алгоритм позволяет выполнить автоматизированное сопоставление типов элементов сети оператора с классами доменной онтологии, сопоставить атрибуты элементов сети оператора с классами онтологии TNMO и автоматически расширить её, если соответствие не найдено.

5 Пример

Бизнес-задача: Оператор ТС использует систему мониторинга сети, построенную без онтологической модели сети. ТС предоставляет услуги, приложения и доступ к контенту. Требуется подключение данной сети к облачной платформе мониторинга на базе ГЗ, для чего необходимо согласовать классы доменной онтологии с типами элементов сети оператора и расширить онтологию мониторинга TNMO .

Исходные данные: Типы элементов сети оператора и их атрибуты (см. таблицу 1).

Таблица 1 – Типы элементов сети оператора и их атрибуты

Типы элементов ТС
CableTVNetwork	Идентификатор сети оператора кабельного телевидения
STB	Set Top Box – пользовательская телевизионная приставка
NetworkRouter	Сетевой маршрутизатор
VODAsset	Video On Demand Asset - Видеоролик по запросу
PPVEvent	Pay-per-View Event – платная телевизионная передача
Атрибуты элементов ТС
OutgoingTraffic	Переданный сетевой трафик, байт
IncomingTraffic	Полученный сетевой трафик, байт

Расширенные классы онтологии TNMO после подключения сети оператора кабельного телевидения к облачной платформе мониторинга в нотации OWL представлены в следующем виде:

tnmo:CableTVNetwork_STB

tnmo:CableTVNetwork_NetworkRouter

tnmo:CableTVNetwork_VODAsset

tnmo:CableTVNetwork_PPVEvent

tnmo:CableTVNetwork_STB_IncomingTraffic

tnmo:CableTVNetwork_STB_OutgoingTraffic

tnmo:CableTVNetwork_NetworkRouter_IncomingTraffic

tnmo:CableTVNetwork_NetworkRouter_OutgoingTraffic

Полная версия расширенной в соответствии с представленным примером онтологии TNMO доступна в открытом репозитории GitHub [30].

Заключение

В работе предложен новый алгоритм, позволяющий подключить сеть оператора ТС, структура которой описана без использования онтологической модели, к облачной платформой мониторинга. Рассматриваемая облачная платформа мониторинга использует ГЗ в качестве структурной модели ТС, при этом элементы модели описаны в соответствии с многоуровневой онтологией, предполагающей использование ряда общих онтологий, онтологий ТС доменного уровня, таких как TSDO и ToCo , а также онтологии уровня приложения, в качестве которой выбрана онтология TNMO . Интеграция новой модели сети оператора происходит за счёт сопоставления её элементов с классами доменной онтологии и за счёт расширения онтологии TNMO . Представлен пример подключения нового сегмента сети оператора к облачной платформе мониторинга для сегмента сети оператора кабельного телевидения.