Что такое TMN? Некоторые скажут, что это технология, другие - что концепция, третьи ответят, что TMN - это собирательное название для совокупности реализаций готовых систем управления телекоммуникационными ресурсами. По большому счету и те и другие и третьи окажутся правы. Правда состоит в том, что аббревиатура TMN стала именем нарицательным для целого круга процессов, систем и логических объектов, объединенных общей направленностью называемой "Управление телекоммуникациями".
Данная страничка предназначена для ознакомления с "азами" TMN. Как известно, наиболее объективными методом познания нового является метод рассмотрения этого самого нового с различных позиций, точек зрения. Поэтому в приведенном ниже материале, создатели сайта постарались охватить как можно больше различных статей и текстов, написанных разными авторами.

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

"Свои" статьи:

- "Что такое TMN?" (В статье дано введение в TMN с описанием основных позиций данной технологии);

- "Интерфейсы и проблемы" (В статье рассматриваются проблемы TMN как технологии, а также описаны предполагаемые причины этих проблем);

Электронные документы других авторов:

- П.О. Дубенсков "TMN в конце туннеля". В статье в краткой форме дается все: от зарождения TMN до стратегий внедрения TMN-систем на сетях. Ссылка: http://ccc.ru/magazine/depot/98_05/read.html?0302.htm

- П. Иванов "Управление сетями связи". Довольно подробное хорошо иллюстрированное изложение проблематики TMN в двух частях. Обращает на себя внимание хорошая подборка ссылок на органы стандартизации и поставщиков систем управления (8-9 и 11-й номера журнала Сети, 1999). Ссылки: http://www.osp.ru/nets/1999/08-09/18.htm и
http://www.osp.ru/nets/1999/11/04.htm

- Довольно неплохое изложение основ TMN с подбором иллюстраций и указанием необходимых стандартов приведено на сайте http://rtmv.kuban.ru/ptl/tmn.htm##1

Возможно, кому-то покажутся полезными англоязычные ссылки по TMN:

- Наипервейшая ссылка - это конечно же "основатель" TMN, Международный Союз Электросвязи. Ссылка: http://www.itu.int/itudoc/itu-t/com4/tmn/tmnrdmp.html

- Красочный, но не совсем удобный для чтения tutorial на сайте http://wwwsnmp.cs.utwente.nl. Ссылка: http://wwwsnmp.cs.utwente.nl/tutorials/tmn/

- Англоязычный TMN TUTORIAL от известного производителя TMN-софта, компании VERTEL. Ссылка: http://www.webproforum.com/vertel/

"Бумажные" издания:

- Одна из самых амбициозных и запутанных книг на русском языке - Н. Слепов "Синхронные цифровые сети SDH". Не смотря на то, что книга посвящена в основном SDH-сетям, в ней достаточно солидно описывается TMN. Дело в том, что технология TMN как в теоретическом, так и в практическом планах лучше всего проработана для управления системами SDH. Возможно, эта книга не покажется Вам запутанной, если Вы уже в достаточной мере освоили "азы" TMN

- Булгак В.Б. "Основы управления связью РФ". В данном труде изложены основы управления связью РФ в нормальной и чрезвычайных ситуациях. Даны основные требования к построению систем управления, не зависимо от форм собственности и ведомственной принадлежности

- Англоязычный источник "OSS Essentials". Книга описывает техническую структуру СПО (Систем Поддержки Операций) для обеспечения телекоммуникационных провайдеров надежным механизмом доставки услуг непосредственно своим клиентам. Условия приобретения книги даны на: www.tmforum.org в разделе BOOKSTORE

Системы Управления Телекоммуникациями. Что такое TMN?

