Данный модуль получает статистические данные о прошедшем трафике в виде SFlow потока аналогично агенту для протокола NetFlow, посылаемого маршрутизатором по протоколу UDP, что предъявляет соответствующие требования к каналу передачи данных между маршрутизатором и сервером, на котором функционирует агент SFlow. В большинстве случаев агент SFlow рекомендуется размещать в той же Ethernet сети, что и маршрутизатор. В зависимости от интенсивности информационного потока, проходящего через маршрутизатор, SFlow поток может также иметь разную интенсивность, однако параметры экспорта потока настраиваются в отличие от NetFlow что является преимуществом. Дэйтаграммы протокола могут отсылаться агенту периодически с задаваемым интервалом, вне зависимости от того имеет место трафик или нет. Так же имеется режим отправки дэйтаграмм по мере накопления статистических данных устройством.

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

Агент для протокола SFlow способен работать в режиме SAFE, когда канал между сервером и агентом ненадежен, или обладает недостаточной пропускной способностью. В этом случае регистрация и хранение первичных данных осуществляется на локальном сервере (доступа) на котором установлен агент. Такой подход минимизирует объем передаваемых данных между сервером и агентом, и позволяет осуществить перехват управления доступом абонентов в сеть в случае отсутствия связи с центральным хранилищем, обеспечивая блокировку и разблокировку абонентов по локальным данным известным на момент пропадания связи с центральной БД. При восстановлении связи происходит автоматическая репликация баз данных агента и сервера.

Рассмотренные протоколы нашли широкое применение в различных системах управления сетями передачи данных. Каждый их них имеет свои достоинства и недостатки.

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

Протокол NetFlow накапливает в памяти статистику и затем отправляет эти данные NetFlow-коллектору, который в свою очередь заносит полученные данные в базу данных для дальнейшего анализа. Данный способ получения данных удобен, так как в этом протоколе не используются агенты, собирающие информацию у системы. Информация, получаемая по протоколу NetFlow, идеально подходит для целей мониторинга производительности и биллинга.

Протокол sFlow еще не нашёл широкого применения, но уже используется в некоторых новых линейках оборудования HP. Специфичный интерфейс ASIC также позволяет выделять этот протокол как очень перспективный (данный интерфейс потенциально может участвовать в мониторинге сети при отсутствии 3го уровня модели OSI; также любопытно, что в него может быть встроен собственный процессор для работы интерфейса как анализатора трафика)

NMS зачастую работает над системой управления элементами сети Element Management System (EMS). EMS можно условно расположить на EML модели LLA TMN. Так одна EMS может отвечать за определённый тип оборудования одного производителя. EMS должны выполнять все функции модели FCAPS рекомендации МСЭ-Т М.3400. Можно сказать (по аналогии с компьютерной системой, т.к. EMS являются совокупностью аппаратных и программных средств), что EMS имеет “северный” и “южный” интерфейс. “Северный” интерфейс обычно направлен в сторону NMS (или OSS при определённом сценарии развёртывания сети), а “южный”-в сторону устройств для взаимодействия с ними. Если говорить в терминах TMN рекомендации M.3010, то можно сказать о следующем факте расположении относительно друг друга NMS и EMS, проиллюстрированном на рисунке 11.

Таким образом, можно сказать, что NMS и/или EMS, согласно рекомендации М.3010, должны взаимодействовать с другими функциональными элементами своей TMN посредством интерфейсов типа Q, а с одноименными элементами других TMN - посредством интерфейсов X. Как было сказано выше, обычно NMS и EMS поставляются производителем оборудования в рамках заказа оборудования и развёртывания серверов под NMS и EMS данного производителя. Поэтому технологических сложностей во взаимодействии оборудования, EMS и NMS обычно не происходит. Так, к примеру, для управления продуктовыми линейками BroadGate, XDM и Apollo, компании ECI Telecom, для каждой из которых в системе должна быть своя EMS, используется программный продукт LightSoft ( в качестве единой NMS), разработанный этой же компанией, что позволяет максимально обеспечить взаимодействие оборудования различных EMS используется Для взаимодействия NMS двух разных производителей или EMS одного и NMS обычно требуется доработка соответствующего интерфейса. Так было в случае с оборудованием линейки Syncom, которую компания ECI Telecom в своё время выкупила себе и также установила под управление LightSoft. Фактически, тогда для этой NMS EMS Syncom представлял собой EMS стороннего производителя и полный функционал управления оборудованием данной линейки через LightSoft был осуществлён относительно не сразу. Подробнее продукт LightSoft будет рассмотрен далее в рамках данной работы.

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

