Построение систем поддержки и эксплуатации сетей для операторов связи

Размещено на http://www.allbest.ru/

ПЛАН

• 1. Актуальность темы исследования
• 2. Состояние разработанности проблемы в научной литературе
• 2.1 Существующие стандарты и модели международных организаций
• 2.1.1 Рекомендации МСЭ-Т и модель TMN
• 2.1.2 Стандарты TM Forum и концепция NGOSS
• 2.2 Реализация систем управления
• 2.2.1 Системы NMS
• 2.2.2 Системы OSS/BSS
• 2.2.3 Программная реализация систем управления
• 3. Цель и задачи исследования
• 4. Предполагаемые результаты
• 5. Область внедрения предполагаемых результатов
• 6. Эффективность внедрения предполагаемых результатов
• 6.1 Техническая эффективность
• 6.2 Экономическая эффективность
• Список сокращений и переводов
• ЛИТЕРАТУРА
• 1. Актуальность темы исследования
• Телекоммуникационные сети за последние два десятилетия претерпели значительные изменения. Причём это касается всех её составляющих: от клиентского оборудования до способов обеспечения транспорта на магистральном уровне. Под телекоммуникационной (и/или транспортной - в контексте данной работы) сетью следует понимать систему передачи носителей информации, а именно систему технических средств, сообщающих сигналы. Сигналом называется самодвижущийся носитель; транспортирующий себя носитель побуждения.
• Следует отметить, что оконечные устройства клиента генерируют всё больше трафика за счёт количественного и качественного роста мультимедийного контента, тем самым органично соответствуя Закону Мура^[7], согласно которому объём трафика растёт пропорционально экспоненциальной функции. Практически все современные устройства частных клиентов требуют широкополосный доступ к внешним телекоммуникационным сетям (технологии уровня доступа в последние годы также претерпели значительные изменения). Корпоративные клиенты используют сервера, виртуальные АТС, мультимедиа-терминалы и приложения, которые также увеличивают нагрузку на транспортную сеть (ТС). Всё это вызывает ответные реакции по развитию сети у операторов связи. стандартизация международный программный управление
• Одной из основных тенденцей последних лет являются методы развития телекоммуникационных компаний, связанные, в том числе с потребностями клиентов и современными технологиями, позволяющими более гибко использовать свою инфраструкту-ру. Сегодня появились виртуальные операторы, не имеющие собственных сетей; бывшие мобильные операторы занимаются предоставлением услуги широкополосного доступа, а магистральные операторы занимаются построением распределённых центров обработки данных. При этом, зачастую, можно наблюдать ситуацию, когда более крупный «игрок» на рынке поглощает компанию определённого профиля, тем самым «входя» на этот рынок или укрепляя на нём свои начальные позиции.
• В наши дни процесс корпоративного слияния у операторов связи проходит довольно грубо и неструктурированно с точки зрения технического объединения транспортных телекоммуникационных сетей. При этом наблюдается сложность в объединении систем управления данных сетей. Связанные с этим затруднения у исполнителей возникают, зачастую, ввиду гетерогенности оборудования (т.е. поставки оборудования от разных производителей). Операторы связи обычно выходят из данной ситуации посредством организационного перераспределения функций в новой эксплуатации, оставляя транспортные сети (а, следовательно, и системы управления) раздельными в зависимости от производителя. Но такой подход является трудоёмким и вызывает значительные затруднения при поиске проблемного места на сети в случае неполадок в работе. Другим распространённым решением является разработка внутри новой структуру логической «надстройки» над существующими системами управления, призванное позволить эксплуатирующим подразделениям осуществлять управление сетью «сверху» - вне зависимости от программно-аппаратного решения вендора. Но зачастую такие решения не могут или очень сложно интегрируются с системами, предназ-наченными для других задач, как, например, системы инвентаризации сетевых элементов или сбора информации о сетевых ошибках.
• В данных условиях требуется такая реализация комплексной системы управления гетерогенной ТС оператора связи, чтобы она отвечающая следующим критериям:
• 1. Интегрируема с существующими и потенциально новыми ТС;
• 2. Может взаимодействовать с другими корпоративными системами;
• 3. Является оптимальной с точки зрения программно-аппаратной реализации.
• В качестве примера корпоративного слияния можно привести поглощения на российском рынке, когда 01.03.2008 ООО «СЦС Совинтел» (торговая марка «Голден Телеком») стала входить в группу компаний «ВымпелКом»^[7],[8], а с июня 2010 ЗАО «Синтерра» стала входить в ОАО «Мегафон»^[7],[8]. Так оба оператора - «ВымпелКом» и «Мегафон» смогли расширить свои опорные и широкополосные сети. Но такой симбиоз помимо административных, юридических и организационных трудностей также имел ряд сложных технических задач. Требовалось настроить межсетевое взаимодействие различных сегментов сетей, построенных на оборудовании разных вендоров и исторически находящихся в административной зоне ответственности у различных подразделений, которые настраивают/управляют «логикой» данного оборудования и эксплуатируют данное обору-дование физически. При этом данные сети технологически предназначены для реализации одних и тех же функций. Примерно с аналогичной задачей сталкиваются операторы, «снимающие» морально и/или функционально устаревшие линейки оборудования с сети - им требуется настроить взаимодействие старого оборудования с новыми линейками и, зачастую, выбор делается не в пользу производителей оборудования, которое стоит на сети (так, к примеру, обстоят дела с оборудованием канадской компании Nortel Networks или оборудованием Alcatel - до объединения с Lucent Technologies - операторы просто не могут обеспечить моновендорность сети из-за упразднения самих компаний). С такой задачей столкнулся национальный оператор «Ростелеком» в связи с активной модернизацией своей сети в последние годы. В обоих случаях, как было упомянуто выше, требуется ряд организационных и технических мер и проведение процедур для эффективного использования сети для нужд бизнеса.
• 2. Состояние разработанности проблемы в научной литературе