Отрасль телекоммуникаций сегодня представляет собой крайне интересный конгломерат технологий, где "мир телефонов" сталкивается с "миром компьютеров", а сама техника обеспечивающая существование этих миров становится предельно автоматизированной и сложной.
Современная микроэлектроника и программное обеспечение сделали возможным построение такого оборудования, которое может эффективно хранить и обрабатывать большие объемы мультимедийной информации. Современная оптика и оптическая электроника позволяют передавать эти объемы информации на большие расстояния, при этом гарантируя высокое качество передачи.
Высокая скорость развития телекоммуникационных технологий, а также постоянно идущие процессы конвергенции сетей способствуют возникновению огромного количества стандартов и рекомендаций. На сегодняшний день, любой крупный телекоммуникационный оператор обладает как минимум 2-мя типами сетей. Это: транспортные сети и сети доступа. В каждой из этих сетей оператор использует еще и по нескольку типов технологий, причем технологий поставляемых оператору в виде конкретного оборудования различными поставщиками. Разные технологии на практике - это опять же различные сети. В результате единое сетевое поле оператора представляет собой смесь из нескольких сетей, где одни сети накладываются на другие, а некоторые существуют параллельно, активно взаимодействуя между собой. Причем, принимая во внимание современный уровень развития микроэлектрооники, следует отметить, что оборудование цифровых сетей (любой технологии) является предельно компьютеризированным и допускает управление практически только на программном уровне.
Напомним, что бизнес-целью оператора является получение максимально возможной прибыли за счет предоставления телекоммуникационных услуг своим клиентам. У полностью независимого от государства оператора, прибыль напрямую зависит от двух составляющих: маркетинга и уровня управления сетевыми ресурсами. Сосредоточимся на последней составляющей. Как уже было упомянуто выше, современный оператор, технически - это совокупность разнородных сетей, оборудование которых на 90 (если не больше) процентов допускает только программное управление.
Как управлять сетями? На что следует ориентироваться при построении системы управления? Какие технологии существуют в этой области, и с какими проблемами сталкиваются операторы и производители? Все это, несомненно, интересует любого оператора. На часть этих вопросов мы постараемся дать ответ в этой статье.
Данная статья носит ознакомительный характер и ориентирована на приобретение базовых знаний по управлению сетями.

TMN

В сфере телекоммуникационного бизнеса сегодня вряд ли найдется человек, который бы не слышал аббревиатуры TMN.Что это такое?

Англоязычная расшифровка TMN звучит как Telecommunications Management Network; в переводе на русский язык Сеть Управления Телекоммуникациями. К сожалению, в русском языке не существует общепринятой аббревиатуры для TMN, поэтому при изложении материала будет использоваться англоязычный термин.
TMN - это по сути дела международный стандарт определяющий технологию построения систем управления телекоммуникационными сетями и определяющий все аспекты их функционирования. Следует отметить, что TMN - технология пришедшая "сверху", т.е. она сначала была задумана на бумаге, а уже затем начала реализовываться на практике. Официально рождением TMN можно считать 1988 год, когда МККТТ (ныне МСЭ) опубликовал первую (и основную) рекомендацию М3010 "Принципы TMN". Некоторое время спустя, а именно в 1992 году в дополнение к М3010 была выпущена целая серия рекомендаций (М3100, М3200, М3300, М.3400 и др.), которые детально описывали основные аспекты TMN, упомянутые в М3010. 1992 год можно по праву считать годом рождения TMN не только как общей концепции, но как телекоммуникационной технологии. Вплоть до 2000 года МСЭ, реорганизованный из МККТТ, выпускал различные дополнительные рекомендации, которые все больше детализировали TMN, вносили разъяснения и поправки к базовым документам, упомянутым выше. Однако во второй половине 90-х годов в виду ряда объективных причин TMN начала терять свою популярность. Многие эксперты и аналитики придерживались мнения, что TMN как технология не имеет практического будущего. Поэтому ввиду наметившегося кризиса, МСЭ вынужден был пересмотреть некоторые рекомендации серии М. Это произошло в 2000 году. МСЭ издал новые версии основных рекомендаций, а именно М3000, М3100, М3400, а также выпустил несколько новых рекомендаций (например, М3013) пытаясь решить появившиеся проблемы. В следующей статье, мы проанализируем, удалось это сделать или нет, а пока рассмотрим основные аспекты технологии TMN.

Рассмотрение TMN