EMS может применять на сетях операторов связи, где стоит задача управлением большим количеством однородных устройств или даже моногенных доменов, образованных таким оборудованием. EMS обладает важным для оператора связи свойством масштабируемости и предоставляет возможность упрощенной интеграции с системами сторонних производителей. Это соответствует ожиданиям поставщиков услуг по системам OSS.

2.2.2 Системы OSS/BSS

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

По мере роста ассортимента и объемов услуг оборудование становилось всё боле сложным и число компьютеров увеличивалось. В некоторых системах поддержки число компьютеров могло исчисляться тысячами, причем в одной и той же сети могли размещаться буквально все типы существующих операционных систем, баз данных, структур данных и методов связи. Многие системы представляли собой разработки различных ИТ-отделов, лабораторий и подразделений компаний. Как правило, они предназначались для конкретного процесса или оператора, оказывающего вполне определенную услугу. Изменение этой системы под соответствующие нужды требовало значительных временных и ресурсных затрат, что негативно сказывалось на качестве конечного сервиса.

По мере роста количества и усложнения архитектуры систем среди специалистов в данной области появилось мнение, что часть процессов может быть автоматизирована. На том историческом этапе развития телекоммуникаций топ-менеджмент не видел необходимости унификации и развития систем поддержки операций и бизнеса ввиду узкой специализации компаний^[1].

Таким образом, к концу 90х на рынке телекоммуникаций появилось большое количество различных систем OSS/BSS, для которых всё чаще выдвигались требования взаимодействия друг с другом. На сегодняшний день можно наблюдать определённые сложности отрасли связи, которые возникают при интеграции систем поддержки операторской деятельности. Как было отмечено выше, это, прежде всего, связано с тем, что изначально системы поддержки бизнеса и операций разрабатывались для выполнения вполне определённой функции, иногда - специально под определённые низкоуровневые элементы в качестве источника информации (элементы NML и EML-в зависимости от реализации OSS; применительно к BSS данное замечание неверно). Таким образом, при необходимости обмена данными между двумя OSS (такая необходимость возникает при запуске параллельной OSS относительно существующей - для новой функции или при замене устаревшей OSS обновлённой) могут возникнуть определённые проблемы. Более сложно вопрос обстоит с BSS - сложными комплексными системами, отвечающими за поддержку управления жизненным циклом продукта, инфраструктуру, стратегию предприятия, комплексный менеджмент предприятия - в зависимости от реализации BSS (различные процессы первого уровня декомпозиции eTOM, относящиеся к стратегии бизнеса, отношениям с клиентами и поставщиками и другими глобальными вопросами в деятельности предприятия). Внедрение BSS на существующую инфраструктуру, как верхнеуровневой системы, всегда является крайне сложной задачей и требует длительного анализа по внедрению данной системы.

Описанные выше замечания могут быть минимизированы в будущем при использовании открытых систем и стандартизованных интерфейсов. В частности, решению данной задачи на эталонной сети может помочь использование интерфейсов типа Q и X согласно рекомендации М.3010 МСЭ-Т для взаимодействия разных функциональных блоков. Так же, как упоминалось выше, в качестве Q-интерфейсов между NMS и OSS могут использоваться MTOSI или CORBA - интерфейсы. Рассмотрение интерфейсов типа MTOSI или CORBA для упрощения взаимодействия гетерогенных и разных технологических систем в рамках данной работы не производится. Пример такого эталонного взаимодействия гетерогенных систем приведён на рисунке 12.

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

На сегодняшний день можно наблюдать отсутствие международных рекомендаций и стандартов для построения систем NMS, OSS и BSS. Но в то же самое время существуют международные стандартизующие документы относительно построения эффективных и прозрачных систем управления сетями с точки зрения процессов. Таким образом, становится вполне решаемой задачей вопрос организации процессно-ориентированных систем с иерархической структурой, построенной с минимальным воздействием на структуру в плане её изменения. При этом в структуре должны быть использованы принципы, обеспечивающие максимальную непривязанность и абстрактность относительно решений, используемых на соседних уровнях TMN (или функциях/процессах eTOM). Это позволит реализовать оптимальное взаимодействие современных гетерогенных сетей, отвечая различным задачам компании-оператора и клиента.