2.1 Существующие стандарты и модели международных организаций

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

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

Основополагающей международной организацией в области стандартизации телекоммуникаций на текущий момент является Международный союз электросвязи - МСЭ (ITU -- International Telecommunication Union), работающий под эгидой ООН. В его составе работает три сектора: радиосвязи (МСЭ-R), стандартизации (МСЭ-Т), а также сектор развития электросвязи (МСЭ-D)^[10].

Помимо МСЭ немаловажную роль в области международной стандартизации в области телекоммуникаций играет Международная организация по стандартизации ISO (International Organization for Standardization). МСЭ и ISO плотно взаимодействуют в области стандартизации, что на выходе даёт частичное дублирование и взаимное отображение рекомендаций МСЭ и стандартов ISO.

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

Ещё одной организацией, стандарты которой будут интересны к рассмотрению в рамках данной работы, является TM Forum (TeleManagement Forum) -- отраслевая некоммерческая ассоциация предприятий в области телекоммуникаций: операторов, производителей, сервис-провайдеров и т.д. Данная организация ставит перед собой основной целью оптимизацию деятельности предприятий посредством выработки стандартов, рекомендаций и моделей для информационных технологий в телекоммуникационной отрасли^[7].

Как было сказано выше, основополагающей международной организацией в области стандартизации является МСЭ. При этом существует практика отображения стандартов других организаций в рекомендациях МСЭ-Т. Особый интерес представляют рекомендации, «мигрировавшие» из стандартов TM Forum в рекомендации МСЭ-Т группы М.3050.х-модель eTOM (GB921-TMF), о которой будет рассказано далее и Х.700 - определение структуры управления для взаимосвязи открытых систем (ISO 7498-4).

2.1.1 Рекомендации МСЭ-Т и модель TMN

Как было сказано выше, управление современными телекоммуникационными сетями - процесс довольно сложный и с технической, и с организационной точек зрения. Особого внимания требуют стандарты серии M (Management)-серия, в которой описываются функции и модели управления процессами в телекоммуникационной компании на различных уровнях. Так, особое внимание мы уделим стандартам: М.3010, где излагаются общие принципы планирования, функционирования и технического обслуживания системы управления электросвязью и вводится модель сети управления TMN - Telecommunications Management Network, М.3400, где приводятся функции управления TMN, М.3050, в котором описывается модель eTOM , а также стандарт серии Х - Х.700 - определение структуры управления для взаимосвязи открытых систем. Также полезными при изучении данного вопроса могут быть рекомендации M.60, в которой проводится перечисление и описание терминов, используемых в рекомендациях МСЭ-Т, серии «Management»^[9], и рекомендация M.3000, в которой приводится краткий обзор всех рекомендаций серии «Management» и обозначается их взаимосвязь^[10],

Одним из основных, интересующим нас, результатом работы МСЭ-Т в области стандартизации является рекомендация М.3010, в которой вводится понятие модели TMN- Telecommunications Management Network и свойств её компонент. Разработанная ещё в далёком теперь 2000 году, эта рекомендация надолго определила стандарты развития систем управления телекоммуникационных компаний.

Концепция TMN проводит эталонную декомпозицию процесса управления по трём взаимоувязанным компонентам, называемых «архитектурами» ввиду обширного спектра возлагаемых на TMN задач. В рекомендации M.3010 в явном виде выделены^[11]:

Функциональная архитектура TMN, показывающая распределение функционала по элементам сети управления;

Информационная архитектура сети, описывающая TMN с точки зрения взаимодействия открытых систем согласно модели OSI, при этом опираясь на объектно-ориентированный подход;

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

В данной рекомендации представлены архитектурные требования для построения TMN, отвечающей потребностям различных операторов связи в планировании, обеспечении инфраструктуры, развёртывании, текущей работе и администрированию сетей и служб связи^[11]. Примеры и план решаемых задач при внедрении TMN освещены в рекомендации M.3013.

Стоит отметить, что сеть TMN в рекомендации М.3010 представляется эталонной структурой, без привязки к конкретным технологиям, протоколам и техническим решениям. Она, как и другие рекомендации МСЭ-Т носит рекомендательный характер для обеспечения взаимодействия гетерогенных сетей. Общая схема сети представлена на рисунке 1. Необходимо иметь ввиду, что модель условна и границы TMN могут быть расширены в т.ч. на клиентские устройства.