Традиционно описание TMN начинается с рассмотрения трех ее архитектур: функциональной, информационной и физической. Каждая из архитектур содержит в себе часть полного набора базовых аспектов, свойств и атрибутов присущих TMN. Такой подход помогает упорядочить каркас базовых представлений о TMN и сделать их более доступными для понимания и изучения.
Итак, опишем TMN с точки зрения трех вышеуказанных архитектур.
Первая архитектура - физическая. Эта архитектура описывает, из каких главных физических компонентов (оборудования) должна состоять Система Управления, построенная по принципам TMN. Рекомендация М.3010 определяет следующие компоненты:
- Системы Операций;
- Устройства Преобразования (Q-адаптеры, медиаторы);
- Рабочие Станции;
- Сетевые Элементы.
Каждое из тих названий является собирательным для какого то вида "реального" оборудования. К примеру, в настоящей сети сервер, на котором установлено ПО по управлению телекоммуникационной сетью будет представлять Систему Операций, а мультиплексоры SDH - сетевые элементы. Устройства преобразования могут быть выражены программными модулями - например специальными утилитами, осуществляющими преобразование протоколов обмена информацией на одном из TMN-интерфейсов. Физически же эти утилиты могут находиться, например, на том же сервере. Поэтому сервер может рассматриваться и как Устройство Преобразования. В общем случае нет жесткой привязки отдельной единицы оборудования на "реальной" сети к какому-либо из четырех типов компонент физической архитектуры TMN. Одна и та же единица оборудования теоретически может представлять и Систему Операций и Сетевой Элемент и Устройство Преобразования одновременно. Более детально этот вопрос рассматривается ниже.
Как определить к какому типу компонент относится та или иная единица оборудования? В TMN такое определение делается исходя из жесткой дифференциации наборов функций, выполняемых тем или иным компонентом физической архитектуры. Функции и их наборы - это основа функциональной архитектуры TMN. Функциональная архитектура TMN определяет четыре основных набора функций TMN (в рекомендации М.3010 их называют блоками):
- блок функций Системы Операций (OSF);
- блок функций Рабочей Станции (WSF);
- блок функций Преобразования (TF);
- блок функций Сетевого Элемента (NEF).
Блок функций OSF отвечает за обработку всей информации относящейся к координации, контролю и управлению телекоммуникационными ресурсами, а также ресурсами самой системы управления.
Блок функций WSF выполняет задачу представления информации поступающей от системы управления к человеку-оператору, и, наоборот, от человека-оператора к средствам системы управления.
Блок функций NEF делится на две части:
- осуществление непосредственных телекоммуникационных функций (например для SDH-мультиплексора - это формирование и расформирование кадров STM, их передача в линию и т.п.);
- осуществление репрезентативных и исполнительских функций управления (т.е. извлечение и представление определенных данных управления в OS и непосредственное исполнение команд управления, поступающих с OS)
Блок функций TF предоставляет услуги по обеспечению взаимодействия между несовместимыми по протоколам (или/или информационным моделям) функциональными средами (к примеру, между двумя разными TMN реализациями).
Возвращаясь к физической архитектуре, проведем небольшой анализ о связях между этой архитектурой и архитектурой функциональной на примере конкретного оборудования. Для большей ясности приведем таблицу взаимосвязи:
Таблица 1

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