2.2.3 Программная реализация систем управления

В последние годы всё более остро встаёт вопрос о взаимодействии традиционных систем управления и систем класса OSS/BSS на сетях операторов связи. При формировании новых систем и попытках обеспечения взаимодействия существующих структур (к примеру, после приобретения федеральным провайдером регионального) встаёт вопрос взаимодействия и интеграции данных систем.

Самым распространённым и гибким решением на сегодняшний момент является так называемое “midleware” - промежуточный слой для обеспечения взаимодействия систем. изначальным вариантом, получившим широкое распространение, было сочетание MTMN с CORBA. Такое решение имело целый ряд недостатков, в частности узкий круг применения - только между уровнями EML и NML модели TMN и необходимость наличия индивидуального интерфейса для взаимодействия каждой EMS. Впоследствии после ряда итераций для MTMN было предложено использовать XML в качестве IDL.

Наиболее актуальной альтернативой MTOSI/XML на сегодняшний день представляется инициатива OSS/J TMForum, которая в качестве языка описания взаимодействия использует язык Java и его приложения. Основной разницей между MTOSI/XML и OSS/J является объект действия: в MTOSI/XML им является процесс, а в OSS/J - сущность. Это является следствием того, что при разработке концепций преследовались различные цели: MTMN, а в последствии MTOSI, должна была обеспечить независимость от гетерогенности сетевых элементов и транспортных технологий, в то время как OSS/J разрабатывалась в качестве надстройки для взаимодействия систем OSS/BSS вне зависимости от используемого верхнеуровнего протокола (JMS, HTTP и т.д.).

В силу очевидной необходимости взаимодействия брокеров объектных запросов (ORB) систем, построенных с согласно концепции TMForum MTOSI и OSS/J, которая выделилась в отдельное направление развития, в обоих сообществах ведутся работы по формированию рекомендательных документов для обеспечения взаимодействия таких структур и API, соответственно.

Пример такого рекомендательного взаимодействия приведён ниже.

Рисунок 13. Общая эталонная структура трансляции IDL CORBA в OSS/J - объекты

Сегодня на рынке представлен широкий спектр программного обеспечения для реализации различных средств управления инфраструктурой и процессами предприятия в зависимости от требований и инвестиционной способности компании-клиента. Всю массу решений можно, по-большому счёту, разделить на две значительные группы по разработчику. Так разработчиком может выступать сторонняя компания - разработчик программного обеспечения и компания - вендор, разрабатывающая решения в первую очередь под своё оборудование. В более редких случаях создателем программного продукта (обычно класса OSS) могут выступать работники самой компании - оператора/провайдера. В случае, когда в качестве разработчика системы управления выступает компания - разработчик программного обеспечения на выходе получается более унифицированный - «коробочный» продукт, который может обладать ( а может и не обладать - зависит от политики компании) адаптивностью и гибкостью к нуждам клиента. Во втором случае, когда разработчиком выступает вендор, решение является менее гибким, но зато гарантированно работает и оперативно поддерживается производителем.

Рассмотрев представленные решения, можно сделать следующие общие выводы.

1. Системы в своём большинстве строятся на основе стандартизованных интерфейсов, что призвано обеспечить взаимодействие с другими системами.

2. Системам управления присуща модульность, что положительно сказывается на унификации сборного решения и лояльности клиента (нет затрат на ненужный функционал).

3. Все системы управления не являются комплексными, покрывающими все сквозные бизнес-процессы предприятия (решение HP является исключением, подчёркивающее общую тенденцию).

4. Нет решений, базирующихся на несетевом подходе локализации проблем (нет отдельной инфраструктуры/системы управления в составе комплексной - для разрешения проблем ниже сетевого уровня модели OSI).

Данные заключения позволяют систематизировать общие тенденции систем управления, полученные в результате резюмирования общедоступных материалов.

3. Цель и задачи исследования