С точки зрения оператора связи, модель TMN описывает услуги для управления сетями, которые определяются потребностями самого оператора к управлению сетью. Управление телекоммуникационной инфраструктурой происходит через специальные опорные точки функциональной архитектуры, реализуемые в виде стандартизованных или нестандартизованных интерфейсов TMN физической архитектуры. Для сообщения и управления аппаратурой и средствами связи TMN соединяется с DCN (Data Communication Network), которая фактически является ТС для TMN (принято считать, что располагается на первых четырёх - транспортных - уровнях OSI). В M.3010 отдельно отмечается, что DCN не является транспортной инфраструктурой телекоммуникационной сети, но частично может эту инфраструктуру использовать.

Эталонная TMN, построенная по рекомендации, должна быть способной к выполнению сложных и комплексных задач по управлению сетями предприятий. Так, в список объектов, потенциально попадающих в управленческую сферу действия TMN, могут быть включены различные объекты сетевой инфраструктуры^[11].

Размещено на http://www.allbest.ru/

В рекомендации M.3010 указывается на возможность рассмотрения логической многоуровневой архитектуры сети TMN (LLA-Logical Layered Architecture), которая предлагает подходы структурированного управления сетью. В этой модели все функции делятся в зависимости от иерархической принадлежности с точки зрения предприятия в целом. Эта функциональная архитектура содержит функциональные блоки, связанные между собой эталонными точками. Такой подход значительно упрощает спецификацию и разработку интерфейсов для данной системы.

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

Эталонные точки реализуются в интерфейсах. Обозначаются аналогично эталонной точке - в зависимости от функционала (X-интерфейс - в эталонной точке x, Q-интерфейс - в эталонной точке q, G-интерфейс - в эталонной точке g, M-интерфейс - в эталонной точке m, F-интерфейс - в эталонной точке f). Интерфейсом в данной терминологии является обобщенной архитектурной условностью, посредством которого обеспечивается взаимодействие между физическими блоками в эталонных точках. Все эталонные точки в зависимости от их месторасположения в структуре TMN представлены на рисунке 2.

На данном рисунке также представлены основные функциональные блоки модели TMN. Функциональным блоком называется наименьшая из реализуемых функциональных единиц управления модели TMN.

Блоком функций операционной системы (Operations systems function block - OSF) называют функциональный блок, который работает с информацией, связанной с управлением телекоммуникационной инфраструктурой с целью мониторинга/координации и/или контроля телекоммуникационных функций и поддержки функций, в т.ч. функций оправления (включая управление самой TMN). Операционной системой (Operations systems - OS) называется независимая система, которая выполняет операционные и системные функции (OSF). Для реализации функции управления весь функционал управления может быть разбит, к примеру, на уровни модели LLA, о которых речь пойдёт ниже.

Блок преобразования функций (Transformation Function block - TF) обеспечивает межфункциональное взаимодействие двух функциональных элементов с несовместимыми коммуникационными механизмами. Примером таких механизмов могут являться протоколы. TF может быть использован где угодно: внутри TMN или на её границе.

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

Блок функций Q-адаптера (Q-adapter function block - QAF) используется для присоединения к TMN блоков функций сетевых элементов NEF и блоков функций операционной системы OSF, которые не поддерживаются стандартными интерфейсами TMN. Основным назначением QAF является трансляция между TMN и не соответствующим TMN (например, проприетарным) интерфейсом и поддержка деятельности последнего вне TMN. Q-адаптером (Q-adapter - QA) называется устройство, которое соединяет объекты типа NE или OS (например, с эталонными точками типа m), которые не отвечают рекомендациям TMN, с Q-интерфейсами.

Блок функций сетевого элемента (Network element function block - NEF) может включать в себя и/или поддерживать такие функции. NEF является функциональным блоком, которым может взаимодействовать с TMN для мониторинга и/или управления. Сетевой элемент (Network element - NE) состоит из телекоммуникационного оборудования (или же групп/частей телекоммуникационного оборудования) и выполняет поддержку этого оборудования. NE выполняет функции поддержки сетевого элемента (NEF) и имеет один или несколько стандартных Q-интерфейсов.

Блок функций рабочей станции (Workstation function - WSF) - функциональный блок, представляющий информацию TMN человеку-пользователю и обратно. Рабочая станция - физический блок, который выполняет функции рабочей станции WSF. Физический блок - архитектурная условность, являющаяся реализацией одного или более блоков функций.

Пользователь - человек или машина, которому (-ой) клиент делегировал использование сервисов и/или средств телекоммуникационной сети.

Таким образом, межфункциональное взаимодействие элементов через эталонные точки может быть сведено в таблицу 1.

Таблица 1. Соответствие эталонных точек и функциональных элементов модели TMN

	NEF	OSF	TF	WSF	QAF	Не-TMN