Как видно из таблицы, определенные элементы физической архитектуры могут нести, кроме обязательных, еще и опционные (необязательные) блоки функций. Конкретный пример: оборудование системы передачи SMS 600 компании NEC. Вполне естественно, что доминирующим блоком для SMS 600 является NEF. Однако в состав SMS 600 входит также плата AGENT, которая отвечает за взаимодействие с Сетевой Системой Управления. Для взаимодействия используется протокол Q. Однако NEF изначально использует иную информационную модель и протокол для представления вовне управляемых характеристик мультиплексора. Эта модель и протокол используются для взаимодействия мультиплексора и локального рабочего терминала. Для взаимодействия же с удаленной Сетевой Системой Управления (которая одновременно контролирует большое количество мультиплексоров) нужно трансформировать и модель и протокол. Этим и занимается блок AGENT. Следуя вышеописанной логике, AGENT в составе SMS 600 выполняет функции TF.
Рекомендация М.3010 определяет следующее: любой неименованный физический объект системы TMN получает имя одной из компонент физической архитектуры, исходя из того, какой блок функций в данном объекте является доминантным.
Рассмотрим еще один пример. Допустим, что при построении интегрированной системы управления транспортной сетью оператора требуется осуществить стыковку с существующими системами управления (пусть это будут системы INC100, производства NEC и EMOS, производства Siemens). В терминах рекомендации М.3010, то, что мы пытаемся сделать - это организовать стыковку новой системы TMN с двумя существующими системами TMN. Предположим, что взаимодействие этих трех систем будет осуществляться через сервера. Иначе говоря, сервер новой TMN будет обмениваться информацией с сервером INC100 и с сервером EMOS. Допустим, что во всех трех системах для взаимодействия с внешними объектами используется стандартный интерфейс "Y". Но у INC100 - это "Y1" у EMOSа - это "Y2", у нашей новой TMN - "Y3". Иными словами, не смотря на стандарт, интерфейсы все же различаются в деталях реализации (такая ситуация вполне типична для современных систем управления). Для решения проблемы взаимодействия серверов, вероятнее всего, на стороне сервера новой TMN придется организовывать программное Устройство Преобразования, или Х-медиатор. В реальности - это может быть, например, утилита с условным названием "ConnectY", которая будет преобразовывать форматы сообщений "Y1" и "Y2" в формат "Y3" и наоборот. Для взаимодействия с администратором новой TMN на сервере может быть установлен соответствующий программный пакет и добавлено аппаратное обеспечение (монитор и т.п.). Они будут выполнять функции WSF. Тем не менее, является очевидным тот факт, основной задачей сервера будет выполнение функций OSF, т.е. мониторинг и управление подконтрольными сетями телекоммуникаций и системами управления INC100 и EMOS. Таким образом, OSF - доминантный блок функций. Поэтому, в терминах компонент физической архитектуры TMN, сервер будет являться Системой Операций, и Устройство Преобразования, упомянутое выше, не будет иметь самостоятельного значения. Иначе говоря, мы не можем назвать сервер "Устройством Преобразования", потому что блок TF будет играть в нем не доминирующую роль (хотя это вопрос спорный, если рассматривать сервер с точки зрения важности сопряжения систем).
В функциональной архитектуре TMN для взаимодействия различных блоков функций определены так называемые "ссылочные точки" (reference points). "Ссылочные точки" - это информационное пространство между функциональными блоками. Различные типы точек определяются парами соответствующих блоков функций (см. рис.1)

Рис. 1 - Классы "ссылочных точек" в TMN

Почему для обозначения информационного пространства между блоками функций был выбран термин "ссылочная точка" не объясняет ни одна рекомендация МСЭ. Возможно, это связано с тем, что смысловая нагрузка этих "точек" довольно абстрактна. Они не имеют самостоятельного значения и наполнености. Почувствовать их значение можно в основном через потенциальные действия (и их параметры) имеющие место в той или иной "точке" и константно ссылающиеся на ту или иную точку. Отсюда удобное, но не очень понятное для неспециалиста название - "ссылочная точка". Ссылки на "точки" обычно делаются при описании информационной архитектуры и тех составляющих блоков функций, которые ориентированы на взаимодействие с другими блоками функций.
Определения точек таковы:
Точка q определена как информационное пространство взаимодействия, существующее между блоками NEF и OSF, NEF и TF, TF и OSF, OSF и OSF.
Точка f определена как пространство взаимодействия между блоками OSF и WSF.
Точка x определена как информационное пространство между блоками OSF двух различных TMN.
Точка g определена как информационное пространство между человеком и WSF.
Точка m определена как информационное пространство между адаптером интерфейса TMN и управляемым объектом, который реализован не по TMN-технологии.
Каждая из этих "точек" может находиться как внутри физических компонент TMN, так и вовне этих компонент (например, между двумя серверами ). При этом на каждую внешнюю "точку" однозначно ссылается определенный интерфейс. Интерфейсом в данном случае называют набор сред передачи, форматов и процедур, по которым осуществляется обмен информацией между любыми двумя двумя блоками функций системы управления. Понятие интерфейса принадлежит к информационной структуре TMN. В общем случае, информационная архитектура TMN определяет правила, согласно которым информация управления должна быть представлена в системе управления. Данная архитектура также определяет, в каких объемах и форматах должен происходить обмен информацией между объектами TMN и какие процедуры и правила должны при этом соблюдаться.
Ключевыми для информационной архитектуры являются следующие понятия:
- информационная модель (information model);
- информационный элемент (information element);
- разделяемое понятие об управлении (shared management knowledge, SMK);
- модель взаимодействия (interaction model).
Информационная модель - это понятие информационной архитектуры, которое определяет уровень абстракции всех ресурсов и процессов управления, которые имеют место в TMN, а также общие правила виртуализации этих ресурсов и процессов. В рамках правил (парадигм) одной или более сетевых моделей, строятся информационные элементы, или если говорить языком программирования - объекты. Чтобы лишний раз продемонстрировать взаимосвязь архитектур TMN, скажем, что разработка информационной модели целиком и полностью инициализируется определенной функциональной архитектурой и ее составляющими блоками функций. Ведь, скажем, не определив нужные функции по управлению конфигурацией определенного мультиплексора, мы не сможем определить процессы и наборы данных. В итоге мы не сможем создать модель управления конфигурацией и соответствующие объекты, потому что не будем обладать знаниями о том, какая функциональность нам требуется. Говоря проще, мы не будем знать что, как и когда конфигурировать.
Еще одним важным аспектом информационной архитектуры является SMK - разделяемое понятие об управлении. SMK - это полностью разделяемое и синхронизируемое между различными объектами информационное пространство. SMK- это полный набор всех разрешенных к обмену данных между любыми двумя информационными элементами. Другими, словами каждый информационный элемент должен "знать" что можно "спрашивать" у других информационных элементов, и что нужно "отвечать" в ответ на запросы от других информационных элементов. Если возникает, ситуация, когда один элемент посылает стандартный "запрос" другому элементу TMN, а последний не может на него ответить, это говорит о том, что в информационной модели есть ошибка и отсутствует консистентность SMK.
Последним важным аспектом информационной архитектуры является понятие о модели взаимодействия.
Модель взаимодействия определяет роли функциональных блоков при обмене информацией. Рекомендация М3010 описывает две возможные роли для любого блока функций:
- роль агента, и
- роль менеджера.
При обмене информацией, менеджер является ведущим, а агент ведомым взаимодействующим блоком. Например, сервер системы управления в роли менеджера может посылать периодический запрос определенному мультиплексору на предмет предоставления данных о фоновых ошибках определенного 2М потока. Мультиплексор, в роли агента должен собрать необходимую информацию и передать ее на сервер в качестве ответа.
Вкратце рассмотрев три основные архитектуры TMN, нельзя не остановиться еще на двух важных составляющих.
Первая из них - это логическая многоуровневая модель TMN. Эта модель определяет взгляд на распределение функций управления TMN с точки зрения конечных потребителей, а если говорить точнее - с точки зрения операторов и провайдеров телекоммуникаций. Суть ее заключается в том, чтобы определить приоритеты построения системы управления согласно факторам административной и экономической целесообразности.

Иерархия уровней показана на рис. 2

Рис. 2 - Логическая архитектура TMN

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

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

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

Уровень управления бизнесом - самый высокий уровень логической иерархии. Реализация управления на этом уровне предполагает управление всем предприятием оператора (провайдера) в целом. Управление предприятием предполагает управление доходами от предоставляемых услуг, управление недвижимостью, финансами, людскими ресурсами и.т.д. Данный уровень управления может эффективно использоваться средним и высшим управляющим звеном предприятия.
Следует отметить эффективность подхода к построению логической многоуровневой иерархии. Каждый последующий уровень базируется на функциональности и информации предыдущего уровня, отбирая нужные сервисы предыдущего уровня и отбрасывая лишние.
Еще одной важной составляющей TMN, которая всегда присутствует при описании технологии TMN, является концепция областей управления. Концепция явилась результатом анализа потребностей сетевого управления операторов. Согласно концепции, все аспекты управления телекоммуникационной сетью могут быть описаны с помощью пяти областей управления, а именно:
- управление рабочими характеристиками сети;
- управление аварийными ситуациями на сети;
- управление (ре-)конфигурацией сети;
- управление расчетами (биллинг);
- управление безопасностью сети.
Согласно М.3010 предполагается, что вышеуказанные пять областей управления входят во все уровни управления логической иерархии TMN, однако присутствуют на каждом уровне в разных пропорциях. Действительно, если рассматривать уровень управления сетью, становится очевидным, что управление расчетами как область управления на данном уровне не нужна. Однако для данного уровня характерна сильная реализация управления рабочими характеристиками, управления аварийными ситуациями и (ре-)конфигурацией сети.
На основании вышеописанных областей строятся наборы функций и отдельные функции управления TMN, детально регламентирующие все процессы свойственные той или иной области.