NEF	-	q	q	-	q г)	mг)
OSF	q	q,xа)	q	f	q г)	mг)
TF	q	q	q	f		mв)
WSF	-	f	f	-		gб)
QAF	q г)	q г)
Не-TMN	mг)	mг)	mв)	gб)
а) эталонная точка типа x используется только при взаимодействии OSF разных TMN б) эталонная точка типа g находится между WSF и человеком-пользователем в) эталонная точка типа m находится между TF и функциональным блоком телекоммуникационной среды г) QAF соединяет через эталонную точку q NEF или OSF, стандартизованный TMN, а через эталонную точку m соединяется с одноименным функциональным блоком, не отвечающим рекомендациям TMN. Примечание: любая функция может взаимодействовать с эталонной точкой, не вписывающейся в рекомендации по TMN.Эти точки могут быть стандартизованы другими группами/организациями для частных случаев.

После изучения основных вопросов терминологии вернёмся к вопросу рассмотрения функциональной модели LLA. В модели LLA вся функциональная деятельность компании подразделяется на следующие уровни функционального управления.

1. Уровень управления элементом (Element management layer-EML) отвечает за управление отдельным сетевым элементом на основе частного или группового принципа и поддерживает представление о функциях, предоставляемых уровнем управления сетью.

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

Уровень управления элементом выполняет три основных функции.

1.1. Управление и координация сетевых элементов на основе индивидуальной функции сетевого элемента. Это значит, что блоки функций операционной системы элемента поддерживают взаимодействие между уровнем сетевого элемента и уровнем управления сетью путем обмена информацией управления между блоками функций операционной системы и отдельным блоком функций сетевого элемента. Блоки функций операционной системы элемента должны обеспечивать полную доступность к функционалу сетевого элемента.

1.2. Уровень управления элементом может контролировать и координировать подгруппу сетевых элементов на групповой основе.

1.3. В рамках обеспечения управления уровень управления элементом также может обеспечивать поддержку статистики, ведение логов другой служебной информации.

Блоки функций операционной системы на уровне управления элементом взаимодействуют с блоками функций операционной системы на том же или на других уровнях модели LLA в рамках одной TMN через эталонные точки типа q и с OSF других TMN через эталонные точки типа x.

К этому уровню можно отнести и уровень сетевого элемента (Network Element Layer -NEL), который имеет свою функцию NEF, взаимодействующую через эталонные точки типа q с OSF. NEF с OSF других TMN напрямую не взаимодействует.

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

2.1. Управление и координация доступностью сетью всех сетевых элементов внутри данного домена управления.

2.2. Обеспечение, приостановление или модификация возможностей сети для подачи сервиса клиентам.

2.3. Поддержание производительности сети на должном уровне.

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

2.5.Сетевые OSF могут управлять взаимоотношениями (к примеру, связностью компонентов) между NEF.

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

OSF на уровне управления сетью взаимодействуют с другими OSF того же или другого уровня внутри данной TMN через эталонные точки типа q и через эталонные точки типа x с OSF других TMN.

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

У уровня управления сервисом 4 основные функции:

3.1. Общение с клиентами и согласование вопросов с операторами связи. При этом общение с клиентами представляют собой основную точку контакта с клиентом для всех решений по предоставлению сервиса, в том числе обеспечение или приостановление предоставления сервиса, ведение счетов, поддержание определенного уровня качества сервиса, ведение отчётности об ошибках и т.д.

3.2. Взаимодействие с провайдерами сервисов

3.3. Ведение статистических данных (например, параметров качества обслуживания типа QOS)

3.4. Взаимодействие между сервисами

OSF на уровне управления сервисом взаимодействуют с другими OSF того же или другого уровня внутри данной TMN через эталонные точки типа q и через эталонные точки типа x с OSF других TMN.

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

4. На уровне управления бизнесом реализуются управленческие функции предприятием. Для предотвращения несанкционированного доступа к этим функциям, OSF этого уровня обычно не поддерживают взаимодействие посредством эталонных точек типа x. OSF уровня управления бизнесом получают информацию от других уровней управления. Уровень управления бизнесом был включен в архитектуру TMN для выработки спецификаций его свойств и требований к другим уровням управления.

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

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

Обычно OSF на уровне управления бизнесом взаимодействует с OSF только данной TMN посредством эталонных точек типа q.

Основными функциями уровня управления бизнесом являются:

4.1. Поддержка процессов принятия решения оптимального инвестирования и использования новых ресурсов

4.2. Поддержка управления OA&M - процессов бюджетирования

4.3. Поддержка обеспечения и запросов OA&M - процессов, связанных с трудовой деятельностью персонала

4.4. Поддержка концентрации и систематизации информации о предприятии в целом

В рекомендации M.3400 (которая перекликается с X.700 МСЭ-Т и ISO 7498-4) описываются основные функции TMN относительно функционала, реализуемого сетью^[12]. Все функции могут быть разделены на 5 типов функций управления, отображённые на рисунке 3.

Рисунок 3. Компоненты модели FCAPS

Основными компонентами модели FCAPS являются следующие функции:

Управление процессом устранения отказов (Fault Management, FM);

Управление конфигурацией сети (Configuration Management, CM);

Управление расчётами с пользователями и поставщиками услуг (Accounting Management, AM);

Контроль производительности сети (Performance Management, PM);