Системы Управления Телекоммуникациями. Интерфейсы и Проблемы

Рассмотренная в предыдущей статье ("Что такое TMN?") общая архитектура TMN содержит еще один важный аспект, который должен рассматриваться отдельно, так как является наиболее существенной и проблемной частью TMN. Этот аспект называется интерфейсы.
Под интерфейсом в TMN понимается некоторый стандартизированный набор технологий, протоколов и алгоритмов предназначенных для осуществления взаимодействия между блоками функций. Как уже было упомянуто ранее, местом определения интерфейсов являются "ссылочные точки", причем каждый интерфейс получает название согласно своей дислокации. Таким образом, общее количество типов интерфейсов в технологии TMN равно пяти. Это интерфейсы Q, X, F, G, M соответственно определенные в точках q, x, f, g, и m* .
Наиболее важным среди этих пяти типов принято считать интерфейс Q, так как именно этот интерфейс на 90% определяет технологическую функциональность TMN. В рекомендациях МСЭ описанию данного интерфейса уделено очень много внимания. Он является наиболее проработанным практическим аспектом технологии TMN. Однако, не смотря на это (а возможно, и по причине этого) интерфейс Q является самой большой проблемой TMN-технологии. И именно интерфейс Q во многом предопределил то, что TMN на сегодняшний день воспринимается телекоммуникационной отраслью скорее как концепция, а не как технология. Не смотря на то, что рекомендации МСЭ являются фактическим стандартом для производителей телекоммуникационного оборудования, сами производители зачастую производят телекоммуникационные системы управления, которые используют фирменные технологии, частично поддерживающие или совсем не поддерживающие спецификации интерфейсов технологии TMN. В чем же причина?
Возможных причин много и среди них нельзя выделить какую-либо наиболее главную или важную. Скорее всего, падение популярности TMN, как технологии это результат целого ряда взаимосвязанных как объективных, так и субъективных факторов. В целях большей наглядности можно представить их в тезисном виде:
Причина 1. Технология TMN берет свое начало из теории, а не из практики. На этапе формирования TMN, большинство ее ключевых составляющих (языки, протоколы, детальные информационные модели) не были широко используемы и развиваемы в телекоммуникационной индустрии.
Причина 2. Технология TMN с технической точки зрения не проработана настолько, чтобы считаться законченной стандартизированной технологией, которую можно было бы реализовать на практике в виде конкретной законченной системы.
Причина 3. Существует более или менее стандартизированная адаптация TMN к применению на транспортных сетях SDH и сетях абонентского доступа ISDN (рекомендации серий G. и M.). Однако для других важных телекоммуникационных технологий (например, сети IP) детализированная адаптация TMN отсутствует.
Причина 4. Рекомендации, которые в своей совокупности должны давать полное представление о TMN, имеют довольно сложный для правильной интерпретации формальный язык написания с большим количеством перекрестных ссылок, что затрудняет как чтение, так и изучение рекомендаций.
Причина 5. Все рекомендации, имеющие отношение к TMN довольно сложным образом организованы в блоки и серии. Большая разбросанность и фрагментарность информации делают их трудными для понимания.
Причина 6. Техническое воплощение основных правил TMN регламентируется целыми наборами рекомендаций, которые не локализованы в серии М. и были разработаны в разные года разными группами специалистов. Соединить данные рекомендации в единое "смысловое поле" довольно сложно, ввиду того что основные цели, степень детализации и направленность отдельных рекомендаций далеко не всегда соответствуют проблематике создания систем управления телекоммуникациями.
Причина 7. В рекомендациях МСЭ проблема управления телекоммуникационными сетями с точки зрения реальных операторов, производителей и потребителей освещается настолько абстрактно и настолько не соответствует современным реалиям, что многие технологические решения, определяемые такой абстракцией, оказываются просто невостребованными и ненужными.
Причина 8. Многими экспертами реализация TMN-интерфейсов рассматривается неоправданно сложным и дорогостоящим делом. Считается что протокольные стеки регламентированные для Q-интерфейса являются слишком "перегруженными" и "тяжелыми". Также считается что верхние уровни модели OSI для данных протокольных стеков стандартизированы довольно слабо, являются довольно абстрактными и кроме того сильно усложнены по структуре и методам взаимодействия. Такая ситуация приводит к неоднородности интерпретации интерфейсов различными разработчиками. Чрезмерная сложность сказывается на надежности и цене программного обеспечения.
Причина 9. Наличие новых, более рентабельных, надежных и, что очень немаловажно, популярных коммерческих технологий, предоставляющих новые средства реализации интерфейсов, однозначно ослабляют позиции TMN.
Причина 10. Ощутимо медленное развитие, изменение и детализация TMN в соответствии с изменениями, происходящими в области компьютерной и телекоммуникационной индустрии

Список возможных причин можно было бы продолжить. Но, как известно из реальной жизни (в том числе истории развития телекоммуникаций), многие перспективные начинания не смотря на множество отрицательных факторов, все же нашли себе место под солнцем. Объяснением этому служит один простой фактор - объективная востребованность и "нужность". Проблема в том, что TMN оказалась ненужной, по крайней мере в своем оригинальном виде.
В конце 80-х годов, когда технология TMN еще только зарождалась, объективной потребности в "высокоинтеллектуальном" и, что немаловажно, интегрированном управлении сетями телекоммуникаций не было. Это диктовалось тремя факторами: политическим, экономическим и техническим. Политический фактор заключался в том, что в области телекоммуникаций, в большинстве стран мира, государство сохраняло монополию или обладало сильным влиянием на большинство телекоммуникационных ресурсов. Не существовало жесткой конкуренции на рынке телекоммуникаций, поэтому не было потребности в гибком управлении и совершенствовании средств управления телекоммуникациями (экономический фактор). Кроме того, телекоммуникационные средства и технологии не были еще настолько разнообразными, сложными и интеллектуальными для того, чтобы возникла потребность в TMN (в том понимании, в каком эта технология сейчас существует). В 1992 году с выпуском в свет дополнительных рекомендаций TMN приобрела очертания стандартизированной технологии в области телекоммуникационных систем управления. В качестве базовых TMN объявила следующие принципы:
· распределенность программных и технических средств (концепция распределенных вычислений);
· использование принципов "инкапсуляции" или "наложения" сетевых структур
· объектная ориентированность как основа для разработки программного обеспечения и информационного взаимодействия вычислительных систем;
· ролевая иерархическая модель взаимоотношений информационных компонент вычислительных систем (менеджер-агент, клиент-сервер);
· многоуровневость и блочность (объектность) протокольных стеков согласно модели OSI.