Обеспечение безопасности работы сети (Security Management, SM).

Примеры реализации функциональных областей, соотнесённые с рисунком 3, сведены в таблице 2.

Совместив данные рекомендации M.3400 c M.3010 на уровне декомпозиции функциональной модели LLA, получим утрированную модель межуровневого взаимодействия функциональных блоков разных уровней управления в зависимости от объекта управления. Данная функциональная декомпозиция представлена на рисунке 1.4.

Важно отметить, что вся функциональная модель LLA опирается на концепцию того, что соседние уровни независимы друг от друга и только получают/обмениваются необходимой информацией между своими соседями по LLA через эталонные точки q. С другими же одноуровневыми OSF уровни взаимодействуют также по интерфейсам q, как было показано ранее на рисунке 2, а с одноуровневыми OSF другой TMN - эталонными точками типа x.

Таким образом, на каждом уровне функциональной декомпозиции модели LLA должны (могут) выполняться набор функций управления FCAPS.

Как отмечалось ранее, модель LLA (а, следовательно, и декомпозированная модель LLA, представленная на рисунке 4) TMN может быть использована в условиях различных факторов, что, возможно, потребует создания многих других необходимых/требуемых уровней с последующим наложением ограничений на взаимодействия внутри данной модели с целью её упрощения.

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

Таблица 2. Примеры реализации функций FCAPS

F	C	A	P	S
Работа с ошибками	Инициализация ресурсов	Подсчет использования сервиса/ресурса	Тенденции утилизации и ошибок	Выборочный доступ к ресурсам
Восстановление работоспособности сети	Резервное копирование и восстановление	Стоимость сервиса	Сбор данных о производительности	Оповещения о проблемах безопасности
Работа с аварийными сигналами	Управление изменениями	Аудиты	Генерация отчетов о производительности	Конфиденциальность данных
Диагностические тесты	Опись и каталогизирование	Установка лимитов для аккаунта	Отчеты о проблемах	Проверка прав доступа пользователя
Запись ошибок в журнал Logging	Копирование конфигурации	Сочетание стоимости для разных ресурсов	Планирование загрузки оборудования	Аудит безопасности
Статистика ошибок	Удалённое конфигурирование и развёртывание софта	Биллинг	Оповещения о проблемах производительности	Журналы подключений



Рисунок 4.Функциональная межуровневая декомпозиция модели LLA

Можно сделать следующие выводы:

1. Уровни модели независимы друг от друга - выступают как отдельные блоки, что упрощает унификацию, а, следовательно, разработку реализаций других уровней;

2. Уровни взаимодействуют лишь с соседними уровнями (в случае стандартной реализации, представленной в рекомендации M.3010), что обеспечивает унификацию межуровневых интерфейсов;

3. Процессы управления и планирования сервисом значительно упрощаются благодаря наглядному представлению и визуализации. Так, при внедрении нового сервиса (что является решением стратегическим, принимаемым на уровне BML) решение спускается на уровень управления сервисом, где адаптируется применительно к клиенто-ориентированным бизнес-процессам и системам. Фактически, на BML и SML работу проводят коммерческие специалисты компании: специалисты по заключению договоров, маркетингу, рекламе, анализу, статистике, работе с клиентами, общему менеджменту предприятия и т.д. После того, как были выбраны методы реализации данного сервиса (без учета того: можно технически его внедрить или нет) данное стратегическое решение спускается техническим специалистам компании, которые изыскивают техническую возможность и реализацию в зависимости от функционала оборудования на сети и своей квалификации. Если техническая возможность реализации данной задачи есть, то даётся обратная связь вверх по модели TMN LLA и процесс запускается в реализацию. Данный процесс схематически представлен на рисунке 5.

Если технической возможности развёртывания данного сервиса нет, то по обратной связи нетехнические подразделения получают данный результат, и, просчитав экономическую эффективность, доносят до уровня BML (на котором зачастую расположен так называемый топ-менеджмент компании). На уровне BML выносится решение о том, что техническая инфраструктура будет модернизирована для реализации технической возможности предоставления данной услуги либо об отклонении развертывания данного стратегического решения.

2.1.2 Стандарты TM Forum и концепция NGOSS

Международный союз электросвязи, безусловно, является основополагающим международным органом стандартизации, о чём подробно было сказано выше. Но в силу своей инертности ввиду масштабов и поставленных задач данной организации, МСЭ-Т зачастую немного отстаёт по времени от современных тенденций в сфере телекоммуникаций, что создаёт определённые неудобства производителям и разработчикам данной сферы.

TM Forum на сегодняшний день является одной из самых крупных и передовых отраслевых некоммерческих ассоциаций, объединяющих предприятия области телекоммуникаций и их поставщиков с целью выработки стандартов, рекомендаций и моделей для информационных технологий в отрасли связи. На сегодняшний день число таких членов организации превышает 700. Такая консолидация заинтересованных сторон (операторов, разработчиков, производителей и поставщиков услуг) в одной организации позволяет обеспечивать значимую для всего телекоммуникационного сообщества “основу”, на которой можно строить различные решения, которые гарантированно могут быть восприняты другими сторонами ввиду унифицированных подходов и стандартов, на основе которых это решение было построено.