Нужно отметить, что все без исключения вышеуказанные принципы, которые были выдвинуты разработчиками еще в 80-х годах в качестве основы для построения систем управления, до сих пор являются актуальными и современными. Иными словами разработчикам TMN удалось каким-то образом предугадать, а во многом опередить развитие не только систем управления, но и телекоммуникационной индустрии в целом.
Однако обратимся к вопросу о технологиях, которые разработчики выбрали для реализации интерфейсов и информационных моделей. На момент создания TMN, у разработчиков был довольно скудный и не проверенный практикой ассортимент технологий. С точки зрения теории, выбор, например для семантического построения моделей GDMO с помощью декларативного языка ASN.1 является вполне обоснованным. Также является технологически обоснованной стройная модель организации интерфейсов по системе OSI. Функциональные протоколы и сервисы верхних уровней интерфейсов Q и X (CMIP, CMISE, ROSE и т. д.) также смотрятся на первый взгляд довольно проработанными и не менее обоснованными. Однако хорошая теоретическая обоснованность еще не является 100% залогом технического и коммерческого успеха. Так и случилось с основными составляющими технологии TMN, а именно с протоколом CMIP и моделями GDMO, построенными на синтаксисе ASN.1. Как уже было отмечено выше, на момент создания TMN, в телекоммуникационной индустрии не существовало большой потребности в высокоинтеллектуальных унифицированных сетевых системах управления. Когда же процессы либерализации индустрии телекоммуникаций во многих развитых странах внезапно и лавиннообразно подняли вопросы конкуренции - для TMN наступил первый момент проверки практикой. Конкуренция стимулировала небывалый рост сетей, появление большого количества новых технологий и как результат поиск более эффективных, централизованных и мощных средств управления. К середине 90-х годов сложилась такая ситуация, когда компьютерная индустрия начала продуцировать новые технологии объектных вычислений для среды географически и логически распределенных информационных ресурсов. Появились довольно дешевые и надежные коммерческие решения (например DCOM, CORBA, JAVA), которые почти сразу завоевали большую популярность. Разработка этих технологий велась давно, однако с развитием конвергенции и глобальных компьютерных сетей, эти технологии в силу своей практичности, простоты, доступности и большого ресурса адаптируемости, завоевали популярность и в мире "обычных" телекоммуникаций. В те годы любая компания-разработчик программных средств для систем управления, с гораздо большим энтузиазмом развивала уже прошедшие некоторую проверку практикой компьютерные технологии (JAVA, CORBA , TCP/IP), чем "нулевой" сложный и запутанный вариант со стандартными интерфейсами TMN. Поэтому, начиная примерно с 1998 г., во всех аналитических материалах по проблематике систем управления телекоммуникациями, сложилось общее мнение о наступлении кризиса "стандартной" TMN.
Чем же ответил на "кризис" основатель и главный разработчик TMN, а именно Международный Союз Электросвязи? С особым прискорбием можно сказать, что практически "ничем". Судить о реальных причинах прямо таки загадочной инертности МСЭ в вопросах управления телекоммуникациями не берусь. Возможно, бурное развитие новых технологий и такое же бурное устаревание старых и не оправдавших доверия технологий поставило в некоторый цейтнот исследовательские группы МСЭ. Возможно МСЭ, как и любая крупная бюрократическая организация не способна с такой же легкостью и гибкостью модернизировать TMN, интегрируя в нее новые более рентабельные технологии, как это делают менее формальные, а потому и более адекватные организации типа TMF (TeleManagement Forum). Вполне возможно, что причина кроется и в невыгодности унификации правил построения систем управления для отдельных крупных компаний-производителей, которые наряду с телекоммуникационным оборудованием поставляют еще и свои "бортовые" системы управления, которые реализованы на фирменных технологиях. Приобретая такие системы управления, оператор попадает в техническую, а затем и в финансовую зависимость от конкретной компании-производителя. Оператор будет просто вынужден платить довольно крупные деньги за каждый "апгрейд" системы управления, уже не говоря о том, сколько денег придется выложить за покупку лицензий исходных кодов программного обеспечения, если он вдруг захочет заняться интеграцией нескольких систем управления в одну.
Немного обнадеживает тот факт, что МСЭ в 2000 году все-таки выпустила новые версии рекомендаций М.3010 и М.3400. В дополнение к ним была выпущена еще и новая рекомендация под номером М.3013. Однако, ничего радикального ни в новых-старых рекомендациях, ни в новой М.3013 не наблюдается. Основных проблем они не решают. Если говорить более конкретно, то, к примеру, М.3010 немного упрощает именование интерфейсов (теперь вместо Qx и Q3 интерфейсов будет один - Q) и допускает к рассмотрению в рамках TMN (на определенных условиях, разумеется) новые технологии типа CORBA (что касается вовлечения в TMN новых технологий, то необходимость в этом уже, честно говоря, перезрела). Обращаясь к М.3013, скажем, что в ней авторы попытались дать связное описание TMN: что это такое, для чего это может понадобиться операторам и провайдерам, и как это поможет решить их проблемы. М.3013 также призвана дать более или менее интегрированное описание TMN как целостной системы с точки зрения ее конечного пользователя (имеются ввиду операторы и провайдеры). В общем, рекомендация конечно полезная, особенно для начинающих интересоваться проблематикой TMN, но для специалистов она не подставляет ровным счетом никакой ценности.
Не смотря на весь пессимизм ситуации, следует отметить тот факт, что сам МСЭ все теснее начинает сотрудничать с неформальными (но от этого не менее влиятельными) телекоммуникационными организациями для выработки жизнеспособных решений, которые могут быть включены в рамки TMN. Заметим, что и ожесточенные споры по поводу TMN, жив он/она или нет, практически прекратились. Наступило относительное затишье, а это значит - началась реальная работа.

Владимир Романцов,
специалист по телекоммуникационным системам управления