В 1998 году был выпущен первый релиз карты процессов деятельности телекоммуникационной компании - Telecom Operations Map (TOM) ^[3], в которой в наглядном систематизированном виде предлагалось решение унификации бизнес-процессов внутри телекоммуникационной компании. Ввиду того, что данная “карта” отображала процессы внутри телекоммуникационной компании, но без учёта процессов деятельности компании во вне структуры организации, была предложена расширенная карта процессов деятельности телекоммуникационной компании - Enchanced Telecom Operations Map (eTOM), которая составила основу концепции NGOSS. Конецпция New Generation Operation Systems and Software (Новое поколение систем и программного обеспечения^[1] [для управления операционной деятельностью телекоммуникационной компании]), или сокращенно -- NGOSS развивалась консорциумом TM Forum с 2000 года, вобрав в себя лучшие наработки организации в вопросе управления бизнес-процессами. Основу концепции NGOSS образуют несколько составных частей.

1. Расширенная карта бизнес-процессов еТОМ, которая описывает системынй подход к бизнес-процессам в телекоммуникационных компаниях.

2. Информационная модель SID, определяющая подход к описанию и использованию данных, задействованных в бизнес-процессах компании связи.

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

4. Архитектура интеграции TNA & CID (Technology Neutral Architecture and Contract Interface Definitions), определяющая принципы взаимодействия и интеграции приложений, данных и бизнес-процессов в распределенной среде NGOSS.

5. Система контроля соответствия принципам NGOSS (NGOSS Compliance), позволяющая проверить компоненты NGOSS-решения на соответствие принципам концепции.

В 2010 году TM Forum запустил разработку Frameworx 10.0, которую принято считать полноправным приемником концепции NGOSS. В рамках Frameworx 10.0 было принято решении о развёртывании центров сертификации специалистов по бизнес-процессам данной концепции, что должно было бы упростить взаимодействие организаций ввиду того, что их сотрудники гарантированного будут использовать единый подход к управлению предприятием. На апрель 2012 года актуальной версией Frameworx является версия 11.5 (находится в beta-версии); актуальной из доступных является версия 9.0 (согласно документу RN311), о которой речь пойдёт ниже^[7].

При планировании построения бизнес-деятельности и системы управления особое внимание следует уделить расширенной карте процессов деятельности телекоммуникационной компании - eTOM (в обновлённой терминологии TM Forum - Концепция бизнес-процессов - Business Process Framework).

Как было сказано выше, Business Process Framework является одним из основополагающих компонентов Frameworx консорциума TM Forum. Frameworx даёт своим пользователям возможность анализировать бизнес-процессы своих компаний и сопоставлять их с производственными процессами, стандартами, в которых описывается разработка приложений и работы с информацией. Также Frameworx формирует основу для подготовки, разработки и внедрения конкурентоспособной операционной среды предприятия. Данная концепция может быть использована как комплексное руководство для решений “из конца в конец”, но может также использоваться как компонент решения отдельных задач. Frameworx может использоваться операторами, разработчиками и системными интеграторами в качестве единой платформы ведения деятельности^[14].

В рамках данной работы особо интересен документ RN311^[14], вносящий дополнения в основное описание Frameworx GB921^[15], а также GB921-T, в котором обозначается отображение функций FCAPS, описанных в рекомендации M.3400 МСЭ-Т на плоскость eTOM. Таким образом, будем в качестве основного использовать документ GB921 релиза 9.0, версии 9.1^[15]. Отметим, что в 2004 году 4 релиз eTOM был отображён в рекомендациях МСЭ-Т в виде группы рекомендациях M.3050.x^[3].

В документе GB921 релиз 9.0, версия 9.1^[15], опубликованном в апреле 2011 года, описывается взгляд на построение операционной деятельности предприятия с точки зрения организации оптимальных сквозных процессов с выполнением определенного функционала.

Для этого используется подход, предлагаемый TM Forum, изложенный в вышеобозначенном документе. Приведём общее описание подхода, предварительно введя некоторые определения^[3].

1. Процесс (англ. Process) - последовательность связанных между собой действий, необходимых для получения определенного результата. Следует различать процесс-элемент и процесс-поток.

2. Процесс-элемент (англ. Process Element) ставится в соответствие некоторой бизнес-операции и при необходимости может быть декомпозирован на несколько составляющих, дающих более подробное описание функций исходного процесса. Другими словами, процесс-элемент - последовательность управляемых действий, которые преобразуют исходные данные в требуемые результаты и связаны между собой операциями условия и триггерами, инициирующими выполнение конкретных действий.

3. Процесс-поток (англ. Process Flow) описывает совместную работу во времени нескольких процессов-элементов и содержит последовательность действий, которые необходимо предпринять для обеспечения той или иной функциональности.

4. Продукт (англ. Product) - материальные или нематериальные объекты, которые телекоммуникационная компания продает или сдает в аренду клиентам для получения прибыли. Продукт может включать услуги, обработанный материал, программное обеспечение, аппаратные средства и любое их сочетание.

5. Услуга (англ. Service) - то, что разрабатывается внутри компании-поставщика для реализации или поддержки предложенных на рынке продуктов; некоторый компонент реализации или поддержки продукта. Несколько продуктов могут включать одну и ту же услугу.

6. Ресурс (англ. Resource) - физический и/или логический элемент, используемый для построения услуг. К ресурсам относятся элементы сети, программное обеспечение, информационные системы и т. д.

7. Термин «сущность» (англ. Entity) служит для обозначения взаимодействующего или вовлеченного в бизнес-процесс компании физического или юридического лица, технологии или некоторого другого объекта. Наиболее значимой для компании сущностью является клиент. Помимо этого, например, процессы управления предприятием взаимодействуют с государственными структурами, конкурентами, средствами массовой информации, а процессы управления отношениями с партнерами и поставщиками - с дилерами, партнерами, поставщиками услуг и ресурсов.

В качестве основного инструмента построения процессов предприятия предлагается использовать расширенную карту бизнес-процессов предприятия eTOM. В качестве отправной точки рассмотрения бизнес-процессов используется концептуальный (нулевой) уровень, изображенный на рисунке 6^[3].

Концептуальным данный уровень считается потому, что описывает самый общий взгляд на предприятие и его окружение - функциональные сущности. Нулевым он является с точки зрения декомпозиции процессов - основного инструмента структурирования процессов на бизнес-карте. TM Forum рекомендует использовать уровни декомпозиции не более четырёх (с 0 по 3) - это зачастую позволяет описать все процессы предприятия с достаточной точностью. При необходимости, безусловно, декомпозиция может быть продолжена сколь необходимо много, но, как показывает практика, после семи итераций эффективность данного процесса теряется т.к. теряется сама идея унификации карты eTOM и резко возрастает объем исполняемой работы^[3].

Как было сказано выше, нулевой уровень декомпозиции eTOM вводит понятия предприятия и его окружения. Внутри деятельности предприятия выделяются три основные функциональные группы:

Стратегия, Инфраструктура и Продукт - включает планирование и управление жизненным циклом (связано с производством и доставкой услуги и продукта). Сюда входят стратегия и обязательства предприятия, планирование, разработка и управление поставкой сервисов, а также развитие продуктов и инфраструктуры предприятия.

Операции - включает основу управления операционной деятельностью предприятия. Сюда входят ежедневные процессы предприятия по поддержке операций и сервисов. Также сюда относятся управление взаимоотношениями с поставщиками/партнерами и управление продажами.

Управление предприятием - включает общий менеджмент предприятия и управление бизнесом. Является логичной и неотъемлемой частью любого крупного предприятия. К этой группе процессов обычно относят такие общекорпоративные функции/процессы как финансовый менеджмент, кадровое администрирование и т.д. Элементы данной группы ввиду своей специфики теоретически могут взаимодействовать с любыми другими процессами из других групп.

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

Далее процесс декомпозиции переходит на первый уровень декомпозиции, представленный на рисунке 7. На этом этапе можно наблюдать декомпозиции: вертикальную и горизонтальную. Вертикальная декомпозиция представляет собой разделение на группы сквозных бизнес-процессов. Они логически группированы в блоках «Операции» и «Стратегия, Инфраструктура и Продукт». В частности, три группы процессов, максимально возможные к автоматизации в силу своего функционала, а именно Исполнение, Гарантирование, Биллинг - логически объединены в одну подгруппу, в которой возможна оптимизация, т.к. данные процессы являются по своей природе пограничными с клиентским взаимодействием и требует ежедневной работы.

Как отмечено в GB921^[15], eTOM была построена на основе и как развитие рекомендаций группы M МСЭ-Т, в частности М.3010, в которой представляется модель управления TMN. Так, автор [3] также отмечает, что уровни декомпозиции eTOM вполне однозначно перекликаются с уровнями модели LLA TMN, разобранной выше.

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

Данный комплексный подход для эталонного представления структуры предприятия, который предлагает нам концепция NGOSS, был бы неполным без упоминания об интерфейсах мультитехнологических систем управления (MTOSI- Multi-Technology Operations System Interfaces), которые призваны унифицировать процесс проектирования, интеграции и взаимодействия. MTOSI играют в унификации примерно такую же роль, как эталонные интерфейсы в модели TMN. MTOSI является рекомендованным интерфейсом для реализации TM Forum, документ TMF513.

На настоящий момент можно твёрдо сказать, что системы управления имеют довольно основательный теоретический и нормативный фундамент, выраженный в виде стандартизующих документов для разработки и проектирования систем управления телекоммуникационным оборудованием, сетями, процессами и бизнесом. Основными международными организациями, вносящими весомый вклад в развитие данного направления, являются МСЭ-Т, играющий роль надгосударственного отраслевого органа, и TMF, который вносит активное участие за счет членства в своём составе ведущих производителей и разработчиков сферы телекоммуникаций.

На сегодняшний день оптимальным решением для построением комплексной системы управления было бы сочетание модели TMN (через кросстехнологические интерфейсы MTOSI) с набором функциональным набором FCAPS (с упором на безопасность) совместно с реализацией концепции NGOSS (на базе трёх основных составляющих).

2.2 Реализация систем управления

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

2.2.1 Системы NMS

Системы управления сетью - Network Management System (NMS) являются системами, реализующими уровень NML модели TMN. Физически NMS представляет собой комбинацию программного обеспечения с аппаратной частью, на которой это программное обеспечение имеет серверную часть. Обычно данные системы построены по принципу “агент-менеджер”. такое взаимодействие аналогично общепринятому взаимодействие типа “клиент-серевер” и условно проиллюстрировано на рисунке 8.

Рисунок 8. Условная схема взаимодействия “агент-менеджер”

Стандартом де-факто (который фактически является «рабочей» и «упрощенной» альтернативой отраслевому CMIP), поддерживаемым в той или иной версии любым производителем телекоммуникационного оборудования, на сегодняшний день является простой протокол управления сетями (Simple Network Management Protocol, SNMP), разработанный сообществом проектирования Интернета (Internet Engineering Task Force, IETF) специально для стека TCP/IP^[4].

Архитектура SNMP предполагает построение системы управления по схеме «менеджер-агент», т. е. использование архитектурного стиля «клиент-сервер», о чем было сказано выше. Система SNMP содержит множество управляемых узлов, на каждом из которых размещается достаточно простой сервер - агент SNMP, а также, по крайней мере, один узел, содержащий сложного клиента - менеджера SNMP.

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

Для повышения масштабируемости и административной управляемости вводится понятие прокси-агента, который может переправлять операции протокола SNMP, а также понятие менеджера промежуточного уровня, который скрывает несущественные подробности управляющей информации от систем управления сетями верхнего уровня, интегрируя получаемые от агентов данные. Это позволяет создавать многоуровневые системы управления, соответствующие архитектурному стилю «многоуровневый клиент-сервер»^[4].

Данные системы используют для обмена между клиентом и сервером транспортный уровень модели OSI с его протоколами. Это могут быть TCP, UDP, SCTP. Обычно используется TCP, как наиболее распространённый; SCTP является на сегодняшний день менее используемым, но более перспективным с точки зрения предоставляемых возможностей сетевой настройки.

Помимо SNMP в качестве протокола управления можно использовать другие протоколы, такие как NetFlow.

Протокол NetFlow является запатентованным протоколом компании Cisco Systems. Он оперирует понятием «поток», который определяется как последовательность пакетов между источником и пунктом назначения, идентифицируемая IP-адресом сетевого уровня и портами источника и пункта назначения транспортного уровня модели OSI.

Рисунок 9. Процедура взаимодействия агента SNMP и менеджера SNMP

На сегодняшний день доступна версия 9 протокола NetFlow, так называемый протокол IPFIX. После первичного анализа можно сделать вывод о том, что эти два протокола на этапе рассмотрения без объекта приложения мало различимы; дифференциация может проявится только на этапе «тонкой настройки сети.

Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP. Netflow имеет три основных компонента:

1. Сенсор;

2. Коллектор;

3. Система обработки и представления данных.

Сенсор -- демон (англ. daemon), который “слушает” сеть и фиксирует данные сеанса.Сенсор должен иметь возможность подключиться к сетевому элементу, "зеркалированному" порту коммутатора или любому другому устройству, для просмотра сетевого трафика. Сенсор будет собирать информацию о сеансах и сбрасывать ее в коллектор.

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

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

В целом, сбор данных с использованием NetFlow может быть сведён к единому виду, изображённому на рисунке 10.

Рисунок 10. Типовая топология при использовании NetFlow

Другим, наиболее перспективным на сегодняшний день, по мнению автора, протоколом такого типа является протокол SFlow. Агент для протокола SFlow - программный модуль, осуществляющий учет и тарификацию услуг доступа в сеть Internet (IP услуг), предоставляемых абонентам по выделенному каналу, средствами аппаратуры, поддерживающей экспорт статистических данных по протоколу SFlow. Протокол SFlow (RFC 3176) сравнительно новый и, как следствие, обладает рядом преимуществ по сравнению с NetFlow (Cisco Systems) так же как, впрочем, и рядом недостатков. Среди основных преимуществ протокола явным образом можно выделить меньшую по сравнению с NetFlow потребность в процессорных ресурсах аппаратуры и большее количество экспортируемых параметров о трафике.

Несомненным недостатком является то, что протокол поддерживается еще не слишком широким кругом производителей, среди которых основным является Hewlett Packard, осуществляющий поддержку SFlow второй версии в верхней линейке коммутаторов третьего уровня HP ProCurve 53хх и HP ProCurve 93xx. Особенностью является то, что в отличие от NetFlow в SFlow экспортируется как входящий на интерфейс трафик так и исходящий, что в ряде случав может быть преимуществом, а в ряде случаев недостатком.

Основные задачи, решаемые агентом, аналогичны задачам, решаемым агентами NetFlow, а именно: регистрация, тарификация и первый уровень агрегирования данных об IP трафике, прошедшем через маршрутизатор или коммутатор.